Accessibility isn’t a feature request
Somewhere near the bottom of every backlog sits a ticket called "accessibility pass." That ticket is a confession.
Somewhere near the bottom of the backlog, there’s a ticket. It’s called “accessibility pass” or “a11y cleanup” or, our favorite, “compliance sweep.” Rescheduled twice already. It’ll be rescheduled again, because it’s framed as a feature, and features compete for priority, and this one has no champion in the room.
Here’s the thing that ticket quietly admits: the team built something that doesn’t fully work, shipped it, and put “make it work” in the queue.
Accessibility isn’t a feature. A door a wheelchair can’t pass through isn’t a door missing an upgrade. It’s a door that fails at being a door for some of the people who need one. Nobody files a ticket to make the door “more inclusive.” The architect just gets it right, because getting it right is the job.
The web version of getting it right isn’t mysterious, either. Most of it comes down to three pieces of craft that keep getting treated like chores.
Contrast is a design decision
At some point, light gray text on a white background became shorthand for sophistication. It photographs beautifully in a dribbble shot and reads terribly on a phone in sunlight, which is where actual humans actually are. Low contrast doesn’t say refined. It says the designer never watched anyone over forty-five try to read it.
Contrast ratios sound like bureaucracy until you reframe them: they’re the measured difference between text that everyone can read and text that some people can’t. Working inside that constraint isn’t a limitation on your palette. It’s the same discipline as any other design constraint, and constraints are where the interesting decisions live. Our own site is black and white, close to the highest contrast a screen can produce. We won’t pretend that was purely an accessibility play, but it taught us something: when you can’t lean on color, hierarchy has to come from type, spacing, and restraint. The page gets clearer for everyone, not just the people the guidelines were written for.
Focus states are interface design
There’s a line of CSS that shows up in the first week of almost every project: the one that removes the focus outline.
:focus { outline: none; }
It goes in because the default ring looked off-brand next to the beautiful buttons, and nobody replaced it with anything, and now the site is unusable without a mouse.
Tab through your own site sometime. Can you tell where you are? Plenty of people navigate that way every day: screen reader users, people with tremors or limited mobility, power users who find the keyboard faster, and anyone whose trackpad died an hour before a deadline. For all of them, the focus state is the cursor. Deleting it is like shipping a site where the mouse pointer turns invisible.
The fix isn’t restoring the browser default and calling it done. The fix is designing the focus state with the same care as the hover state, because it’s the same kind of object: a signal of where attention is. A focus ring can carry your brand. It can be genuinely handsome. It just has to exist, and be visible, and never be an afterthought bolted on during the compliance sweep.
Alt text is writing
Alt text has a reputation as data entry, the field you fill with “image” so the CMS stops nagging. But it’s copywriting with an unusually honest brief: describe what matters about this image to someone who can’t see it.
That brief forces a good question, which is what’s actually load-bearing here. If the photo shows your team mid-argument at a whiteboard, “four people in a conference room” is technically accurate and completely empty. What matters might be the argument. Write that. And if the image carries no meaning at all, the honest answer is empty alt text, so a screen reader skips it instead of reciting decorative noise.
Deciding an image says nothing is also writing.
Sometimes it’s the most truthful sentence on the page.
You can hit every one of these marks for the wrong reason. Plenty of teams do: they run the audit, clear the checker, frame the certificate, and treat the guidelines as a ceiling instead of what they are, which is a floor. The checkbox version of accessibility asks what we can get away with. The craft version asks who we’re building for, and answers: more people than we pictured, in more situations than we imagined, on worse connections and smaller screens and harder days.
Respect doesn’t show up in the audit report. It shows up in the tab order nobody had to file a bug about, the caption someone wrote like they meant it, the text a tired reader didn’t have to squint at. Compliance is what you do when someone’s checking.
Craft is what you do when no one is.