Accessibility6 min read
Immersive ≠ inaccessible
There is a quiet assumption in the world of award-site design: that the moment you reach for WebGL, scroll choreography, and forty thousand glowing particles, you have implicitly decided that screen-reader users, keyboard users, and people with vestibular disorders are not your audience.
I think that assumption is lazy. This site is my attempt to prove it wrong.
The false trade-off
The pattern I keep seeing is immersion built first and accessibility bolted
on later — usually as an aria-label sprinkled over a <canvas> and a
prayer. By then it is genuinely too late: the information architecture lives
inside the animation, and no amount of labeling can retrieve it.
But the trade-off runs the other way if you sequence it honestly. Every technique that makes this site accessible also made it better engineered:
- The DOM is the source of truth; the canvas is commentary. Every era of
my career, every case study, every skill on this site exists as semantic
HTML — lists, headings, buttons — before a single particle renders. The
WebGL layer is
aria-hidden,pointer-events: none, purely decorative. Unplug it and the site loses its glow, not its content. - Reduced motion is a state, not a media query you sprinkle. There is exactly one gate in the codebase every animation must pass through. When it says no — from the OS setting or from the toggle in Case File 03 — GSAP timelines never build, the smooth-scroller never mounts, CSS keyframes freeze to their final frame, and the sun becomes a still portrait. One enforcement point means zero forgotten corners.
- Keyboard users get the same narrative, not a service entrance. The orbital timeline is a plain ordered list of buttons underneath its comet choreography. Focus a skill in the constellation and the same relations light up that a hover would show — and a text panel mirrors them for anyone not looking at the star map.
- Screen readers get parity, not subtitles. Every decorative visualization has an adjacent text equivalent describing what sighted visitors are watching. The scramble-in name settles instantly for assistive tech. Live regions announce state changes the animations imply.
Constraints are a rendering engine
WCAG 2.2 AA did not fight the creative direction of this site. It shaped it, the way a sonnet's fourteen lines shape a poem.
The contrast requirements decided where the sun could sit behind the typography — which is why the hot core rises above the headline on small screens instead of burning underneath the body copy. The reduced-motion fallback forced the content to be complete without any animation, which in turn forced the copy to be strong enough to stand alone. The keyboard walkthrough exposed every place where "just scroll" was doing work that a real interface should do explicitly.
None of that made the site less immersive. It made the immersion honest.
Try it yourself
Somewhere on this page there is a case study with three switches: reduced motion, high contrast, keyboard mode. They are not a simulation — they genuinely reconfigure the site you are reading, live. That is the whole thesis in three buttons: an immersive experience that can take its costume off and still be worth your time.
Immersive and accessible were never opposites. One is a texture. The other is a contract.