Accessibility Audit as a Service (WCAG 2.2 AA): What You Get

An accessibility audit as a service means a provider tests your product against the WCAG 2.2 AA standard and reports every issue with its fix: things that stop people using a keyboard, a screen reader or zoom from completing a journey. You buy it before a launch, a tender or a procurement review. An audit tells you what fails and how to fix it; it does not certify legal compliance.

If you would rather have it audited for you, see how RAITHub would test this below, or start at the QA as a service overview. For the hands-on method, read the accessibility testing checklist.

What is an accessibility audit as a service?

Accessibility means a product works for people who navigate by keyboard, hear the screen through a screen reader, zoom to 200%, or depend on sufficient colour contrast. WCAG 2.2, the Web Content Accessibility Guidelines published by the W3C, is the recognised standard, and AA is the level most organisations target. An audit checks each relevant success criterion and records where the product passes or fails.

"As a service" means a provider runs the audit for you: automated scans to catch the obvious, then manual testing with a keyboard and a screen reader to catch what scanners miss, which is most of it. Automated tools find roughly a third of issues; the rest need a person.

What does an accessibility audit actually check?

Area	What it answers	What you should receive
Keyboard operation	Can every control be reached and used without a mouse?	Issues on focus order, traps and hidden focus, each with a fix
Screen reader	Is every element announced with a meaningful name and role?	Findings on labels, headings, landmarks and live regions
Contrast and text	Is text readable at the required contrast and at 200% zoom?	Contrast failures with the measured ratio and the target
Forms and errors	Are fields labelled, and are errors announced and explained?	Findings per form, mapped to success criteria
Dynamic content	Do modals, menus and updates work for assistive tech?	Issues on focus management and announcements
Structure	Do headings, landmarks and reading order make sense?	A structural review per template or page type

Each finding is mapped to its WCAG 2.2 success criterion and given a severity, so you can fix the blockers first. A finding without a criterion and a fix is an opinion, not an audit.

What do you receive, and what it is not

• An audit report: every issue, its WCAG 2.2 success criterion, its severity, where it occurs and how to fix it.
• A prioritised list, so blockers are addressed before cosmetic issues.
• A retest of the fixes, where that is in scope, confirming the issues are closed.

What it is not: a legal compliance certificate. An audit against WCAG 2.2 AA tells you what fails and how to fix it, but it does not certify compliance with the ADA, the European Accessibility Act or Section 508. That is general information; confirm your legal obligations with your adviser.

When in a project do you need an accessibility audit?

• Before a public launch, so the product is usable by everyone from day one, which is cheaper than retrofitting later.
• Before a tender or procurement review, where buyers increasingly ask for an accessibility statement backed by an audit.
• After a redesign, because new components and layouts are where accessibility regressions appear.

Buy, build or hire?

Route	What you get	Choose this when	Watch out for
A tool or SaaS platform	Automated scanning, such as an axe-based checker	Your developers want to catch obvious issues in CI	Automated tools catch roughly a third of issues; the rest need a person
Freelancers or crowdtesting	An individual auditor, or testers with assistive tech	A one-off audit on a defined set of pages	Depth and WCAG mapping vary by auditor
An in-house specialist	Someone who builds accessibility in continuously	Accessibility is central and you can keep the role	Hard to justify a dedicated hire early
A managed QAaaS team	A WCAG 2.2 AA audit with fixes and a retest, you own	You want a credible audit without hiring	It reports to WCAG; it does not certify legal compliance

Why RAITHub for an accessibility audit?

• Auditors who build. Each finding comes with a fix a developer can apply, because the same team builds accessible production software.
• Automated plus manual. Scans with axe-core catch the obvious; keyboard and screen-reader testing catch the rest, which is where most real barriers are.
• Measured, honest accessibility work. This website has measured WCAG 2.2 AA fixes in its own build. There is no standalone accessibility-audit case study yet, so judge the service on a free audit and a written scope.
• Everything stays yours. The report is yours, the IP is assigned to you, and an NDA is standard.

When don't you need an accessibility audit service?

• When you need a signed legal compliance certificate; no honest audit provides one, and the obligation is a question for your adviser.
• When your team already audits against WCAG 2.2 AA and only needs automated scanning in CI; buy the tool.
• When the product is pre-launch and still changing shape daily; audit once the templates are stable.

How RAITHub would test this

• Scope: agree the templates, journeys and page types to audit, and the target level (WCAG 2.2 AA).
• Audit: automated scans with axe-core, then manual keyboard and screen-reader testing against each relevant success criterion.
• Report: every issue mapped to its WCAG 2.2 criterion, with a severity and a fix, prioritised so blockers come first.
• Retest: where in scope, a retest confirming the fixes close the issues.

Timeline: an accessibility audit is fixed in scope and dates before it starts; it can also sit inside a monthly QA plan. You receive: the audit report mapped to WCAG 2.2 AA, a prioritised fix list and a retest where in scope, all yours, under an NDA as standard. Next step: a free 15-minute audit, then a written fixed quote. RAITHub publishes no rates, and the audit reports to WCAG 2.2, not to any legal standard.

To start, request a one-off accessibility audit. For the specialist page, see accessibility testing; for a related human-led check, the usability testing service.

Frequently asked questions

What does an accessibility audit test against?

WCAG 2.2 at level AA, the Web Content Accessibility Guidelines published by the W3C. The audit checks each relevant success criterion and records where the product passes or fails, with a fix for each failure.

Does an accessibility audit make my product legally compliant?

No. An audit tells you what fails against WCAG 2.2 AA and how to fix it, but it does not certify compliance with the ADA, the European Accessibility Act or Section 508. Confirm your legal obligations with your adviser.

Can't an automated tool do the whole audit?

No. Automated scanners catch roughly a third of issues, mostly contrast and missing attributes. The rest, such as focus order, screen-reader clarity and dynamic content, need a person testing with a keyboard and a screen reader.

What is in the audit report?

Every issue, its WCAG 2.2 success criterion, its severity, where it occurs and how to fix it, ordered so blockers come first. Where in scope, a retest confirms the fixes close the issues.

How long does an accessibility audit take?

It depends on the number of distinct templates and journeys, since similar pages share findings. The scope and dates are fixed in the written quote before the audit starts.

How much does an accessibility audit cost?

It depends on the number of templates and journeys and whether a retest is in scope. RAITHub publishes no rates and quotes a fixed price after a free 15-minute audit call.