How do you do an accessibility audit?

In short

An accessibility audit means using your product the way someone with a visual, hearing, motor or cognitive disability would. The benchmark is WCAG. In my audits I target WCAG 2.2 level AA.

Accessibility test, accessibility review and a11y audit are different names for the same work. “a11y” is short for accessibility: there are 11 letters between the a at the start and the y at the end.

I don't sell accessibility as a separate product. The core WCAG 2.2 checks are already part of the UX Audit. What the criteria say is in the WCAG guide. This page is about the test itself: where and how I look.

• An automated scan is only the start. The real test is done by a person with a keyboard, a screen reader and at 320 pixels wide.
• Every finding is tied to a screen, a WCAG criterion and a fix.

When to have an audit

An audit is cheapest while the design is still in Figma. Light grey help text, or an error shown only through colour, takes minutes to fix there. After release, the same fix needs a code change and a new version.

I recommend an audit in these cases:

• Before a new product or a big redesign goes live.
• When a user writes that they couldn't finish a task with a screen reader or keyboard.
• When a new component goes into the design system. An error in the button travels to every screen the button is on.
• When a public body or a client asks you for WCAG conformance. Where the law points to WCAG is in the WCAG guide.

Who audits matters too. The team that uses the product every day easily misses barriers, because it knows how the screen is supposed to work. An outsider notices on the first try that the menu won't open with the keyboard.

The WAI also mentions experts who know first-hand how people with different disabilities use the web. They can judge problems that individual users wouldn't find.

In the audit I do my own checks. Where possible, I also recommend a short round with real users to the team.

Don't treat the audit as a once-a-year ceremony. Going through the main flow with the keyboard at every big release stops errors from piling up.

Automated and manual testing: the difference

Automated tools are fast, but they don't have the last word. The W3C's Web Accessibility Initiative (WAI) says it plainly: evaluation tools can't determine accessibility, they can only help.

According to the WAI guide to selecting tools, some checks can't be automated and need human judgement. The same guide says tools sometimes give false or misleading results. Zero errors in a tool report therefore doesn't mean the site is accessible.

Alt text shows this well. According to the WAI's Easy Checks page, an automated test can tell whether the alt attribute is missing. Whether the text fits is decided by someone who sees the image in context.

I wrote the table below from my own practice:

Check	What the tool does	What the person does
Alt text	Checks whether the alt attribute is missing.	Decides whether the text describes what the image is for.
Form labels	Finds fields without a label.	Reads whether the label says what the field wants.
Contrast	Measures the ratio for text on a solid background.	Measures text on photos or gradients by hand.
Focus	Usually says nothing.	Tabs through and sees whether the ring is visible and the order makes sense.

A user test alone isn't enough either. According to the WAI page on involving users, testing with users with disabilities uncovers usability problems that a conformance review alone doesn't find. The same page adds that a user test alone can't determine whether a site is accessible.

A good audit therefore combines both methods.

My order

I run the automated scan after the first manual round. First I go through the screen like a user and note where I get stuck. That way the tool's list doesn't steer me from the start.

After the scan I put both lists side by side. If the tool found something I missed, I go back to that screen. If the tool flags something as an error but I see no barrier on screen, I open the code and look myself. Only findings I confirmed with my own eyes go into the report.

The WAI page on users makes one more point. A user with a disability doesn't necessarily know how other people with the same disability use the web. So I don't read one user's comment as a general rule either.

The audit, step by step

I start an audit with a scope: which flows and which WCAG level I look at. In WCAG-EM, the W3C's evaluation methodology, defining the scope is also the first step. Then on every chosen screen I work in this order.

Next to each step I wrote the matching WCAG 2.2 criterion. The full list is in the WCAG guide.

1. Keyboard (2.1.1, A)

Put the mouse away and try to finish the main flow with only Tab, Shift+Tab, Enter, Space and the arrow keys. According to WCAG 2.2, all functionality of the content has to be operable through a keyboard interface. I pay special attention to drop-down menus, the X that closes a dialog, and date pickers.

The only exception is functionality that depends on the path of the user's movement, such as freehand drawing. When a card is dragged into a list, the path doesn't matter. So dragging is not covered by the exception and has to work with the keyboard too.

2. Focus (2.4.3, A; 2.4.7 and 2.4.11, AA)

While navigating with the keyboard I ask three questions. Is the focus ring visible on every element? Does focus follow the reading order on screen? Does the focused element disappear under a sticky header or a cookie banner?

2.4.11 requires that the focused element is not entirely hidden by content added by the page's authors. The W3C names sticky headers and footers as a typical example. In the demo below you can try the first two questions yourself.

3. Contrast (1.4.3, AA)

For normal text the contrast ratio between text and background has to be at least 4.5:1, for large text at least 3:1. According to WCAG, large text is at least 18 point, or 14 point bold. By the W3C's calculation that is about 24 and 18.5 pixels.

I measure body text, help text, placeholders, button text and error messages one by one. You can find the ratio of two colours with the contrast checker.

4. Alt text (1.1.1, A)

Every image that carries information needs a text alternative that serves the same purpose. The alt text of a product photo describes the product, for example “Navy linen shirt, long-sleeved”. The word “image” or the file name doesn't do that.

Decorative images follow the opposite rule. The W3C requires them to be marked up so assistive technologies can ignore them. The W3C's HTML technique uses empty alt text for this, alt="".

5. Headings (1.3.1, A)

Anything that looks like a heading on screen also has to be a heading in the code, an element from h1 to h6. Easy Checks also looks at whether the heading hierarchy makes sense.

With the screen reader I go through the page once from heading to heading. A bold paragraph can't be heard at all in that round. Then I pull out the list of headings and see whether it reads well on its own.

6. Form labels (3.3.2, A)

Wherever input is required, there has to be a label or instructions. According to the W3C, a label is shown to everyone, while an accessible name may be visible only to assistive technologies. A field named only through aria-label therefore doesn't meet the criterion if the label isn't shown to everyone.

My view: fields labelled only with placeholder text are risky. As soon as the user types, the text disappears, and what the field wants is gone from the screen. Keep the label above the field at all times.

7. Screen reader

I turn on VoiceOver on Mac and iPhone, TalkBack on Android, and try to finish the main flow without looking at the screen. Before any criterion I ask one question here: does what I hear describe the same task as what I see?

What I find most often are icon buttons without a name and status messages that stay silent. An X read out only as “button” doesn't say what it closes. If “Added to cart” appears on screen but can't be heard, the user doesn't know whether it worked.

8. Reflow and zoom (1.4.10, AA)

Content has to be usable at 320 CSS pixels wide without scrolling in two directions. According to the W3C's note, that matches a window 1,280 pixels wide at 400% zoom.

I test it two ways. In a desktop browser I zoom the page to 400%, then in the developer tools I set the width to 320 pixels. If a horizontal scroll bar appears or a button runs off the screen, I note it.

9. Motion and flashing (2.2.2 and 2.3.1, A)

Motion that starts on its own, appears next to other content and lasts more than five seconds has to be pausable. A ticker with offers or an auto-playing slider are examples.

Also, nothing may flash more than three times in one second. The only exception in the criterion is flashing below the thresholds the W3C defines. From my own practice I add one check: I turn on the operating system's reduced motion setting and see whether the page respects it.

What these nine steps don't cover

This list is a first round. A full conformance test asks for more. The WAI warns the same about Easy Checks: a page can seem to pass these checks and still have serious barriers.

If your product has video, captions, transcripts and audio description need a round of their own. A unique, descriptive page title on every page is also one of the Easy Checks. Which screens I check for it, I write down beforehand in the scope document.

Try it: navigate with the Tab key

The small form below has two errors. Press Start the test and Tab to the end of the form. The yellow box tells you, for each element, which criterion is met or failed.

Then switch to Fixed and do the same round. Nothing seems to change on screen, but with the keyboard the difference is obvious.

Navigate with the Tab key

Example: appointment request at a dental practice

Full name

Email

Phone

Remind me one day before the appointment

Request appointment

Because JavaScript is off, the form is in its fixed state. The two errors are described below the demo.

The example form sends nothing. In the broken state two errors are there on purpose: the Phone and Email fields are in the wrong order in the code, and the button's focus ring was removed. Without a keyboard, press Show tab order to see the order as numbers.

Error 1: wrong focus order (2.4.3, A)

On screen, Email sits above Phone. In the code Phone comes first, and the CSS swaps the two. Because the Tab key follows the code, focus jumps down and back up. Fix: put the code in the visible order instead of building the order with CSS.

Error 2: no focus ring (2.4.7, AA)

The browser's focus outline on the button was removed and not replaced. Keyboard users can't see that they have reached the button. Fix: define a strong, high-contrast outline for :focus-visible.

There is a reason I see these two errors so often: if you look with the mouse, you see neither. At design sign-off the screen looks right; the error shows only when someone navigates with the keyboard.

The report

The last step in WCAG-EM is to collect and report the findings. My report is less a conformance grade than a to-do list. When the team opens it, they should see which item to start with today.

Each finding has:

• Which screen or which step of the flow it appears on.
• What happens, in one sentence from the user's point of view.
• Number and level of the WCAG 2.2 criterion.
• Who it affects and how I tested.
• A recommended fix and the severity.

The example finding is not from a real client project; it is written from the demo above.

I describe the 0 to 4 severity scale I use in the UX audit guide. For accessibility findings I have one rule: anything that stops the user from finishing their task goes to the top.

Who the report is for

Design, development and product management read the report with different goals. So I tag every finding by where it gets fixed. Contrast and label text are fixed in the design file, focus order and screen reader names in the code.

At the top of the report I write a short summary for product management. It says how many findings there are and which ones block a task completely. The criterion numbers are where development looks for them: in the finding itself.

The work isn't over at handover. When the fixes are live, I repeat the same steps on the same screens. Only then do I take a finished item off the list.

My note

I see accessibility as part of usability. That's why I didn't make it a separate package. When I review a flow, I look at keyboard and contrast in the same round.

Where teams go wrong most often is the green tick in the automated scan's report. The report is clean and everyone relaxes. Then someone presses Tab and never reaches the payment button.

If you want to try it yourself, start with the first two of the nine steps: keyboard and focus. A one-hour round brings the most visible barriers to light. The rest I can do on your screens in the UX Audit.