The envelope, or the email, usually lands on a Tuesday afternoon with no warning. A law firm says your website shuts out blind and low-vision customers, lists a handful of problems it claims to have found, cites the ADA, and wants an answer sooner than seems reasonable. The reflex is to phone your web designer and ask them to “make it compliant by Friday.” Hold that thought: ADA demand letter website work goes better when it follows a set order.
Two separate jobs now sit on your desk. The legal job belongs to an attorney: reading the letter, judging the claim, handling deadlines and any negotiation. The technical job is finding out what is really wrong with the site, fixing it in a sensible order and keeping evidence of each step. We do only the second. We are a WordPress team, not lawyers, and nothing on this page is legal advice. What follows explains how our ADA demand letter website work runs, what your lawyer will probably ask of the web side, and the moves that tend to make things worse.
The first days after an ADA demand letter: legal side and website side
Before anyone touches the site, two things should happen. Get the letter to an attorney who handles ADA matters, and do not ignore the response date while you look for one. Then, separately, take a full backup of the website exactly as it is today: files, database and a set of screenshots of the pages the letter names.
That snapshot matters more than people expect. Once fixes start, the “before” version disappears. Your lawyer may want to know what the site looked like on the day the letter was written, and a dated backup answers that cleanly. If you are unsure how to take one, our guide on backing up a WordPress site walks through it, or we can do it as step one.
For the general order of steps from a business owner’s point of view, including what to say and not say in those first days, read the owner’s step-by-step guide for the weeks after a letter. This page stays on the technical work.
Who handles which part of the response
Confusion about roles wastes time and can create risk. Here is the split we work to.
| Task | Your attorney | Your team | WebMaintor |
|---|---|---|---|
| Reading the letter and advising on the claim | Yes | Provides background | No |
| Replying to the sender, deadlines, any settlement talk | Yes | Approves decisions | No |
| Preserving the site as it was | Advises on what to keep | Grants access | Takes backups and screenshots |
| Testing the site against WCAG 2.2 AA | Reviews findings | Names key pages and forms | Runs the audit |
| Deciding fix priorities and timing | Weighs in on sequence | Signs off on design changes | Proposes a plan |
| Making and retesting fixes | No | Edits content if they wish | Code, theme, plugin and content fixes |
| Records of what changed | Uses them | Keeps a copy | Writes and maintains the log |
We do not contact the law firm that sent the letter, and we do not draft replies to it. If your attorney wants to speak with us directly about technical findings, that is welcome and often helpful.
What counsel usually asks for from the web side
Every lawyer runs a matter their own way, but the technical requests tend to look similar. They want facts, not reassurance. The list usually includes:
- An independent assessment of the site against a named standard, normally WCAG 2.2 Level AA or its predecessor, 2.1, done by someone other than the person who built it.
- A view on the specific items in the letter: can they be reproduced, and on which pages?
- A remediation plan with a realistic order of work and target dates the business can actually meet.
- Proof of progress: what was changed, on which date, and what retesting showed.
- A plan for the future, such as regular checks after updates, so the same barriers do not drift back.
Our job is to produce those materials in plain, checkable form. Whether and how they are used in the legal matter is for your attorney to decide.
An independent audit of the site as it stands
We start by testing the site as it is, not as anyone wishes it were. The audit covers the pages named in the letter and the journeys a customer actually takes: the homepage, the main menu, service or product pages, contact and booking forms, cart and checkout if you sell online, account login and any PDFs people need, like menus or intake forms.
The testing has several layers:
- Scans with tools such as WAVE and axe across every template, to catch the machine-detectable problems quickly.
- A keyboard-only pass: Tab, Shift+Tab, Enter, Space, arrow keys and Escape, watching where focus goes and whether anything traps it.
- Screen reader passes with NVDA and VoiceOver, listening for unlabeled buttons, missing headings, images read out as file names and errors nobody announces.
- Zoom and reflow checks at 200 percent and at a 320-pixel-wide view, where layouts often fall apart.
- A content review of headings, link wording, alt text, captions and documents.
Scanners find some issues fast, yet plenty of barriers only show up when a person uses the site the way a disabled customer would. Letters often quote scanner output, so we confirm each quoted item by hand and note any that turn out to be false positives. Each finding in the report names the success criterion, the location, how to reproduce it and how serious it is. If you have never read one of these reports before, our explainer on reading an accessibility audit report shows what each part means. For the full method, see the WCAG audit page.
A fix plan with a sensible order and honest dates
An audit on a typical small business site produces dozens of findings, sometimes more. Nobody fixes them all in a day, and trying to usually breaks something else. So on ADA demand letter website projects we turn the report into a plan grouped like this:
- Blocking issues on key journeys. Anything that stops a person from contacting you, booking, buying or reading essential information. A checkout button the keyboard cannot reach. A form with no labels. A menu that opens only on hover.
- Items named in the letter, if not already covered above.
- Site-wide template problems that repeat on every page, such as missing skip links, invisible focus outlines or low-contrast footer text. One fix here clears many findings.
- Content issues like missing alt text, vague link wording and heading levels used for styling.
- Third-party items we cannot edit directly, with a note of what the vendor has been asked to change.
Each group gets a target date we believe we can meet, agreed with you and, if they want, reviewed by your attorney. We would rather give a slower date and hit it than promise speed and miss.
When a redesign is already on the table
Some owners tell us the site was due for a rebuild anyway, so why fix the old one? It is a fair question. The trouble is timing. A new site can take months to plan, build and launch, and during all that time the current one stays as it is. Our usual advice is to fix the blocking problems on the live site now, on the journeys customers use most, and build the new site to WCAG 2.2 AA from the first wireframe. Then the fix log covers the old site and the new build has its own test record before launch. Your attorney may have a view on whether waiting is acceptable; that is their call, not ours.
The actual fixing is described on our accessibility remediation services page.
Change records: the fix log behind every step
When a business later says “we fixed it,” the obvious question is: what exactly, and when? A good fix log answers that without anyone relying on memory. Ours records, for every item:
- The original finding and its success criterion.
- The page or template affected.
- What was changed, in plain words, plus a technical note for developers.
- Who made the change and on what date.
- The retest result, the method used and the date of the retest.
- Screenshots or short notes where they help show the before and after.
We work on a WordPress staging site where one exists, so changes are tested before they go live, and the log notes when each one was deployed. Items still open are kept on the same log with the reason, so the record is complete, not just a list of wins.
What the log will not say is just as deliberate. We do not write that the site is “ADA compliant,” that the matter is resolved or that no further letter can arrive. It states which WCAG 2.2 AA barriers were found, which were removed, how each was retested and what is still open. Those are facts we can stand behind; legal conclusions belong to your attorney.
What not to do after a website accessibility demand letter
A few moves come up again and again, and each one can make the situation harder.
Do not rush in a widget
The most common reaction is to install an overlay toolbar the same afternoon, then reply that the site is now accessible. Overlays add a layer on top of the page; they do not rebuild a broken menu or label a form properly. Disability advocates and many in the field criticize them, businesses running them have been sued anyway, and in 2025 the FTC brought an action against the overlay vendor accessiBe concerning its marketing claims. If an overlay is already on the site, we can help you replace it with real fixes; the overlay alternative page explains how we take one off safely.
Do not quietly delete or rewrite the pages in question
Pulling pages down or rewriting them in a panic can look bad and destroys the “before” picture. Ask your lawyer first, and keep the backup.
Do not let anyone promise an outcome
A web vendor who says “we will make this letter go away” or “you will be fully protected” is making a promise nobody can keep. The technical work removes barriers. The outcome of the dispute is a legal matter.
Do not fix only the items in the letter
The letter is a sample, not a full audit. If the same template problem exists across your site, fixing one page leaves the rest exactly where it was.
Do not treat a customer complaint as less serious
Not every warning comes from a law firm. Sometimes a customer emails to say she gave up on your order form, or calls the front desk because the online intake form will not let her move past the second page. Reply to that person, thank them, ask which device and assistive technology they use if they are willing to say, and offer another way to get the service in the meantime. Then fix the problem and tell them it is fixed. A complaint handled well is useful testing. One that is ignored can be the start of a formal dispute.
For background on how these letters and suits tend to arise, see how ADA website lawsuits work.
What we need from you, and from your counsel
- A copy of the letter, or the parts your lawyer is comfortable sharing, so we can check the specific items it names.
- A WordPress administrator account in our name, plus hosting or SFTP access if theme files need editing.
- Your staging site details, if you have one.
- A short list of the pages and forms that matter most to your customers.
- Logins or test accounts for embedded tools such as booking, ordering or payment, so we can test the full journey.
- One person on your side who can approve visible design changes quickly.
- Your attorney’s preference on how findings and reports should be shared, and with whom.
Some lawyers prefer that technical reports go through them first. We are happy to work that way; just tell us at the start.
How to judge whether the technical response is solid
You are paying for evidence, so check that you are getting it.
| A solid response | A weak one |
|---|---|
| Audit names WCAG 2.2 AA criteria for each finding | A screenshot of a scanner score |
| Manual keyboard and screen reader testing described | Only automated results |
| Fix log with dates, locations and retest results | “All fixed” in an email |
| Open items listed with reasons | No mention of anything left |
| Fixes in code, theme, plugins and content | A script added to the footer |
| Plan for checks after future updates | Nothing after handover |
Try one thing yourself too. Unplug the mouse, go to the page the letter complained about most, and use the keyboard to do what a customer would do there. If you can now finish the task and see where you are at each step, real progress has happened.
Handling it in-house versus bringing in an outside team
If your developer knows accessibility well, they can do much of the fixing. The catch is independence. When the same person who built the site also audits it, a reviewer may reasonably ask how objective the findings are. A common setup is an outside audit and fix log from us, with your own developer working alongside on content or design changes, all recorded in one place.
Content tasks, like rewriting link text or adding alt text, are fine for your staff once they know what to look for. Theme code, plugin markup, focus handling and form error behavior are where an experienced hand saves time and avoids new bugs.
Questions to put to any firm doing post-letter fixes
- Will you test the whole site’s key journeys, or only the items in the letter?
- What share of the testing is done by a person with a keyboard and a screen reader?
- Will each fix be retested and logged with a date?
- Do you rely on an overlay, plugin or script for any part of the work?
- Are you willing to talk to our attorney and keep reports in the format they want?
- What will you say in writing about the result? (Walk away from any promise of full compliance or protection from suits.)
- What happens after the fixes, when the next theme update lands?
Staying on track once the dispute settles down
Whatever happens on the legal side, the site keeps changing. A plugin update next spring can undo a form fix from this fall. New staff add images without alt text. A redesign brings in a theme nobody tested. Settlement terms, where there are any, sometimes include ongoing obligations, and only your attorney can tell you what those mean for you.
On our side, the practical answer is to fold accessibility checks into regular care. With our WordPress maintenance plans, updates and accessibility retests happen together, and the monthly report extends the same fix log you started with. If you are reading this before any letter has arrived, the broader ADA website compliance support page describes the same audit-and-fix approach for businesses acting early, and you can see every service in the WebMaintor accessibility hub.