You Received a Website Accessibility Complaint or Demand Letter: What to Do First

The message might be a polite email from a customer who could not finish checkout with a screen reader. It might be a formal letter from a law firm that says your website “is not accessible to blind and visually impaired individuals” and lists violations of the Web Content Accessibility Guidelines. Either way, someone is telling you that a person with a disability could not use your site, and that you are expected to do something about it.

This guide is for small business owners, nonprofits and the web designers they call when one of these arrives. It walks you through the first days: what to protect, what the complaint is really measuring, how to find and fix the barriers that matter most, and how to document the work. This guide is not legal advice. Laws, deadlines and strategy depend on where you and the complainant are, so the legal side belongs with a lawyer. The technical side, which is what this guide covers, is where you and your designer can make real progress right away.

What is happening

Accessibility complaints come in a few shapes, and the right first move depends on which one you have.

What arrived	What it usually means	First move
Email or contact form message from a visitor	A real person hit a real barrier and is asking for help	Thank them, ask which page and task failed, offer another way to complete the task, then fix it
Demand letter from a law firm	A claim that your site violates disability law, usually with a list of WCAG failures and a request for settlement or remediation	Send it to a lawyer before you respond to anyone
Court papers (a complaint or summons)	A lawsuit has been filed; strict response deadlines apply	Lawyer immediately; note the date you were served
Notice from a government agency, school or client contract	A procurement or regulatory requirement, often naming a specific WCAG version and level	Read the exact standard named and the deadline, then involve your lawyer or contract manager

Whatever the format, nearly every complaint measures your site against the same yardstick: the W3C Web Content Accessibility Guidelines, Level AA. WCAG is a technical standard, not a law, but many laws and regulations point to it. In the United States, the Department of Justice published guidance in 2022 saying the ADA applies to the web content of businesses open to the public, and its 2024 rule for state and local governments adopts WCAG 2.1 Level AA (an April 2026 interim rule pushed its compliance dates back by a year, to April 2027 and April 2028 depending on the entity’s size, so check the current Federal Register entry). In the European Union, the European Accessibility Act has applied since 28 June 2025 to many consumer products and services, and the harmonized standard behind it, EN 301 549, incorporates WCAG 2.1 AA. Ontario requires WCAG 2.0 AA for larger organizations. WCAG 2.2, published in October 2023, adds nine success criteria on top of 2.1, so a site that meets 2.2 AA also meets 2.1 AA.

Demand letters typically list barriers found by an automated scan or by a tester using a screen reader. The same handful appear again and again: images with no text alternative, form fields with no label, links and buttons with no accessible name, low color contrast, menus that cannot be used with a keyboard, and missing page language. These are concrete, fixable defects.

Before you start

Gather this access before you change anything:

• WordPress administrator access and access to your theme or page builder settings.
• A staging copy of the site, if your host offers one, so you can test fixes without touching the live site.
• A fresh full backup (files and database), downloaded off the server. Label it with the date the complaint arrived.
• Dated screenshots or saved copies of each page the complaint names. Ask your lawyer what else to preserve before you start editing.

How to run the commands in this guide. Two kinds of commands appear below. Server commands run in an SSH terminal on your hosting account, from the site folder (the one that contains wp-config.php). Depending on your host, WP-CLI is called wp or wp-cli; try wp --info first. Scanning commands run on your own computer and need Node.js installed (from nodejs.org). On macOS and Linux, use the built-in Terminal. On Windows, use PowerShell or WSL; the commands are the same.

Step 1: Read the complaint carefully and set the clock

Before you open your site, extract the facts. Write down:

• The date it arrived and any deadline stated in it.
• Who sent it and on whose behalf.
• Every URL it mentions, and every task it says failed (for example “could not add a product to the cart” or “could not submit the contact form”).
• The standard it cites (WCAG 2.0, 2.1 or 2.2, and which level).
• What it asks for: a fix, a timeline, a payment, or all three.

Then do three things. Do not ignore it, because silence rarely makes a legal problem smaller. Do not reply directly to a law firm, argue the claims, or post about it publicly; let your lawyer handle communication. And ask your lawyer or insurance broker whether any business policy you hold needs to be notified, because some policies have notice requirements.

If the complaint came from a customer rather than a lawyer, the tone changes. Reply promptly, thank them, ask what device and assistive technology they use if they are willing to share, and offer an alternative route to complete their task (an email order, for example) while you fix the problem. A fast, respectful reply is the decent thing to do and keeps a barrier report from growing.

Step 2: Reproduce the specific barriers named

Start with exactly what the complaint describes, on the exact pages it lists. If it says the menu cannot be opened with a keyboard, unplug or ignore your mouse, load the page, and press Tab. If it says images lack alternative text, inspect those images. Confirming each claim gives you a verified list, and it also tells your lawyer which claims hold up.

For each item, record: the URL, what you did, what happened, what should have happened, and the WCAG success criterion involved. A simple spreadsheet works. You will add to this log in every later step, and it becomes the core of your documentation.

Step 3: Run automated checks, knowing their limits

Automated tools are fast and objective, so they are the right second step. Use more than one, because their rule sets differ.

• axe DevTools: a free browser extension for Chrome, Edge and Firefox from Deque. Open developer tools, choose the axe tab and scan the page. Results are grouped by rule and given an impact level of critical, serious, moderate or minor.
• WAVE: a free browser extension from WebAIM that overlays icons on the page itself, which makes it easy to see where an error sits.
• Lighthouse: built into Chrome developer tools. Its Accessibility score runs a subset of axe rules and weights them. A score of 100 means no automated rule failed, not that the site is accessible.

To scan many pages at once, build a URL list on the server and feed it to Pa11y on your computer. First, on the server over SSH, in the site folder:

wp post list --post_type=page,post --post_status=publish --field=url > urls.txt

There are no placeholders in this command. --post_type=page,post includes both pages and posts; add your product type (for WooCommerce, product) if you sell online. --post_status=publish skips drafts. --field=url prints only each permalink, one per line, and > urls.txt writes them to a file. Good output is a file of full URLs starting with https. If you see an error such as “Error: This does not seem to be a WordPress installation”, you are in the wrong folder. Download urls.txt to your computer with SFTP or your file manager.

Then, on your own computer, in the folder where you saved urls.txt:

while read -r URL; do npx pa11y --runner axe --standard WCAG2AA "$URL"; done < urls.txt > pa11y-report.txt

URL is a shell variable that takes each line of the file in turn; you do not replace it. npx pa11y downloads and runs Pa11y the first time. --runner axe uses the axe-core rule engine; --standard WCAG2AA tests Level A and AA rules. The output goes to pa11y-report.txt. Good output for a page is the line “No issues found!”. Bad output lists each problem with its rule, a message such as “Images must have alternate text”, and the CSS selector of the element. On Windows PowerShell, use Get-Content urls.txt | ForEach-Object { npx pa11y --runner axe --standard WCAG2AA $_ } instead.

Now the important caveat. Automated rules can only test what a machine can decide. A tool can tell that an image has no alt attribute, but not whether the alt text that exists is accurate. It can tell that a button has a name, but not whether the name makes sense. It cannot tell whether focus moves logically through a popup, whether an error message is helpful, or whether a video has accurate captions. Many WCAG success criteria need a human. A clean automated report is a good start, never a finish line.

Step 4: Test by hand with a keyboard and a screen reader

Pick your most important user journeys: finding a service, reading a key page, submitting the contact form, booking, and checking out. Then test each one two ways.

Keyboard only

Click in the browser address bar, then put the mouse aside. Press Tab to move forward, Shift+Tab to move back, Enter to follow links and press buttons, Space to toggle checkboxes and press buttons, arrow keys inside menus and radio groups, and Escape to close popups. Ask: can I see where I am at all times? Can I reach every link, menu item and control? Can I get out of every popup? Does the order make sense?

Screen reader smoke test

On a Mac, press Command+F5 to start VoiceOver. On Windows, install the free NVDA screen reader from nvaccess.org. Navigate by headings and form fields and listen. Unlabeled buttons announced only as “button”, images announced by file name, and form errors that are never spoken are the most common findings.

Our separate guides cover keyboard and focus problems, color contrast, images and buttons that screen readers cannot understand, and accessible forms, each in depth. Use them as the fix manuals for what you find here.

Step 5: Fix the high-impact issues first

You will probably find more issues than you can fix in a week. Prioritize by how badly a barrier blocks a task and how many pages it touches.

Priority	What belongs here	Why
1	Anything that stops a core task: checkout, contact form, booking, login, the main menu	A blocked task is a complete failure for that visitor, and these are the barriers complaints describe
2	Site-wide template problems: header, navigation, footer, cookie banner, popups	One fix in a template repairs every page at once
3	Recurring component problems: buttons, cards, sliders, accordions, tabs built by a theme or builder	Fixing the component or its global style fixes every instance
4	Page-level content: alt text, heading order, link text, contrast of individual text blocks	Real issues, but each one affects less of the site

Within each priority, fix critical and serious automated findings before moderate and minor ones. If a plugin or theme component is the source and cannot be fixed, replace it; do not try to patch around it page by page. After every fix, retest the same way you found the problem, and record the retest result in your log.

Step 6: Document the work

Good documentation shows a sustained, good-faith effort, and it makes future maintenance easier. Keep these together:

• The issue log from Steps 2 to 5: URL, issue, WCAG criterion, severity, date found, date fixed, who fixed it, and retest result.
• Scan reports saved with dates, before and after fixes.
• A change record: theme, plugin and template changes with dates. If your designer uses version control, the commit history serves this purpose.
• Third-party gaps: components you rely on but do not control (a booking widget, a payment form, an embedded map), what you asked the vendor, and their answer.

Some organizations, especially those selling to governments or universities, are asked for an Accessibility Conformance Report. That is a structured report, usually based on the VPAT template published by the Information Technology Industry Council, stating how a product meets each criterion. Hire a qualified auditor if you need one; a self-written report that overstates conformance creates new problems.

Step 7: Publish an accessibility statement

An accessibility statement is a page that tells visitors what you are doing and how to reach you when something does not work. Keep it honest and specific. Include:

• The standard you are working toward, for example WCAG 2.2 Level AA.
• The current status, stated plainly. Say “we are working toward” rather than claiming full conformance you have not verified.
• Known limitations, such as a third-party booking tool or older PDF documents, and the alternative you offer.
• A way to report a barrier: an email address and an accessible contact form, with the response time you commit to.
• The date the statement was last reviewed.

The W3C Web Accessibility Initiative publishes a free statement generator that walks you through these sections. Link the statement from your footer so it is reachable from every page. Show the wording to your lawyer before it goes live if a legal claim is active.

Advanced: why overlay widgets do not make a site compliant

Within hours of receiving a complaint, many owners are offered an “accessibility widget” or “overlay”: a script added to the site that shows a toolbar icon and promises automatic compliance. It is worth understanding how these work before you spend money on one.

An overlay is JavaScript that runs in the visitor browser after your page loads. It typically does two things. First, it offers a user-facing toolbar to enlarge text, change contrast, or pause animations. Second, it tries to repair the page automatically: guessing alt text for images, adding labels to fields, or rewriting markup on the fly.

The criticism from accessibility practitioners, documented in the public Overlay Fact Sheet that hundreds of practitioners have signed, runs along these lines:

• Automatic repair cannot fix what a machine cannot judge. The same limits that apply to automated testing apply to automated fixing. A script can add an alt attribute but cannot know what the image is meant to communicate on that page. It cannot reorder a confusing checkout or write a helpful error message.
• The toolbar duplicates tools people already have. People who rely on assistive technology have usually configured their own screen reader, zoom, high contrast mode or browser extensions. A second layer of controls on each site does not help them and can conflict with their setup.
• The underlying code stays broken. Your source HTML is unchanged, so any visitor whose browser blocks or delays the script, and any tester who inspects your markup, still sees the original barriers.
• Marketing claims have drawn regulatory action. In 2025 the US Federal Trade Commission finalized an order against one overlay vendor, requiring a payment of 1 million US dollars and barring it from claiming its automated product could make any website WCAG compliant without evidence to support that.

Overlay vendors argue that their products help some users and give owners a starting point, and some toolbar features can be pleasant for some visitors. The fair conclusion is narrow: an overlay is not a substitute for fixing your site, and it does not, by itself, make a site conform to WCAG. If you already have one installed, ask your lawyer before removing it during an active claim, then plan to fix the underlying issues regardless.

Advanced: reading an axe result like an auditor

When you open an axe or Pa11y finding, read four parts. The rule ID (for example color-contrast, image-alt, label, button-name, link-name) tells you the category. The tags (such as wcag2aa or wcag22aa) tell you which WCAG version and level the rule maps to; rules tagged best-practice are good advice but not WCAG failures. The impact tells you severity. The target is a CSS selector for the failing element; paste it into the developer tools console as document.querySelector("SELECTOR"), replacing SELECTOR with the target text, to jump to the element. If one selector shows up on every page, it lives in a template, and a single fix clears it everywhere.

Also watch for results marked “needs review” or “incomplete”. These are cases where axe found something suspicious but could not decide, such as text over a background image where contrast cannot be computed. They need a human decision, and they are often where real problems hide.

When to contact your host

Your host cannot judge whether your site is accessible, but it can help with the infrastructure around the fix. Open a ticket when you need:

• A staging copy of the site, so fixes can be tested without disturbing live visitors.
• A dated backup preserved off-site, if your lawyer asks you to keep the site exactly as it was.
• Server access logs for a specific date the complainant mentions. For example, if a visitor says a form failed on a particular day, logs can show whether the form request returned a 403 from a firewall rule rather than an accessibility barrier. Give the URL, the date and approximate time in UTC, and the form or page involved.
• A full cache purge (server cache and CDN) after you deploy fixes, so testers do not see the old version.

For the accessibility work itself, consider a professional audit by an experienced accessibility specialist who tests manually with assistive technology. Bring them your issue log and scan reports. Our diagnostic tools can help you check the server side, and if the site is actually down or failing, start at the Emergency Room.