Web Accessibility: Covering WCAG Without Losing Your Mind

Actualizado: 2026-05-03

WCAG accessibility stopped being an “extra” years ago. With the European Directive 2016/2102^[1] in force and the European Accessibility Act^[2] being adopted, meeting WCAG 2.1^[3] level AA has moved from a good practice to a legal requirement for many organisations. Yet many development teams still treat accessibility as a giant, impossible project. This article proposes a pragmatic path to cover WCAG without losing your mind.

Key takeaways

• WCAG 2.1 level AA is the realistic legal and technical target; AAA is optional.
• 40% of criteria are resolved by writing semantic HTML correctly.
• For complex components (modals, menus, tabs) prefer accessible libraries over hand-crafted ARIA.
• No automated tool detects more than 30-40% of issues; always add manual keyboard and screen-reader passes.
• A disciplined team reaches WCAG 2.1 AA in 2-3 months with axe in CI, accessible libraries, and a per-release checklist.

The four principles that structure WCAG

WCAG is built around four principles, remembered as POUR:

• Perceivable: content must be presentable in ways the user can sense.
• Operable: the interface must be usable by keyboard, voice, switches — not just mouse.
• Understandable: both information and UI behaviour must be intelligible.
• Robust: code must be interpretable by current and future assistive technologies.

Each principle breaks down into guidelines, and each guideline into success criteria tagged with a conformance level (A, AA, or AAA). Level AA is the practical target: it includes everything from level A and adds criteria covering the vast majority of real accessibility needs. Level AAA exists, but in many cases is unreachable without sacrificing other dimensions of the product.

Starting by reading all 50 level-AA criteria is overwhelming. The good news: you don’t have to solve them all at once.

An incremental three-layer path

Instead of treating WCAG as a giant check, organise it into three layers that align with three different kinds of work.

Layer 1: semantic HTML

Roughly 40% of WCAG criteria are resolved by writing HTML correctly. Non-negotiable rules:

• Use <button> instead of <div onclick>.
• Put a <label> on every <input>.
• Respect heading hierarchy (<h1> → <h2> → <h3>).
• Associate tables with <th scope="col">.
• Add alt attributes to meaningful images and alt="" to decorative ones.

This work needs no libraries or tooling: it needs discipline and a systematic review of existing markup. It’s also the layer with the most impact on screen reader users, keyboard navigation, and high-contrast modes. If you do nothing else, do this.

Layer 2: behaviour with JavaScript

The second layer appears when HTML alone isn’t enough:

• Dropdowns.
• Modal dialogs.
• Tabs.
• Custom comboboxes.

This is where the ARIA Authoring Practices Guide^[4] comes in, documenting proven accessible interaction patterns for each composite component.

The golden rule of ARIA: don’t use ARIA if you can avoid it. A native accessible <button type="button"> is always preferable to a hand-crafted <div role="button" tabindex="0" aria-pressed="false">. But when there’s no alternative, ARIA provides the vocabulary to communicate states and roles to the accessibility tree.

Mature library components solve most of this work with proven implementations (focus management, keyboard navigation, screen reader announcements):

• Radix UI^[5] for React, headless and style-agnostic.
• Headless UI^[6] from the Tailwind authors, also headless.
• React ARIA^[7] from Adobe, low-level primitives.

If you’re prototyping in Figma, this fits the discipline we describe in Figma for collaborative prototyping: accessible components are born in the design system, not in the last sprint.

Layer 3: content

The third block surprises technical teams: WCAG has criteria about the content, not just the code. The most common:

• Colour contrast and text readability.
• Captions on videos and transcripts on audio.
• Instructions that don’t rely solely on colour or shape.
• Text alternatives for any information conveyed visually.

These criteria require involving designers, writers, and product teams — not just development. As we noted in word choice in your application, clear language is part of accessibility: simple sentences, short phrases, and consistent terminology particularly benefit users with cognitive disabilities.

Practical tools

No automated tool can detect beyond 30-40% of accessibility issues — the experts at Deque^[8] have documented this ceiling — but they cut manual work in half. Three tools worth integrating from day one:

• axe by Deque^[8] — the audit engine used by dozens of tools. Available as a browser extension, Cypress/Playwright integration, and CI action. Finds what any auditor would catch on first pass.
• WAVE by WebAIM^[9] — ideal for quick visual audits. It overlays icons on the page marking issues, making communication with non-technical stakeholders easy.
• Chrome Lighthouse — built into DevTools, covers a subset of axe’s rules. Useful as a continuous guardrail.

Add a manual keyboard pass (navigate the whole app without a mouse) and a screen-reader pass — NVDA on Windows, VoiceOver on macOS — at least once per iteration. No automated test replaces this step. Same logic we apply to Pact contract tests: the automated tool isn’t the only level of verification, it’s the first.

Recommended workflow

For teams starting from zero, the least-friction order is:

1. Initial audit with axe or WAVE over the 5-10 most critical views. Classify findings by WCAG success criterion.
2. Three sprints of semantic HTML: fix labels, headings, alt-text, visible focus, contrast. No new design, no new code — just correction.
3. Incorporate accessible libraries for the composite components the team builds: dialogs, menus, tabs.
4. Integrate axe into CI (rule: block merge on critical errors). This prevents regressions.
5. Manual checklist like the A11y Project’s^[10] before each release, complemented by the keyboard + screen-reader pass.

Executed with discipline, this path gets most applications to WCAG 2.1 AA compliance in 2-3 months. It’s not fast, but it’s also not the endless project many fear. The key is disciplined repetition — same principle we recommend in mature prompt engineering: small verifiable steps, not big leaps.

Common mistakes to avoid

Accompanying projects through this transition, four problematic patterns keep appearing:

• Treating accessibility as a one-off audit instead of a continuous practice. Without CI, errors reappear every sprint.
• Confusing “passes Lighthouse 100” with “is accessible”. Lighthouse doesn’t detect half the real issues — it helps lower the noise floor, not guarantee quality.
• Adding aria-label to everything just in case. A redundant aria-label can make a screen reader announce information twice. “The less ARIA the better” applies here too.
• Testing with only one screen reader. NVDA, JAWS, and VoiceOver interpret some patterns differently. If your audience is broad, test with at least two.

More broadly, accessibility connects with design thinking: a cross-cutting product competence, not a final check.

Conclusion

WCAG 2.1 AA is reachable by layers: first semantic HTML, then dynamic behaviour, then content. With axe in CI, an accessible component library, and a manual checklist per release, most teams reach compliance without major restructuring.

1. European Directive 2016/2102
2. European Accessibility Act
3. WCAG 2.1
4. ARIA Authoring Practices Guide
5. Radix UI
6. Headless UI
7. React ARIA
8. Deque
9. WAVE by WebAIM
10. the A11y Project’s