Web accessibility stopped being an “extra” years ago. With the European Directive 2016/2102 in force and the European Accessibility Act gradually being adopted, meeting WCAG 2.1 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.
The Four Principles That Structure WCAG
WCAG is built around four principles, remembered as POUR: Perceivable, Operable, Understandable, and Robust. 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 the criteria that cover 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 indeed 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. 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 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 like Radix UI, Headless UI, or React ARIA solve most of this work with proven implementations, including focus management, keyboard navigation, and screen reader announcements.
Layer 3: Content
The third block usually surprises technical teams: WCAG has criteria about the content, not just the code. Colour contrast, text readability, video captions, audio transcripts, instructions that don’t rely solely on colour or shape. 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 have documented this ceiling repeatedly — but they do cut manual work in half. Three tools worth integrating from day one:
- axe by Deque: 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: 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.
Recommended Workflow
For teams starting from zero, the least-friction order is:
- Initial audit with axe or WAVE over the 5–10 most critical views. Classify findings by WCAG success criterion.
- Three sprints of semantic HTML: fix labels, headings, alt-text, visible focus, contrast. No new design, no new code — just correction.
- Incorporate accessible libraries for the composite components the team builds: dialogs, menus, tabs.
- Integrate axe into CI (rule: block merge on critical errors). This prevents regressions.
- Manual checklist like the A11y Project’s 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.
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-labelto everything just in case. A redundantaria-labelcan 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 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.
Follow us on jacar.es for more on accessibility, frontend development, and design best practices.
