An accessibility audit for a web application starts with selecting a qualified provider, defining the scope of the evaluation, and agreeing on the WCAG conformance level. The provider then evaluates the application screen by screen, identifying accessibility issues across interactive components, forms, navigation, dynamic content, and workflows. The result is a detailed report that maps each issue to a specific WCAG criterion with steps for remediation.
Web applications carry more complexity than static websites. State changes, dynamic content, custom controls, and multi-step workflows all require evaluation by a person who understands how assistive technology interacts with code. Automated scans only flag approximately 25% of issues, and they miss most of the interaction patterns that define a web app experience.
| Factor | Detail |
|---|---|
| WCAG Standard | WCAG 2.1 AA is the current audit standard for most organizations |
| Evaluation Method | Screen-by-screen (manual) evaluation by a qualified auditor using assistive technology |
| What Scans Cover | Approximately 25% of issues; scans miss dynamic interactions and state-dependent content |
| Typical Cost Range | $4,000 to $12,000+ depending on scope and complexity |
| Deliverable | A report mapping each issue to WCAG criteria with severity, location, and remediation guidance |
| Turnaround | 2 to 6 weeks depending on application size |
Why Web Applications Need a Different Approach
A marketing website is mostly static content. A web application is interactive. Users create accounts, fill out forms, navigate dashboards, trigger modals, filter data, and move through multi-step processes.
Each of these interactions must be operable with a keyboard, communicated properly to screen readers, and visually perceivable under WCAG 2.1 AA. A scan cannot evaluate whether a custom dropdown announces its selected value to a screen reader. It cannot determine whether a multi-step checkout retains focus correctly when moving between steps.
A (manual) accessibility audit evaluates all of this. It is the only way to determine WCAG conformance for a web application.
What Does the Audit Process Look Like?
The process follows a predictable sequence. Here is what to expect from start to finish.
1. Scoping: The provider reviews the application and determines which screens, user flows, and roles will be evaluated. For large applications, a representative sample is selected. The scope directly affects cost and turnaround time.
2. Access and environment setup: The auditor needs access to the application. For SaaS products, this usually means a staging environment or test account with appropriate permissions. If the application has multiple user roles, each role may need a separate account.
3. Evaluation: The auditor works through each screen and user flow, evaluating against WCAG 2.1 AA criteria. This includes keyboard navigation, screen reader interaction, color contrast, form labeling, error handling, focus management, and ARIA implementation. Every issue is documented with its location, the WCAG criterion it maps to, and guidance on how to fix it.
4. Report delivery: The final report organizes issues by severity, screen, or WCAG criterion depending on the provider. A quality report gives developers enough context to begin remediation without guesswork.
5. Post-audit support: Some providers offer a follow-up period where developers can ask questions about specific issues. Accessible.org includes post-audit support as part of every engagement.
How to Choose an Audit Provider
Not every accessibility company evaluates web applications well. Static websites are straightforward. Web apps require auditors who understand JavaScript frameworks, dynamic DOM updates, ARIA roles and states, and how screen readers interpret custom components.
When evaluating providers, look for these indicators:
- Experience with web application accessibility projects specifically, not only marketing sites
- Screen reader evaluation as a standard part of the audit, not an add-on
- Reports that map issues to specific WCAG criteria with developer-ready remediation steps
- A clear scoping process that accounts for user roles, states, and dynamic content
Ask for a sample report before committing. The quality of the report determines how useful the audit will be for your development team.
How Much Does a Web App Accessibility Audit Cost?
Cost depends on the size and complexity of the application. A focused evaluation of a single-role SaaS product with 15 to 20 screens can start around $4,000. A larger application with multiple user roles, complex workflows, and dozens of unique screens can reach $12,000 or more.
The cost reflects the time an auditor spends working through every interaction. Each custom component, each conditional state, each user flow adds evaluation time. There is more detail on pricing in this breakdown of web app audit costs.
For organizations that also need an ACR (Accessibility Conformance Report) for procurement, the audit can often serve as the foundation for that document. The audit identifies the issues; the ACR communicates the product’s conformance status to buyers.
What Happens After You Receive the Report?
The report is the starting point, not the finish line. Development teams use it to prioritize and fix the issues identified during the evaluation.
Prioritization matters. Not every issue carries the same weight. A form that cannot be submitted with a keyboard affects core functionality. A contrast ratio that falls slightly below the threshold on a secondary page is less urgent. Risk Factor or User Impact prioritization formulas help teams sequence their remediation work. Accessible.org audit reports include severity ratings that support this process.
Many teams load audit issues into a project management tool or an accessibility tracking platform. The Accessibility Tracker Platform is designed for this workflow, allowing teams to upload audit results, assign issues to developers, and track progress toward conformance.
After remediation, a follow-up evaluation confirms the fixes are correct. This is sometimes called a re-audit or validation pass. It closes the loop and confirms that the application has moved closer to WCAG 2.1 AA conformance.
Can a Scan Replace an Audit for a Web Application?
No. Scans and audits are completely separate activities. A scan checks code patterns against known rules. It identifies issues like missing alt text, insufficient color contrast, or absent form labels. That covers approximately 25% of issues.
The other 75% requires human evaluation. Can a keyboard user complete the checkout flow? Does the modal trap focus correctly? Does the screen reader announce error messages when they appear? Does the data table communicate its structure? None of this is detectable by a scan.
Scans have their place as a monitoring tool between audits. But a (manual) accessibility audit is the only way to determine whether a web application conforms to WCAG.
Frequently Asked Questions
Do I need to fix everything before getting an ACR?
No. An ACR documents the current conformance status of your product, including known issues. Many organizations get the audit, fix the most critical issues, and then produce the ACR. The ACR is honest about what conforms and what does not. Fixing issues first improves the ACR’s content, but it is not a prerequisite.
How often should a web application be audited?
After every significant product update that changes the user interface or introduces new functionality. If the application is actively developed, an annual audit at minimum keeps conformance from drifting. ACRs lose freshness as the product changes, so the audit schedule and the ACR update schedule often align.
What WCAG version should the audit evaluate against?
WCAG 2.1 AA is the standard for most organizations in 2025. It is referenced by ADA Title II, Section 508, and the European Accessibility Act. Some organizations opt for WCAG 2.2 AA, which adds criteria focused on authentication and dragging interactions. Your provider can help determine which version fits your regulatory and contractual requirements.
Does the auditor need access to source code?
Not typically. Most accessibility audits evaluate the rendered output in the browser, the same way a user experiences the application. The auditor inspects the DOM, evaluates ARIA usage, and interacts with the interface using assistive technology. Source code access can be helpful in specific cases but is not required for a thorough evaluation.
Getting an accessibility audit for a web application is a defined process with clear steps: scope, evaluate, report, remediate. The complexity of web apps makes (manual) evaluation essential, and the report it produces gives development teams a concrete path toward WCAG conformance.
Contact Accessible.org to scope an accessibility audit for your web application.
