Good Accessibility Is Good Design
Accessibility isn't a layer you add on top of good design, it's good design with a stricter standard. I used to think of it as a separate checklist, something you did after the fact. I don't think that way anymore.


Accessibility isn't a layer you add on top of good design. It's good design held to a stricter standard. I used to treat accessibility as a checklist, something you ran after the real design work was done. I don't think that way anymore, and the moment that changed my mind was small enough that I almost dismissed it: a dropdown menu, some focus styling, and a decision that seemed harmless.
A <select> element, the kind used for picking one option from a list. When a user clicked it, the dropdown opened, and the select kept its focus outline visible the whole time, marking it as the active element on the page. That outline became the point of disagreement. Someone proposed removing it once the dropdown opened. The team argued about it. The case for keeping it was straightforward: people depend on that outline to know where they are, and there was real legal exposure in stripping it out. The case for removing it came down to one comparison. A bigger, more successful company in the same space did the same thing, so if it worked for them, it should work for us.
A bigger company doing something tells you it's common. It doesn't tell you it's correct. Nobody in that conversation knew whether the comparison company had tested the decision with people who rely on that outline, or just shipped it because it looked cleaner.
This turned out not to be a matter of taste. WCAG's Success Criterion 2.4.7, Focus Visible, requires that a keyboard-operable interface have at least one mode where the focus indicator stays visible. The reason is simple: people need a way to tell, at any given moment, which element they're interacting with. WCAG goes further than stating the rule. It names this exact failure: hiding or removing a focus indicator through CSS is common enough to have its own documented failure pattern.
Here's the part worth sitting with. This was never really a request to "make it accessible." It was a request to make the interface honestly represent its own state, open or closed, focused or not. That's not a niche concern. It's one of the most basic jobs a design has. Most accessibility critique works the same way. It isn't a separate discipline bolted onto UX. It's UX held to a standard that won't let ambiguity slide. Same logic applies elsewhere: most teams wouldn't accept "a bigger company does it" as a reason to skip a security precaution. There's no real reason to accept it here.
Accessibility and good design aren't two separate wins you trade against each other. Nobody was wrong to want a better-looking dropdown. The mistake was treating "remove the outline" as the only way to get there. A more deliberate focus indicator would have solved the actual complaint without taking anything away from the people who depend on it.

Frontend engineer writing about design systems, accessibility, and web performance.