INCLUSIVE DESIGN / ACCESSIBILITY / DESIGN ENABLEMENT
Designing for inclusion, not just accessibility compliance.
Accessibility too often entered the conversation after an experience had already been designed. By then, teams were focused on making existing interactions work with assistive technology instead of asking whether those interactions could be more inclusive from the start.
I proposed and led a framework that made designers responsible for considering and specifying accessible behavior as part of everyday product work. The goal went beyond documentation: to build the awareness and judgment behind more inclusive decisions, clearer engineering handoffs, and fewer issues discovered during QA.
Accessibility
Design enablement
Process change
THE BIG PICTURE
01 / CHALLENGE
The opportunity was to change design decisions, not just their timing.
When accessibility is addressed late, teams can end up adapting a finished interaction for assistive technology instead of questioning the interaction itself. Asking designers to specify reading order, focus, labels, control behavior, and alternatives earlier created space to reconsider those choices while designs could still change. A more inclusive approach could also improve usability for people with different sensory, motor, and cognitive capabilities.
BEFORE / LATE-STAGE REWORK
AFTER / ACCESSIBILITY UPSTREAM
The shift was from addressing accessibility after design to considering inclusive interaction choices, documenting behavior, and making decisions before engineering handoff and QA.
02 / PROCESS
From direct support to a repeatable practice.
I proposed and led a framework to make inclusive design a repeatable part of everyday practice. Rather than rely on accessibility specialists to catch issues downstream, I developed guidance, documentation patterns, and tools that helped designers make and specify informed decisions within their own design files.
01
02
03
04
03 / FROM FRAMEWORK TO PRACTICE
Make accessibility part of the design workflow.
THE TOOLKIT / BUILT INTO FIGMA
Guidance built into the design file.
The Figma library combined role-specific checklists, reusable annotations, and examples that helped designers document requirements clearly for engineering.
Figma library overview: checklists, annotation components, and working examples, integrated into the design-to-development workflow.
APPLIED IN PRACTICE
Requirements alongside the interface.
Designers could annotate reading order, labels, and other behaviors directly next to the product UI. That made accessibility decisions visible during review and more specific at handoff.