WCAG compliance is the floor, not the ceiling. Here's how I build accessibility into every design decision.
Rethinking Accessibility Standards
WCAG 2.1 AA and CVAA compliance provide essential baselines—minimum contrast ratios, screen reader support, keyboard navigation, captions. But they don't inspire delight or create innovative gameplay. They ensure playability, not joy. I designed Ascendant Continuum with this question at the core: how can accessibility features make the game *better* for everyone, not just "usable" for people with Ascendant Continuum uses haptics as a primary design language, not just simple feedback. I created unique vibration patterns for each of the five realms (Ember pulses feel warm and irregular, Abyss feels cold and methodical), rhythmic pulses that hint at hidden puzzle solutions (the rhythm matches the solution sequence), and gentle directional feedback that guides exploration. Players with hearing loss get spatial audio translated into directional haptics—they "feel" where sounds are coming from through unique vibration patterns for each of the five realms (Ember pulses feel warm and irregular, Abyss feels cold and methodical), rhythmic pulses that hint at hidden puzzle solutions (the rhythm matches the solution sequence), and gentle directional feedback that guides exploration. Players with hearing loss get spatial audio translated into directional haptics—they "feel" where sounds are coming from through vibration positioning.
Screen Reader Immersion
Standard screen reader support announces UI elements in monotone system voices: "Button. Play. Button. I designed immersive narration for every game element, giving them distinct personalities and atmospheric context instead of monotone system announcements. Screen reader users get rich descriptions—not "healing potion" but "a crystalline vial of amber liquid that catches the light, warm to the touch, smelling of honeysuckle and starlight." They experience a parallel narrative layer unavailable to sighted players,
Community Co-Design Process
Accessibility quality is driven by iterative solo testing and direct community feedback. I review feedback patterns, replay difficult flows, and adjust interaction friction one pass at a time. The goal is practical usability without treating accessibility as an optional add-on. Real progress comes from consistent implementation and validation.
Accessibility as Standard PracticeI build accessibility into every development phase, not as an afterthought. Iterative testing, direct community feedback, replaying difficult flows, and adjusting interaction friction one pass at a time. This is how solo development works best—lean, responsive, accessible by design. Accessibility isn't an add-on; it's the foun">Back to all posts