Six Errors Cause 96% of Detected Accessibility Failures. Fix Them Before You Buy a Widget.
WebAIM scanned a million home pages in 2026 and found the same six problems for the seventh year in a row. Here is how I find and fix each one on a small-business site.
In February 2026, WebAIM ran an automated accessibility scan on the home pages of the top one million websites. It found detectable failures on 95.9% of them.
That number gets quoted a lot. The more useful one is buried further down the report: 96% of every error it detected fell into just six categories. They have been the same six categories for seven years.
I build websites for small businesses and home care agencies, and I run accessibility checks before every launch. My view after doing this for a while is simple. Most small-business sites don’t have an accessibility mystery. They have some mix of these six problems, and each one is a fix in code you already own.
So fix those first. Then test the site with a keyboard and a screen reader. Don’t buy an accessibility widget until both are done, and probably not even then.
The six errors, ranked
A quick definition first. WCAG, the Web Content Accessibility Guidelines, is the W3C standard that most accessibility laws and lawsuits point to. Its middle level, AA, is the usual target. WebAIM’s scan uses a tool called WAVE to flag failures a machine can detect.
Here is the share of home pages with each error type in the WebAIM Million 2026 report:
- Low-contrast text: 83.9% of home pages, with an average of 34 instances on each page.
- Images with no alt text: 53.1%.
- Form fields with no label: 51%.
- Empty links: 46.3%. These are links a screen reader can’t name, usually an icon with no text.
- Empty buttons: 30.6%. Same problem, on buttons.
- No document language set: 13.5%.
It is getting worse, not better. The average home page had 56.1 detected errors, up 10.1% from 2025. Pages are also heavier: WebAIM counted 1,437 elements on the average home page, up 14.3% in a year. More parts means more places to forget a label.
Look at that list again. Nothing on it needs a specialist. Every item is a color choice, a text attribute, or a word that should have been written and wasn’t.
Fix 1: contrast, decided before anyone writes CSS
WCAG asks for a contrast ratio of at least 4.5:1 between text and its background. Large text, which W3C puts at roughly 24px, or about 18.5px bold, needs 3:1. Buttons, form borders, focus outlines and meaningful icons need 3:1 against whatever sits next to them.
Two details trip people up. The ratios are not rounded, so 4.49:1 fails. And logos are exempt, so your wordmark can stay exactly as it is. The exemption stops at the logo. Your headlines and buttons don’t get a pass just because they use brand colors.
Contrast is the most common failure because it is usually decided in the wrong room. A palette gets picked on a big monitor next to a logo, and nobody tests it on a phone in daylight.
Here is a real example. For PrintVision, a print and packaging house in Lahore, the palette is the printing process itself: cyan #00AEEF, magenta #EC008C, yellow #FFF200 and a charcoal #231F20. It is a great identity. Run through the WCAG formula, it also shows how one color can pass and fail at the same time.
- Magenta on white measures 4.25:1. It fails for body text and passes for large headlines and button shapes.
- Cyan on white measures 2.53:1. It fails for everything, even a button outline.
- Cyan on charcoal measures 6.44:1. It passes for everything.
- Yellow on white measures 1.17:1. Yellow on charcoal measures 13.94:1.
The fix is not to drop the colors. It is to give each color a job. Charcoal carries body text. Magenta gets large headlines and button fills with charcoal labels. Cyan and yellow live on dark grounds. I wrote up the full role table in my guide to accessible brand colors, and you can check any pair yourself in the free WebAIM Contrast Checker.
Fixes 2 to 6: names for the things a screen reader can’t see
The other five errors share one cause. Something on the page has a meaning that is obvious to a sighted mouse user and invisible to everyone else.
Alt text. Every meaningful image needs a short description of what it is for, not what it looks like pixel by pixel. The Justice Department’s web guidance puts it plainly: “To be useful, the text should be short and descriptive.” A photo of your team at a job site might be “Our crew installing a commercial sign in Allen.” A purely decorative swoosh gets an empty alt attribute, alt=””, so a screen reader skips it instead of reading out a file name.
Form labels. This is the one I see most on small-business sites, because of a design habit. The field shows grey placeholder text like “Your email” and no visible label. It looks clean. Then the placeholder disappears the moment someone starts typing, and placeholder text is not a reliable label for screen readers. WebAIM found that 33.1% of all form inputs it tested had no proper label.
The fix is a few characters of HTML:
Before:
<input type="email" placeholder="Your email">
After:
<label for="email">Email</label>
<input id="email" type="email" autocomplete="email">The autocomplete attribute is a bonus. It lets browsers fill the field for people who find typing slow or painful, and it is its own WCAG requirement.
Empty links and buttons. These are almost always icons. The hamburger menu. The little X that closes a popup. The Facebook and Instagram logos in the footer. To a screen reader user, each one is announced as “link” or “button” with nothing after it. Give each one a name with visible text or an aria-label, such as aria-label=”Open menu”.
Get Jawad Farooq Naik’s stories in your inbox
Join Medium for free to get updates from this writer.
Document language. One attribute on the html tag: lang=”en”. W3C explains that screen readers use it to load the right pronunciation rules. If you run a Spanish version of your site for clients in Texas, those pages need lang=”es”, or a screen reader will try to read Spanish with English pronunciation.
I scanned my own sites. One real flag, six false ones.
Before writing this, I ran a quick script over the server-rendered HTML of four of my own pages: the home and contact pages of pinn.media and jnaikcreates.solutions. It checked the five errors you can test without rendering the page. Contrast needs a real browser, so I left it out.
Across 40 images, 221 links, 153 buttons and 9 form fields, it found:
- A language set on all four pages.
- No images missing alt text.
- No empty links.
- One unlabeled form field.
- Six empty buttons.
The unlabeled field is real. The pinn.media contact page has a small paint canvas where you can sketch an idea, and its brush color picker has no label. A screen reader user would land on a color control with no name telling them what it changes. The fix is aria-label=”Brush color”, and it is on my list.
The six empty buttons are not real. They are keys on a decorative keyboard drawing on the jnaikcreates.solutions home page. That whole drawing is already hidden from assistive technology with aria-hidden=”true”, and each key is taken out of the tab order. My script didn’t account for that. A person looking at the page would see it in two seconds.
That is the whole argument for pairing tools with people. The Justice Department’s guidance says it directly: “A ‘clean’ report does not necessarily mean everything is accessible. Also, a report that includes a few errors does not necessarily mean there are accessibility barriers.” WebAIM says the same about its own numbers. Missing errors don’t prove a page is accessible.
One more finding from the report is worth knowing before you start sprinkling ARIA attributes everywhere. Pages that used ARIA averaged 59.1 detected errors. Pages without it averaged 42. ARIA is a precise tool. Used to patch a div that should have been a button, it tends to add problems.
Why an overlay is the wrong first purchase
An overlay is a script you paste into your site that adds an accessibility toolbar and promises to fix issues automatically. They are sold hard to small businesses, usually with the word “compliant” somewhere on the page.
In April 2025, the Federal Trade Commission finalized an order requiring accessiBe to pay $1 million. The FTC said the company had claimed its accessWidget tool could make any website WCAG compliant. The order bars the company from claiming an automated product can make a site compliant, or keep it compliant, without evidence to back it up.
Look back at the six errors and the problem is obvious. A script can guess at alt text, but it doesn’t know that the photo is your crew in Allen. It can’t write a label for a field it doesn’t understand, caption your videos, fix a scanned PDF, or untangle a menu that traps keyboard focus. Those fixes live in your pages, and the money is better spent there.
The 30-minute check I run before launch
This is the manual pass I do on every site after the scanner is clean. You don’t need to be a developer to run most of it.
- Tab through the home page and the contact page. Put the mouse away and press Tab. You should always see where you are, and you should reach every menu item, link and button in a sensible order. If the highlight vanishes or you get stuck in a popup, that is a failure.
- Watch for a hidden focus. WCAG 2.2 added a rule that a focused item can’t be completely hidden behind content you put there, like a sticky header, a chat bubble or a cookie banner.
- Check tap targets. WCAG 2.2 also asks for targets of at least 24 by 24 CSS pixels, or enough spacing around smaller ones. Tiny footer icons and close buttons are the usual offenders.
- Zoom to 200%. Text should grow without overlapping or getting cut off.
- Run every color pair through a contrast checker. Body text, links, button labels, and placeholder text if you insist on keeping it.
- Submit every form wrong on purpose. The error should be in words, next to the field, not only a red border.
- Listen to one page. Turn on VoiceOver on a Mac or iPhone, or the free NVDA screen reader on Windows. Listen to your home page from the top. Unnamed buttons and missing labels become very obvious very fast.
- Check the widgets you didn’t build. Chat boxes, booking schedulers and review carousels are part of your site to a visitor. “The vendor built it” doesn’t help the person who can’t use it.
I keep a longer version of this list, with the launch steps around it, in the website redesign checklist on the Pinn.Media journal.
Who is on a clock
This part varies by who you are, so treat it as orientation, not legal advice.
The ADA applies to state and local governments under Title II and to businesses open to the public under Title III. For governments, the Justice Department has set WCAG 2.1 AA as the technical standard, with compliance dates in 2027 and 2028 depending on size.
Health and care providers that receive federal money from HHS have their own dates under Section 504: May 11, 2027 for recipients with 15 or more employees, and May 10, 2028 for smaller ones, again at WCAG 2.1 AA. I covered that sector in detail in my guide to home health website accessibility.
For most private businesses there is no single federal deadline. There is the plain requirement in the Justice Department’s guidance that businesses open to the public provide equal access, and WCAG is the yardstick people use to measure it.
Start with the boring six
The good news in the WebAIM data is how unglamorous it is. The web’s most common accessibility failures are pale text, missing descriptions, missing labels, unnamed icons and a missing language tag. A small team can fix all of them in an afternoon.
So start there. Open your home page, put the mouse in a drawer, and press Tab. Count how many times you lose track of where you are. That number is your to-do list.
