Accessibility Is Structural, Not Cosmetic
A deliberately retro, amber-on-black system sounds like an accessibility problem. It isn't — accessibility lives under the visuals, not in them. So I audited my own components and wrote down the ones that failed.
"You can't make that accessible. It's amber text on a black screen."
I hear versions of this whenever I show eidotter — my design system, which is unapologetically a DOS terminal: CGA colors, monospace type, sharp corners, the warm glow of a 1985 monitor. The assumption underneath the comment is that a retro aesthetic and accessibility are opposites, that the look itself is the barrier.
The look was never the barrier.
Accessibility is structural, not cosmetic. It lives under the visuals — in the semantics, the focus behavior, the contrast ratios — not in whether the palette is flat or amber or gradient. The interactive parts of eidotter sit on , so focus management and keyboard wiring are handled at a layer the aesthetic never reaches. And the palette isn't a dead end either: there's a light theme that remaps the CGA colors to instead of abandoning them. You keep the amber. You keep the character. You just don't ship contrast that fails people the moment they step outside.
Which raises the question of who accessibility is actually for. It's easy to picture a permanent disability and stop there. But the made a11y a legal floor across the EU, and the more useful framing is that the people it helps are a moving target. Someone in bright sunlight. Someone navigating one-handed with a broken arm. Someone with a screaming toddler and half their attention left. WCAG is the floor, not the ceiling; situational and temporary impairments widen the circle until it includes, on a long enough timescale, everyone.
So I stopped theorizing and audited my own components. Honestly — hits and misses. And I'm going to name the misses, because that's the only part of "beyond compliance" that means anything.
Focus management, when things overlay
The test for any overlay — modal, dialog, lightbox — is boring and strict: . Get one wrong and a keyboard user is stranded.
My Modal and my Lightbox got it right. Focus trapped, Escape closed, focus returned to where it came from.
My Nav didn't. Open the menu, press Tab, and focus wandered off into the page behind it. It looked fine — it worked with a mouse, it was correct in every screenshot — and it was quietly broken for anyone not using a pointer. The look told me nothing. The audit did.
Clickable things should say they're clickable
Native elements first. A button should be a <button>. The moment you make a <div> clickable you've signed up to reimplement everything the browser gave you for free: .
My TimelineNode did all of it. It's a custom interactive element and it behaves like a real control.
My Icon and my Tag didn't. They were clickable in places and told no one — no role, no focus style, invisible to the keyboard and the screen reader. Fine to look at. Broken to use.
What "beyond compliance" actually means
There's a comfortable version of accessibility that ends at a checklist and a green badge. That's the floor. The version that matters is less comfortable: you audit your own work, you find the corners you cut, and you write them down where people can see them — including the ones in a system you're otherwise proud of.
The retro look was never the risk. The risk was the same as it is everywhere: a control that looks right and doesn't announce itself, an overlay that traps a mouse but not the focus. Accessibility is structural, which is the good news — you can build it under any aesthetic you like, a CGA terminal included, as long as you're willing to check underneath the glow and honest about what you find there.