Accessibility ensures people using keyboards, screen readers, voice control, or situational limitations can complete real tasks—not an optional polish layer.
HTML responsibilities
- Correct heading hierarchy and landmarks.
- Labels tied to every form control.
- Visible focus outlines unless replaced with equally clear indicators.
- Text alternatives for non-text content.
- Motion sensitivity (
prefers-reduced-motion) coordinated via CSS.
ARIA bridging
Use aria-* when no native element expresses your widget—but implement keyboard patterns from WAI-ARIA Authoring Practices.
Testing
- Automated scanners catch ~30% of issues.
- Manual keyboard walks and screen reader spot checks remain mandatory.
Legal context
Many jurisdictions reference WCAG for compliance—translate standards into concrete acceptance criteria per feature.
Often skipped manual tests
- 200% zoom + reflow: text must not truncate critical actions.
- Reduced motion: vestibular issues from parallax—honor user preference.
- Voice control: click targets need accessible names matching spoken commands.
False confidence sources
Passing axe in CI does not prove keyboard operability; designers’ Figma specs don’t include focus order—engineers must verify.
Skip navigation pattern
<body>
<a class="skip-link" href="#main">Skip to content</a>
<header>…</header>
<main id="main" tabindex="-1">…</main>
</body>
Rendered (demo uses a unique fragment id so it never collides with the site #main)
Keyboard: tab once from the preceding paragraph to expose the visually hidden skip control.
Landing zone (#html-lesson-a11y-skip-target)
Accessibility test script (manual runbook)
- Keyboard test: press Tab once from the top of the page and confirm the skip link becomes visible and focusable.
- Expected screen reader phrase: your SR should announce a link similar to “Skip to demo target” and then “Landing zone” after activation.
- 200% zoom test: zoom browser to 200% and verify skip link/focus ring remain visible and not clipped.
Important interview questions and answers
- Q: What does progressive enhancement mean in API-driven pages?
A: Core tasks should work with baseline HTML first, then richer APIs enhance experience when supported. - Q: Why is feature detection better than browser sniffing?
A: It checks actual capability, avoids brittle UA assumptions, and degrades gracefully. - Q: What is the first accessibility check before shipping any page?
A: Verify keyboard-only task completion with visible focus and meaningful accessible names.
Challenge
Keyboard check
- Tab through your form controls in the playground.
- Ensure focus order matches visual order.
Done when: every interactive control is reachable without a mouse.
Interview prep
- What is a focus order problem?
When tab sequence does not match visual reading order—common after CSS reordering or positive tabindex abuse.