Back to HTML for JavaScript Developers: Build the Bones

Accessibility & HTML That Speaks

I used to think accessibility was optional—something you added later if you had time or budget. That was a mistake. It’s not a feature. It’s the foundation. The moment I watched someone navigate my site with just a screen reader and keyboard, I realized how much I’d been leaving people out. No amount of pretty CSS can fix HTML that ignores real-world users. So in this lesson, we’re focusing on making our project speak, listen, and respond like a pro—no flashy JavaScript needed, just thoughtful HTML.

The Screen Reader’s Perspective

Imagine your website, but with your eyes closed. That’s what screen reader users experience. They rely entirely on semantic structure, landmarks, and meaningful text to navigate.

Here’s the good news: if you’ve followed this course so far and used proper tags (<header>, <nav>, <main>, <section>, <footer>, etc.), you’ve already helped a ton. But there’s more.

Use headings intentionally. Screen readers often scan a page by jumping through heading levels. Skipping from <h1> to <h4>? That’s like going from chapter 1 to chapter 7 with no warning. Keep your structure logical:

html
1
2
3
4
          <h1>About Me</h1>
  <h2>Work Experience</h2>
    <h3>Frontend Developer</h3>
  <h2>Education</h2>

Also, don’t forget the almighty <alt> tag. Screen readers do read it—when it's written well. “Screenshot 2021-08-10” isn’t helpful. “Smiling portrait of Jane Doe, frontend developer” is.

Bonus? Use a free screen reader (like NVDA) or built-in macOS VoiceOver to test your project. It's humbling in the best way.

Tab Order, Roles, and Landmarks

Keyboard users—whether due to mobility issues or just preference—navigate with the Tab key. Your HTML defines the order things get focus.

Here’s what matters:

  • Don’t mess up natural tab order. If you avoid tabindex abuse and stick to semantic HTML, the browser handles this just fine.
  • Use landmarks. Tags like <main>, <nav>, and <aside> aren’t just for structure—they let screen readers skip directly to key areas.
  • Don’t forget ARIA—but don’t overuse it. The first rule of ARIA? *Don’t use ARIA if you can do it with native HTML.

That said, ARIA roles like role="alert" or role="dialog" can be helpful when you're building complex interfaces. For our static project? Stick to semantic tags unless you absolutely need something extra.

Keyboard First: Test Like a Pro

Want to catch 80% of accessibility issues in 2 minutes? Unplug your mouse and navigate your site with just the keyboard.

  • Can you reach every link, button, and form field?
  • Can you see where you are (focus outline!)?
  • Can you submit a form and interact with any dropdowns or modals?

If the answer to any of these is “no,” your users will struggle too. And if you’ve ever hit Tab 15 times just to find the nav? You know the pain.

Pro tip: don’t remove focus outlines unless you replace them with something better. Seriously. They exist for a reason.

Let’s Improve the Contact Page

Let’s revisit the contact form from the last lesson and tighten it up with accessible touches:

html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
          <main>
  <section aria-labelledby="contact-heading">
    <h1 id="contact-heading">Contact Me</h1>
    <form action="/contact-submit" method="post">
      <label for="name">Name</label>
      <input type="text" id="name" name="name" required aria-required="true">

      <label for="email">Email</label>
      <input type="email" id="email" name="email" required aria-required="true">

      <label for="message">Message</label>
      <textarea id="message" name="message" rows="5" required aria-required="true"></textarea>

      <button type="submit">Send</button>
    </form>
  </section>
</main>

We’ve added aria-labelledby to describe the section, and aria-required for clarity (though it’s redundant with required, it can help with older assistive tech). This is subtle, thoughtful markup—and it matters.

What’s Next?

Your site can now speak, listen, and respond—all with pure HTML. Next up, we clean house. Let’s validate your HTML, catch sneaky errors, and make your markup bulletproof. If it’s going to live on the internet, it better be solid. Onward to Validating, Cleaning & Prepping Your HTML for the Real World.