You Can't See Who's Visiting Your Website

Most accessibility problems are decisions someone made without picturing the person on the other end. Here are the ones I run into most, matched to who they hit.

• Vestibular disorders and migraines: auto-rotating carousels, parallax scrolling, and animated backgrounds can cause dizziness or nausea. A 5-slide hero that spins on its own is a common offender.
• Photosensitive epilepsy: flashing content. WCAG's rule is no more than 3 flashes per second, and the easy way to follow it is to not flash anything.
• Dyslexia and ADHD: walls of text, justified paragraphs, autoplay video, and popups that grab focus. Short paragraphs, left-aligned text, and real headings do more than people expect.
• Low vision: light gray text on white. Also anyone reading on a cracked phone in direct sun.
• Hearing loss: video with no captions, and information that only exists in audio.
• Tremors, chronic pain, and fatigue: tiny tap targets, menus that only open on hover, and anything that requires dragging. WCAG 2.2 sets a minimum target size of 24 by 24 CSS pixels.
• Brain fog and cognitive disabilities: sessions that time out mid-form, forms that wipe your answers after one error, and asking for the same information twice. WCAG 2.2 added a requirement that people shouldn't have to re-enter information they already gave in the same process.

None of these visitors announce themselves. The person who bounces from your site after 10 seconds looks the same in analytics as the person who was never interested.

WebAIM runs an automated scan of the top 1 million home pages every year. In the 2026 WebAIM Million report, 95.9% of those pages had detectable WCAG 2 failures, up from 94.8% the year before. That reversed a slow, small improvement. Average errors per page rose to 56.1.

The failures are also boring. Low-contrast text showed up on 83.9% of pages. Six categories (contrast, missing alt text, missing form labels, empty links, empty buttons, and missing page language) account for about 96% of everything the scan found.

One detail I like, because it argues against the usual instinct to bolt something on: pages that used ARIA averaged more errors than pages that didn't (59.1 versus 42). ARIA is a useful tool. It is also easy to use badly, and it can't rescue markup that was wrong to begin with.

For scale, the CDC says about 1 in 4 US adults has a disability. If your site loses even a fraction of them, that is a lot of people.

You don't need a full audit to make progress. These five take an afternoon or less, and I'd do them in this order.

1. Do the keyboard test. Put the mouse away and Tab through your homepage. Can you see where focus is? Can you reach every link and button? Can you get out of every menu? If not, you have your first fix.
2. Check your text contrast. Normal text needs a 4.5:1 ratio against its background. Gray body text, gray footer links, and pale button labels are the usual failures. Often the whole fix is one CSS variable.
3. Stop anything from moving on its own. Pause the carousel or replace it with one static image. Then respect the visitor's system setting for reduced motion:

   @media (prefers-reduced-motion: reduce) {
     *, *::before, *::after {
       animation: none !important;
       transition: none !important;
       scroll-behavior: auto !important;
     }
   }

4. Put text in text. Event flyers and program cards that are really images can't be read by a screen reader, translated, or searched. Write the words in HTML, add real alt text to the photos that carry meaning, and caption your videos.
5. Fix your forms. Every field gets a visible label (a placeholder doesn't count). Errors say what went wrong in plain words. A failed submit keeps what the person already typed. Nothing times out while someone is still filling it out.

Automated scanners catch only a portion of real problems, so run one (WAVE and axe are both free) and then do the keyboard test and a screen reader pass by hand. I'd also skip the overlay widgets that promise to fix accessibility with one line of script. The problems live in your markup, and a script on top of it doesn't change that.

You will never see most of the people your website fails. That is the whole reason to check. If you build the site so the keyboard user, the migraine sufferer, the person with a foggy afternoon, and the visitor squinting at a phone in the sun can all finish what they came to do, it works better for everyone else too.