syntaqx

About 1 in 6 people worldwide live with a significant disability, and far more are situationally impaired at any moment: a broken arm, a phone in direct sunlight, a noisy train. Accessibility isn't a feature for a niche audience. It's whether a large share of your users can use the product at all.

It's also part of "done", not a later pass, for a practical reason: retrofitting means redesigning components people already depend on, while building it in mostly means using the platform the way it was designed. Most of the work below costs nothing if it's done first.

The Baseline: WCAG 2.2 AA

I target WCAG 2.2 at level AA for everything I ship. Level A alone leaves real barriers, like insufficient contrast, in place. AAA can't be met by all content (some of its criteria rule out entire kinds of material), so it works as an aspiration for specific pages, not a baseline. AA is the level that's achievable everywhere without compromising design, and it's the one regulators, procurement teams and courts reference.

WCAG 2.2 added criteria worth knowing by name (what's new):

Criterion	Level	In practice
2.4.11 Focus Not Obscured (Minimum)	AA	Sticky headers and cookie banners can't completely cover the focused element
2.5.7 Dragging Movements	AA	Anything done by dragging has a single-pointer alternative
2.5.8 Target Size (Minimum)	AA	Pointer targets are at least 24 by 24 CSS pixels, or spaced as if they were
3.2.6 Consistent Help	A	Help links appear in the same place across pages
3.3.7 Redundant Entry	A	Don't make people retype what they already entered in the same flow
3.3.8 Accessible Authentication (Minimum)	AA	No cognitive tests to log in; allow paste and password managers

Semantic HTML First

The browser already knows how to make a <button> focusable, keyboard-operable and announced correctly. A <div> with a click handler knows none of that.

Use the element that means what you're building: <button> for actions, <a href> for navigation, <nav>, <main>, <label>, <table> for tabular data, headings in order.
ARIA only when HTML can't do it. ARIA changes what's announced, not how anything behaves. role="button" on a <div> makes a screen reader say "button", but the div still ignores Enter and Space and can't receive focus, so it's now a broken button that claims to work. A wrong role is worse than none, which is why the W3C's first rule of ARIA is to use a native element whenever one exists.
Custom widgets (tabs, comboboxes, dialogs) follow the ARIA Authoring Practices Guide patterns, including their keyboard behavior.

Keyboard and Focus

Everything usable with a mouse is usable with a keyboard alone.

Logical tab order, following the visual order. No positive tabindex.
Visible focus, always. Never remove outlines without a replacement. :focus-visible shows focus for keyboard users without flashing it on every mouse click.
Dialogs trap focus while open and return it to the trigger when closed. Escape closes them.
A skip link to the main content on pages with long navigation.

Color and Contrast

Text: at least 4.5:1 against its background, 3:1 for large text (18pt, or 14pt bold).
UI components and graphics: at least 3:1 for borders of inputs, focus indicators, icons and chart marks that carry meaning.
Never color alone. Errors get an icon and text, links get an underline or another cue, charts get labels or patterns.
Check every theme. A palette that passes in dark mode can fail in light mode. See Design Tokens & Theming.

Motion

Respect prefers-reduced-motion. Animations that move, zoom or parallax get a reduced or static alternative. Nothing flashes more than three times a second.

Forms

Every input has a visible <label>. Placeholders aren't labels; they vanish when you type.
Errors are specific and attached: the message says what's wrong and how to fix it, and it's linked to its field (aria-describedby) so screen readers announce it.
Don't clear the form on an error. Keep what the person typed.
Use the right type and autocomplete, so mobile keyboards and password managers help instead of fight.

Images and Media

Meaningful images get alt text that says what the image communicates, not what it looks like.
Decorative images get alt="", so screen readers skip them.
Video has captions; audio has transcripts.

Testing

Automated tools are necessary and nowhere near sufficient. They can tell that an image has alt text, but not whether it describes the image; that a button has a name, but not whether the name makes sense. axe-core, the engine behind most of them, reports finding about 57% of WCAG issues on average. A clean automated report means the easy half is done. The rest takes a person:

Automated checks in CI with axe on key pages, failing the build on new violations.
A keyboard pass on every new flow: unplug the mouse and finish the task.
A screen reader pass on new components: VoiceOver on macOS and iOS, NVDA on Windows.
Zoom to 200% and check at 320px width: content reflows, nothing overlaps or gets cut off.

It's the Law, Too

In the US, the Department of Justice's position is that the ADA applies to the websites of businesses open to the public (ADA.gov guidance). In the EU, the European Accessibility Act has applied since 28 June 2025 and covers e-commerce and other consumer services. Building to WCAG 2.2 AA puts you on the right side of both.

References

Specifications

W3C: Web Content Accessibility Guidelines (WCAG) 2.2, success criteria, contrast ratios and conformance levels
W3C: What's New in WCAG 2.2, the nine criteria added in 2.2
W3C: Using ARIA, the rules of ARIA use, starting with native HTML first

Reference

W3C: ARIA Authoring Practices Guide, keyboard and ARIA patterns for custom widgets
MDN: prefers-reduced-motion, detecting the reduced-motion preference
Deque: axe-core, the automated testing engine and what share of issues it catches

In practice

WHO: Disability and health, 1.3 billion people, about 1 in 6, with significant disability
ADA.gov: Guidance on Web Accessibility and the ADA, how the ADA applies to websites
European Commission: European Accessibility Act, scope of the EU requirements