Accessibility fundamentals: bringing it all together

Accessibility hasn't been a separate topic in this series — it's been a recurring thread in nearly every part, because genuinely correct HTML is largely already accessible HTML. This part gathers everything already covered, then adds the pieces that still need direct attention: ARIA and keyboard navigation.

What's already been covered, gathered in one place

Part 3:  real heading hierarchy, one <h1>, no skipped levels
Part 4:  real <ul>/<ol>/<dl> instead of fake, manually-typed lists
Part 5:  real target="_blank" + rel="noopener noreferrer" discipline
Part 6:  genuine, descriptive alt text — not "image", not omitted
Part 7:  real semantic landmarks (header/nav/main/aside/footer)
Part 9:  real <th scope> in tables
Part 10: real <label for>/id association on every form field
Part 11: <fieldset>/<legend> grouping, aria-describedby for errors
Part 12: real <track kind="captions"> on video
Part 13: real, descriptive title on every <iframe>

This list is the honest reason accessibility was woven throughout rather than saved entirely for one part at the end — most of it is inseparable from simply using the right element for the right job, which has been this series' running theme since part 1.

ARIA: for the real gaps native HTML can't fill

<button aria-label="Close" onclick="closeModal()">&times;</button>

<div role="alert">Your cart has been updated.</div>

<button aria-expanded="false" aria-controls="mobile-menu">Menu</button>
<nav id="mobile-menu" hidden>...</nav>

ARIA (Accessible Rich Internet Applications) attributes exist specifically for cases native HTML doesn't have a built-in solution for — an icon-only close button with no visible text needs aria-label to have any real accessible name at all; a dynamically-appearing message (like a cart update) needs role="alert" to be announced automatically, since a screen reader doesn't re-scan the whole page on every change; a collapsible menu's real open/closed state needs aria-expanded for a screen reader user to know which state it's currently in.

Keyboard navigation: a real, separate check from screen reader support

Real check: unplug the mouse (or just don't touch it), and try to
  reach and activate every real interactive element on the page —
  every link, button, and form field — using only Tab, Shift+Tab,
  and Enter/Space

A genuinely large, real population of users navigate primarily by keyboard — not only visitors using a screen reader, but people with motor impairments who can't reliably use a mouse, and plenty of power users who simply prefer it. Native interactive elements (<a>, <button>, <input>) are keyboard-operable automatically, with no extra work — another real, concrete reason to prefer them over a <div> with a click handler bolted on, which receives no keyboard focus at all by default.

Focus order and visible focus indicators

<!-- wrong: removing the browser's default focus outline with no replacement -->
<style>
  a:focus { outline: none; }
</style>

<!-- correct: a real, deliberate, visible replacement -->
<style>
  a:focus-visible { outline: 2px solid #4fd1c5; outline-offset: 2px; }
</style>

Removing the default focus outline without providing a real, visible replacement is a common, damaging real mistake — it makes keyboard navigation genuinely unusable, since there's no visual indication of which element currently has focus. :focus-visible (a real, modern CSS selector) is worth knowing about even before this series reaches CSS in depth, specifically because this particular mistake is common enough to flag early.

A real, quick manual accessibility check

1. Tab through the entire page — does every interactive element get
   a real, visible focus indicator, in a sensible order?
2. Turn on a screen reader (VoiceOver on Mac, Narrator on Windows,
   both built in and free) and navigate the page by headings alone
3. Check every image has real alt text, and every form field has a
   real associated label

This three-step check, run against Bright Leaf Coffee's actual pages built across this series, is a genuinely useful real habit — not a full audit, but enough to catch the most common, most damaging real gaps before they ship.

Next: character encoding and HTML entities — getting special characters, accented text, and reserved symbols correct.