An accessibility audit is a structured, evidence-based review of a website, app, document, or kiosk that finds the barriers stopping people with disabilities from completing a task. Auditors test against WCAG success criteria with a mix of automated scans and hands-on testing, score every finding by severity, and hand back a prioritized remediation plan. Understanding how accessibility audits work comes down to five stages: set the scope, test the product, classify the findings, report them, and fix them.
Most teams meet the topic at the worst possible moment, when a procurement officer asks for a VPAT or a resident emails about a page they cannot read. By then the barrier has been shipping for months. The better moment is before a redesign, when a template can be fixed once instead of a thousand pages.
Table of Contents
- What Is an Accessibility Audit?
- How Accessibility Audits Work Across Five Stages
- What Does an Audit Review?
- How Accessibility Audits Work on Kiosks, PDFs and Apps
- Which Testing Methods Are Used?
- How Accessibility Audits Work With WCAG
- How Are Findings Prioritized?
- What Should an Accessibility Audit Report Include?
- How Do Teams Turn Audit Findings into Fixes?
- How Often Should a Team Run an Accessibility Audit?
- Frequently Asked Questions
- What does an accessibility audit cost?
- Can automated tools replace manual accessibility testing?
- Which WCAG level should we audit against?
- How long does an accessibility audit take?
- Does an accessibility audit guarantee legal compliance?
- What accessibility issues do automated scanners miss?
- Conclusion: Start With the Task Users Are Trying to Finish
What Is an Accessibility Audit?
An accessibility audit is a formal evaluation of how usable a digital product is for people with disabilities, measured against a published standard. It produces a list of concrete problems, each tied to a specific success criterion, an affected page or flow, a severity score, and a suggested fix.
Who performs one depends on the reason for the audit. In-house teams usually run the automated baseline and triage the results. Specialist consultants do the manual testing and the formal conformance work. Public-sector teams sometimes bring in an accessibility user who tests real tasks with their own assistive technology, which is the part no scanner can replicate.
The digital experiences covered go well beyond a website. Mobile apps get tested with TalkBack and VoiceOver. PDFs need document remediation and a check that tags survived export. Self-service kiosks are tested for screen height, reach, audio output, and time limits. Maps, dashboards, and open data portals are tested for keyboard operability and for whether a data table offers the same content as the graphic.
An initial audit and ongoing compliance work are also different things. The initial audit is a one-time assessment that produces a baseline and a fix list. Ongoing work is a habit: automated scanning in the build pipeline, manual checks before each release, and periodic re-audits after meaningful change. Teams that treat the audit as a single event keep rediscovering the same contrast failures a year later.
How Accessibility Audits Work Across Five Stages
The mechanics of an audit rarely change, whether it covers a small brochure site or a municipal service with thousands of pages. Here is how accessibility audits work stage by stage, along with what each stage produces.
- Define the scope and the conformance target. The auditor and the team agree on which assets are in scope: templates, key flows, documents, or the whole estate. They also agree on the standard, usually WCAG 2.2 Level AA, and any legal overlay such as Section 508 for a federally funded project or EN 301 549 for a European public service. Output: a written scope statement and a list of the most important user flows.
- Review the product. This is the hands-on stage. The auditor walks each flow by keyboard, runs an automated scanner for the mechanical failures, tests with at least one screen reader, checks zoom and reflow, and reads the content for structure and clarity. Output: a raw issue list with reproduction steps for each one.
- Classify the findings. Every issue is mapped to a WCAG success criterion and scored for user impact and urgency. A missing label on a payment field and a decorative image with redundant alt text are both findings, but they are not the same size of problem. Output: a severity-ranked list, usually grouped by affected template.
- Report and recommend. Findings are written up with evidence, the affected scope, the standard reference, and the recommended fix. The auditor explains which fixes are quick wins and which need design or engineering work. Output: the audit report and a remediation roadmap.
- Fix and retest. Owners are assigned, work is scheduled, and the auditor retests the changed items to confirm the fix landed without breaking something else. Output: a retest result and an updated conformance statement.
What Does an Audit Review?
The review checklist is longer than most teams expect, and it covers behavior as much as markup. Reviewers look at nine areas.
Keyboard access. Can you reach and operate every control without a mouse? Is there a keyboard trap, where focus enters a component and cannot leave? Does the page offer a skip link to the main content, and is the focus indicator visible against the background?
Screen reader output. Does each control expose an accessible name? Is the accessibility tree sensible, or does a div-based button announce as an unlabeled group? Are dynamic updates announced through a live region instead of appearing silently?
Color and contrast. Body text needs a contrast ratio of 4.5:1 and large text 3:1. Color alone is not allowed to carry meaning, which is where the red-and-green status pills on a permit tracker usually fail.
Focus states and order. Tab order should follow the visual reading order, and focus should never land somewhere invisible. On a booking or payment flow, an invisible focus ring makes the whole page unusable.
Forms and error messages. Every field needs a programmatic label, error text has to name the field and say what to do, and errors should be identified in text rather than color alone. A 311 request form with placeholder-only labels is one of the most common failures in civic services.
Navigation and structure. One H1 per page, headings that descend in order without skipping levels, landmarks for the header, nav, main, and footer, and page titles that describe the destination rather than the department.
Multimedia. Prerecorded video needs synchronized captions, audio needs a transcript, and anything that flashes more than three times a second fails the seizure criterion.
Mobile interaction. Tap targets should be at least 24 by 24 CSS pixels, and pinch-zoom should not be disabled. Content should reflow at 320 pixels wide without two-dimensional scrolling.
Content structure and reflow. Zoomed text to 200 percent, spacing overrides applied, and the layout still readable. This is where long sidebar blocks and fixed-width tables break.
How Accessibility Audits Work on Kiosks, PDFs and Apps
Digital teams often treat these as afterthoughts, then wonder why a finding lands at the end. Each asset needs its own method.
A kiosk audit starts with the physical setup. Mount height, reach range, screen angle, glare, and audio volume all count, because a perfectly coded screen is unusable from a wheelchair at the wrong height. Kiosks also need generous time limits, visible focus, and a way to back out of a flow without losing entered data.
PDF remediation is a different craft. The file needs a correct reading order, tagged headings, a language setting, and meaningful link text. After remediation you export an accessible PDF and test that file rather than the source document, because tagging is often lost in the export.
Mobile app audits follow the same WCAG criteria but use mobile assistive technology: TalkBack on Android, VoiceOver on iOS, switch access, and voice control. Custom gestures deserve special attention, since a swipe-only interface has no keyboard equivalent on a phone.
Which Testing Methods Are Used?
An accessibility audit combines methods, because no single one covers the ground. Knowing what each method catches keeps teams from trusting a clean scan.
| Method | What it finds | What it misses | Typical effort |
|---|---|---|---|
| Automated scan | Missing alt attributes, contrast failures, unlabelled inputs, duplicate IDs, broken heading order, reflow errors | Meaning and context: whether alt text is useful, whether tab order makes sense, whether a heading structure reflects the content | Minutes per site, near-zero marginal cost per page |
| Manual code and content review | Markup problems tools skip: ARIA misuse, incorrect roles, focus management in dialogs, vague link text, heading logic | Anything that depends on how a real person moves through the interface | Roughly 1 to 3 hours per screen or template for a full WCAG 2.2 AA review |
| Keyboard walkthrough | Keyboard traps, missing visible focus, illogical tab order, controls that cannot be operated without a mouse | Screen reader announcement quality, zoom and reflow, content clarity | 20 to 40 minutes per flow |
| Screen reader testing | Missing accessible names, confusing announcements, wrong reading order, live regions that never fire, custom widgets that announce as generic groups | Visual presentation, color, anything requiring vision to confirm | 1 hour or more per flow, once the tester is fluent |
| Testing with disabled users | The combination no method models: a screen reader user plus voice control, a switch user, someone at 400 percent zoom working under time pressure | Broad coverage. Useful for priorities, not for exhaustive conformance checking | A day of sessions changes the priority order more than a week of scanning |
Practitioners on accessibility forums describe the pattern consistently: a clean automated scan gives false confidence, and a single session with a real user exposes the barrier that mattered. The reverse is also true. Manual testing alone on a large estate never finishes, so most mature teams run scanning continuously and spend manual effort where traffic and task criticality are highest.
The assistive technology matrix below is the pairing most teams find useful, because each tool stands in for a different user situation.
| Test with | Stands in for | What it uncovers |
|---|---|---|
| Keyboard only, no mouse | Motor impairments, switch users, some cognitive disabilities | Traps, focus order, invisible focus rings, mouse-only controls |
| NVDA on Windows | Blind and low-vision desktop users | Accessible names, roles, states, live regions, reading order |
| JAWS on Windows | Long-time screen reader users and enterprise workflows | The same as NVDA plus complex grid and form behaviour that experienced users hit daily |
| VoiceOver on iOS and macOS | Mobile screen reader users, including VoiceOver rotor navigation | Touch target issues, rotor order, gesture dependence, Voice Control access |
| TalkBack on Android | The large Android user base, including older devices and low bandwidth | Android-specific semantics, gesture alternatives, performance on constrained hardware |
| Voice control (Voice Control, Dragon) | People with motor disabilities, tremor, or limited hand use | Controls with no visible text label, icons with no accessible name, custom gestures |
| Browser zoom to 200 percent and 400 percent | Low-vision users | Reflow failures, text clipped by fixed heights, content hidden behind hover states |
| Switch access or a large-button setup | People with severe motor disabilities | Sequencing problems, time limits, actions that require simultaneous input |
On a browser-based service, you rarely need every row. Keyboard, one screen reader pair, voice control, and high zoom will find the overwhelming majority of real barriers.
How Accessibility Audits Work With WCAG
WCAG 2.2 is the reference every audit measures against. It is organized into principles, guidelines, and success criteria, and each criterion is a single testable requirement such as “images have text alternatives” or “color contrast is at least 4.5:1”. That structure is what lets an audit be objective: a finding either meets a criterion or it does not.
The three conformance levels matter. Level A covers the barriers that make content unusable outright. Level AA adds the requirements most organizations must meet, including contrast, visible focus, and captions for live media. Level AAA covers enhanced requirements such as sign language for audio content, which very few sites target.
Most audits target Level AA, and public-sector work often has no choice. Section 508 in the United States incorporates WCAG 2.0 Level AA into federal procurement requirements, and the European Accessibility Act leans on harmonized standard EN 301 549, which also maps to WCAG. ADA Title III obligations for state and local government in the US reach the same territory through a different legal route.
One distinction matters legally: an audit identifies issues against a standard, but it is not a legal opinion on whether an organization complies with any particular statute. Courts and agencies make that call. A good report says what failed, against which criterion, and leaves the legal conclusion to the organization.
The numeric thresholds auditors check most often:
| Check | Threshold at Level AA |
|---|---|
| Text contrast | 4.5:1 for normal text, 3:1 for large text (18pt regular or 14pt bold and above) |
| Non-text contrast | 3:1 for icons, focus indicators, and meaningful graphics |
| Text resize | 200 percent without loss of content or function |
| Reflow | 320 CSS pixels wide with no two-dimensional scrolling |
| Target size | 24 by 24 CSS pixels minimum, with spacing exceptions |
| Line height | Content survives 1.5 times line height and paragraph spacing overrides |
| Focus visible | A visible indicator on every keyboard-focusable element |
| Timeouts | Extendable, adjustable, or disabled unless essential |
Public bodies often go one step further and publish a VPAT, or Accessibility Conformance Report, which maps every criterion to Supports, Partially Supports, or Does Not Support, with explanations. That document is not a marketing claim. It is a record of known gaps, and buyers ask for it.
How Are Findings Prioritized?
Priority comes from user impact, not from how many tools flagged an issue. A report with 400 findings and no ordering is the single most common reason remediation stalls, because nobody can defend a schedule built on it.
Five inputs drive the score:
- User impact. Can the user complete the task at all, or is it slower and more effortful?
- Task criticality. Paying a bill, booking an appointment, or reporting a pothole matters more than a footer link.
- Frequency. How many people hit this flow, and on which templates?
- Number of users affected. A barrier hitting a large group outranks an obscure one affecting three people.
- Effort to fix. A one-line alt text fix and a redesign of a checkout both matter, but only one can ship this week.
| Severity | What it means | Typical response |
|---|---|---|
| Blocker | Blocks a core task entirely for a group of users | Fix before the next release |
| Critical | Makes a core task substantially harder, or blocks a secondary task | Fix within the current sprint cycle |
| Serious | Causes real difficulty but has a reasonable workaround | Schedule in the next planned release |
| Moderate | Friction that most users push through | Add to the backlog and batch with related work |
| Minor | Technical or consistency issue with limited user effect | Fix opportunistically |
The second half of prioritization is scope compression. Fixing one contrast token in the design system repairs every instance across the estate. A useful audit report groups findings by root cause, not just by page, because that is how the fix list gets short enough to act on.
What Should an Accessibility Audit Report Include?
A report you can actually work from has nine parts. If one is missing, ask for it before the work starts.
- Executive summary. What was tested, what the overall state is, and the handful of findings that matter most.
- Scope and methodology. Which pages, templates, devices, and assistive technologies were covered. This tells you what the report does not claim.
- Conformance target. The standard and level the audit measured against, plus any legal framework in play.
- Findings by success criterion. Each issue listed with its WCAG reference so the team can look up the intent.
- Severity and affected scope. How bad it is and how many pages share the problem.
- Evidence. A screenshot, a short script, or the exact steps to reproduce it. Findings without evidence get disputed.
- Recommended fix. The specific change, not “improve accessibility”. Concrete code or markup beats a principle.
- Pass and fail counts. Criteria met, criteria partially met, criteria failed. This is the number a manager reads.
- Retest results. Which items were verified after the fix and which remain open.
Groups that publish their conformance status online, usually in an accessibility statement, get more out of the same audit. The statement sets out the standard used, known issues, and a contact route for reporting a barrier, and it forces the team to write down what it does not yet support.
How Do Teams Turn Audit Findings into Fixes?
The remediation step is where most audits quietly die. A report lands, engineering assumes everything is a bug, and the low-hanging items get fixed while the structural ones drift. A workable workflow assigns the work properly.
- Triage within a week. Get the report in front of design, engineering, content, and the service owner together. Mark each blocker with a named owner and a date. Anything unassigned will stay unfixed.
- Split the work by discipline. Color tokens, type scale, and focus styles are design decisions. ARIA, focus management, and semantic markup are engineering work. Heading structure, link text, captions, and form instructions are content work. Trying to route all of it through developers is how accessibility budgets get blown.
- Fix at the template layer. Most findings live in a shared component. Fixing the component once beats fixing the symptom on 300 pages, and it prevents the regression from coming back.
- Add checks to the pipeline. Run the scanner on pull requests and fail the build on new errors. Pair it with a short manual checklist for anything the scanner cannot see.
- Retest and close. Verify the fixed items, confirm nothing regressed, and update the conformance record.
For civic and public-sector teams, add a step: publish the conformance status and the known gaps. Residents who hit a barrier need somewhere to report it, and a published statement turns scattered emails into a tracked list.
How Often Should a Team Run an Accessibility Audit?
Most teams need a full audit once a year at minimum, plus automated scanning continuously and targeted manual checks in every release. The exact rhythm depends on how fast the product changes.
Run a full audit when a product is new, when a major redesign touches navigation or layout, when the service adds a new transaction type, and after a platform migration such as moving to a new CMS or design system. On a large municipal estate, audit one journey at a time, starting with the highest-traffic and most task-critical flows: applying for a permit, paying a bill, reporting an issue, booking an appointment.
Content-heavy services change more often than that. Publishing calendars, seasonal campaigns, and rapidly updated dashboards deserve quarterly checks, because new content arrives with fresh templates and fresh mistakes.
None of this replaces building accessibility into design and development. An audit finds what shipped; a design system with accessible components stops the problem from being created. Treat the audit as a safety net, not the practice.
Frequently Asked Questions
What does an accessibility audit cost?
Most small sites with a handful of templates fall in the low thousands of dollars, while large public or commercial estates run into five figures. The price tracks scope, not page count alone. A focused audit of one journey costs far less than an estate-wide review, and the manual share dominates the cost: practitioners report two to three hours per screen or template for a full WCAG 2.2 AA review. Automated scanning is cheap or free; the expensive part is skilled human testing and the remediation follow-through.
Can automated tools replace manual accessibility testing?
No. Automated scanners reliably catch mechanical failures such as missing alt attributes, low contrast, unlabelled inputs, and broken heading order. They cannot judge whether alt text is meaningful, whether tab order follows the visual reading order, whether an error message explains how to fix the problem, or whether a custom widget announces usefully to a screen reader. Treat a clean scan as a baseline, not a result.
Which WCAG level should we audit against?
Level AA is the standard target for almost every organization. Level A covers only the most severe barriers, and Level AAA targets enhanced requirements such as sign language for video that few sites attempt. In the United States, Section 508 incorporates WCAG Level AA into federal procurement rules, and in Europe the European Accessibility Act points to harmonized standard EN 301 549, which also references WCAG.
How long does an accessibility audit take?
An automated scan of a moderate site takes minutes. Manual testing takes considerably longer: practitioners report two to three hours per screen or template, plus time to write up findings. A focused audit of one critical journey can finish in a week. An estate-wide audit with dozens of templates runs in weeks or months, which is another reason to prioritize journeys rather than crawl every page.
Does an accessibility audit guarantee legal compliance?
No. An audit reports where a product fails specific success criteria under a named standard. Whether that constitutes a violation of the ADA, Section 508, the European Accessibility Act, or an equivalent law is a legal determination made by a court or a regulator, not by an auditor. Publish your results, fix what you can, document known gaps, and get qualified legal advice on the rest.
What accessibility issues do automated scanners miss?
The list is long and predictable: alt text that is technically present but useless, logical reading order, focus order across a complex layout, custom ARIA widgets, keyboard traps inside composite components, time limits, captions that exist but drift out of sync, and any problem where the meaning depends on layout or context. Voice control also exposes gaps automated tools miss, such as icon buttons with no visible text label.
Conclusion: Start With the Task Users Are Trying to Finish
If you do one thing after reading this, list the three journeys your users depend on most, then audit those flows with a mix of methods rather than a scanner alone. Keyboard first, then a screen reader, then high zoom, then one session with a person who actually relies on assistive technology daily. Sort what comes back by whether a user can finish the task, fix the blockers at the template layer, and run the scanner on every build from then on.
That is how accessibility audits work in practice: not a document you file away, but a loop that runs from scope to retest and tells you exactly who is still being left out.
