HTML Accessibility

Introduction

HTML accessibility engineering starts with semantic markup — not ARIA wallpaper on divs. Staff engineers ship pages where the accessibility tree is correct at parse time, keyboard paths work without JavaScript, and WCAG conformance is proven in CI before legal or users find failures.

Business problem

Business pressure: Accessibility overlay widgets and ARIA-heavy refactors cost millions yet fail audits. Root cause is usually HTML: unlabeled inputs, wrong headings, div buttons, missing lang.

• Legal: Domino's-style litigation targets operable markup failures.
• Revenue: 15-20% population excluded when checkout HTML blocks AT users.
• Brand: Public audit failures spread on social — trust damage exceeds fix cost.

Why this feature exists

Platform motivation: HTML semantics were designed with accessibility hooks — headings, labels, button, native focus — before ARIA existed.

• History: table layouts → div soup → semantic HTML5 revival → ARIA 1.2 complement rules.
• Alternative rejected: Parallel "accessible version" site — maintenance nightmare, unequal experience.
• Modern role: First rule of ARIA — don't use ARIA if native HTML suffices.

Browser internals

Accessibility tree: Built from DOM + computed accessible name/role/state. HTML tags map to platform roles — button, heading, link — without ARIA.

• Parser: Missing labels break name computation for inputs at DOM creation.
• DOM: aria-hidden on wrong ancestor nukes subtree for AT.
• Script impact: Client-rendered widgets must preserve semantic HTML shell for no-JS baseline.

Rendering workflow

Visual vs a11y order: CSS grid reorder can decouple visual from DOM order — screen reader order follows DOM unless aria-owns (complex). Fix in HTML structure first.

• Critical path: Skip link and h1 early in DOM benefit AT navigation immediately.
• Layout: focus-visible styles must not be removed in reset CSS on semantic controls.
• Paint: prefers-reduced-motion in HTML media features for video/autoplay decisions.

Feature deep dive

HTML accessibility engineering checklist: lang, title, h1-h6 hierarchy, landmark regions, labeled forms, button vs div, alt text, table headers, caption, focusable interactive elements, live regions only when needed.

• Name, role, value: Native elements provide most; ARIA fills gaps.
• Keyboard: Tab order follows meaningful sequence; no positive tabindex except rare manage-focus cases.
• Testing: axe + keyboard + SR + users with disabilities.

<form>
  <fieldset>
    <legend>Shipping address</legend>
    <label for="ship-street">Street</label>
    <input id="ship-street" name="street" autocomplete="street-address" required>
    <label for="ship-zip">Postal code</label>
    <input id="ship-zip" name="zip" autocomplete="postal-code" inputmode="numeric">
  </fieldset>
  <button type="submit">Save address</button>
</form>

Accessibility analysis

Deep a11y analysis: Map each WCAG failure to HTML-first fix before ARIA. Document focus management for full-page vs in-page updates.

• Screen readers: Test heading navigation and landmark shortcuts — NVDA H / D keys.
• Keyboard: No keyboard trap in modals — use dialog element with focus trap JS or native.
• WCAG 2.2: Focus not obscured, target size, accessible authentication — HTML form choices matter.

SEO impact

SEO overlap: Semantic headings and alt text help crawlers and AT — aligned incentives, not trade-off.

• Crawl: nav in semantic lists improves structure understanding.
• Rich results: Accessible product markup often matches Product schema needs.
• Core Web Vitals: Skip link and landmarks don't hurt perf — benefit UX broadly.

Security considerations

Security + a11y: CAPTCHA alternatives required — puzzle-only blocks AT users and fails WCAG; use token-based or honeypot with care.

• XSS: Injected script can hijack focus and spoof AT announcements — sanitize.
• CSP: Overlay scripts often violate CSP and a11y — double failure.
• Phishing: Accessible phishing is still phishing — teach safe link text patterns.

Performance impact

Perf: Accessibility fixes in HTML rarely hurt perf — semantic elements are lighter than ARIA + JS widgets.

• LCP: Meaningful alt on LCP image — required for perceivable LCP.
• INP: Native button faster than div + role + keydown handler.
• CLS: Consistent focus rings don't cause layout shift if designed in outline offset.

Real production example

Production pipeline: PR → jest-axe → pa11y-ci on static HTML → manual SR spot check on release candidates.

// jest-axe example
const { axe } = require("jest-axe");
test("checkout fragment", async () => {
  const html = await renderCheckout();
  expect(await axe(html)).toHaveNoViolations();
});

Enterprise usage

Enterprise: VPAT/ACR documents cite HTML patterns used; procurement requires axe CI evidence on design system releases.

• Design system: Components document accessibility tree and required HTML attrs.
• CMS: WYSIWYG allowlist tags; authors cannot strip headings or labels.
• CI gates: Block merge on serious/critical axe in HTML snapshots.

Common production failures

What breaks in prod: "Accessible" redesign used aria-label on div buttons — keyboard users could not activate on iOS VoiceOver.

• Incident: Missing lang attribute — screen reader wrong pronunciation on global launch.
• Legal: Form placeholders only — lawsuit settlement required native labels.
• Perf regression: Accessibility overlay JS — INP regression plus still failing audit.

Architecture review questions

• Does every input have associated label or accessible name?
• Is heading hierarchy logical with one h1?
• Are interactive elements native button/a with keyboard support?
• Is lang set on html element?
• Did you use ARIA only where HTML cannot express semantics?

Hands-on project

Project: Remediate provided inaccessible HTML checkout to WCAG 2.2 AA — zero critical axe, keyboard recording, SR notes.

• Deliverable: semantic HTML only; minimal ARIA justified in comments.
• Verify: pa11y-ci pass; peer keyboard test.
• Stretch: Write VPAT-style paragraph for one component.

Interview questions

Try it yourself

Edit the HTML, CSS, or JS panels — the preview updates as you type.

Summary

HTML accessibility engineering prioritizes semantic structure, labeled forms, keyboard-native controls, and CI-verified WCAG conformance — ARIA supplements but never replaces correct markup.