What WCAG 2.1 AA Compliance Actually Requires
A practical guide to accessibility conformance — what Level A and AA mean in terms of real code and design decisions, and how automated testing fits in.
WCAG 2.1 compliance is frequently misunderstood as a checkbox exercise — run a scanner, fix what it flags, done. In reality, automated tools catch roughly 30–40% of accessibility issues. The rest require human judgment. Understanding what the standard actually requires helps you prioritise both.
The three conformance levels
Level A — the minimum. Failures at this level make it impossible for some users to access content at all. Missing alt text, keyboard traps, no language attribute on the HTML element. These should be zero in any shipping product.
Level AA — the standard target for most legal compliance requirements (ADA, EN 301 549, etc.) and the level SentinelFlux tests by default. Failures here significantly impair access for users with disabilities. Colour contrast, resize text, consistent navigation, meaningful link text.
Level AAA — enhanced accessibility, not required for general compliance. Sign language interpretation, extended audio descriptions, reading level. SentinelFlux can report on these but doesn't include them in pass/fail assessments by default.
What automated testing catches well
- Missing or empty
altattributes on images - Colour contrast ratios below 4.5:1 (AA) or 3:1 (large text)
- Form inputs without associated labels
- Missing page
langattribute - Duplicate IDs that break ARIA relationships
- Empty buttons and links (no accessible name)
- Tables without headers
- ARIA attributes with invalid values
What automated testing misses
Automated tools can't judge whether alt text is meaningful (they can only check it exists), whether keyboard focus order is logical (they can check it's present, not intuitive), whether error messages are sufficiently descriptive, or whether the overall reading flow makes sense for a screen reader user navigating by headings.
For these, you need manual testing — ideally with a screen reader (NVDA, VoiceOver, JAWS) and keyboard-only navigation. The automated scan gets you to a baseline; manual testing gets you to genuinely accessible.
How SentinelFlux runs accessibility tests
The Accessibility module runs axe-core against each page in your application via Playwright. It reports violations by impact level (critical, serious, moderate, minor) and by page, so you can see which pages have the most work and prioritise accordingly. Results are displayed in the dashboard with the specific element, the violated rule, and a remediation hint.
Running this in CI means accessibility regressions get caught the same day they're introduced — not in a quarterly audit after they've proliferated across 50 pages.