Tag: Web Design

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.

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.

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:

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:

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

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.