Accessibility audit: what it covers, what it costs, how to do one

An audit checks whether disabled people can use your site: people who are blind and use a screen reader, people who cannot use a mouse, people with low vision who zoom in, and people who are deaf and need captions. The checklist behind it is WCAG, the Web Content Accessibility Guidelines from the W3C. The laws and rules that name a standard usually point to level AA. Our plain guide to WCAG 2.2 AA explains each rule.

The W3C publishes a method for this kind of review, called WCAG-EM (Website Accessibility Conformance Evaluation Methodology). A new version came out on July 23, 2026. Most good auditors follow something close to it, even if they do not name it.

An audit is not the same as these three things, which are often sold under the same name:

• An automated scan. Software checks the rules it can measure. It is fast and useful, but it misses problems that need a person.
• An overlay or widget. A toolbar added to your site does not test anything and does not fix your theme code. Read why overlays do not fix accessibility.
• A certificate. An audit report describes your site on the day it was tested. It is not a certificate, and it does not make your store compliant on its own.

A full audit mixes software and people. Ask for each of these parts by name when you get a quote, because vendors often price very different work under the word audit.

Some audits add testing by people with disabilities. That is the best way to learn whether the store really works, and it usually costs extra.

A Shopify store has a few parts that a general auditor may not know. Ask them to include the cart drawer, the variant picker, search, any pop-ups from email or review apps, the customer account pages and the checkout. Shopify builds and runs the checkout, so your control there is mostly limited to branding and checkout apps, but a tester should still try to buy something.

Nobody tests every page of a store with 2,000 products, and nobody needs to. Your product pages all come from the same template, so a problem on one is almost always on all of them. Auditors test a sample. The W3C method has five steps:

For a small Shopify store the sample is a short list of templates and tasks. One audit firm's cost guide uses an example Shopify store with 12 templates and screens: home, collection, product, cart, checkout, account and search (see the costs below). If you have custom landing pages, a store locator, a bundle builder or a quiz, add them. Custom features are where new problems often hide.

Most audit firms do not publish prices. These two do, so they are a useful benchmark. Prices are the firms' own, in US dollars, as of October 2026. We have no connection to either firm and this is not a recommendation.

Fixing the problems is a separate cost, and often a bigger one. On Shopify, many fixes are theme settings or product data you can change yourself, such as alt text and colours. Others need changes to your theme code. Ask your developer to estimate fixes per template once you have the report.

A common offer is a free audit that turns out to be an automated scan with a score. That report is worth having, but it is not an audit. The W3C says plainly that evaluation tools “can not determine accessibility, they can only assist in doing so”. The US Justice Department's web guidance says automated checkers need to be used carefully, that a clean report does not mean a site is accessible, and that pairing them with a manual check gives a better picture.

Scores can mislead in the same way. Google's Lighthouse accessibility score is a weighted average of automated pass or fail checks, and its manual checks do not count toward the score. Shopify asks Theme Store themes for an average Lighthouse accessibility score of at least 90 across the home, collection and product pages. That is a useful floor, but it says nothing about whether a screen reader user can choose a size. More on this in our guide to accessible Shopify themes.

Send every vendor the same scope and ask the same questions. Good vendors answer these easily.

1. Which standard and level? WCAG 2.2 AA is the current version. Ask for it unless you have a reason to use 2.1.
2. Which pages and tasks, by name? The quote should list them. “Up to 10 pages” is not a scope.
3. How much is tested by hand? Ask which screen readers and browsers they use, and whether they test on a phone.
4. Who does the testing? Look for named training such as the IAAP CPACC or Web Accessibility Specialist (WAS) credentials, or the US Department of Homeland Security Trusted Tester program. Ask whether testers with disabilities take part.
5. Can I see a sample report? With the client's name removed. You want issues you could hand to a developer, not a list of scanner messages.
6. Is a retest included, and for how long? Fixes need checking.
7. Do you know Shopify? They should know which problems sit in the theme, which come from apps, and which are inside the Shopify checkout.

Each finding should let someone who was not in the room find the problem, understand who it affects and fix it. Here is one finding written well, for a common Shopify problem: size buttons built from plain div elements.

{%- for option in product.options_with_values -%}
  <fieldset>
    <legend>{{ option.name }}</legend>
    {%- for value in option.values -%}
      <input type="radio"
        id="option-{{ option.position }}-{{ forloop.index }}"
        name="{{ option.name | escape }}-{{ option.position }}"
        value="{{ value | escape }}"
        {% if value.selected %}checked{% endif %}>
      <label for="option-{{ option.position }}-{{ forloop.index }}">{{ value }}</label>
    {%- endfor -%}
  </fieldset>
{%- endfor -%}

This is a cut-down version of the pattern Dawn uses. It belongs inside your product form, in place of the old picker. Your theme's own JavaScript still needs to update the variant, price and image when the choice changes, so ask your developer to connect it, then test it with the keyboard and a screen reader.

You do not need to be a developer. This is a lighter version of the W3C method, aimed at the problems that stop people buying. Plan for an afternoon on a small store. Our ADA website checklist lists what to check on each page, and the guide to automated and manual accessibility testing explains each test in more detail.

If your store is behind a password page, an online checker only sees the password page. Run your scans when the store is open, or use a browser extension while you are on the page yourself.

1. Fix by template and by impact. Start with anything that blocks a purchase, then work through each template. One fix in the product template fixes every product page.
2. Retest the fixes. Ask the auditor, or run the same keyboard and screen reader steps yourself.
3. Watch for new problems. Theme updates, new apps and new content can add issues the week after an audit. Scan again after each change.
4. Publish an accessibility statement. Say what you have done and how shoppers can report a problem. The free accessibility statement generator writes a first draft.
5. Keep the paperwork. Keep the report, the dates of fixes and the retest results. If you ever receive a complaint or a demand letter about your website, a dated record of real work is useful to your lawyer.