It Works for Me: Accessibility Gaps Hiding in Plain Sight

Quick answer: a website can work perfectly for you and still be unusable for someone else, because you are only one kind of visitor. If you use a mouse, see colors clearly, read at default zoom, and don't mind animation, you will never notice the problems that stop keyboard users, screen reader users, people with low vision, and people sensitive to motion. These gaps are not rare edge cases. They are ordinary ways people use the web. The only reliable way to find them is to deliberately browse your own site the way those visitors do.

This is the last part of a three-part series. In part one, the gap was between your machine and a visitor's. In part two, it was between launch day and every day after. This time, the gap is between you and everyone who experiences your site differently.

It is the hardest gap of the three to see, for a simple reason. The first two were about environments. You can borrow a slow phone or wait a few months. This one is about people, and you can't switch off your own eyesight or stop reaching for your mouse by accident.

In short: "it works for me" describes one visitor. Before you call a page done, try it without a mouse, with a screen reader, zoomed to 200%, and with color turned off. Each one takes minutes and shows you a different website.

Why your own experience is a sample of one

Frontend developers test constantly, but almost always as themselves. You click with a trackpad, you scan the page visually, you read small gray text without squinting, and you never wait for a screen reader to announce each element in order.

That makes your testing honest but narrow. Every design decision gets checked against one person's abilities, habits, and equipment. When a pattern works for that one person, it feels finished.

Accessibility problems usually come from small, reasonable-looking choices: removing a focus outline because it looked untidy, using an icon without a label because the icon seemed obvious, or showing an error in red because red means error. None of these feel like bugs to the person who made them. To someone else, each one can be a locked door.

What "works" means to different people

Using only a keyboard

Many people navigate with the Tab key instead of a mouse. That includes people with motor disabilities, people using switch devices, and plenty of power users who simply prefer it. For them, a page works only if every interactive element can be reached and used from the keyboard, in a sensible order, with a visible sign of where they are.

The most common failures are quiet ones:

• The focus outline was removed in CSS, so users can't see which element is selected.
• A "button" is actually a styled div, so Tab skips right past it.
• A popup opens, but focus stays behind it on the page, or gets trapped inside it with no way out.

Try it: put your mouse in a drawer, press Tab from the top of the page, and try to complete your main flow. If you ever lose track of where you are, so will your visitors.

Using a screen reader

Screen readers announce the page out loud, one element at a time. They rely entirely on what the code says, not on what the page looks like. A magnifying glass icon is obvious to your eyes. To a screen reader, an unlabeled icon button is just "button."

Common gaps include images with no alt text, form fields with no connected label, icon-only buttons with no accessible name, and headings chosen for their size instead of their meaning, which breaks the outline screen reader users rely on to jump around a page.

Try it: turn on the screen reader built into your operating system (VoiceOver on Mac and iPhone, Narrator on Windows, TalkBack on Android) and listen to your homepage with your eyes closed. Can you tell what the page is for, and where the main action is?

Seeing color and contrast differently

Color vision varies a lot between people, and contrast that looks fine on a bright developer monitor can be hard to read on a cheap screen in sunlight. Two patterns cause most of the trouble: light gray text on white backgrounds, and using color as the only signal. A form field that turns red on error, with no icon or message, tells a colorblind visitor nothing.

Try it: use your browser's developer tools to emulate color vision deficiencies, or simply switch your screen to grayscale. Every status, error, and link should still be clear. Check text contrast against the WCAG guideline of at least 4.5 to 1 for normal body text.

Zooming in

People with low vision often zoom the browser to 200% or more. A well-built page reflows into a single readable column. A fragile one clips text inside fixed-height boxes, overlaps elements, or forces the reader to scroll sideways on every line.

Try it: press Ctrl and + (or Cmd and + on a Mac) until the browser shows 200%, then use the site normally. Pay attention to navigation menus, buttons with fixed widths, and anything positioned on top of something else.

Sensitive to motion

Parallax scrolling, auto-playing carousels, and large animated transitions look polished in a demo. For people with vestibular disorders, they can cause dizziness or nausea. For people who are easily distracted, a carousel that moves on its own makes the page harder to read.

Try it: turn on "reduce motion" in your operating system settings and reload your site. If nothing changes, your site isn't listening. The prefers-reduced-motion CSS media query lets you tone animation down for people who have asked for less of it.

Tired, distracted, or in a hurry

Not every accessibility gap is about a disability. Everyone has moments of low attention: on a phone, on a train, with a child asking questions. Pages that rely on memory and precision fail everyone in those moments. Watch for placeholder text used instead of labels (it disappears as soon as someone starts typing), vague error messages like "Invalid input," and sessions that time out without warning halfway through a long form.

Try it: fill in your longest form one-handed on your phone, and step away for a few minutes halfway through. Then come back and finish it.

A 20-minute "different person" test

You don't need specialist equipment to catch most of these. Before a release, spend twenty minutes browsing your key pages as someone other than yourself:

• Keyboard only (5 minutes): Tab through your main flow. Check that focus is always visible and nothing is skipped or trapped.
• Screen reader (5 minutes): listen to your homepage and your main form. Every button and field should announce a clear name.
• Grayscale (3 minutes): switch to grayscale and check that errors, statuses, and links still make sense.
• Zoom to 200% (4 minutes): check navigation, forms, and buttons for clipping or sideways scrolling.
• Reduced motion (3 minutes): turn it on and confirm that large animations calm down.

Do this once and you will start to notice the same patterns while you build, which is where fixing them is cheapest.

Where automated scanning fits

Some accessibility problems are easy for a machine to find: missing alt text, form fields without labels, low color contrast, empty links, and skipped heading levels. Checking those by hand on every page is slow and easy to forget, so they are well suited to an automated scan.

Other problems need a person. Only a human can judge whether alt text actually describes the image, whether the focus order makes sense, or whether an error message is clear. The best setup combines both: automation for coverage, people for judgement.

FlawPilot scans your live site for the issues a machine can catch reliably, and explains each one in plain language, so your manual testing time goes to the questions only people can answer.

The whole series in one table

Over three posts, the same sentence kept coming back in a slightly different form. Each version hides a different kind of problem:

Final Thoughts

Across this series, the same idea kept appearing: the person who builds a page is the one least equipped to see its problems. Your machine is too fast, your memory of launch day is too fresh, and your own way of using the web feels like the only way.

"It works for me" is the easiest of the three sentences to believe and the most important to question, because the people it leaves out often can't tell you. They don't file bug reports. They just leave. Test your site as a few different people, let automation handle the repetitive checks, and "it works" can start to mean it works for everyone.