Building an ADA audit scope before you hire a consultant saves money, shortens remediation time, and prevents the most common failure I see in accessibility programs: paying for a broad audit that answers the wrong questions. In this context, ADA usually refers to the Americans with Disabilities Act, while digital accessibility work is commonly measured against the Web Content Accessibility Guidelines, currently WCAG 2.1 or 2.2, Level AA. An audit scope is the written definition of what will be tested, which systems are included, what standards apply, how findings will be prioritized, and what deliverables the consultant must provide. If that scope is vague, the audit will be vague. If it is precise, the resulting compliance work becomes manageable, budgetable, and defensible.
This matters because most organizations do not have one website, one audience, or one risk profile. They have marketing pages, authenticated tools, PDFs, mobile flows, third-party widgets, videos, and transactional paths that affect employment, education, healthcare, government services, or commerce. Each carries different legal exposure and different user impact. I have seen teams spend heavily on automated scans, then discover that the inaccessible pieces lived inside checkout, onboarding, or support workflows that scanners barely touched. A strong ADA audit scope fixes that by defining critical journeys first, then mapping tools, testing methods, and remediation expectations around those journeys.
As a hub for ADA Audits & Compliance Tools, this article explains how to define audit boundaries, choose standards, inventory assets, identify high-risk experiences, document technical requirements, compare audit methods, and prepare the information a consultant needs to price the work accurately. It also helps you connect this page to deeper implementation topics such as manual accessibility testing, WCAG issue prioritization, VPAT reviews, PDF accessibility, mobile app testing, assistive technology coverage, and remediation governance. If you build the scope before procurement, you gain leverage: better proposals, clearer statements of work, fewer change orders, and findings your internal teams can actually use.
Start with business risk, user impact, and the systems that matter most
The first step is deciding why you are commissioning the audit. Some organizations are responding to a demand letter. Others are preparing for a redesign, procurement review, merger, public launch, or policy commitment. The purpose changes the scope. A legal-risk review focuses on public-facing pages and core transactions. A design-system validation looks deeply at reusable components. A procurement diligence review may examine templates, authoring workflows, and vendor dependencies. Write the reason down in one sentence, because that sentence will shape every later decision.
Next, identify who could be harmed by barriers and where those barriers would matter most. A healthcare provider should prioritize appointment booking, patient forms, and billing. A university should prioritize admissions, course registration, learning platforms, and disability services information. An employer should prioritize careers, application forms, benefits enrollment, and employee self-service. This is not abstract. Under Title II and Title III expectations, inaccessible high-value transactions create more urgency than a low-traffic campaign page. Scope follows consequences.
Then list the digital properties in play. Include the main website, microsites, subdomains, portals, native mobile apps, downloadable documents, embedded media, kiosks if applicable, and third-party tools that appear to users as part of your service. Teams often miss help centers, scheduling platforms, chat widgets, or identity flows hosted elsewhere. If users experience them as your service, they belong in the scoping discussion even when the code is owned by a vendor.
Define audit boundaries so the consultant can estimate accurately
Good scopes answer five basic questions directly: what is in scope, what is out of scope, what standard applies, what testing depth is required, and what deliverables must be produced. Be explicit. “Audit our website for ADA compliance” is not enough. A useful statement sounds more like this: audit the public marketing site, careers section, and authenticated customer portal against WCAG 2.2 AA, including representative templates, top twenty user journeys, mobile responsive views, keyboard-only use, screen reader testing, and PDFs published in the last twelve months.
Include environment details. Consultants need URLs, page counts, platform names, CMS details, design-system usage, authentication requirements, release cadence, and whether the audit should happen in production, staging, or both. If staging differs materially from production, say so. If parts of the site are being redesigned, note that too. I have seen proposals vary by tens of thousands of dollars because one buyer disclosed component reuse and another did not.
Out-of-scope items matter just as much. If archived PDFs, legacy campaign pages, or low-value microsites will be handled later, document that choice. If a third-party payment tool cannot be tested beyond the handoff page because of contract limits, note the limitation. Clear exclusions protect both sides and reduce disputes after findings arrive.
Create an asset inventory before anyone tests a page
An ADA audit should not begin with random crawling. It should begin with an inventory. Build a spreadsheet or repository that lists every digital asset type, owner, platform, and business purpose. Separate templates from individual pages. For example, your site may have a homepage template, article template, product template, location template, and account dashboard template. Auditing representative templates is far more efficient than sampling pages blindly, especially when the design system drives repeated patterns.
Also inventory non-HTML assets. PDFs remain a persistent problem because they often contain unlabeled headings, incorrect reading order, missing tags, inaccessible form fields, and image-only scans. Videos may need captions, transcripts, and audio description analysis. Mobile apps require platform-specific review for iOS and Android accessibility APIs. If you do not list these formats during scoping, they tend to disappear from proposals and return later as expensive add-ons.
Ownership is another essential inventory field. Every in-scope asset should have an internal owner who can answer questions and receive findings. Without that, consultants end up reporting issues to a generic project mailbox, and remediation stalls. In mature programs, this inventory becomes the foundation for ongoing compliance operations, not just a one-time audit.
Prioritize critical user journeys and sample intelligently
The best audit scopes are journey-led. Instead of asking for “500 pages reviewed,” ask for representative templates plus end-to-end testing of the tasks users depend on. A critical journey is a sequence with a clear goal: find a product, compare options, add to cart, check out, and confirm; or search jobs, create an account, upload a resume, complete forms, and submit an application. Accessibility failures often emerge across steps, not on isolated pages.
Sampling should balance breadth and depth. Breadth reveals systemic problems across templates, while depth uncovers state changes, validation errors, modal behavior, focus order, and dynamic content updates. A consultant should test key states and variations: empty search results, error messages, success confirmations, expanded accordions, carousels, filters, date pickers, and document downloads. If your scope names only URLs and ignores states, the audit will miss common barriers.
| Scope Element | What to Specify | Why It Matters |
|---|---|---|
| Templates | Homepage, article, product, form, dashboard, checkout | Finds repeated defects once and applies fixes many times |
| User journeys | Top tasks with all key steps and error states | Captures barriers scanners and page samples often miss |
| Formats | HTML, PDF, video, native apps, emails if applicable | Prevents hidden accessibility debt outside webpages |
| Assistive technology | Screen readers, keyboard-only, magnification, speech input where needed | Shows whether real users can complete tasks successfully |
| Deliverables | Issue list, severity, code references, screenshots, recordings, retest plan | Makes remediation faster and vendor proposals comparable |
When volume is high, ask the consultant to propose a statistically sensible sample tied to template families and traffic tiers. Pair analytics with business criticality. A low-traffic login flow can matter more than a high-traffic blog article because the legal and functional impact is greater when a user cannot sign in, pay, enroll, or apply.
Select standards, methods, and tools with enough precision to be useful
Most organizations should scope against WCAG Level AA and specify the version. Today that usually means WCAG 2.1 AA or WCAG 2.2 AA, depending on policy commitments and procurement timelines. Some sectors may also need Section 508 alignment, EN 301 549 references, or state-specific requirements. The consultant should not have to guess which ruleset governs the work.
Testing method matters as much as the standard. Require a combination of automated and manual testing. Automated tools such as axe DevTools, WAVE, Accessibility Insights, Siteimprove, Pope Tech, Monsido, and DubBot can quickly surface missing alt text, color contrast issues, empty links, form labeling gaps, and structural errors. But automation typically catches only a portion of WCAG failures. It does not reliably judge focus management, meaningful sequence, accessible names in context, screen reader announcements, error prevention, or the usability of complex widgets. Manual testing is nonnegotiable.
Name the minimum manual coverage you expect. That usually includes keyboard-only navigation; screen reader testing with combinations such as NVDA and Firefox, JAWS and Chrome, and VoiceOver on Safari; zoom and reflow checks at 200 percent and 400 percent where applicable; color contrast verification; form error handling; and review of dynamic components such as menus, modals, tabs, carousels, and custom selects. For native apps, include TalkBack and VoiceOver testing. If speech input is relevant to your user base, state that explicitly.
Specify the outputs you need to turn findings into remediation
An audit is only valuable if the findings are actionable. Ask for issue reports that map each problem to the relevant WCAG criterion, severity, affected pages or components, reproduction steps, screenshots, code snippets where helpful, and plain-language impact on users. Severity should reflect both user impact and business criticality, not just technical elegance. A missing form label in checkout is usually more urgent than a decorative image missing alt text on a press release.
Request roll-up reporting too. Executives need a summary of systemic issues, risk themes, and remediation effort. Product and engineering teams need component-level findings they can fix once across many pages. Content teams need guidance on headings, alt text, link purpose, tables, and document authoring. If your consultant only delivers a giant spreadsheet of isolated defects, you will spend internal time reorganizing the work before anything gets fixed.
Retesting should be part of the scope. Confirm whether the consultant will validate remediations, how many rounds are included, and whether updated conformance statements or VPAT support are available. This is especially important when accessibility findings affect procurement, public commitments, or litigation response.
Prepare internal documentation before you issue an RFP or request a proposal
Consultants price certainty. The more organized your inputs, the better their proposals. Assemble a scoping packet with URLs, app store links, analytics on top tasks, asset counts, authentication instructions, test accounts, platform architecture, known accessibility issues, current tools, design-system documentation, and any policies already in force. Include whether teams can remediate code, content, and documents internally or expect outside support. These details determine not just audit cost, but the shape of remediation work that follows.
Also decide how findings will be consumed. Will issues flow into Jira, Azure DevOps, or another ticketing system? Do you need CSV exports, dashboards, or presentations? Should results separate defects by team ownership, such as engineering, content, design, procurement, or legal? On large programs, these operational questions matter as much as the testing itself because they affect how quickly barriers are removed.
Finally, define success. A realistic ADA audit scope does not promise perfect compliance forever. It aims to identify material barriers within agreed boundaries, provide enough evidence to prioritize fixes, and establish a repeatable process for ongoing monitoring. Write that expectation into your internal plan before you hire anyone. Then ask prospective consultants to respond to the scope, explain their methodology, and show sample deliverables. The payoff is simple: you buy the right audit, your teams get findings they can use, and users encounter fewer barriers where it matters most. If you are building a compliance and implementation program, start by drafting the scope now, then use it to compare consultants on substance rather than sales language.
Frequently Asked Questions
What is an ADA audit scope, and why should you define it before hiring an accessibility consultant?
An ADA audit scope is the written plan that defines exactly what will be reviewed, how it will be tested, which standards will be used, who the intended users are, what deliverables you expect, and what business questions the audit needs to answer. In digital accessibility, that usually means clarifying that the work will be measured against WCAG 2.1 or WCAG 2.2 Level AA, even though the broader legal discussion often references the Americans with Disabilities Act. Creating that scope before you hire a consultant helps you avoid one of the most expensive mistakes organizations make: paying for a large, generic audit that produces a long list of issues but does not help the team make practical remediation decisions.
When your scope is clear, consultants can estimate effort more accurately, compare proposals on equal footing, and focus on the parts of your website, app, or platform that matter most. That saves money because you are not paying for unnecessary testing, duplicate review, or vague recommendations. It also shortens remediation time because your internal teams get findings tied to real workflows, priority templates, and actual user risk instead of a massive report with no implementation path. In other words, a well-defined scope turns the audit from a broad compliance exercise into a decision-making tool that supports legal risk reduction, better user experience, and smarter budgeting.
What should be included in an effective ADA audit scope document?
A strong audit scope should identify the digital properties being reviewed, such as public websites, authenticated portals, mobile apps, PDFs, multimedia content, or third-party integrations. It should also define the specific pages, templates, screens, and user journeys that matter most. For example, instead of saying “audit the website,” a better scope might say “audit the homepage, product listing pages, product detail pages, search, navigation, forms, account creation, checkout, and customer support flows.” That level of detail prevents confusion later and ensures the consultant evaluates the experiences that carry the highest user and business impact.
The document should also state the conformance target, typically WCAG 2.1 or 2.2 Level AA, along with the test methods expected. A complete scope usually includes automated scanning, manual keyboard testing, screen reader testing, form validation review, focus management checks, semantic structure analysis, color contrast testing, and, where relevant, testing of dynamic components and documents. It should also define environments and platforms, such as desktop and mobile browsers, operating systems, and assistive technologies. Finally, it should spell out the expected deliverables: issue reports, severity ratings, screenshots or code references, remediation guidance, executive summaries, and any retesting or validation support. The more precise you are upfront, the more useful and actionable the final audit will be.
How do you decide which pages, templates, and user flows to include in the audit scope?
The most effective way to build scope is to prioritize by risk, usage, and business importance. Start with the experiences people rely on most: your homepage, navigation, search, forms, login, registration, e-commerce checkout, scheduling tools, account management, customer service, and any function tied to conversion, compliance, or core service delivery. If your site uses templates, components, or design system patterns, it is often more efficient to scope representative examples rather than every individual page. That approach gives you broad coverage without wasting budget on repetitive testing.
You should also look for high-risk areas that tend to generate accessibility failures, such as custom widgets, modals, accordions, carousels, video players, PDF downloads, and embedded third-party tools. If certain content is required for employment, education, healthcare, government services, payments, or legal disclosures, include it even if traffic is lower. The goal is not to test everything at once; it is to capture the parts of the experience that best represent the whole system and expose the biggest barriers. A consultant can help refine this later, but if you define these priorities first, you make sure the audit answers the right operational questions instead of simply producing a broad inventory of defects.
What mistakes should organizations avoid when creating an ADA audit scope?
The biggest mistake is using vague language. Phrases like “audit our website for ADA compliance” sound straightforward but leave too much open to interpretation. Without specificity, one consultant may review ten pages while another reviews fifty, one may test only with automation while another includes manual and assistive technology testing, and one may benchmark against WCAG 2.1 while another uses WCAG 2.2. That makes proposals hard to compare and often leads to disappointing results. Another common mistake is focusing only on public-facing pages while ignoring critical authenticated experiences, documents, embedded tools, or mobile interactions that may create even greater user barriers.
Organizations also run into trouble when they fail to define the audit’s purpose. Are you trying to support a redesign, prepare for litigation risk reduction, improve a procurement review, validate a design system, or build a phased remediation roadmap? The answer affects what should be tested and how findings should be delivered. Other frequent problems include excluding key stakeholders, underestimating the role of PDFs and media, forgetting third-party vendors, and requesting a report without requiring remediation guidance. A good scope should not just ask what is broken. It should ask what the organization needs to learn, fix, and prioritize in order to improve accessibility efficiently.
How can a well-built ADA audit scope save money and speed up remediation after the consultant is hired?
A well-built scope reduces wasted effort at every stage of the engagement. Before the audit begins, it helps you get more accurate bids because consultants can estimate effort based on known assets, flows, and testing expectations. During the audit, it keeps the review focused on the pages and interactions that will produce the most meaningful findings. After the audit, it gives developers, designers, content owners, and leadership a report they can actually use. Instead of a generic compliance document, they receive prioritized issues tied to real templates, components, and business processes. That means less time sorting findings, fewer clarification meetings, and faster handoff into remediation planning.
It also saves money by helping your organization phase the work intelligently. If the scope is written around representative templates, critical workflows, and repeatable components, a single audit can uncover system-level issues that explain barriers across large sections of the site. Fixing those patterns often resolves many downstream problems at once. In practical terms, that shortens remediation timelines and improves return on the audit investment. Just as important, a strong scope helps prevent rework. When the consultant knows your technology stack, environments, conformance target, and reporting needs upfront, the final deliverables are far more likely to align with how your team actually builds and ships accessible digital experiences.
