Most businesses don’t think seriously about website accessibility until somebody else forces them to. By then, the conversation has changed.
Your website has been online for years.
Customers use it. Your staff uses it. Maybe a web developer built it for you. Maybe you’ve redesigned it two or three times.
Nobody has ever mentioned accessibility.
Then one day, an email, letter, complaint, or legal filing arrives alleging that people with disabilities can’t fully use your website.
Suddenly, you’re reading terms like ADA, WCAG, screen reader, keyboard accessibility and alternative text.
And you’re asking a much different question:
How did we get here?
Welcome to what happens after the demand letter.
The Problem Usually Started Long Before the Letter Arrived
Website accessibility problems rarely appear overnight.
They accumulate.
A new image gets uploaded without alternative text.
A website redesign introduces menus that don’t work properly from a keyboard.
A new form gets added without properly associated labels.
A third-party scheduling system, shopping cart or payment tool introduces accessibility barriers.
A video gets published without captions.
A developer changes colors and suddenly text no longer has sufficient contrast.
One change at a time, the website evolves.
The business sees a functioning website.
A person using assistive technology may experience something very different.
That distinction matters.
The U.S. Department of Justice has consistently taken the position that the ADA applies to the goods, services, privileges and activities offered by businesses open to the public, including those offered through websites.
But website accessibility law for private businesses isn’t as simple as saying, “The ADA requires every private website to meet WCAG.”
Courts have taken different approaches to some questions involving websites, and unlike the newer Title II requirements applicable to state and local governments, there isn’t one federal technical website standard that universally applies WCAG to every private business under Title III.
That legal complexity is one reason businesses shouldn’t wait until they receive a legal claim to begin understanding their accessibility risk.
Because when that happens, the question is no longer theoretical.
Step 1: Somebody Encounters—or Identifies—an Accessibility Barrier
Imagine trying to use a website without a mouse.
Can you reach every menu, button, form field and link using only the keyboard?
Can you see where keyboard focus is located?
Or imagine using a screen reader.
Does the website tell you what its images represent?
Do buttons have meaningful names?
Can you understand the structure of the page from its headings?
Does a form tell you which field contains an error and how to correct it?
These aren’t obscure technical details.
They affect whether somebody can actually use the site.
Website accessibility claims commonly involve issues such as:
- Missing or inadequate alternative text
- Unlabeled form controls
- Keyboard navigation problems
- Insufficient color contrast
- Improper heading structure
- Inaccessible menus and navigation
- Missing captions or transcripts
- Poor focus management
- Inaccessible pop-ups or dialogs
- Improper use of ARIA
- Third-party applications that create barriers
An automated accessibility scanner can detect some of these problems.
It can’t detect all of them.
That becomes important later.
Step 2: The Business Receives a Demand Letter, Complaint or Lawsuit
This is usually the moment accessibility becomes an executive-level issue.
Until yesterday, accessibility might’ve been buried somewhere between web maintenance, marketing and IT.
Today, the owner, attorney, web developer and management team may all be discussing it.
And several questions immediately surface:
Is the allegation legitimate?
How inaccessible is the website?
What exactly needs to be fixed?
Who’s responsible for fixing it?
How quickly can it be done?
How much is this going to cost?
What should we tell our attorney?
And perhaps the biggest question:
Why didn’t anybody tell us about this before?
Recent reporting continues to document small businesses being surprised by ADA claims and then facing potentially significant legal expense defending or resolving them.
Whether you believe every accessibility lawsuit is justified isn’t really the point.
Whether you believe some litigation is excessive isn’t the point either.
The business still has a problem sitting in front of it.
Step 3: Your Attorney Needs Facts
Once an accessibility claim enters the legal process, one of the worst things a business can do is start guessing.
“We think the website is accessible.”
“Our developer said it was ADA compliant.”
“We installed an accessibility plugin.”
“We ran a scanner and got a 95.”
“We’ve never had a customer complain.”
None of those statements tells you the actual condition of the website.
Your attorney handles the legal strategy.
But somebody still needs to answer the technical question:
What accessibility barriers are actually present?
That may require a qualified accessibility evaluation involving automated testing, manual inspection and, where appropriate, assistive-technology testing.
That evaluation may uncover legitimate problems.
It may also provide important context about allegations made against the site.
Either way, now you’re working with evidence instead of assumptions.
Step 4: The Accessibility Work Becomes Urgent
This is where waiting gets expensive.
Imagine discovering that your website has 75 accessibility problems when you’re under no external pressure.
You can assess them.
Prioritize them.
Assign responsibility.
Fix the highest-impact problems first.
Document your progress.
Test the fixes.
Build accessibility into future updates.
Now imagine discovering those same 75 problems after receiving a legal claim.
The technical problems haven’t necessarily changed.
The environment has.
Your attorney needs information.
Management wants answers.
Developers may need to interrupt other projects.
Outside accessibility specialists may need to be hired.
Decisions that could’ve been made methodically now have deadlines attached to them.
That’s the difference between managing accessibility risk and reacting to accessibility risk.
The Worst Time to Start Managing Accessibility Risk Is After Somebody Else Has Already Discovered It
That’s really the message of this article.
Accessibility isn’t just a pass-or-fail exercise.
And managing accessibility risk doesn’t begin and end with running a website scanner.
A more mature process asks:
What barriers exist?
Which barriers create the greatest impact?
Which pages and user journeys matter most?
What can we correct immediately?
What requires development work?
What involves a third-party vendor?
Who owns each issue?
How are we documenting the work?
How will we verify that fixes actually work?
What happens when the website changes again?
Those are management questions.
And they can be answered before a demand letter ever arrives.
What If My Developer Says the Website Is ADA Compliant?
Ask a second question:
How was that determined?
There’s a significant difference between designing a website with accessibility in mind and evaluating the finished product for accessibility.
There’s also a difference between automated testing and a complete accessibility evaluation.
Automated tools are useful. We use them.
But many WCAG success criteria require human judgment.
A scanner might tell you that an image contains an alt attribute.
It can’t necessarily determine whether the alternative text accurately communicates the purpose of the image.
A tool may identify certain keyboard-related coding issues.
It can’t fully replicate somebody navigating an entire transaction with a keyboard.
And passing an automated scan doesn’t mean a website is fully accessible.
Accessibility requires testing.
What About Accessibility Widgets and Overlays?
Businesses sometimes discover accessibility overlays when searching for a quick solution.
Install a piece of JavaScript.
Display an accessibility icon.
Problem solved.
Unfortunately, website accessibility generally isn’t that simple.
An overlay may provide certain user controls or attempt to modify parts of the website dynamically, but it doesn’t eliminate the need to address accessibility problems in the underlying website.
If the checkout process is inaccessible, fix the checkout process.
If form controls aren’t properly labeled, fix the labels.
If somebody can’t operate the navigation using a keyboard, fix the navigation.
If videos need captions, caption them.
Accessibility should be built into the product itself.
A Better Position: Know, Prioritize, Fix and Document
There’s no credible accessibility professional who should promise that following a checklist guarantees that nobody will ever file a claim against you.
Nobody controls whether another person files a lawsuit.
What a business can control is its own behavior.
You can evaluate your website.
You can identify known barriers.
You can prioritize remediation.
You can document what you’ve corrected.
You can document what remains.
You can establish responsibility.
You can publish an appropriate accessibility statement.
You can provide a way for users to report accessibility problems.
You can incorporate accessibility into future web development.
You can demonstrate an ongoing, good-faith accessibility process.
That’s a fundamentally stronger position than:
“We had no idea.”
Before the Demand Letter
This is why we call this series Before the Demand Letter.
The objective isn’t to frighten businesses into buying accessibility services.
It’s to ask a much simpler question:
Would you rather discover your website’s accessibility problems yourself—or have somebody else discover them for you?
If you identify them first, they’re problems you can manage.
You can evaluate them.
Prioritize them.
Budget for them.
Fix them.
Document the work.
Improve your process.
But once a demand letter, complaint or lawsuit arrives, you may still have to do all of those things—except now you’re doing them while responding to a legal matter.
Same website.
Same accessibility barriers.
Very different circumstances.
Start Before You Have To
You don’t need to become an accessibility expert.
You do need a process.
That’s why we created the Accessibility Risk Assessment Playbook™.
It gives organizations a structured, business-first framework for identifying, prioritizing and documenting digital accessibility risk.
It isn’t a promise that you’ll never receive a demand letter.
It isn’t legal advice.
And it isn’t a magic “ADA compliance” certificate.
It’s something far more practical:
A way to begin doing the work before somebody else gives you a reason to.
Because the best time to understand your accessibility risk isn’t after the demand letter.
It’s before.
This article is provided for educational and informational purposes only and isn’t legal advice. Accessibility requirements and legal obligations can vary depending on the organization, jurisdiction, technology and circumstances. Organizations facing an accessibility claim should consult qualified legal counsel regarding their specific situation.
About 508 Help Desk
508 Help Desk helps organizations understand, assess and manage digital accessibility risk through practical accessibility education, assessment tools and structured remediation processes.