Hiring Someone to Fix Website Accessibility: What to Ask
Short answer: Ask any vendor how they test, which WCAG version and level they target, and what proof of work they deliver. Require a before and after audit that includes manual testing, and be wary of guarantees or overlay-only fixes. Scope the work by page templates and user flows, not just page counts.
Fixing website accessibility is a normal piece of web work, but it is easy to buy the wrong thing. Some vendors sell a script and a badge. Others sell a thorough audit and real code changes. The two are not interchangeable, and the difference matters most when you are under time pressure, for example after receiving a demand letter.
This guide covers what to ask, what to watch out for, what to require in writing, and how to scope the job. It is general information and not legal advice. For legal questions, talk to an attorney.
What “fixing accessibility” actually involves
Most accessibility work follows the same sequence:
- Audit the site against a defined standard, usually WCAG 2.1 AA.
- Fix the issues in the underlying code, templates, content, and design.
- Retest to confirm the fixes worked and did not break anything else.
- Maintain accessibility as pages, plugins, and content change.
Automated scanners are useful for step 1, but they detect only a portion of WCAG issues. Many problems need a person to judge them: whether alt text is meaningful, whether a focus order makes sense, whether a form error is understandable. A vendor who treats a scan report as the whole job is selling less than they appear to.
Questions to ask any vendor
Good vendors answer these plainly. Vague or defensive answers are information in themselves.
About their standard and process
- Which WCAG version and conformance level do you test against? (WCAG 2.1 AA is a common target. See WCAG 2.2 vs 2.1 if you are unsure which applies to you.)
- How do you combine automated and manual testing?
- Which assistive technologies do you test with, and on which browsers and devices?
- Do you test real user flows such as checkout, booking, contact forms, and login, or only individual pages?
About the fixes themselves
- Will you change the source code, templates, and content, or add something on top of the site?
- Who fixes issues that live in a theme, plugin, or third-party widget? (This often comes up on WordPress sites.)
- How will fixes be delivered: pull requests, a staging site, a ticket list?
- Will you document what changed so my developer can maintain it?
About proof and accountability
- What reports will I receive, and are they dated?
- Will you retest after fixes and give me a before and after comparison?
- What is out of scope, and what do you do when a fix is not possible?
- Can you describe a similar project, with the platform and size, without sharing confidential details?
Red flags
Guarantees of compliance or legal protection
No vendor can honestly promise that a website will never be the subject of a demand letter or lawsuit. Accessibility law is applied differently across jurisdictions, and courts disagree on several questions. A vendor who “guarantees compliance,” “guarantees you won’t be sued,” or sells “ADA certification” is making a claim they cannot back up. Treat it as a reason to walk away.
Overlay-only solutions
An accessibility overlay is a script or widget added to your site that claims to detect and fix problems automatically, often with a toolbar or badge. Overlays can offer some convenience features, but they generally do not repair the underlying code, and many accessibility professionals and disability advocates are critical of them. Sites using overlays have also been named in legal complaints. See accessibility overlays and lawsuits for more detail. If a vendor’s only deliverable is an overlay, you have not bought remediation.
The FTC has also taken enforcement action over deceptive claims about accessibility products, so marketing claims deserve scrutiny. The FTC website has more on that.
Other warning signs
- A fixed price quoted before anyone has looked at the site
- No manual testing in the proposal
- A report that is only an automated scan export
- Pressure to sign quickly because of a legal deadline
- No mention of retesting
- A refusal to document what was changed
Deliverables to require
Put these in the statement of work. Do not rely on a verbal promise.
| Deliverable | What it should include |
|---|---|
| Baseline audit | Dated report listing issues by WCAG success criterion, page or template, severity, and how to reproduce each one |
| Fix plan | Prioritized list of changes, who owns each one, and which need design or content decisions |
| Remediated code or content | Delivered through your normal workflow (repository, staging, or CMS), not a black-box script |
| Retest audit | Dated report showing which issues are resolved, which remain, and why |
| Before and after comparison | Clear mapping from baseline findings to retest results |
| Manual testing notes | Which keyboard, screen reader, zoom, and contrast checks were performed, and on what |
| Handoff documentation | Guidance for your team on keeping new pages and content accessible |
Dated records are valuable because they show what was tested, when, and what was found. See dated accessibility audit records for what a useful one contains.
What manual testing should cover
At a minimum, expect checks like these:
- Keyboard operation: every control reachable and usable (WCAG 2.1.1), with a visible focus indicator (WCAG 2.4.7)
- Screen reader behavior: names, roles, and states announced correctly (WCAG 4.1.2). See screen reader testing basics.
- Text alternatives: images described meaningfully (WCAG 1.1.1)
- Structure: headings, lists, and tables marked up properly (WCAG 1.3.1)
- Contrast and resizing: WCAG 1.4.3 and WCAG 1.4.4
- Forms: labels and instructions (WCAG 3.3.2)
How to scope the work
Scope drives price and timeline. A few decisions make estimates much more reliable.
Scope by templates and flows, not only page count
Most sites are built from a limited number of templates: home, product, article, contact, checkout. Fixing a template fixes every page that uses it. Ask the vendor to audit a representative sample of each template plus the critical user flows, then extend fixes across the site.
Decide what is in and out
- Which domains, subdomains, and apps are included?
- Are PDFs, videos, and embedded third-party tools included? Prerecorded video needs captions (WCAG 1.2.2).
- Who is responsible for ongoing content, such as new product images or blog posts?
Settle ownership of fixes
Some issues are in your theme, plugin, or a vendor’s widget. Agree in advance who fixes them, who contacts the third party, and what happens if a component cannot be fixed and must be replaced.
Plan for maintenance
A site that passes today can regress next month after an update or a content change. Ask about periodic retesting and agree on a cadence that fits how often your site changes.
A sensible order of operations
- Get a baseline audit so you know what you are dealing with.
- Triage by impact: issues that block users from completing tasks come first.
- Fix at the template and component level.
- Retest manually and with automated tools.
- Keep the dated records of each step.
- Re-audit on a schedule.
If you want a quick starting point before talking to vendors, run a free scan to see the kinds of issues automated testing can detect, then treat it as the beginning of the conversation rather than the end. For more context on legal risk and process, see ADA website lawsuits explained, and consult an attorney about your specific situation.
Frequently asked questions
Can a vendor guarantee my site will be compliant?
No honest vendor can guarantee legal outcomes. Accessibility standards are open to interpretation in places, courts do not all agree on how the law applies to websites, and sites change constantly. Look for vendors who promise a clear process and documented results instead.
Is an accessibility overlay enough?
Generally not. Overlays add a layer on top of your site and usually leave the underlying code unchanged, which is where many barriers live. Many accessibility professionals recommend fixing the source and using any overlay, if at all, only as a supplement.
Do I need manual testing, or is an automated scan enough?
You need both. Automated tools reliably catch certain issues, such as missing form labels or low contrast, but they cannot judge things like whether alt text is meaningful or whether keyboard navigation is logical. A credible audit includes manual checks with a keyboard and a screen reader.
What should a before and after audit show?
It should show dated findings from the baseline, the fixes made, and a retest that marks each issue as resolved or still open. Each finding should reference the relevant WCAG success criterion and the affected page or template. This lets you and your developer verify the work independently.
How long does accessibility remediation usually take?
It varies with the size of the site, the platform, the number of templates, and how many issues are found. A small brochure site may need much less work than a store with a custom checkout. Ask the vendor for a timeline tied to specific phases rather than one overall estimate.
Related
- Do accessibility overlay widgets prevent ADA lawsuits?
- Why a dated accessibility audit record matters
- WCAG 2.1 AA checklist for business websites
- Screen Reader Testing for Business Owners: VoiceOver and NVDA Basics
Proof of Access provides technical accessibility assessments. We are not a law firm and nothing on this page is legal advice. If you have received a demand letter or a lawsuit, talk to an attorney.