Most people assume accessibility is something you “deal with later”—or worse, something a plugin or automated tool will take care of for you.
That assumption is dangerously wrong.
Web accessibility is not just a best practice. It is tied directly to U.S. civil rights law under the Americans with Disabilities Act (ADA).
And yet… almost no one is talking about how serious this actually is.
The uncomfortable truth
If your website serves customers, sells products, or provides services, it may fall under Title III of the ADA, which applies to places of public accommodation.
Even though the ADA was written before the internet existed, courts and regulators have repeatedly interpreted it to apply to websites.
You can read the law directly here:
The key idea is simple:
If your business is open to the public, your website is expected to be accessible to people with disabilities.
This is reinforced by guidance from the U.S. Department of Justice.
Why this is confusing for most people
There is no single law that explicitly says:
“All websites must follow WCAG 2.1 AA.”
Instead, what exists is:
- A civil rights law (ADA)
- Court rulings interpreting that law
- DOJ enforcement actions and settlements
- Accessibility standards used as benchmarks
This creates a gap where many website owners and teams assume:
“If no law explicitly says it, I’m safe.”
But in reality:
Enforcement happens through lawsuits and settlements—not certifications.
The standard everyone quietly uses
Even though it is not written directly into the ADA, most legal cases and settlements reference the Web Content Accessibility Guidelines (WCAG) from the W3C.
Most legal actions reference WCAG 2.1 AA as the practical benchmark.
WCAG covers things like:
- Keyboard navigation
- Screen reader compatibility
- Color contrast
- Form labeling
- Focus management
If your site fails these areas, you are exposed—even if it “looks fine.”
The false promise of “AI website builders”
A new wave of "AI website" and no-code tools promise a complete site in minutes. They are fast, cheap, and incredibly tempting if you just want to get something online.
But fast and simple does not mean accessible or legally safe.
These tools can generate decent-looking layouts, but they do not:
- Understand your specific user journeys
- Manually test keyboard navigation or screen readers
- Catch subtle issues in menus, modals, and forms
At best, they can help with a starting point. They are not a substitute for deliberate design, semantic HTML, and real accessibility testing.
The real test is not a tool
True accessibility is not measured by a score.
It is measured by usability.
A simple rule:
If a user cannot fully use your site with only a keyboard, it is not accessible.
That includes:
- Tabbing through all interactive elements
- Seeing a visible focus indicator
- Opening/closing menus and modals
- Submitting forms without a mouse
If any of these fail, you have a real accessibility problem regardless of what a scanner says.
Why this matters legally
The ADA is enforced through civil litigation and complaints—not certifications.
In real-world cases, common failure points include:
- Unlabeled form inputs
- Buttons not accessible via keyboard
- Missing focus states
- Checkout or booking flows that require a mouse
These are not edge cases—they are extremely common in modern web apps.
The U.S. Department of Justice has explicitly acknowledged that access to the goods and services offered on the web sites of public accommodations is critically important for people with disabilities, and that title III covers access to those sites. You can read this discussion in the DOJ's own Title III regulations preamble here:
You can read DOJ guidance here:
Why no one is talking about it
1. It feels “handled” by tools
People assume automated scanners solve the problem.
2. It is invisible until it fails
Most accessibility issues are not obvious to people who don’t rely on assistive technology.
3. It is treated as legal noise
People see ADA compliance as paperwork instead of user experience.
4. Modern UI frameworks make it worse
Component libraries often prioritize visuals over semantic HTML.
The reality of modern web development
Here is the uncomfortable truth:
A large portion of modern websites are not fully accessible by default.
Not because people don’t care—but because:
- Non-semantic clickable elements are common
- Custom components break keyboard behavior
- Accessibility is not tested manually
- Design systems often skip real-world usability checks
What actually makes a site “safe” (practically)
You don’t need perfection.
But you do need the fundamentals:
- Full keyboard navigation support
- Semantic HTML (buttons, labels, links)
- Visible focus indicators
- Accessible modals and forms
- Reasonable color contrast
If those are in place, you are already ahead of most websites on the internet.
Final thought
Web accessibility is often treated like a checkbox.
But in reality, it is infrastructure.
If people cannot use your product, it does not matter how good it looks.
And the most surprising part?
It is still massively under-discussed in mainstream web development—even though it affects millions of users and carries real legal risk.