Accessibility QA for agencies and freelancers: a repeatable workflow for client sites

Why agencies add accessibility checks

Clients ask for them, procurement asks for them and demand letters create urgency. A repeatable check at launch catches problems before the client's customers do, and a dated record helps you show the work. Treat it like cross-browser testing: a step in delivery, not a special project.

The workflow

1. Scope by template. List each distinct template (home, collection or category, product or service, article, form, cart, checkout, account). A fix to a template fixes every page using it.
2. Baseline scan. Scan one representative page per template and save the results with the date. A free scan gives you a first view; see free checkers compared.
3. Triage. Group findings by cause: theme or template, a plugin or app, or content. Fix by impact: blocked tasks first.
4. Fix and recheck. Apply fixes (fix guides) and rescan to confirm each finding is gone.
5. Hand-test the key flows with a keyboard and a screen reader: navigation, forms and checkout (steps).
6. Hand over a record. Give the client the scan results, what changed and what remains, and a draft accessibility statement.
7. Offer a recheck cycle. Plugins, themes and content edits reintroduce problems. A scheduled recheck is an easy retainer.

What Agency Pass covers

Agency Pass is a subscription for professional client work. Plans: Solo ($390 a year, 100 client pages per 90-day project window), Studio ($99 a month or $990 a year, 300 pages) and Agency ($249 a month or $2,490 a year, 1,000 pages). A client project can include up to 50 pages on Solo, 100 on Studio and 200 on Agency, and holds its pages for a 90-day window, then the capacity frees up. Rechecks are included as needed during the window and do not use extra pages. Each started client project has its own private report link you can share with the client or their developer.

Agency Pass focuses on client projects, private report links, Fix Packs and rechecks; the Agency Pass page lists exactly what each plan includes. You stay responsible for how you present results to clients.

What to tell clients

• Automated checks find a subset of problems; high-risk flows deserve manual review (what scanners can and cannot find).
• A scan does not make a site legally compliant, and no tool can (overlays explained).
• Accessibility is maintained, not finished: recheck after changes.

Where accessibility checks fit in a project

A handover pack that clients value

• A one-page summary of what was tested, when and how.
• A list of known issues with owners and dates.
• A short guide for editors on alt text, headings and links.
• A draft accessibility statement for the client to review and publish.
• A recommended schedule for rechecks.

Explaining limits to clients

Clients may ask whether the work makes them compliant. A good answer is honest: you built and tested to a standard, you documented what you did and you cannot guarantee a legal outcome. Offer to retest on a schedule, and give the client the records so they can show their effort. This protects the relationship, because it sets expectations that you can meet.

Common agency mistakes

• Treating accessibility as a final polish step.
• Selling an overlay as a solution. See overlays explained.
• Relying on a scan alone. See where automated tools fit.
• Skipping content training, so problems return after launch.
• Leaving no record, so you cannot show what was tested.

Training your team

A short internal training pays back quickly. Spend an hour with designers on contrast, focus and component choices, an hour with developers on semantics, keyboard behavior and testing, and an hour with content staff on headings, links and images. Add a one-page checklist to each project template, and review it at the end of each project.

A repeatable QA checklist for each template

1. Run an automated scan and save the report.
2. Tab through the page and confirm every control is reachable, visible and in order.
3. Check the heading outline and landmarks.
4. Check images, icons and link text.
5. Submit each form with and without errors.
6. Zoom to 200 and 400 percent and check reflow.
7. Check color contrast of text, controls and states.
8. Test on a phone, in both orientations.
9. Run a screen reader on the key task for the template.
10. Record results, screenshots and any exceptions, with the date and tester name.

Keeping a client file

A client file for each project keeps your evidence in one place. Include the scope, the standard targeted, test dates, tools and browsers used, findings and fixes, retest results, known issues with owners and the version of the statement published. If a question arises months later, you can answer quickly. If you hand the site to another agency, the file shows what has been done.

Working with client content teams

Even a well-built site can lose accessibility when new content arrives. Give content teams a one-page guide and a short training. Cover alt text, headings, link text, captions, tables and PDF documents. Set up a simple process for review before publishing high-traffic pages, and run a monthly scan to catch problems early. This is also an opportunity to offer a continuing service.

Dealing with third-party tools

Clients often use chat tools, booking widgets, review apps and payment forms that the agency did not build. Test them, document problems and report them to the vendors. Tell the client what you found and offer options: a different tool, a workaround or a different way to complete the task. Record the vendor's response so that the file shows you raised the issue.

Selling the service without overpromising

• Describe what you will test and how, in plain language.
• Say that you cannot promise a legal outcome.
• Offer a retest, so fixes are verified.
• Show a sample of your reports with client details removed.
• Be open about what needs a specialist, and refer when appropriate.

A worked example: a four-person agency adds accessibility QA

A small agency builds around twenty sites a year on Shopify and WordPress. They decide to add a standard accessibility step. First they choose a target: WCAG 2.2 AA. They write a one-page checklist that covers the ten checks in this guide and add it to their project template. Two developers take a half-day course on keyboard and screen reader testing. They set up an automated scan that runs on each template before launch.

On the next project they find that a client's chosen theme has a mega menu that traps keyboard focus. They explain the problem, show the recording and propose a simpler menu. The client agrees. The launch includes a test record and a draft statement. The agency now lists accessibility QA as a line item in its proposals, priced as a fixed amount for small sites and as a quote for larger ones, and it offers a quarterly recheck.

Metrics worth tracking

Writing findings developers can act on

A finding is only useful if the person who reads it knows what to do. Use a consistent format: where the problem is, what happens, why it matters, which criterion it relates to and how to fix it. Add a screenshot or a short recording for keyboard problems, since describing a sequence in words is slow. Give each finding a severity and an owner. When a fix is a code change, include a suggested snippet.

Page: /cart
Issue: The "Remove" icon button has no accessible name.
Impact: Screen reader users hear "button" with no purpose.
Criterion: WCAG 4.1.2 Name, Role, Value (A)
Severity: High (checkout)
Fix: Add aria-label="Remove Blue mug from cart".
Owner: Theme developer

Handling disagreements about severity

Teams sometimes disagree about whether something is a high or low priority. A useful rule is to rank by the harm to a user's task. If a person cannot complete a core task, it is high. If they can, but with difficulty, it is medium. If it is an annoyance or a minor gap, it is low. Agree on the rule at the start of the project, and apply it consistently.

Offering a continuing service

Describe each package in plain terms, with what is and is not included. Do not promise outcomes that depend on laws or courts. A clear scope protects both you and the client.

Working with accessibility specialists

Agencies do not need to employ an expert for every project, but it helps to know a specialist you can call. Use them for complex components, for testing with assistive technology you do not have, for usability testing with disabled people and for formal conformance reports. Share what you have already done, so they can focus on the hard questions, and learn from their findings to improve your process.

Frequently asked questions from agencies

• Do we need to be accessibility experts to offer this? No, but you need a process, some training and a specialist you can call for hard cases.
• How do we handle clients who refuse to fix issues? Document your recommendation, the client's decision and the date. This protects both sides.
• Can a scanner do our QA for us? It covers a share of the work. Pair it with manual checks.
• Should we publish our own accessibility statement? Yes. It shows you practise what you recommend.
• What do we do about a client's legacy content? Agree a scope. Fix templates and key pages first, and propose a plan for the rest.

Putting it together

A workable agency process is short: agree the standard, design with it in mind, build and test each component, review content, run a pre-launch check, hand over a test record and offer a recheck. None of the steps is difficult. The value comes from doing them consistently, and from being able to show what you did.

If you compare your process with the ecommerce checklist and the redesign checklist, you will find that each phase of a project already has natural places for these checks.

Setting up the tools

You do not need a large toolbox. A browser extension for automated checks, a contrast checker, a screen reader on each operating system you support, a headings viewer and a text spacing bookmarklet cover most of what a pre-launch check needs. Add an automated scan to your build pipeline if your team uses one, so that new issues fail the build before a client sees them. Keep your tools updated and note the versions in your test record.

Reporting to clients

Clients appreciate a short, plain summary. Open with the headline: what was tested, what passed, what did not and what happens next. Follow with a table of issues by severity and a list of what you need from them. Keep jargon out of the summary and put the technical detail in an appendix. A one-page report that people read is more valuable than a thirty-page report that sits in an inbox.

Continuous improvement

After each project, hold a short review. Which issues appeared most often? Which could have been caught earlier? Which components should be added to your library as tested, reusable patterns? Update your checklist and your templates. Over a year, the issues you find at launch will fall, because the problems have been prevented upstream.

Pricing the service

Common models are a one-time launch check, a fixed fee for remediation, or a recurring retainer that covers rechecks after updates. Scope in templates and flows so the work is predictable. Audit cost explains how scoped manual audits are priced, in case a client needs one in addition.