Accessibility Testing: WCAG 2.2, the EAA & a QA Checklist

The Quick Answer

Accessibility testing verifies that people with disabilities can use your product - that it works with a keyboard alone, with a screen reader, at 200% zoom, without relying on colour to convey meaning, and without a time limit that cannot be extended. It has moved from a nice-to-have to a legal requirement in a growing number of markets.

The standard: WCAG - the Web Content Accessibility Guidelines - is the reference nearly every law points at. WCAG 2.2 is the current version, and Level AA is the conformance level almost all regulation requires.

The compliance shift: The European Accessibility Act has applied since June 2025, extending accessibility obligations to a wide range of private-sector products and services sold in the EU - not only public sector websites. For many product teams this is the first time accessibility carries a legal deadline rather than a good intention.

The testing reality: Automated tools catch roughly a third of accessibility issues. The rest require manual testing with a keyboard and a screen reader. Any accessibility programme that consists only of running a scanner is not testing accessibility.

This article covers what WCAG actually requires in practice, the current legal picture, where automated and manual testing each apply, how to run keyboard and screen reader checks, and a checklist you can put into your regular QA process.

What Accessibility Testing Covers

Accessibility is often reduced to screen readers and blind users. The scope is considerably wider, and most of the population it serves does not use assistive technology at all.

• Visual - blindness, low vision, colour vision deficiency; needs screen reader support, sufficient contrast, zoom and text resizing without loss of content
• Motor - limited dexterity, tremor, paralysis; needs full keyboard operability, generous target sizes, and no reliance on precise or timed gestures
• Auditory - deafness and hearing loss; needs captions, transcripts, and visual alternatives to audio cues
• Cognitive - dyslexia, attention and memory differences; needs clear language, predictable navigation, forgiving forms, and no unexpected changes of context
• Situational and temporary - a broken arm, bright sunlight, a noisy room, a slow connection; the largest group by far, and the one that makes accessibility work pay off for everyone

That last category is worth keeping in mind when making the internal case. Captions serve people watching in a quiet office. Keyboard operability serves power users. Sufficient contrast serves anyone outdoors. Accessibility improvements rarely benefit only the group they were designed for.

WCAG 2.2 in Practice

WCAG is organised under four principles, usually remembered as POUR. Each contains testable success criteria, graded at three conformance levels: A (minimum), AA (the standard almost all regulation requires), and AAA (rarely mandated in full).

Perceivable

Information must be available to the senses. In practice: every non-decorative image has a text alternative that conveys its purpose; video has captions and, where required, audio description; text contrast meets 4.5:1 for normal text and 3:1 for large text and interface components; content does not rely on colour alone to convey meaning; and content reflows at 320px width without horizontal scrolling, unless it genuinely needs two dimensions.

Operable

Interface components must be usable. In practice: everything reachable and operable by keyboard alone in a logical order; visible focus indication at all times; no keyboard traps; time limits adjustable or removable; nothing that flashes more than three times a second; skip links or landmarks to bypass repeated blocks; and pointer targets large enough to hit reliably.

Understandable

Content and operation must be comprehensible. In practice: page language declared; navigation consistent across pages; form fields with programmatically associated labels; errors identified in text with a description of how to fix them; no unexpected change of context on focus or input; and any help mechanism that repeats across pages - contact details, a self-help link, a chat widget - appearing in the same relative order on each of them. Note the shape of that last one: WCAG does not require you to offer help, only that help you already repeat is where users expect to find it.

Robust

Content must work with assistive technologies. In practice: the correct name, role and value for every custom component, including states such as expanded, selected and disabled; and status messages announced to assistive technology without moving focus. Markup validity is not itself a criterion - WCAG 2.2 removed the old parsing requirement - so a validator error is worth fixing but is only an accessibility failure when it changes what assistive technology is told about a component.

What WCAG 2.2 Added

Version 2.2 introduced criteria that are particularly relevant to modern application interfaces. The ones that most often produce findings in a product built before they existed: focus must not be entirely hidden by sticky headers or overlays; dragging must have a single-pointer alternative; targets must meet a minimum size unless an exception applies; users must not be required to re-enter information they already provided in the same process; and authentication must not depend on a cognitive test such as remembering or transcribing a code, unless an alternative or an assisting mechanism is offered. That last one affects a surprising number of login and checkout flows.

The Legal Picture

Accessibility requirements now come from several directions, and most of them converge on WCAG AA.

The practical consequence: Because almost every framework lands on Level AA, a product that genuinely conforms to WCAG 2.2 Level AA is well positioned across all of them - 2.2 keeps the earlier AA criteria and adds to them, so building to the current version rather than to a specific jurisdiction's paperwork is the efficient strategy.

Two caveats. Scope, exemptions and the WCAG version each regime incorporates all vary - thresholds for small enterprises, transition periods for existing content, and laws that still cite WCAG 2.0 or 2.1 rather than 2.2 - so confirm the edition named in the regimes that apply to you before making a claim against them. And conformance claims often need documentation, not just a working product: many procurement processes ask for an accessibility conformance report. Confirm your specific obligations with legal counsel rather than treating an engineering summary as advice.

Automated and Manual Testing

The most consequential fact about accessibility testing is how little of it can be automated.

Automated scanning typically detects around a third of WCAG issues. That is a good return for the effort - it is fast, cheap, and easy to put in a pipeline - but a clean scan is not a pass. The failures that most affect real users, like an alt text that reads "image1" or a tab order that jumps from the header to the footer and back, are invisible to a scanner because the markup is technically valid.

Testing with people who rely on assistive technology is the highest-value method in the table and the least frequently done. It is also not a substitute for a systematic pass against the criteria: a session tells you whether what you built is usable, which no conformance check can, but it only covers the flows and the assistive technology in the room.

An Accessibility QA Checklist

This is a practical pass that a tester can run on a feature without specialist tooling, and it catches the majority of issues that scanners miss.

Keyboard

• Unplug the mouse and complete the primary task start to finish
• Every simple control - button, link, checkbox, text field - is reachable with Tab and operable with Enter or Space
• Composite widgets - radio groups, tab lists, menus, listboxes, sliders, trees - take a single tab stop and then move or change value with the arrow keys, plus Home and End where the pattern calls for it
• Focus is always visible, and never hidden behind a sticky header or overlay
• Tab order follows the visual reading order
• Modals move focus in on open, trap it while open, and return it to the trigger on close
• Escape closes dismissible overlays
• No element traps focus permanently

Screen Reader

• Every control announces a name that describes its purpose, not "button" or "link"
• Headings form a sensible outline with no skipped levels
• Form fields announce their label, current value, and any error
• Dynamic updates - validation, loading states, toasts, results counts - are announced without stealing focus
• Images convey their purpose; decorative images are silent
• Tables have proper header associations

Visual

• Text contrast meets 4.5:1, and interface components and graphics meet 3:1
• No information conveyed by colour alone - errors, statuses, and chart series carry a second cue
• Content usable at 200% zoom and at 320px width without horizontal scrolling, unless the content requires a two-dimensional layout - a data table, a map, a diagram, a code editor
• Layout survives text spacing overrides
• Nothing flashes more than three times per second

Pointer and Touch

• Interactive targets are at least 24 by 24 CSS pixels, or have equivalent spacing around them, unless an exception applies such as a link inside a sentence
• Anything operated by dragging - reordering a list, a slider, a canvas control - has a single-pointer alternative that does not involve dragging, such as tapping a stepper or a move action in a menu
• Nothing depends on a path-based or multi-point gesture without a simpler equivalent

Content and Interaction

• Error messages state what is wrong and how to fix it
• Time limits can be extended or turned off
• Motion and autoplay can be paused, and reduced-motion preferences are respected
• Information already provided in the same flow is auto-populated or selectable, unless re-entering it is essential, required for security, or the earlier value is no longer valid
• Authentication does not depend on remembering or transcribing a code, unless there is an alternative method or a mechanism that does the work for the user - password manager support, paste into the field, and autofill all qualify, so a flow that allows them is not a failure

Building Accessibility into the QA Process

Accessibility handled as a separate audit before release produces a long list of defects at the point where they are most expensive to fix. Handled as part of normal testing, most of them never get written.

Three changes carry most of the benefit. First, add the keyboard pass to the definition of done for any feature with an interface - it takes a few minutes per feature and catches a large share of issues at the cheapest possible moment. Second, put automated scanning in the pipeline as a blocking check on the criteria it can reliably detect, so contrast and labelling regressions never reach a tester. Third, keep accessibility criteria as reusable test cases rather than a checklist in a wiki, so they are selected into a run like any other coverage and their results are recorded per release.

That last point is what turns accessibility from a periodic project into ongoing coverage. Holding the keyboard, screen reader, and visual checks as shared steps in test case management means every feature run includes them, and reporting can show what was verified - which is exactly the evidence a conformance claim or a procurement questionnaire asks for. Where these obligations sit alongside other regulated requirements, our guide to software testing in regulated industries covers the wider documentation picture.

Common Mistakes

• Treating a clean automated scan as conformance. Scanners find about a third of issues; the remainder are the ones users notice most.
• Auditing once before launch. Accessibility regresses with every release unless it is part of routine testing.
• Adding ARIA to fix problems. Native elements are almost always better than a custom component patched with ARIA attributes; incorrect ARIA makes things worse than no ARIA.
• Writing alt text that describes rather than conveys. Alt text should communicate the image's purpose in context, not narrate its appearance.
• Removing focus outlines for visual reasons. If the default indicator does not fit the design, replace it with a visible one - do not delete it.
• Testing only with one screen reader. Behaviour differs across screen reader and browser combinations; test at least two.
• Assuming an overlay widget solves it. Third-party accessibility overlays do not fix underlying markup problems and are frequently criticised by the users they claim to serve.
• Never involving people with disabilities. Conformance and usability are not the same thing, and only real users reveal the difference.
• Reporting criteria without their exceptions. Several WCAG 2.2 criteria are conditional, and a checklist applied literally produces false failures against reflow, redundant entry, target size and authentication.

Conclusion

Accessibility testing verifies that your product can be used by people who navigate it differently than you do. The technical target is clear enough: Level AA is the bar essentially every regime sets, and WCAG 2.2 is the current version of the standard, so building to 2.2 Level AA leaves you in a defensible position across jurisdictions. Which edition a given law actually incorporates is a separate question, and often an earlier one - Section 508 and AODA cite WCAG 2.0 AA, the US rule for state and local government cites 2.1 AA, and the European Accessibility Act works through EN 301 549 rather than naming WCAG itself - so check the version named in the regimes that apply to you before you claim conformance with them.

The method is less about tooling than teams expect. Automated scanning is worth having in the pipeline and will find roughly a third of issues. The rest come from unplugging the mouse and completing the task, listening to how a screen reader announces the interface, checking the page at 200% zoom, and eventually watching someone who relies on assistive technology try to use what you built.

What makes it sustainable is treating those checks as regular coverage rather than an annual audit. QA Sphere lets you keep accessibility criteria as reusable test cases and shared steps, include them in every test run, and produce a record in reporting of exactly what was verified and when. See pricing or book a demo.