Context
Web accessibility is easy to deprioritize and hard to retrofit. As part of a company-driven effort to build the team's knowledge, I researched and wrote a training document for developers who understood accessibility but needed practical guidance on implementation: what it really means to make a project accessible, where the hard problems lie, and how to test.
Role
Process
- 01
Structuring for reference, not just reading
As a living document rather than a one-time presentation, the training needed to be something developers could return to, not just read once and forget. That shaped how it was organized: high-level concepts up front, with deeper dives into specific problem areas that developers could jump to as needed.
- 02
Focusing on the hard problems
Rather than cataloging every WCAG success criterion, the training zeroed in on the areas that cause the most trouble in practice: multimedia accessibility, keyboard navigation patterns, drop-down navigation, and testing strategies.
Outcome
The document became a living reference for a small team of developers. Following the training, accessible code became a baseline expectation for new work, including defending accessibility to stakeholders when possible.
Reflections
Not all stakeholders understand the nuts and bolts of accessibility, but the training raised awareness of the concept and why it matters. Accessibility techniques also take practice, and taking the time to go deep on the subject was worth the effort, even when individual projects fall short. Getting it right consistently is a long game.