The Reality Check You Need

Let me be honest from the start. If you’re looking for another series of “learn to code in 21 days” tutorials that give you false confidence, this isn’t it; this is going to be a long ride where I aim to cover as much as I possibly can. It’s frustrating that with all the resources available today, there’s still no comprehensive, practical guide that actually prepares you to be a real developer.

Here’s the typical developer journey that needs to change:

The Broken Education Path

• Start with outdated college courses taught by professors who last coded when JavaScript was optional
• Get surrounded by peers who memorize data structures but can’t explain why their shit breaks on prod
• Read inspiring success stories about developers who “made it big” with their revolutionary to-do app
• Search for tutorials where they teach you with pre-written code, ready to copy-paste their way through a 20-minute “build a full-stack app” video
• Read about getting out of this “tutorial hell”, but can’t because you’ve no idea what to build or where to even begin

The Problem

Most tutorials teach you to copy, not to understand. They show you the “what” but skip the “why”. They give you a false sense of progress without building real competence.

I’m here to (at least try to) fix that gap. This SMM series assumes you got a brain or 2 up there, but starts from absolute basics. We’ll build your understanding progressively, covering everything from HTML to scalable systems, from web development to blockchain and AI/ML, yada yada, you name it. I understand that there might be a thing or two that I forget to teach, but just feel free to reach out to me in any of my socials and let me know, I’ll update it quickly!

What You’ll Get

• Real understanding, not just surface-level knowledge
• Practical skills that work in production environments
• Industry context that bootcamps and colleges skip
• The kind of deep knowledge that separates good developers from great ones

Whether you’re completely new to development or have some experience, this series will fill the gaps in your knowledge. I promise you’ll learn something valuable, even in topics you think you already know.

Let’s start with the foundation every developer needs to understand.

The Foundation

Let me address some of you first who might be wondering: “I’m not trying to be a web developer, why do I need HTML?”

Because I’m not writing this series for developers who only learn what they absolutely need. I’m writing for those who want to stand out, who understand that comprehensive knowledge creates better developers. And yes, HTML won’t make you stand out obviously, but it’s a start. For those still staying around, here’s a cookie 🍪, love you

Why Browsers and HTML Matter

Let’s start with browsers (those applications you probably have 47 tabs open in). Firefox, Chrome, Safari, Edge…the glorified document viewers.

When the internet was young (it still is, TBH), there was an obvious need: how do you share information across different computers with different operating systems, different hardware, different everything? The World Wide Web emerged as the solution, but it needed a common language for information exchange.

Browsers became the translators. They take structured documents and render them consistently across vastly different systems. They parse code, interpret its meaning, and present it as something humans can understand and interact with.

But why HTML specifically? Why not some other technical format?

Think about it: browsers aren’t mind readers. They need explicit instructions, but those instructions also need to be human-readable and maintainable. HTML strikes that balance. It’s semantic (meaning it describes what things are, not just how they look), readable, and purposeful. A <p> tag clearly means “paragraph,” a <header> tag clearly means that it’s for…a header, you get the point. It’s direct communication.

Clearing Up a Common Misconception

Before we go further, let’s address this directly: HTML is not a programming language. It doesn’t execute logic or perform calculations. HTML is a markup language, it structures and labels content. It’s descriptive, not instructive.

“So why not just use a real programming language instead?” Great question. HTML serves a different purpose. It’s designed to describe document structure and meaning, which browsers can then interpret consistently. Programming languages would overcomplicate this simple need.

Even if you never touch web development directly, understanding how information is structured and presented digitally is fundamental. Skipping this foundation leads to problems later.

Accessibility and SEO

What are these terms?

• Accessibility means your content works for everyone, including people using screen readers, those who navigate with keyboards only, users with visual impairments, or anyone using assistive technologies. HTML was designed with this in mind. Using proper semantic elements like <button> instead of generic <div> tags isn’t just good practice; it’s essential for inclusive design.
• SEO is how search engines understand your content. Google and other search engines parse your HTML to determine what your page is about and how it should rank in search results. If you use a <div> instead of a <footer> for your web page’s footer, search engines can’t understand your content structure properly. Poor HTML structure leads to poor search visibility. Your content would be as lost as you are in life right now.

File Extensions

Let’s address something fundamental that’s often overlooked—file extensions. You’ve seen them everywhere: .mp3, .jpg, .pdf, .exe, .zip. These aren’t decoration for your ugly pc; they’re tags that tell your computer exactly what type of file it’s dealing with.

The .html extension works the same way. When you see index.html, that extension tells the browser: “This is an HTML document. Parse it accordingly.” The browser recognizes the extension and knows exactly how to process the content inside.

This naming convention is what allows your browser (or any other software) to distinguish between different file types and handle them appropriately. No extension or wrong extension would obviously mess things up badly.

The Anatomy of Every HTML Document

Think of an HTML document like a building, it needs a solid foundation and clear structure. Every webpage follows the same basic blueprint.

Here’s the standard HTML document template you’ll encounter almost everywhere:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Your Stupid Page Title</title>
  </head>
  <body>
    <h1>Your stupid text.</h1>
  </body>
</html>

Let’s break down each component and understand why it matters:

DOCTYPE Declaration

<!DOCTYPE html> is actually a document type declaration. This single line prevents a world of pain by telling the browser to use modern HTML5 standards.

Without this declaration, browsers (especially older ones) might enter quirks mode, essentially reverting to how they behaved in the early 2000s. This means:

• Inconsistent rendering across browsers
• Broken layouts and styling
• Unpredictable behavior with modern CSS

Browsers these days operate in three modes:

• Standards mode: Modern, consistent rendering (what you want)
• Quirks mode: Legacy behavior from the IE6 era (what you want to avoid)
• Almost standards mode: Mostly modern with some legacy quirks

The DOCTYPE ensures standards mode. Always include it.

And be fortunate that HTML5 simplified this. Previous versions required complex declarations like:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

I don’t even understand that shit. HTML5’s simple <!DOCTYPE html> declaration is much easier to remember.

The HTML Root Element

<html lang="en"> is the root container that wraps all content on your page. The lang="en" attribute serves multiple important purposes:

Accessibility: Screen readers use this information to pronounce content correctly. If your content is in English but you don’t specify this, screen readers might use incorrect pronunciation rules.

SEO: Search engines use language information to serve your content to the right audience and understand context.

Browser behavior: Some browsers adjust typography and text rendering based on the specified language.

The lang attribute is just one example of HTML attributes; they’re additional properties that provide extra information about elements. Another attribute for the <html> element, for example, is:

• dir="rtl" for right-to-left languages like Arabic or Hebrew
• dir="ltr" for left-to-right languages (the default)

Understanding Tags vs. Elements

Before diving deeper, let’s clarify some terminology. In HTML:

• Tags are the markup syntax: <head>, </head>, <meta>
• Elements are complete structures: <head>...</head> with its content (you can, in a way, say that tags + content = elements)
• Attributes are additional properties: lang="en", charset="UTF-8"

Most HTML elements need both opening and closing tags (<head> and </head>), while some are self-closing (<meta />, <br />).

How About Some Head?

<head>...</head> contains metadata (information) about your document that isn’t displayed to users but is crucial for browsers, search engines, and other tools. Think of it as your document’s configuration section.

Character Encoding: <meta charset="UTF-8" />

This meta tag specifies your document’s character encoding. UTF-8 is a character encoding standard that can represent any character in the Unicode standard. Essentially, it can handle any text from any language, plus emojis and special symbols.

Why is this important? Without proper character encoding declaration:

• Special characters might display as � symbols
• Non-English text could render incorrectly
• Emojis and symbols might break

UTF-8 has become the web standard because it’s backward compatible with ASCII and can handle international content seamlessly. This link contains a good explanation of ASCII and UTF-8:

Everything in a computer is a number. If we want to have letters in computers, we need to all agree on what number corresponds to what > letter, this is called “character encoding”.

The simplest encoding is called ASCII. In ASCII, A is 65, B is 66, & is 38. ASCII characters are stored using only 7 bits, which means there’s only 27=128 characters possible.

ASCII works fine for encoding basic English/Latin characters, but there’s way more than 128 characters in the world! Unicode is the name of a system that supports up to 1,112,064 characters, which includes letters from every major alphabet, and lots of other characters like math symbols, emojis and more.

But now there’s the question of how do we store these characters, how big does the “number have to be”. UTF-32 is a character encoding that uses one 32 bit number for each character. This makes a lot of sense, but it wastes a lot of space. Why do we need a number big enough to hold 1,112,064 values, when most of the time we’re only going to use the first 128 values.

UTF-8 is a “variable length encoding”. That means a lot of the time, each character only takes up 8 bits, but it can expand to up to 32 bits if necessary. This system can support any Unicode character without wasting space, which has made it the most popular character encoding.

Now as for how this relates to webpages, when your browser gets a webpage from a server, it needs to know which encoding to use. If you don’t specify anything, most browsers will default to ASCII. This is usually fine, since all characters required for html like < can be written in ASCII, and you can add special Unicode characters to your HTML by writing things like &#x2660.

But if you want to include Unicode characters right in your code, then the file will be saved as UTF-8, and you will need to include a header or meta tag to tell your browser the right way to read your file.

Hope that was helpful!

Viewport Configuration

“<meta name="viewport" content="width=device-width, initial-scale=1.0" />” is arguably one of the most important meta tags. It controls how your page appears on mobile devices. And no, this alone does not make your website responsive to smaller screens, but it’s a step towards it.

Let’s break down each part:

• name="viewport": Tells the browser we’re configuring viewport settings
• width=device-width: Sets the viewport width to match the device’s screen width
• initial-scale=1.0: Sets the initial zoom level to 100% (no zoom)

Without this tag, mobile browsers assume your site was designed for desktop and zoom out to fit the entire page on the small screen, making everything tiny and unreadable.

Page Title: <title>Your Page Title</title>

The title element defines:

• What appears in the browser tab
• The default bookmark name when users save your page
• The clickable headline in search engine results
• What screen readers announce when the page loads

Write descriptive, concise titles that clearly indicate the page’s purpose.

Additional Head Elements

While not in our basic template, other important head elements include:

• Favicon: The small icon that appears in browser tabs

<link rel="icon" href="/favicon.ico" type="image/x-icon" />

• Description meta tag: Used by search engines for result snippets

<meta name="description" content="A clear, concise page description" />

The Document Body

<body>...</body> contains all the visible content users interact with (texts, images, buttons, videos, forms, and everything else that makes up your user interface).

Inside the body, HTML elements can be nested within each other, creating a hierarchical structure. The entire HTML document is built on this nesting concept: <body> nested inside <html>, paragraphs nested inside <body>, and so on.

Not all body tags are created equal. They fall into two main categories:

• Semantic tags: Elements that describe their content’s meaning and purpose (<header>, <nav>, <article>, <button>)
• Non-semantic tags: Generic containers with no meaning (<div>, <span>)

This distinction matters for accessibility, SEO, and code maintainability.

HTML has over 100 different tags, but rather than memorizing them all, it’s more important to understand the principles behind proper HTML structure. Let’s focus on the most important categories and when to use them.

First, let’s get the non-semantic ones aside:

• <div>: You’ll come across this a lot. If you see this or <span> one too many times used within an HTML page, take pride in the fact that you’ll know more HTML than him/her by the end of this article. These tags exist for a reason, but you don’t just use them everywhere freely. It does not have any meaning, so, technically, it can be used to contain anything. Any kind of text, image, or another tag, whatever. It’s generic. But that doesn’t mean it should be everywhere. You should avoid using them. These tags exist when the content/data that’s to be fit inside can’t be used anywhere else, or for layout purposes, as you’ll learn when we get to CSS in the next article.
• <span>: Just like how <div> is a generic container, <span> is a generic inline container. When you use <div>, it “breaks” lines, meaning that it’ll display the contents in the next line. It isn’t the case with <span>. It will display the content in the same line. Tags like <p>, <div>, etc. break the line before as well as after the content, while tags like <span> do not break any lines at all by default, while there are tags like <br />, which break the line only after (not before).

Consider this example:

Code:

<!DOCTYPE html>
<html>
  <head>
    ...
  </head>
  <body>
    <p>This is a paragraph tag.</p>
    <p>This is another paragraph tag.</p>

    <div>This is a div block.</div>
    <div>This is another div block.</div>

    <br />

    <span>This is a span.</span>
    <span>This is another span.</span>

    <div>
      <span>Span inside a div</span>
      <span>Another span inside the same div</span>
    </div>

    <p>
      Span with a break: <span>This is inline</span><br />
      <span>But this is on a new line because of br.</span>
    </p>
  </body>
</html>

Output:

This is a paragraph tag.
This is another paragraph tag.

This is a div block.
This is another div block.

This is a span.This is another span.

Span inside a divAnother span inside the same div

Span with a break: This is inline
But this is on a new line because of br.

For layout and stuff, some of the important tags could be

• <header>...</header>: This goes for any content that resides in the top part of the page.
• <nav>...</nav>: Pretty self explanatory, our whole navigation bar goes here. After users look at your horrible website, you would want to show the link to the support and therapy page. You would typically do that here.
• <main>: Again, all these tags are self explanatory. This is where the main content of our page goes.
• <section>: You’d use this to divide your content into logical sections, like contact information would all be one section, while your CTA buttons and stuff would be inside another section. They aren’t related, so they wouldn’t be in the same section. Simple as that.
• <article>: Blogs, articles, news, yada yada. If the thing can stand alone and be shared, use this.
• <aside>: Sidebar content (ads, widgets, stuff like that that no one really looks at). Don’t put important content here.
• <footer>: Bottom stuff (credits, contact info, etc.). Marks the end of the page. Google knows it. Screen readers know it. You should, too.

These are some of the semantic tags. They’re meaningful, and their names indicate what they’d be used for. They help both in accessibility and SEO. Like, <header> could help indicate to a screen reader where the page is starting from, <nav> would indicate to search engines where our navigation bar is, etc.

For text content and stuff, some tags could be

• <h1>, <h2>, ..., <h6>: Headings. Hierarchy. Again, no need for me to go in depth, as they’re pretty self explanatory. <h1> is the main heading, the headings’ heading. Typically, you’d want to use only one <h1> per page. It’s for the biggest heading. As the number increases and goes from 1 to 6, the importance of the heading decreases.
• <p>: Use it for paragraphs.
• <strong>: For some important text. Screen readers say it louder. Also helps with emphasis in SEO.
• <em>: Emphasized text (usually italic).
• <br />: As already explained, it’s job is to break lines.
• <hr />: It displays a horizontal line. It’s for dividing content visually. Kind of outdated but whatever, it still works.

For media purposes, some tags are

• <img>: Used for images.
• <video>: Self-explanatory, used to add videos. You can add controls, autoplay and stuff like that.
• <audio>: Used for audio files. Good for podcasts, music previews, etc.

And then there are interactive elements, like

• <a>: You use this anchor tag for links.
• <button>: Buttons for when you want to perform certain actions (like, when an element is clicked on). Helps accessibility.
• <input>, <select>, <textarea>, etc.: Form fields. Little things you use to let the user enter stuff like email, password, etc.

Obviously I am not going to go through all of them because there are way too many tags, but my point here is, there are tons of tags which are created for specific purposes. SEO and accessibility rely on them. So, be helpful for once and use them instead of spamming <div> every chance you get just because it’s easier. It’s really not.

Accessibility: Building for Everyone

Understanding A11Y

What even is A11Y? It stands for accessibility (‘a’ + 11 letters + ‘y’). It’s similar to how i18n represents internationalization. As already explained, accessibility means building websites that work for everyone, regardless of their abilities or the tools they use to browse the web. This fundamental question should guide every development decision:

Can everyone, regardless of their physical capabilities, technical setup, or browsing method, use your website effectively?

Who benefits from accessible design?

• Users with visual impairments who rely on screen readers
• People with motor disabilities who navigate using keyboards only (lazy shits like me fall into this category as well 💔)
• Users with cognitive disabilities who need clear, consistent interfaces
• People with hearing impairments who need visual alternatives to audio
• Anyone using assistive technologies
• Users in challenging environments (poor lighting, noisy spaces, slow connections)

Accessibility isn’t optional, it’s a fundamental requirement for inclusive web development. And beyond being the right thing to do, accessible websites provide better user experiences and typically perform better in search engines. It’s a win win for everyone.

Practical Accessibility Implementation

Semantic HTML First

This is your foundation. Semantic HTML elements communicate meaning to both browsers and assistive technologies.

Poor approach:

<div onclick="handleClick()">Submit</div>

Better approach:

<button type="submit" onclick="handleClick()">Submit</button>

The button element automatically provides keyboard support, screen reader announcements, and clear semantic meaning.

Meaningful Alt Text for Images

Every image needs alternative text that describes its content and purpose. This helps when images fail to load and provides essential context for screen reader users.

What not to do:

<img src="chart.png" />

What to do:

<img
  src="chart.png"
  alt="Image displaying that sales revenue increased 40% from Q1 to Q2 2024"
/>

Write alt text that conveys the image’s essential information, not just its appearance.

ARIA (Use Sparingly and Correctly)

ARIA (Accessible Rich Internet Applications) attributes provide additional semantic information when HTML alone isn’t sufficient.

<div role="button" aria-pressed="false" tabindex="0">Toggle</div>

Critical rule: ARIA supplements semantic HTML; it doesn’t replace it. If a semantic HTML element exists for your use case, use that instead of ARIA.

No ARIA is better than bad ARIA.

– APG themselves

Keyboard Navigation Support

Many users navigate websites using only a keyboard. Your interface must support this interaction method completely.

Essential keyboard behaviors:

• Tab moves through interactive elements logically
• Enter or Space activates buttons and links
• Escape closes modals and overlays
• Arrow keys navigate within components (like menus)

Never trap keyboard focus without providing an escape route.

Color Contrast Standards

Ensure sufficient contrast between text and background colors. Poor contrast makes content difficult or impossible to read for users with visual impairments or anyone in bright lighting conditions.

Use tools like WebAIM’s contrast checker to verify your color choices meet accessibility standards.

WCAG AA requirements:

• Normal text: minimum 4.5:1 contrast ratio
• Large text (18pt+ or 14pt+ bold): minimum 3:1 contrast ratio

Proper Form Labels

Forms are critical interaction points that often have terrible accessibility. Every form input needs a proper label.

Inadequate approach:

<input type="text" placeholder="Your Name" />

Accessible approach:

<label for="name">Your Name</label>
<input type="text" placeholder="Your Name" />

Why Do Labels Matter?

• Screen readers announce the label when users focus the input
• Labels remain visible even when the input has content (unlike placeholders)
• Clicking the label focuses the input, providing a larger click target

User-Controlled Media

Auto-playing videos or audio can be disorienting and problematic for users with screen readers, attention disorders, or limited bandwidth.

Best practices:

• Never auto-play videos with sound
• If you must auto-play, keep it muted with visible controls
• Always provide pause/stop controls
• Include captions for videos with spoken content

Exceptions obviously exist, but try to avoid it where possible.

Hierarchical Headings

Use heading elements (<h1> through <h6>) to create a logical document outline. Screen readers use this structure to help users navigate content efficiently.

Proper heading hierarchy:

<h1>Main Page Title</h1>
<h2>Major Section</h2>
<h3>Subsection</h3>
<h4>Sub-subsection</h4>

Don’t skip heading levels or use headings just for visual styling.

Visible Focus Indicators

The default focus outline (often a blue border) shows keyboard users where they are on the page. Removing this without providing an alternative breaks keyboard navigation.

If you customize focus styles, ensure they’re clearly visible and have sufficient contrast with the background.

Key Takeaways

HTML forms the foundation of everything you’ll build on the web. These fundamentals (semantic markup, proper document structure, and a11y, etc.) will help you greatly later on. It’s not about just knowing proper HTML, it’s about creating a mindset where you consider your user base thoroughly while creating your product. The concepts we’ve covered here will serve you throughout your entire development career, even if you don’t ever write HTML again.

What’s Next

This is just the beginning. In upcoming articles, I’ll dive into CSS for styling and layout, JavaScript for interactivity, and eventually full-stack development concepts. Each builds on this previous article’s foundation.

For now, practice what you’ve learned. Create simple HTML pages, experiment with different semantic elements, and test your pages with accessibility tools.

If you found this helpful, you’re ready for the next part of the SMM series. We’re building comprehensive developer knowledge step by step, the kind of deep understanding that creates truly skilled developers.

See you soon, stranger :)