Accessibility
Making sure the UI works for everyone.
What is accessibility?
Accessibility (often shortened to a11y, for the a, then 11 letters, then y) means everyone can use your UI, including people with disabilities. That covers someone navigating by keyboard instead of a mouse, someone using a screen reader to hear what is on screen, and someone with low vision who needs strong color contrast.
Accessibility covers a far wider spectrum than most people picture: permanent disabilities (blindness, motor impairments), temporary ones (a broken arm), and situational ones (bright sunlight on your phone). Designing for it means designing for all of these, which turns out to be nearly everyone at some point.
The good news is that the web has accessibility built in. Semantic HTML elements like <button>, <label>, and <nav> carry meaning that assistive tools can read out. The most common failures aren’t hard problems, they’re simple oversights: missing alt text, low contrast, a clickable <div> where a <button> belongs, an input with no label.
Why it matters
The WHO puts it around 15% of the world’s population, more than a billion people, living with some form of disability. Build an inaccessible UI and you are not just annoying those users, you are locking them out of the thing entirely.
It is also, increasingly, the law: the ADA in the US and the European Accessibility Act require accessible digital experiences, with WCAG (the Web Content Accessibility Guidelines) as the standard they point to. And fixing these problems usually makes the code simpler, not more complex. A real <button> needs less styling and JavaScript than a <div> rigged to act like one.
Announced as a filename
A screen reader hits your hero image and, with no alt text, reads out “IMG_2048.png.” The user has no idea what they just missed.
Red, and nothing else
A form marks the failed field in red and adds no icon, no text. To a colorblind user, or anyone on a sun-washed screen, the field looks perfectly fine.
Later, then a lawsuit
Ship an inaccessible public service and the first formal complaint turns “later” into “now.”
Interactive demo
Before you toggle anything: with every fix off, Tab through the form. Can you reach the Log In button? Make a guess, then try it, then start flipping the switches in the audit panel.
Log in to your account
Log In
Accessibility Audit
alt text
contrast
form labels
keyboard
score0 / 4
Try breaking it:
- Turn alt text on and a green
altbadge appears on the logo; turn it off and it is gone. With it off, what is left for a screen reader to announce when it reaches that image? - With form labels off, click the text sitting above a field. Nothing focuses. Turn labels on and the same click lands in the input, because the label is now tied to it.
- Turn contrast off and read the heading. That is the same text at a ratio that fails for low-vision users, even if you can still just about make it out.
How it works
Flip each switch in the Accessibility Audit and the form changes to match; the score counts how many of the four you have fixed. Each one maps to a real-world failure:
- alt text: describes images for screen readers, so non-sighted users know what is on screen
- contrast: keeps text readable for low vision and in bright environments
- form labels: tie each input to its description, so screen readers can announce it and clicking the label focuses the field
- keyboard access: a real
<button>can be reached and pressed without a mouse; a<div>cannot
The keyboard fix is the one to feel rather than read. Tab through with it off and focus skips the Log In control entirely, because it is a <div>. Turn it on and the same control becomes a real <button>, in the tab order and announced as a button. None of these fixes are new tools; they are the semantic HTML the DOM is already built from.
If you remember one thing
Most accessibility is small, boring correctness (the right element, a real label, enough contrast), and it decides whether some people can use your UI at all.