Understanding accessibility checks
Catchable today, the rest needs a human.
What automated accessibility checks reliably find, what they reliably miss, and the WCAG ladder the rules are checking against.
WCAG, the standard the rules check against.
Web Content Accessibility Guidelines (WCAG) is the W3C standard, currently at version 2.2. It's organised by four principles — perceivable, operable, understandable, robust — with success criteria graded A (minimum), AA (the legal floor in most jurisdictions), AAA (aspirational). Automated checks usually target AA. Reaching AA across a real site is a meaningful project; AAA is rarely appropriate everywhere because some criteria (contrast 7:1, simplified-language alternatives) constrain design more than they need to.
What automated checks find.
Image alt attributes (presence, not quality). Form input labels. Colour contrast ratios. Heading hierarchy (no jumping from h1 to h3). Document language attribute. Duplicate IDs. ARIA attribute correctness. Missing button text on icon buttons. These rules have unambiguous answers; automated tools (axe-core powers most of them) find them reliably. A clean axe run is a baseline, not a destination.
What automated checks miss.
Whether the alt text actually describes the image. Whether the heading hierarchy matches the page's information structure. Whether focus order makes sense for keyboard users. Whether interactive elements work without JavaScript. Whether the page reads sensibly when announced linearly. Whether colour conveys information that isn't also encoded another way. Research suggests automated tools catch roughly 30 % of WCAG issues; the rest need a person operating a screen reader and keyboard.
A worked check.
A page reports: 3 images without alt, 1 form input without label, 1 contrast failure on muted-grey-on-white, 2 buttons with only icon content. Five real bugs, all fixable. Adding alt="" to decorative images (correct), descriptive alt to the informative one (correct), <label> to the input (correct), tightening the muted-grey to #595959 (correct), and aria-label on the icon buttons (correct). Five quick fixes; the page is now mechanically compliant. Whether it's actually usable still wants a manual test.
Quick wins from an automated run
alt, labels, contrast, button names
High-yield categories that automated checks find reliably.
5 reported issues → 5 mechanical fixes
= Baseline AA
Keyboard navigation, the manual test.
The single highest-yield manual check: unplug your mouse and try to use the page. Can you reach every interactive element with Tab? Does Tab go in a sensible order? Can you activate buttons with Enter or Space? Can you escape modals with Esc? Is focus always visible (no outline: none without a replacement)? This one walkthrough catches more real problems than any automated scan.
Screen readers — pick one and test.
The big three: VoiceOver (Mac, built-in), NVDA (Windows, free), JAWS (Windows, paid). Modern Chrome and Edge also ship a "ChromeVox" / built-in narrator. Pick one (VoiceOver if you're on Mac, NVDA if you're on Windows), learn the basic shortcuts, and listen to a few key flows on your site once a quarter. The exercise is humbling and informative; nothing else gives you the same picture of what your interface sounds like.
The legal floor.
ADA (US), Equality Act 2010 (UK), EAA 2025 (EU-wide from June 2025) and similar legislation in most major markets require websites to meet WCAG 2.1 AA. Settlements and rulings have been ramping up since 2020. Accessibility isn't optional or merely-ethical anymore — it's a compliance baseline. The automated checks won't make you compliant; they'll catch the most embarrassing failures before manual audits do.