The Website Accessibility Letter, and What Reduces the Risk

Something arrived about your website. It names your business, it names some pages, it uses language that sounds like a court has already decided something, and it asks you to respond. Or it has not arrived yet and you heard that a business two streets over got one, which is why you are reading this at eleven at night.

Everything you find when you search this is written by somebody with something to sell to a worried person. On one side, firms who would like to represent you. On the other, products that promise compliance by tomorrow for a monthly fee. Both are speaking to your fear rather than to your situation.

There are three separate questions tangled up here, and pulling them apart is most of the work. What the letter is legally, which needs a lawyer. What is actually wrong with your website, which can be established. And what people are trying to sell you, which becomes much easier to judge once the first two are separate.

Start with the distinction that changes your next hour. A demand letter is not a court order and it is not a finding against you. It is a claim, sent to you, and what it actually is legally depends on what it says, who sent it and what they are alleging. That determination is a lawyer's, and this post is not legal advice.

What you can do straight away is preserve. Keep the letter itself and note the date it arrived. Save the exact URLs it names, and screenshot them as they currently are. Record which version of the site is live, which platform and plugins it runs on, and who has access. Gather any accessibility work anybody has done before. Then ask your attorney how they want that material handled before you share it or start changing pages.

The instinct to go and fix the named pages immediately is understandable and worth pausing on. Talk to counsel first about the sequence, because changing the thing that has been complained about, before anybody has recorded what it looked like, removes the evidence of what was actually there.

Read the letter for specifics while you wait. Does it name a domain, a subdomain, a particular form, a booking flow, a PDF, a checkout? Does it describe a real user journey, somebody trying to book or buy or submit something, or does it only mention the home page? Is the barrier it describes in your own code and content, or in a payment, chat, map or scheduling service that somebody else runs? Those answers shape both the legal conversation and the technical one.

It helps to know what is usually being alleged, because these are concrete failures with people behind them. The Department of Justice's web guidance gives concrete examples, and they are the ones that come up.

A form that cannot be submitted without a mouse, so somebody using only a keyboard fills it in and cannot send it. Images with no text alternative, so a screen reader announces nothing useful where your product or your process is explained. Text with too little contrast against its background. Instructions that rely on colour alone. Video with no captions. A booking flow where the focus jumps somewhere invisible after each step.

Each of those has a person behind it who wanted to contact you or buy from you and could not. That is worth holding onto through the rest of this, because it is the part that stays true whatever happens with the letter, and it is the reason the underlying work is worth doing rather than performing.

DOJ also states its longstanding position that ADA requirements apply to the goods, services and privileges that public accommodations offer, including those offered on the web. Whether Title III applies to your particular business and site is a legal question with fact-specific answers, and again, that one goes to counsel.

This is where the technical answer gets separated from the sales pitch, and one fact does most of the separating: W3C says accessibility evaluation tools cannot check every aspect automatically, and that conformance evaluation needs semi-automated tools combined with manual review by an experienced reviewer.

So, an automated scan is a triage aid. It finds detectable issues quickly and cheaply, and it is genuinely useful for that. It does not tell you whether somebody can complete your booking form with a screen reader, whether keyboard focus behaves sensibly in your menu, whether your error messages make sense when they are read aloud, or whether your alt text describes what the image is actually doing on the page. Those need a person.

A credible evaluation states its own boundaries, and W3C's own report template lists what that means: the base URL, which URLs are included and which are excluded, the date, who reviewed it, which tools and versions were used, what manual testing was done, the WCAG version and level being assessed, the individual findings, and the limitations. If a report does not tell you what it did not look at, you cannot act on it.

One more thing to know before you scope anything. WCAG conformance applies to full pages, and where a task runs across several pages, every page in that process has to conform for the process to conform. So, a claim about a checkout has to cover every page in it.

Once counsel has advised on the letter, the technical work follows a shape.

Define the scope honestly. That means the base domain and any subdomains, the CMS, and every function a customer uses: booking, payment, scheduling, chat, maps, documents, video and third-party embeds. Then the complete journeys, meaning the whole path somebody takes to contact you, book, buy, apply or submit a form, rather than a list of pages.

Get an independent, documented evaluation of that scope. Automated checks plus manual testing, with the findings written down individually rather than as a score.

Triage what comes back. Most lists collapse into a handful of groups: repeated defects in a template, which are one fix applied everywhere; broken high-value journeys, which matter most; missing or poor text alternatives; contrast; headings; form labels and error handling; captions; PDFs; and third-party components you do not control.

Then fix underneath. The repairs belong in the templates, the code, the content and the publishing process, not in a layer applied on top. Some decisions are yours rather than the developer's: what an informative image is actually conveying, which documents are current, what a caption should say, how a form error should be worded.

Re-test the repaired pages and the whole affected process, and keep the record: what was checked, by whom, when, what was fixed, what remains and why.

There is no honest universal timeline for this. Duration depends on how many templates and page types you have, how much of it is dynamic, how many documents and videos are in scope, how many third-party tools are involved, and whether anybody can actually get at the source code. A fixed two-week promise made before the scope exists is describing a schedule rather than your website.

There is no published price schedule for this work, and the numbers you will see quoted are vendor offers rather than market rates. For context on the order of magnitude, published US service pages list an audit from around $3,000 and remediation from around $5,500, and another lists proactive remediation at $2,500 to $7,500. Those are starting prices from particular vendors, not an average and not a quote for your site.

What legitimately moves the number is the number of unique templates and customer journeys rather than raw page count, whether there is a shop or a booking system or a login, how many documents and videos are in scope, how many languages, how much manual and assistive-technology testing is included, and whether anybody can reach the source code.

When you read a proposal, four things decide whether you can hold it to anything. Does it name the scope, including what is excluded? Does it state the exact WCAG version and level, and whether it is an audit, remediation, re-testing, monitoring, or all of them? Does it describe the method, meaning the tools, the manual tests and who is doing them? And does it define what finished looks like, with a dated report, findings at the URL or component level, and a re-test record?

Treat any broad compliance guarantee as something requiring evidence rather than as reassurance. The reason is a matter of public record: in 2025 the FTC finalised an order requiring a $1 million payment to resolve allegations that an AI-powered accessibility tool was misrepresented as able to make any website conform to WCAG. That is one enforcement matter about one company's advertising rather than a verdict on every product, and it is a good reason to ask what evaluation and repair sit underneath any promise.

One thing that may be worth a call to your tax preparer: the IRS describes a Disabled Access Credit for eligible small businesses, defined as those earning $1 million or less or having no more than 30 full-time employees in the preceding tax year, at 50% of eligible access expenditures over $250 with a maximum credit of $5,000. Whether your business and this spending qualify is a question for a qualified preparer.

A useful amount, and none of it requires calling it a compliance result.

Make the inventory: every public site, subdomain, landing page, document library, video, form, booking path, payment flow, third-party embed and customer journey. That list is valuable to everybody who touches this afterwards.

Then the content work, which is genuinely yours because it depends on facts only you know. Write concise, factual descriptions for images that carry information, and mark the purely decorative ones as decorative. Supply accurate captions or transcripts from the original recordings. Replace PDFs that are out of date. Make form instructions clear, and make error messages say what to do rather than only that something is wrong.

Run an automated checker as triage, keep the dated output, and treat it as a starting list rather than a verdict. Name somebody internally as responsible. Add a visible way for a visitor to report an accessibility problem.

Where to stop is specific. Do not start guessing at semantic markup, ARIA behaviour, keyboard focus order, form validation, modal dialogs, checkout or authentication, or third-party code. And do not describe untested changes as a conformance result, because a conformance claim under WCAG has defined components and a defined scope, and an informal one creates a problem rather than solving one.

Two Texas points are worth knowing about, and both are questions for counsel rather than conclusions you can draw yourself.

Texas Human Resources Code chapter 121 prohibits denial of access to a public facility, including failure to make reasonable accommodations or provide necessary auxiliary aids and services, and section 121.004 permits a civil action with a conclusive presumption of at least $300 in damages, subject to section 121.0041 where that applies.

Section 121.0041 is the one to ask about specifically. It expressly covers certain actions alleging failure to comply with applicable technical standards, including internet website accessibility guidelines, and requires written notice at least 60 days before filing. It sets out what that notice must contain, including the individual, the alleged violations in reasonable detail, and the date, place and manner of discovery, and it restricts demanding a damages sum or making a settlement offer before the statutory determination. Whether it governs the document in front of you is exactly the sort of thing an attorney answers.

Locally, there is less than people expect. Arlington has a city ADA coordinator and policy, and that covers the city's own services, programs and activities as a public entity. Texas also has digital accessibility requirements for state agencies and institutions of higher education, which are government duties rather than a general rule for private businesses. The Arlington Chamber published a piece in June 2026 encouraging local businesses to think about accessible communication including websites, captions and alt text, which is a useful nudge rather than a legal authority.

The thing that prevents this recurring is a small ongoing practice, because new content, new documents, new templates and new integrations all introduce new barriers.

Keep the baseline: a dated, scoped evaluation with the tester, the WCAG version and level, what was included and excluded, the findings and the limitations. Keep the re-test record alongside it. If you ever make a formal conformance claim, W3C sets out what it has to contain, including the date, the version, the level and the pages covered, and an informal claim is worse than none.

Then assign the ongoing bits. Somebody owns accessibility for new content. Checks happen before publishing rather than after. There is a visible route for a visitor to report a problem, and somebody reads it. And the whole thing gets re-evaluated after a material change to templates, platform, integrations or content.

You will know the work has genuinely improved things when the documented scope has been evaluated both ways, the cited issues have traceable fixes and re-test results, the core customer journeys work under the chosen test method, and new changes go through the same controls. That is evidence of a real process, which is what you can build and keep.

Is a demand letter the same as being sued? No. It is a claim sent to you rather than a court finding. What it is legally, and what response it needs, depends on its contents and is a question for an attorney.

What should I do in the first 24 hours? Preserve the letter, the URLs it names, screenshots of those pages as they are now, and the date. Then speak to counsel before changing the pages that are being complained about.

Does an accessibility widget make my site compliant? Treat any automatic compliance claim as something needing evidence. The FTC finalised an order in 2025 over allegations that such a claim was misrepresented, and W3C is clear that evaluation requires manual expert testing as well as tools.

Is WCAG the law for private businesses? The Department of Justice says it has no detailed technical web regulation for businesses under the ADA's general requirements, while identifying WCAG as helpful technical guidance. Whether and how the law applies to your business is legal advice.

How much does this cost? There is no published market rate. Vendor pages list audits from around $3,000 and remediation from around $2,500 to $7,500 as starting figures. Your cost depends on templates, journeys, documents and how much manual testing is included.

Is any of this worth doing if no letter has arrived? The fixes make the site usable for customers who currently cannot complete a booking or a form. That is the reason that holds regardless of whether anything is ever sent to you.

Take the three questions apart. The letter is a legal matter and belongs with an attorney, starting today. Your website is a technical matter and can be established with a proper evaluation, meaning automated checks plus manual testing, scoped to whole journeys rather than pages, documented with what it covered and what it did not. And the things being sold to you become easy to assess once you know what a real evaluation looks like, because you can ask any vendor to show you theirs.

Preserve first, take advice, then fix underneath rather than on top. Keep the dated record of what was tested, repaired and left, and give somebody the job of checking new content before it publishes.

If you want the technical half handled properly, and a record you can hand to your attorney, we can do that. Arlington Website Designer builds and repairs websites for businesses in Arlington, Texas and the surrounding Tarrant County towns, and for clients across the country, and accessibility work here means the pages and the journeys underneath rather than a badge on top. Send the letter's page list and your site address through the contact page, and our team will take it from there. The legal question stays with your attorney, and we will work alongside them.