Web accessibility (a11y) means people with disabilities can use the web. Not just blind users with screen readers — also keyboard-only users, motor-impaired users, color-blind users, users with cognitive disabilities, deaf users.
It's also legally required in many jurisdictions and a moral baseline for public-facing software.
This page covers the foundations.
Web Content Accessibility Guidelines. The standard. WCAG 2.1 AA is the common compliance target.
Four principles (POUR):
WCAG has specific success criteria. Most are common-sense rules that good design follows naturally.
The single biggest accessibility win: use the right HTML elements.
<!-- Bad: a div pretending to be a button -->
<div onClick={handleClick}>Click me</div>
<!-- Good: an actual button -->
<button onClick={handleClick}>Click me</button>
The button:
Reimplementing buttons with divs requires recreating all of this with ARIA. Just use the button.
Semantic elements that matter:
<button> for buttons (not links that look like buttons)<a href> for navigation (not buttons that navigate)<form> for forms<nav>, <main>, <aside> for landmarks<h1>-<h6> for headings (in proper order)<label> for form fieldsARIA (Accessible Rich Internet Applications) provides attributes for accessibility info that HTML doesn't natively express:
<button aria-label="Close dialog" aria-expanded="false">
<svg>...</svg> <!-- icon -->
</button>
The first rule of ARIA: don't use ARIA. Use semantic HTML when possible.
The second rule: when ARIA is needed, learn the patterns. The W3C's ARIA Authoring Practices Guide is the canonical source.
Common use cases:
aria-label, aria-labelledby)aria-live)aria-hidden="true")Not everyone uses a mouse. Power users and users with motor disabilities use keyboards.
Required:
Common failures:
outline: none (without replacement)Test: navigate your entire app with only the keyboard. Notice every place it doesn't work.
Screen readers convert visual content to speech (or braille). Test with one:
Open your app; navigate by Tab and arrow keys; listen.
Common failures:
You don't need to be expert; basic listening reveals most problems.
WCAG AA: 4.5:1 for body text, 3:1 for large text.
Tools test contrast (browser DevTools, WebAIM Contrast Checker). Test your design system colors at design time, not after.
Don't communicate solely with color:
Forms are common accessibility failure points.
Required:
<label> associated by for/idrequired attribute + visual indication)aria-describedby)See FormHandlingAndValidation.
A link at the top of the page that skips to main content. Hidden until focused.
<a href="#main" class="skip-link">Skip to main content</a>
For keyboard users navigating around extensive headers/navigation.
After a modal opens, focus moves into the modal. After it closes, focus returns to the trigger. Without this, keyboard users get lost.
Modern modal libraries handle this; custom implementations need explicit work.
For dynamic content that should be announced:
<div role="status" aria-live="polite">
Item added to cart
</div>
Screen readers announce changes to live regions.
Browser extension and library. Runs accessibility tests on a page; reports violations. The standard automated tool.
Most accessibility issues axe catches; more nuanced ones require manual testing.
Built into Chrome DevTools. Has an accessibility audit (uses axe under the hood).
Browser extension. Visual accessibility audit.
Automated tools catch ~30% of issues. Manual testing (keyboard, screen reader) catches the rest.
<div> for everything. Loses semantic meaning.