There is a version of your website you have never seen. When we talk about web accessibility, we are talking about the site a person hears instead of reads, or moves through with a keyboard instead of a mouse. It is the version someone gives up on because light gray text on a white background isn’t readable in a sunlit parking lot. For a meaningful number of your customers, that version is the only version there is.
In April, a federal accessibility deadline that had been years in the making moved. That has a lot of people talking about accessibility as a legal problem. The legal picture is worth understanding, and I will walk through it below. But it is the less interesting half of the story, and if it is the only reason you act, you will probably spend money on the wrong things.
Here is what real web accessibility actually means, what the rules do and do not require, why the one-click widgets are not the answer, and six things you can check on your own site this week without hiring anyone.
Table of Contents
What web accessibility actually means
Essential web accessibility means a person can use your website regardless of how they interact with a computer. That includes people who are blind and use screen reader software, people with low vision who enlarge text or need strong color contrast, people who cannot use a mouse and navigate entirely by keyboard, people who are deaf and need captions on video, and people with cognitive or reading differences who need clear structure and plain language.
It also quietly includes a lot of people who would never describe themselves as disabled. Anyone over sixty with declining vision. Anyone with a broken wrist. Anyone watching your video with the sound off, which is most people on a phone in public.
The technical standard everyone points to is called WCAG, the Web Content Accessibility Guidelines. It is not a law. It is a set of roughly fifty testable criteria published by the World Wide Web Consortium (W3C), the standards body for the web. The relevant version right now is WCAG 2.1, Level AA. That is the benchmark courts, regulators, and procurement officers have converged on.
Level AA is not an exotic bar. It covers things like: images have text descriptions, videos have captions, text has enough contrast against its background, every function that works with a mouse also works with a keyboard, form fields have labels, and page headings are in a sensible order. Most of it is unglamorous, and none of it requires a complete redesign.
The rule that changed in April, and who it applies to
In 2024 the Department of Justice finalized a rule under Title II of the Americans with Disabilities Act requiring state and local government websites and mobile apps to meet WCAG 2.1 Level AA benchmarks. Title II covers public entities: cities, counties, school districts, libraries, public universities, courts, and special districts.
On April 20, 2026, four days before the first deadline was set to land, the DOJ issued an interim final rule pushing both compliance dates back by one year.
| Who | Deadline |
|---|---|
| Public entities serving 50,000 or more people | April 26, 2027 |
| Public entities serving fewer than 50,000, plus special district governments | April 26, 2028 |
| Healthcare providers receiving federal HHS funding, under a separate Section 504 rule | 2027 or 2028, depending on size |
| Private businesses under ADA Title III | No fixed federal deadline. See below. |
I am not an attorney, and nothing in this article is legal advice. I am a web developer describing a technical standard and how to meet it. If you have a specific compliance obligation, a contract with a public entity, or a demand letter in hand, talk to a lawyer who practices in this area.
Two things about that extension are worth sitting with.
The deadline moved. The obligation did not. The ADA already required equally effective communication before any of this rulemaking existed. The extension delayed the date by which a specific technical standard becomes enforceable. It did not create a holiday from the underlying law, and people can still bring legal action during the extension. In the rule itself, the DOJ stated that it fully anticipates implementing the regulation at the new deadline.
If you are a private business, none of these dates are yours. Title II is government. Title III covers private businesses that are places of public accommodation, and the DOJ has never adopted a specific technical standard for Title III websites. That sounds like good news and mostly is not. It means there is no safe harbor, no checklist that certifies you, and no date you are working toward.
What there is instead: courts and settlements have consistently treated WCAG as the measuring stick anyway. According to tracking from legal experts at Seyfarth Shaw, website accessibility lawsuits have run past two thousand federal filings a year since 2018.
There is one more group this touches that people miss. The Title II rule states that it covers web content a public entity provides “directly or through contractual, licensing, or other arrangements.” If you build, host, or supply content for a government website, read that sentence twice. Whether and how it reaches any particular vendor contract is a question for a lawyer, not for me. What I will say plainly is that accessibility language is starting to appear in local RFPs and vendor agreements, and I expect more of it.
The part that takes the longest is not the code
Every web accessibility project I have worked on has had roughly the same shape, and it is not the shape people expect.
The code fixes are usually small. Heading order. Link text that says something other than “click here.” Contrast on a few buttons. Alt text. A skip link. None of it is exotic, and a competent developer can work through most of it quickly. People brace for a rebuild and rarely need one.
The documents are what take the time. PDFs, in particular. A scanned PDF is, to a screen reader, an image of a page with nothing readable on it. Any organization that has been publishing PDFs for a decade is sitting on an archive nobody can hear. That is not a coding problem. It is a content problem, and no amount of work on the theme touches it.
The fix also has to change the workflow, not just the archive. If you remediate hundreds of old documents and then someone uploads a scanned one next Tuesday, you are back where you started. The durable version of this work is unglamorous: publish content as web pages instead of PDFs wherever you can, and train the people who post it. That is less satisfying than a big remediation project, and it is the only part that holds.
The honest summary is that the technical debt is usually shallow and the content habits are what take time to change. That is good news for your budget, and bad news for anyone hoping to solve this by buying something.
About those accessibility widgets
You have probably seen the little person-shaped icon in the corner of a website. Click it and a panel slides out with toggles for bigger text, higher contrast, a dyslexia-friendly font. These are called overlays, and they are sold as a single line of code that makes your site compliant.
I want to be careful and specific here, because this is the section where I am telling you not to buy something.
In January 2025, the Federal Trade Commission (FTC) brought a case against accessiBe, one of the largest overlay vendors, over its marketing claims. According to the FTC’s complaint, the company advertised that installing its widget made a website meet thirty percent of WCAG immediately, and that an AI process would handle the remaining seventy percent within forty-eight hours.
The FTC alleged those claims were false and unsubstantiated, and that the product failed to make basic components like menus, headings, tables, and images accessible. In April 2025 the FTC issued a final order. accessiBe paid one million dollars and is barred from claiming its automated products can make a website WCAG compliant unless it has evidence to support the claim. The company settled without admitting liability.
The number that should actually get your attention is a different one. According to tracking from UsableNet, more than one thousand companies that had an accessibility widget installed on their website were sued over accessibility barriers anyway in 2024. They bought the product specifically to avoid the lawsuit, and got the lawsuit.
There is a deeper problem than the marketing. An overlay sits on top of your site and tries to guess at fixes in the browser. Screen readers are already doing their own interpretation of your page. When a script starts rewriting things underneath them, it can interfere with the assistive technology a person has spent years configuring. Some blind users now keep lists of sites to avoid because an overlay makes them worse, not better.
An overlay is a cosmetic layer over a structural problem. If your images have no alt text, no widget can invent an accurate description of them. If your checkout form has no labels, a contrast toggle does not help. The only thing that fixes a website is fixing the website.
Six web accessibility checks you can do yourself
1. Unplug your mouse
Seriously. Then try to use your own website with only the Tab key to move forward, Shift and Tab to move back, and Enter to activate. Can you reach every link? Can you open the menu? Can you fill out and submit the contact form? Can you always see where you are, or does the focus outline disappear?
This one test catches more real problems than any scanner. If you cannot book your own appointment with a keyboard, neither can a customer with a motor disability.
2. Check your color contrast
Light gray body text on a white background is the most common failure I see, and it usually comes from a designer choosing it on purpose. Body text needs a contrast ratio of at least 4.5 to 1 against its background. Large headings need 3 to 1.
Here is what that actually looks like. These are real colors rather than a screenshot, so you can zoom in on them or read them with a screen reader:
This gray is #999999. It measures 2.85 to 1 against white. It fails, and it is everywhere.
This gray is #767676. It measures 4.54 to 1. It is the lightest gray that passes on white.
This gray is #595959. It measures 7 to 1. It passes comfortably and still reads as gray.
Notice that the passing versions are still gray. Nobody is asking you to use pure black. The difference between the first line and the third is nearly invisible to most people in a well-lit room, and decisive to someone reading your site outdoors on a phone.
Your buttons are the other place this hides. White text on a light brand color is very common, and it almost never passes:
White text on this orange measures 2 to 1. It fails badly.
Dark text on the exact same orange measures 8.6 to 1. It passes easily.
That is the useful lesson. You almost never have to change your brand color. You have to change what you put on top of it. Check your own colors with the free WebAIM Contrast Checker. It takes about a minute per pair.
3. Look at your images
In WordPress, open your Media Library and switch to list view. Every image that conveys information needs alt text describing what it shows. Photos of your team, your work, your storefront, your products. Decorative images that carry no meaning should have empty alt text so screen readers skip them instead of announcing a filename.
Write it the way you would describe the photo to someone over the phone. “Crew installing a standing seam metal roof on a two-story house” is useful. “IMG_4471” is not. Neither is “roof photo.”
4. Watch your headings
Screen reader users navigate by jumping from heading to heading, the way you would skim a page. That only works if the headings are in order: one H1 for the page title, H2s for main sections, H3s nested underneath them. It breaks when headings get chosen for how big they look rather than what level they actually are.
Install the free WAVE browser extension and turn on the heading outline. If it jumps from H1 to H4, or if you have six H1s, that is a real structural problem, and it also hurts your search visibility. Search engines read your page structure for many of the same reasons a screen reader does.
5. Check your forms
Every field needs a visible label, not just placeholder text inside the box. Placeholder text vanishes the moment someone starts typing, which means a person using a screen magnifier or with a memory impairment has no idea what they are filling in halfway through.
Also check what happens when the form fails. Does it just turn a field red? Or does it say, in text, which field is wrong and why? A person who is colorblind cannot see red.
6. Turn on the screen reader already in your pocket
Your phone has one built in. On iPhone it is VoiceOver, under Settings then Accessibility. On Android it is TalkBack. Turn it on, close your eyes, and try to do one thing on your website. Find your phone number. Read your hours.
You will be bad at it, because you have not learned the gestures and the people who rely on this are extremely fast. That is fine. You are not testing your skill. You are listening to what your website says out loud, and that is an experience most business owners have never had. Then turn it off, because it is genuinely disorienting.
What this list is not
You can also run a free scan with WAVE or Lighthouse, and it is worth doing. Just know the limit. Automated testing reliably catches only a portion of web accessibility problems. It can tell you an image has no alt text. It cannot tell you the alt text is wrong. It can tell you a button exists. It cannot tell you the button is unreachable in the order a real person would meet it. Scanners find missing pieces. Only a human finds broken experiences.
And one caution before you feel too good about any of this. These six checks will find real problems, and fixing them will make your site meaningfully better. They are not an audit. Passing them does not mean your site conforms to WCAG 2.1 Level AA, which covers roughly fifty criteria and requires testing with actual assistive technology. Treat this list as a way to find out whether you have a problem, not as proof that you do not.
A legal problem and a customer problem are not the same thing
If you treat web accessibility as a legal problem, you will do what people do with legal problems. You will look for the cheapest thing that makes the exposure go away, you will buy the widget, and you will find out it did not work at the worst possible moment.
If you treat it as a customer problem, the work changes shape entirely. You are not buying protection. You are removing the reasons a person gave up on your site and called someone else. Nobody sends you an email explaining that your contact form was unusable with a screen reader. They just leave, and you never learn why, and the analytics show a bounce that looks exactly like every other bounce.
The CDC estimates that about one in four American adults lives with some form of disability. That is not a niche market. It is also not a fixed group, because most of us join it temporarily or permanently at some point.
The useful part is that the two problems have the same solution. Fix the site for the customer and the legal exposure goes down as a side effect. It does not work in the other direction. Start with the keyboard test. It is free, it takes ten minutes, and it will tell you more about your site’s comprehensive web accessibility than any automated report I could sell you.
Common web accessibility questions
Does the ADA apply to my small business website?
The April 2026 deadlines apply to state and local government, not to private businesses. But ADA Title III has long been applied to businesses open to the public, and courts have generally treated websites as covered. There is no adopted federal technical standard for private business websites, and no certification that makes you safe. In practice, WCAG 2.1 Level AA is the benchmark that courts, settlements, and procurement contracts use. Talk to an attorney about your specific exposure.
What is WCAG 2.1 Level AA?
WCAG stands for Web Content Accessibility Guidelines, a technical standard from the World Wide Web Consortium. It has three conformance levels: A, AA, and AAA. Level AA is the middle tier and the one regulators and courts point to. It includes about fifty testable criteria covering things like alt text, captions, color contrast, keyboard operability, and form labels. WCAG is not itself a law. The ADA is the law that requires meeting it.
Will an accessibility widget or overlay protect me from a lawsuit?
The evidence says no. UsableNet reported that in 2024, more than a thousand companies with an accessibility widget installed were sued over accessibility barriers anyway. In 2025 the FTC ordered one of the largest overlay vendors to pay one million dollars and barred it from claiming its automated product could make a website WCAG compliant. Overlays can also interfere with the screen readers people already use. Treat a widget as a tool at best, never as a substitute for fixing the site.
How much does it cost to make a website accessible?
It depends almost entirely on how the site was built and how much content it has. A small business site on a modern, well-coded theme often needs a handful of fixes: contrast, alt text, heading structure, form labels. A site with hundreds of scanned PDFs, or a heavily customized old theme, is a different conversation. The honest answer is that a professional web accessibility audit comes first, because anyone quoting a price before looking at the site is guessing.
I have a WordPress site. Is it accessible by default?
Partly. Modern WordPress core and the default block themes handle a lot of the fundamentals well. But structural web accessibility is mostly determined by what gets added on top: the theme, the page builder, the plugins, the sliders and popups, and above all the content people publish every day. A well-built WordPress site can absolutely meet WCAG 2.1 Level AA. It does not happen automatically.
I build and maintain WordPress websites for businesses and organizations around Bloomington. Sustainable web accessibility is something I design toward from the start rather than an add-on sold after the fact, and I would rather tell you honestly where a site stands than sell you a certificate. Nobody can promise a website that is permanently compliant, because websites change every time someone publishes a page. What I can do is look at yours and tell you the truth about it.
If that is useful, schedule a conversation.
Related reading: The Bloomington Business Owner’s Guide to Google Business Profile and Search Is Changing: What AI Visibility Means for Your Business. You can also read the accessibility statement for this site.
