What Happens in an Accessibility Audit, Step by Step
An accessibility audit is a careful test of your site or app that finds the barriers in its design and tells your team what to fix first.
An audit answers one question for a leader: can everyone who wants to use this product use it? It answers a second question for the team that builds the product: what do we change, and in what order?
Here is what happens in an accessibility audit, from the first conversation to the last fix.
What does an accessibility audit test against?
Most audits test against the Web Content Accessibility Guidelines, known as WCAG, at the AA level. WCAG is the international standard for accessible websites and apps, and it is the standard most laws and contracts point to. The current version is WCAG 2.2.
The guidelines are a floor, not a ceiling. A page can pass every guideline and still confuse the people who use it, so a good audit also looks at how people move through the product in real life.
Step 1: Scope and price
The audit starts with a short conversation about what to test. A small site might need its main pages and one form. A product team might need its sign-in, checkout, and account settings. You should see the scope and the price before any work begins.
Step 2: Testing
Testing happens in two layers. Automated software checks every page for problems a machine can find, such as missing labels, empty links, and low color contrast. Automated checks catch only part of the picture, so a person then tests by hand.
Hand testing covers what software cannot judge:
A screen reader user can hear every label, button, and error.
Every task works with a keyboard alone, with a visible focus outline at each step.
Video has accurate captions, and audio has a transcript.
The page still works when someone zooms in to 200 percent or more.
Text and controls have enough contrast to read.
Forms explain errors in words and keep what the person already typed.
You can try two of these tests yourself today. Read how to run a keyboard accessibility test and what a screen reader user hears on your checkout page.
Step 3: The report
The report lists every barrier, where it lives, who it affects, and the proposed fix. A useful report ranks the fixes, starting with whatever blocks people from finishing a task. A long list without an order leaves a team guessing, and guessing is expensive.
Step 4: The walkthrough
A report lands best with a conversation. In the walkthrough, the auditor explains each finding in plain language, shows it on the screen, and answers your team's questions. Designers, developers, and leaders all leave knowing what to do next.
Step 5: The fixes
Your team can make the fixes on its own or bring in help. Many fixes are small, such as adding a label or changing a color. Others touch a shared component, which fixes every page that uses the component at once.
After the fixes ship, a follow-up test confirms that each barrier is gone and that nothing new broke.
How is an A+ Audit different?
My A+ Audit is accessibility, plus. It starts from WCAG 2.2 AA and adds four more lenses: usability, trust and safety, site performance, and search engine optimization. Accessibility always leads, and the other lenses catch what stops people even when a page passes the guidelines.
You get a score, a report with my proposed fixes in the order I would make them, and a walkthrough of every finding. Then you decide whether to make the fixes on your own or bring me in.
Why test before you build more
A barrier found in a design file is a conversation. A barrier found in shipped code is a project. Read why accessibility comes first for the case to make to your leaders.