Accessible Design is just Admitting Humans Exist

Photo by Balázs Kétyi on Unsplash

A11Y DESIGN IS NOT EXTRA CREDIT

Designing only for fully-abled users is not “normal.” It is designing for a very specific speed-run category of humans operating under ideal conditions.

In software development you will eventually come across “a11y” (that’s “a-one-one-y” for those of you reading this in a different font). “A11y” is shorthand for “accessibility,” because developers are lazy. Myself, especially.

A surprising amount of modern UI design assumes users interact with computers the same way developers do; in a chair, at a desk, with a mouse and monitor. Meanwhile an actual human is trying to close a popup one-handed while carrying groceries and standing on a moving bus.

Many users will never tell you your interface is inaccessible. They will simply stop using it.

YOUR USERS ARE TIRED

Accessibility is not just about permanent disability. It is also about designing for real-world human conditions instead of idealized ones.

Sometimes the user is just exhausted, stressed, distracted, injured, sleep-deprived, or one bad notification away from launching their laptop into low Earth orbit.

Most users are multitasking through interruptions, background noise, and general chaos. They still use software while recovering from surgery. While commuting. While running on four hours of sleep and caffeine-induced optimism.

Accessibility is often framed like it is a tiny niche concern for a tiny niche audience. In reality, more than 1 in 4 adults in the United States live with some form of disability, which is a statistically impressive number of people to exclude.

Most of us will need some form of accessibility support eventually. Age, injury, illness, fatigue, reduced vision, reduced mobility — human hardware degrades over time.

NOT EVERY USER IS SITTING AT A DESK

Developers unconsciously imagine users interacting with software under ideal conditions. Quiet room. Stable internet. Two free hands. Perfect lighting. A functioning attention span.

Meanwhile somebody is trying to use your interface outdoors in direct sunlight on a cracked phone screen with 12% battery while their child actively attempts to evolve into a gremlin beside them.

People use software while commuting. While cooking. While recovering from surgery. While multitasking at work. While exhausted. While distracted. While dealing with pain, stress, interruptions, or ancient hardware that sounds like it is preparing for atmospheric reentry.

Most users are not sitting upright at a $5000 setup in ideal lighting conditions, carefully studying your interface like it is a museum exhibit.

CLEAN UI CAN STILL BE BAD UI

Somewhere along the way, some designers started confusing “clean” with “barely functional.”

Minimalist design does not have to mean minimal features. Now we have interfaces where every button is light gray on slightly different light gray like a camouflage strategy against the vision-impaired.

There are entire applications that feel perfectly fine right up until you stop using a mouse and monitor. Some of you have never tested using keyboard navigation and audio assist — and it shows.

Minimalism is supposed to reduce clutter. Instead, a lot of modern interfaces remove labels, hide navigation, shrink buttons, and rely entirely on hover states that disappear if you breathe wrong.

A lot of accessibility improvements are really just friction reduction. Clear navigation helps people with cognitive fatigue, but it also helps somebody trying to use your app after a ten hour workday. Larger buttons help users with tremors, but they also help every person using a phone with actual human thumbs.

ACCESSIBILITY FAILURES ARE OFTEN INVISIBLE

One of the hardest parts about accessibility problems is that developers often never see them happen.

Users rarely send detailed reports explaining that your contrast ratios were unreadable, your keyboard navigation broke halfway through checkout, or your hover-only navigation became unusable on mobile. Most people simply leave.

That creates a dangerous illusion where inaccessible software appears “fine” because the people struggling with it quietly disappear before anybody measures the problem.

And developers adapt to their own interfaces extremely quickly. You already know where buttons are. You already understand the workflow. You already know which weird UI behaviors to ignore. New users do not have that advantage.

Accessibility failures are often invisible to the people building the product precisely because the affected users stop interacting with it altogether.

SOFTWARE IS INFRASTRUCTURE

Disabled users are not hypothetical edge cases in the margins of society. They are a massive group of people interacting online daily.

Software is infrastructure now. It affects healthcare, employment, education, communication, banking, and daily life. When accessibility gets ignored, people are not merely inconvenienced. They are excluded.

Some users have chronic pain. Some use screen readers. Some rely entirely on keyboard navigation. And some have neurological conditions that make cluttered, flashing, or low-contrast interfaces feel like psychological warfare.

According to WebAIM reports, over 95% of homepage websites still contain detectable WCAG accessibility failures. Which is incredible in the worst way possible.

Many accessibility fixes are not even technically difficult. Semantic HTML. Proper labels. Readable contrast. Keyboard support. We have the tools to be more inclusive, the hardest part is remembering to implement them.

RESOURCES THAT ACTUALLY HELP

Learn more without feeling like you‘re drinking from a fire hydrant:

• WCAG Guidelines (W3C)
• WebAIM Accessibility Articles & Tools
• MDN Accessibility Guide
• The A11Y Project
• ARIA Authoring Practices Guide