Which accessibility standards does QA Tech Xperts test against?

WCAG 2.2 (A and AA), ADA, and Section 508, using automated scanning plus Manual screen-reader and keyboard Testing, since Automation alone misses most real-world issues.

Which WCAG version and level should we target?

WCAG 2.2 at AA. It is the level referenced by the European Accessibility Act, UK public-sector regulations and most US procurement, and 2.2 is backwards compatible with 2.1, so targeting it satisfies both.

Can we just run axe in CI and call it done?

No. Automated scanning catches roughly a third of real barriers and none of the judgment-based criteria, focus order, meaningful announcements, keyboard alternatives to complex interactions. Use it to hold the line automatically, and Manual assistive-technology Testing to establish conformance.

Quality Engineering

Accessibility TestingWCAG, ADA, Section 508 compliance.

Accessibility is both a legal requirement and a usability multiplier. We audit against WCAG 2.2, ADA, and Section 508 using automated scans plus Manual screen-reader and keyboard-only Testing, because automated tools alone catch less than half of real issues.

Get a Free QA Assessment Book a Call

NDA on Request Senior QA Leadership Start Within Days

What this covers

WCAG 2.2 A/AA audits with prioritized remediation reports

Manual screen-reader Testing (NVDA, VoiceOver) and keyboard-only flows

Color contrast, focus management, and ARIA validation

Accessibility regression checks in CI

Developer guidance so fixes stick

Delivered in

Client names under NDA

Accessibility is a requirement, not a retrofit

Roughly one in six people live with a significant disability, and accessibility law has moved from guidance to enforcement in most of the markets our clients sell into, the European Accessibility Act, Section 508 and ADA case law in the US, the Equality Act and public-sector regulations in the UK. Meanwhile the same work that makes a product usable with a screen reader tends to make it more robust, more testable and better ranked.

We test against WCAG 2.1 and 2.2 at AA, which is the level virtually every regulation and procurement questionnaire references. Conformance is assessed per success criterion with evidence, so you get a defensible position rather than a vague assurance.

Automated scanning finds a minority of it

Automated tools reliably catch a subset of issues, missing alt text, insufficient contrast, absent form labels, some ARIA misuse.

Automated tools reliably catch a subset of issues, missing alt text, insufficient contrast, absent form labels, some ARIA misuse. Industry practice puts that at roughly a third of real barriers, and the tools cannot judge the ones that matter most: whether focus order matches visual order, whether a custom component announces its state, whether an error is actually communicated to a screen reader, whether a modal traps focus correctly, whether a drag interaction has a keyboard alternative.

So we run scanning (axe, Lighthouse) in CI to hold the automatable line, and do the rest by hand: full keyboard-only traversal of every journey, screen reader passes with NVDA, JAWS and VoiceOver, zoom and reflow at 200% and 400%, reduced-motion and forced-colours behaviour, and touch target sizing on real mobile hardware. Our practical starting list is in WCAG 2.2 Quick Wins.

Fixes, not just a conformance table

Each barrier is reported with the failing success criterion, the affected component, the assistive technology that exposes it, and a concrete remediation, usually the specific markup or ARIA change required. Because most failures live in shared components, fixing a handful of design-system primitives typically closes a disproportionate share of the report, and we sequence the findings to make that obvious.

Engagement path

How the engagement runs

Every Accessibility Testing engagement runs the same way: understand the risk, build the thing that reduces it, prove it works, hand it over.

Scope and conformance target

Journeys, platforms and the target level, usually WCAG 2.2 AA, agreed up front, along with which regulation you are answering to.

Automated baseline in CI

axe and Lighthouse wired into the pipeline to catch the machine-detectable regressions on every build and stop the backlog refilling.

Manual and assistive technology passes

Keyboard-only traversal, NVDA, JAWS and VoiceOver, zoom and reflow, reduced motion, forced colours, and real-device touch target checks.

Remediation and verification

Prioritised fixes aimed at shared components first, developer pairing where useful, then a verification pass and a conformance statement you can publish.

Deliverables