A WCAG audit does not start with a tool, it starts with pushing the mouse to the far end of the desk. I know how that sounds, but it is the only way to see, within half an hour, what a slice of your customers see. A scanner will tell you an image is missing a description. It will not tell you that a keyboard user gets stuck in the discount pop-up and never reaches the cart.
This piece is a procedure, not a product description. I go through what I press, in what order, and what I am looking for at each stage, and then how to write up a single finding so it turns into a ticket for a developer rather than another line on a wish list. If what you actually need is what such a review costs and how to read the quotes, I covered that separately in what a WCAG accessibility audit contains and what drives its price.
I am assuming level AA of WCAG 2.1, because that is the reference point the regulations lead to. Who exactly is covered by them I break down in the piece on who the accessibility obligation applies to.
Before you start - pick journeys, not pages
The biggest mistake at the outset is opening the sitemap and trying to walk everything. On a store with a thousand products that is impossible, and on a company site it is pointless, because thirty pages run on five templates.
So I write down journeys, meaning the routes people actually take. In a store: home page, a category listing with filters, the product page, the cart, checkout, login and the customer account. In a service company: home, a service page, pricing, the contact form, the blog. Plus anything that is a gate to money or to contact - if something blocks people there, that gets fixed first and the rest waits.
Next to each journey I note the address and the template it belongs to. It is the same logic I use in a general WordPress site review: I check view types, not addresses. One fix in the product template then closes a thousand items at once.
Step 1 - the automated pass, to clear the obvious
I start with an automated run, but I treat it purely as tidying up the obvious. A browser extension or the audit built into the browser runs through the code and returns the machine-measurable things: contrast that is too weak, images with no description attribute, fields with no label, duplicated identifiers, a scrambled heading order.
I do this on every template I picked, paste the results into one sheet and immediately strip out duplicates. If the same problem comes back on six views, that is one job in the theme, not six.
And the important caveat: if the automated pass found nothing, that does not mean the site is accessible. It means only that there are no errors a machine knows how to recognise. Everything that decides whether someone finishes a purchase comes out in the steps that follow.
Step 2 - the keyboard session
This is the half hour that gives you the most. I put the mouse aside and walk the whole journey using only Tab, Shift+Tab, Enter, the space bar, the arrow keys and Escape.
What I look for, in order:
- Whether you can see where you are at all. The outline around the active element has to be visible against every background. Very often a designer removes it because “it looks ugly”, and the site becomes impossible to walk.
- Whether the order makes sense. Focus should move the way you read the page: top to bottom, left to right. If it jumps from the menu to the footer and then back into the content, something is wrong with the layout in the code.
- Whether there is a shortcut to the content. The first Tab on a page should reveal a “skip to content” link. Without it, a keyboard user goes through the whole menu again on every single page.
- Whether you can get out. A pop-up with a discount, a newsletter or consent settings should close with Escape. If Tab keeps circling the page underneath, or focus stays trapped in the box, you have a keyboard trap - one of the heaviest findings you can get.
- Whether everything clickable is reachable. Menus that only open on hover, carousels with no arrow controls, icons built out of a div instead of a button - the keyboard simply does not see those.
I write down exactly which key press breaks things. “The menu does not work” is not a finding. “On the fifth Tab on the home page focus enters the Services submenu, but the down arrow closes the list instead of moving through the items” - that is a finding.
What helps: do the keyboard pass fresh, before you read the scanner report. Once you have a list of technical warnings in your head, you start hunting for confirmation of them instead of watching where the site actually jams.
Step 3 - zoom, magnification and a narrow window
The third pass is about people who can see, but not well. That is a far larger group than people who are blind, and the one most often skipped.
I set browser zoom to 200% and walk the journey again. I check whether text escapes its container, whether buttons overlap, whether a horizontal scrollbar appears. Then I do the same at 400% in a narrow window, roughly the width of a phone. The page should reflow into a single column at that point, not force you to scroll sideways to finish reading a sentence.
Two things come back regularly here. The first is a sticky header that eats half the screen when zoomed and leaves the user a slot for the content. The second is pricing or specification tables that fall apart horizontally under magnification, because nobody thought about what happens to them outside a designer’s monitor.
While I am at it, I look at contrast in real life rather than in a report. I open the site on a phone and take it outside. Light grey text on white that looked elegant in the office simply disappears in sunlight.
Step 4 - a WCAG audit by ear, walking the site with a screen reader
This is the part no tool replaces, and at the same time the part people running a WCAG audit for the first time dread most. You do not need to be a fluent user to catch the serious things. It is enough to switch on the reader built into your system (a keyboard shortcut on a Mac, a free program on Windows, an accessibility setting on a phone) and close your eyes for three minutes.
The first thing I do is ask for the list of headings. If that list is empty or has a single item, headings are being faked with bold text, and a blind user has no way to jump to the section they want - they have to sit through the whole page.
The second is the list of links. If I hear “more, more, click here, read on”, then link names torn out of context say nothing. The third is images: does the alternative description tell me what is in the photo, or is it a file name and a string of digits.
The most interesting part, though, shows up on actions. I add a product to the cart and listen for anything at all. In a lot of stores the confirmation appears as a green toast in the corner and vanishes after three seconds - visually it exists, for a screen reader it does not. The same happens with category filters, with recalculating shipping costs and with form validation. A change you can see with your eyes, silence in the headphones.
Step 5 - forms, errors and what happens after the click
A form is where accessibility and conversion are exactly the same problem. That is why I run this step separately and in most detail.
I check that every field has a visible label that stays on screen once you start typing - grey hint text inside the field disappears the moment it becomes useful. I check that clicking the label puts the cursor in the field, because that is the simplest test of whether the two are actually connected. I check that address fields let the browser offer saved data, because for some people autofill is the difference between a submitted form and an abandoned one.
Then I deliberately submit the form with errors and watch what happens. Does the message say which field and what is wrong, or does it only turn the border red. Is the error next to the field, or only in a summary at the top. After submission, does focus move to the problem, or is the user left at the bottom of the page to work it out. Can the anti-spam check be passed without recognising images.
I run the same pass on the checkout if it is a store. Payment and delivery are the most expensive place on the site and every snag there costs real money - I write about that at length in shortening the WooCommerce checkout.
What the report shows - the anatomy of one finding
After five passes I usually have somewhere between a dozen and several dozen observations. A bare list of them helps nobody. What helps is a form in which every point can be turned into a task. I stick to seven columns:
- Where - the address and the specific element, not “the store”
- What happens - the dry observation from the pass
- Who it blocks - a keyboard user, a screen reader user, someone using magnification
- Which criterion - the number and name of the guideline, so it can be verified
- Severity - a blocker, an obstacle or cosmetics
- How to fix it - something concrete for a developer
- Effort - in hours, even roughly
In practice a single row looks like this: product page, the “Add to cart” button. Pressing Enter does add the product to the cart, but the screen reader stays silent - the confirmation appears visually in the corner and disappears. A blind user does not know whether the action worked, so they click a second and a third time. Criterion: status messages, level AA. Severity: a blocker on the purchase path. Fix: a message region announced by the reader without moving focus. Effort: about an hour.
Then I put the whole thing into a work order. Blockers on the journey that earns money first. Then the cheap, globally effective things, meaning fixes in the template. Cosmetics last. A document you cannot build the next three sprints from is only a description of the state of play.
What helps: record your screen during the keyboard and screen reader passes. A thirty-second clip showing focus falling into a trap convinces a board and a developer faster than twenty pages of prose.
If you want to see what such a pass looks like on your site, send me the address. I will walk the most important journey with the keyboard and tell you what genuinely blocks people and what is only a scanner warning. The diagnosis is free and comes with no strings attached.
Frequently asked questions
Can I run a WCAG audit myself? The first pass yes, and it is worth doing, because the five steps above will catch most of what genuinely blocks people. For a formal confirmation of compliance and for preparing the documents you need someone who does this regularly and knows the criteria by number.
How long does such a pass take? For a company site with a handful of templates it is usually one working day for the passes and a second for writing the report. A store with a cart, filters and a customer account is a multiple of that, because every interactive element has to be tabbed through and listened to separately.
Where should I start if I only have time for one thing? With a keyboard pass from the home page to a submitted form or a placed order. That single exercise shows more than a full set of automated warnings, because it measures whether people can finish what they came for.
Do I need to repeat the audit after the fixes? Yes, at least on the journeys the changes touched. Accessibility fixes can shift the focus order or change the heading structure somewhere nobody planned to touch, so a second pass is part of the job rather than an add-on to it.
Sitting on this yourself and unsure where to start? I speed up and repair existing sites and stores - Core Web Vitals, outages, the features that are missing. Tell me what is happening and you will get a concrete quote with a date.