Web Development6 min read

Web Accessibility (a11y)

Build websites usable by everyone - applying WCAG 2.2 guidelines, semantic HTML, ARIA, keyboard navigation, and color contrast to meet legal and ethical standards.

AccessibilityWCAGARIAScreen ReaderInclusive Design

skill: Web Accessibility (a11y) category: Web Development tags: [Accessibility, WCAG, ARIA, Screen Reader, Inclusive Design] readingTime: 6

Web accessibility is not optional - WCAG 2.1 AA is a legal requirement in many jurisdictions and missing it opens organizations to lawsuits. Treat accessibility as a quality bar, not a feature. Good accessibility also improves SEO, keyboard usability, and overall UI quality.

Workflow

Use semantic HTML as the foundationNative HTML elements have built-in keyboard behavior, focus management, and ARIA roles. Semantic HTML costs nothing and provides accessibility for free.
Add ARIA only when HTML isn't enoughARIA (Accessible Rich Internet Applications) communicates widget roles, states, and properties to assistive technology - but only when native HTML can't express the semantics.
Ensure keyboard navigabilityUsers who can't use a mouse - motor disabilities, power users - rely entirely on keyboard navigation. Every interactive element must be reachable and operable via keyboard.
Meet color contrast requirementsWCAG AA requires 4.5:1 contrast for normal text, 3:1 for large text and UI components. Low contrast is the most common and easiest-to-fix accessibility failure.
Test with real assistive technologyAutomated tools catch ~30% of issues. Testing with a real screen reader finds the other 70% - flow, verbosity, confusing announcements.

Output Format

WCAG 2.2 AA conformant interface with semantic HTML, ARIA, keyboard navigation, and tested with screen readers.

Checklist:
☐ Landmark structure (header/nav/main/footer)
☐ Heading hierarchy (h1 > h2 > h3, no skips)
☐ All images have meaningful alt or alt="" if decorative
☐ Color contrast ≥ 4.5:1 (normal text)
☐ All interactive elements keyboard reachable and operable
☐ Focus visible on all focusable elements
☐ Forms: labels linked with for/id or aria-label
☐ Error messages: linked to field with aria-describedby
☐ Dynamic content: aria-live regions for status updates
☐ Modals: focus trap + Escape closes + focus returns

Examples

Input

Output

Input

Output

Edge Cases & Gotchas

Disabled buttons and focus - disabled attribute removes an element from the tab order. Use aria-disabled='true' instead when you want the button focusable (so screen readers can explain why it's disabled).
Icon-only buttons - Buttons with only an icon have no text label for screen readers. Add aria-label='Close dialog' or a visually hidden <span> inside the button.
SVG accessibility - Inline SVG needs <title> and aria-labelledby to be announced. Or hide decorative SVGs with aria-hidden='true'.
Infinite scroll vs. pagination - Infinite scroll is difficult for keyboard and screen reader users - they lose their place on page reload. Provide a 'Load more' button as an alternative.

When to Break These Rules

Don't use ARIA to describe every element - over-annotating creates verbose, confusing screen reader output. Native HTML semantics first.
Don't skip accessibility for internal tools - employees with disabilities need to use them too, and ADA/Section 508 may apply.

Reference Files

https://www.w3.org/WAI/WCAG21/quickref/
https://www.a11yproject.com/checklist/