WCAG Audits & Testing

WCAG audit services for websites and web apps

A WCAG audit tells you exactly where your website or web application fails the Web Content Accessibility Guidelines — and what to fix first. We pair automated checks with expert manual testing on real assistive technology, map every finding to its specific success criterion, and deliver a prioritized report your team can ship against.

Schedule a consult See our services

What you get with a WCAG audit

Every engagement combines automated coverage with the manual testing that finds what tools cannot, and ends with a report your developers can execute against.

Manual expert testing

We manually test your key user journeys — registration, search, forms, checkout, account — using keyboard navigation and screen readers. This is where most real barriers show up, even when a scanner comes back clean.

Assistive technology coverage

We validate behavior across common assistive technology and browser combinations — JAWS, NVDA, and VoiceOver among them — to catch the issues automated checks structurally cannot see.

Criteria-mapped findings

Every issue is tied to the exact WCAG success criterion it fails, with its location, steps to reproduce, and evidence. Your team sees what failed, where, and why.

Prioritized remediation plan

Findings arrive ranked by severity and user impact, so your developers fix in the order that reduces risk fastest instead of working through an unsorted dump.

A report teams can use

The report is written for implementation: plain descriptions, criteria mapping, and concrete next steps, not a list of problems that sits in a drawer.

Retest and verification

After your team ships the fixes, we retest and confirm what is resolved. You get an updated, defensible status that supports release notes, stakeholder review, and legal or procurement evidence.

Accessibility audit services built for real website compliance

If you need an audit your team will rely on, whether for remediation, legal evidence or procurement, you need more than a scanner export. Automated tools detect only the machine-checkable portion of accessibility issues. They cannot tell you that a keyboard user gets trapped in your date picker, that checkout cannot be completed with a screen reader, or that your error messages are never announced. Those are the failures that block real users, and they are the ones a legal claim or a procurement review turns on.

Depending on your product, your risk, and your stakeholders' requirements, we audit against WCAG 2.1 or WCAG 2.2 at Level A and AA — and we confirm the target with you before testing starts, so the results line up with the obligation you actually face.

WCAG 2.1 vs WCAG 2.2: choosing your audit target

The right target depends on your obligation and your stakeholders:

WCAG 2.1 is the widely referenced baseline — and the version the Department of Justice adopted for state and local government under ADA Title II.
WCAG 2.2 is the current W3C Recommendation. It adds nine success criteria beyond 2.1 and removes 4.1.1 Parsing as obsolete, with stronger requirements for focus appearance, dragging alternatives, and target size.

Which one is right depends on your obligation: a Title II entity plans against 2.1 AA; a product team building ahead of requirements typically audits against 2.2. Either way, the target is confirmed before testing, so you should not pay to prove conformance to a version nobody asked for. If you are not sure which version applies to you, bring it to a scoping call and we will settle the target against your actual obligation before anything is quoted.

What a full audit covers, and what scanners miss

A real audit goes far beyond surface-level page errors. We evaluate the templates and reusable components that repeat across your product, navigation patterns, complex forms, and the user flows that drive task completion, the places where semantic structure, keyboard interaction, and focus order actually break down.

Checkers and checklists stop at what a machine can see. That is the gap accessibility audit services close: keyboard usability, focus management, form behavior, dynamic components, and real screen reader experience only surface when a person drives the product the way your users do, and those are the failures compliance questions turn on.

Accessibility testing for web applications and SaaS platforms

Most of what we audit is not a brochure site. It is a product: a SaaS platform, a customer portal, an internal dashboard, a booking or claims workflow, an application with roles and permissions. Accessibility behaves differently there, because the interface is assembled at runtime and the barriers live in the parts a crawler never reaches.

A scanner walks pages. A product is not pages, it is states. The failures that matter sit behind a login, inside a multi-step form, in a filter that rewrites results without announcing them, in a modal that traps focus, in a data table that a screen reader reads as a wall of numbers. We test the product the way a person with a disability would actually use it, signed in and working through the flows that carry your revenue.

What we test inside a web application

Authenticated areas: account settings, dashboards, admin views, and anything gated behind a login.
Multi-step workflows: onboarding, checkout, applications, claims, and booking paths tested end to end rather than screen by screen.
Dynamic components: menus, modals, tabs, combo boxes, filters, toasts, and live regions that change without a page load.
Data-heavy interfaces: sortable tables, charts, and reporting views where structure decides whether the content is readable at all.
Role and permission variants, where the same screen behaves differently depending on who is signed in.

Findings from a product audit map to WCAG the same way, so the same engagement supports a VPAT or ACR when a buyer asks for one — which, for most software vendors, is how the question arrives in the first place.

What every finding in your report carries

What broke, in plain terms — for example, keyboard focus disappearing inside the mega-menu.
Where it happens — the page or component, with steps to reproduce it.
The criterion it fails — the specific WCAG success criterion, such as 2.4.7 Focus Visible.
Severity — how badly it blocks users and how likely it is to be flagged in a claim or review.
The fix — remediation direction a developer can act on without a translation layer.

Around the findings, the report states its coverage — which templates, components, and flows were tested — and closes with an executive summary a non-technical stakeholder can read. After your team remediates, the retest updates each finding's status, so the document ends its life as evidence of resolution, not a list of problems.

Where audit results get used

For legal risk: WCAG results are the technical evidence behind ADA website compliance — the defensible record courts and opposing counsel actually examine.
For procurement: the same testing feeds a VPAT/ACR, the conformance report buyers request in RFPs and vendor review.
For federal work: Section 508 is measured against WCAG 2.0 A/AA — a different version with its own rules, and we scope it correctly from the start.

Because every finding is criteria-mapped, one audit serves every downstream requirement — ADA compliance, a VPAT/ACR, or Section 508 — instead of paying for the same testing three times.

Scope my audit

Trusted by leading brands

We are proud of our customers

Common questions about accessibility audits and testing

What do we receive at the end of the audit?

A findings report written for implementation: every issue with its location, the success criterion it fails, severity, steps to reproduce and fix direction. Plus a statement of coverage — the templates, components and flows tested — and an executive summary for stakeholders.

What is the difference between a WCAG audit and an automated scan?

An automated scan can identify some accessibility issues, but it cannot determine whether a website or web application is truly usable for people with disabilities. A WCAG audit includes manual testing, keyboard-only testing, screen reader testing, magnification review, and evaluation of real user flows. ADACP uses automated tools as a starting point, but the audit is built around human review and criteria-mapped findings.

Do I need WCAG 2.1 or WCAG 2.2?

It depends on your legal, procurement, or customer requirement. WCAG 2.1 Level AA is specifically referenced in the ADA Title II web and mobile app rule for state and local governments. WCAG 2.2 is the newer W3C recommendation and may be the better target for future-facing accessibility work. ADACP confirms the right standard before testing begins so your audit matches the requirement you are actually facing.

How is scope decided — do you test every page?

No, and testing every page would waste the budget. We test the templates and reusable components that repeat across the product, plus the journeys that carry the business: sign-in, search, forms, checkout, account. Anything unusual, such as authenticated areas, mobile apps or documents, is agreed during scoping.

Can our developers work straight from the report?

That is what it is written for. Each finding carries the criterion, the location, reproduction steps and fix direction, so a developer can act without first translating an audit into tickets. We can also walk the team through the findings if that speeds things up.

Do you retest after we ship the fixes?

Yes. We re-check the findings, confirm what is resolved, flag anything that regressed, and update your conformance status. Without that step, fixed is an assumption rather than a fact.

Can the same audit support ADA compliance or a VPAT?

Yes, and that is deliberate. Because every finding is mapped to a success criterion, the same evidence feeds ADA compliance work and the ACR behind a VPAT. You do not pay for the same testing three times under three different names.

Do you also make the fixes?

We provide implementation-ready remediation direction and verify the result; the changes are made by your development team. If you need hands-on help, raise it in the consult and we will scope support around your team rather than assume it.

How long does a web accessibility audit take?

Most focused web accessibility audits can be completed in a matter of weeks once access, scope, and testing environments are confirmed. Larger websites, web applications, or products with multiple roles and workflows may take longer, especially if remediation and retesting are included. If you are working against a legal deadline, procurement request, VPAT requirement, or launch date, ADACP can help define the fastest credible path to complete testing and documentation.

How much does a web accessibility audit cost?

The cost of a web accessibility audit depends on the size of the website or web application, the number of templates and user flows, the WCAG version being tested, the platforms in scope, and whether remediation support or retesting is included. A focused audit of key pages and flows will cost less than a complex SaaS platform, enterprise portal, or application with multiple user roles. ADACP scopes the work first and provides a fixed quote so your team knows exactly what is included.

Can you test web applications and SaaS platforms?

Yes. ADACP tests websites, web applications, SaaS platforms, portals, dashboards, forms, and interactive workflows. For web applications, accessibility issues often appear in dynamic components, menus, modals, search tools, filters, account areas, checkout flows, and other paths that automated scans may miss. We test the product the way real users experience it and map findings to WCAG.

Who does this work

David LoPresti

Founder and CEO, ADA Compliance Professionals

David LoPresti founded ADA Compliance Professionals and works directly with software vendors, technology manufacturers, higher education institutions, and government contractors, translating WCAG requirements into practical implementation and verification processes. That is what this engagement delivers: manual and assistive-technology testing of your real user journeys, every finding tied to the success criterion it fails with steps to reproduce it, a remediation plan ranked by user impact, and a retest that records what your team resolved.

The standards this page refers to

Get a clear picture of your website accessibility

Tell us what is driving the audit: a deadline, a complaint, a buyer requirement, or a release you want tested properly, and we will scope it with you on a call.

Schedule a consult