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.
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.
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 auditTrusted by leading brands
We are proud of our customers
Common questions about accessibility audits and testing
What is a WCAG audit?
What is included in a WCAG audit report?
Is a WCAG audit the same as an ADA audit?
Do automated WCAG checkers catch everything?
What is the difference between WCAG 2.1 and WCAG 2.2?
What is a WCAG check?
What is WCAG used for?
What are WCAG violations?
How do you prove WCAG compliance?
What happens if a website does not follow WCAG?
What is a WCAG checklist?
Who does this work
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
- WCAG conformance levels and success criteria, from the W3C Web Accessibility Initiative
- WCAG 2.2, the current W3C Recommendation, including the criteria it adds beyond 2.1
- WCAG-EM, the W3C methodology for evaluating a whole website rather than single pages
- The ADA Title II web rule, which sets WCAG 2.1 Level AA for state and local government
- The Revised Section 508 ICT standards, from the U.S. Access Board
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 (opens in new tab)