Goal
You’ll understand why accessibility genuinely starts with HTML choices, not CSS or JavaScript add-ons, and be able to identify the specific HTML decisions from earlier Parts that were actually accessibility decisions all along.
Learn
A common misconception is that accessibility is primarily a CSS concern (color contrast, font sizing) or something bolted on afterward with ARIA attributes. In reality, most of the accessibility foundation comes directly from correct, genuine HTML choices — many of which you’ve already learned in this course without necessarily labeling them “accessibility”:
- Using real heading levels correctly (Part 1.3) lets screen reader users navigate a page by jumping between headings, understanding its outline instantly.
- Meaningful alt text (Part 2.2) makes image content available to users who can’t see the image at all.
- Semantic layout elements (Part 2.3) let screen reader users jump directly to page regions like main content or navigation.
- Properly connected labels (Part 3.1) make form fields genuinely usable with assistive technology, not just visually clear.
This is the genuinely important insight: a page built with correct, semantic HTML throughout is already substantially accessible before any dedicated “accessibility work” begins — because accessibility was baked into the structural decisions from the start, not added as a separate late-stage layer. ARIA (covered in the next lesson) exists to handle the genuine gaps HTML alone can’t cover, not to compensate for HTML that was written carelessly in the first place.
Decision Task
A developer builds an entire page using only <div> elements with CSS classes for every single piece of content — headings, navigation, buttons, everything — planning to “add accessibility later” using ARIA attributes. Before reading on: is this a sound strategy?
Show Answer
No — this creates far more accessibility work than necessary, and some of it can’t be fully recovered with ARIA alone. Using genuine semantic HTML elements from the start (real headings, real nav, real buttons) provides built-in accessibility behavior automatically; trying to recreate all of that later with ARIA on generic divs is both more work and often produces a worse, more fragile result than using the correct native element would have from the beginning.
Common Mistake
Treating accessibility as a separate, later phase of development rather than a natural outcome of writing genuinely correct, semantic HTML throughout the build process. This backwards approach usually means retrofitting ARIA attributes onto generic markup that should have used real semantic elements from the start, producing more fragile, harder-to-maintain code than building it correctly the first time.
Practice Questions
1. Name two specific HTML decisions from earlier Parts of this course that were genuinely accessibility decisions, even though they weren’t explicitly labeled as such at the time.
Show Answer
Any two of: correct heading levels (Part 1.3), meaningful alt text (Part 2.2), semantic layout elements (Part 2.3), connected form labels (Part 3.1).
2. Why is “build with divs first, add ARIA later” generally a worse strategy than using semantic elements from the start?
Show Answer
It creates more total work recreating behavior that semantic elements provide automatically, and the result is often more fragile and harder to maintain than genuinely correct HTML would have been from the beginning.
3. What specific accessibility benefit does correct heading structure provide to screen reader users?
Show Answer
It lets them navigate the page by jumping directly between headings, quickly understanding the page’s outline/structure without reading through all the content linearly.
4. True or False: a page built entirely with correct semantic HTML is already substantially accessible before any dedicated “accessibility pass” begins.
Show Answer
True — this is the core insight of this lesson: much of accessibility comes from correct structural choices made throughout normal development, not a separate late-stage layer.
5. What is ARIA genuinely meant to address, according to this lesson’s framing?
Show Answer
Genuine gaps that native HTML alone can’t cover — not a general-purpose fix for HTML that was written carelessly or non-semantically in the first place.
Try It Yourself
Looking back across Parts 1-4 of this course, pick one specific lesson’s content and explain, in your own words, exactly how it was actually teaching an accessibility principle, even though it wasn’t framed that way at the time.
This is an open, ungraded reflection exercise — there is no single correct answer to reveal.
Quick Check
1. Is accessibility primarily a CSS concern, or does it genuinely start with HTML choices?
Show Answer
It genuinely starts with HTML choices — correct semantic structure is the real foundation.
2. Give one example of an earlier lesson in this course that was also teaching an accessibility principle.
Show Answer
Any of: heading structure, alt text, semantic layout elements, connected form labels.
3. What’s the risk of planning to “add accessibility later” via ARIA rather than using semantic HTML from the start?
Show Answer
More total work, and often a more fragile, harder-to-maintain result than correct HTML would have provided automatically.
4. What is ARIA meant to address, according to this lesson?
Show Answer
Genuine gaps native HTML can’t cover — not a fix for carelessly written, non-semantic HTML.
5. Why might a page built with correct semantic HTML already be substantially accessible before dedicated accessibility work begins?
Show Answer
Because many accessibility behaviors (navigation by heading, region jumping, label announcements) come built-in with correct semantic elements, requiring no additional work.