How to use this playbook
Mix and match Developer KPIs to make a plan of action.
These starter plays can help you grow your organization’s commitment to accessibility.
Assumptions made
- Ample training opportunities have been procured
- There is an accessibility expert available to answer questions
- Comprehensive automated testing results are being recorded
- Some degree of manual accessibility testing capacity is available
Entry level: Interpreting UX annotations
Begin with a singular change fostering greater collaboration between design and development.
One of the simplest ways to begin committing to accessibility is by asking for annotations to be included in UX/UI design deliverables.
When product owners ask for these annotations, it creates a market for the design team to be able to produce artifacts with this requirement.
Start small and simple
Don’t begin with complex interactions. Start with the simplest structures and attributes:
- Headings
- Alternative text for images
In time, you can include more complex concepts:
- Clarify element names with aria-label
- Custom component roles
- Landmarks
Stakeholders
- Product owners
- Design managers
- Designers
- Developers
Skillset required
- Designers will need an understanding of assistive technology basics
- Developers will need to know how to interpret the annotations
Product demos
- End of sprint ceremonies will now include a screen reader demo of the annotations being used
- Designers are required to attend demos
What gets measured
- The accessibility team will also attend and monitor demos for compliance
- If a team is failing to stay committed, investigate the root cause
Interpreting atomic accessibility acceptance criteria
Add a new layer of commitment to your working processes.
Product owners and developers are now aware of what is required to successfully demo the product with a screen reader. This has sparked curiosity and has created a market for learning how components beyond headings and images interact.
Now, it’s time to add atomic accessibility acceptance criteria to stories. This will require even non-technical product owners to climb a steep but manageable learning curve. They must be able to distinguish between components in your design/component library.
For example, they may know the difference between a checkbox and a radio button, but do they know the difference between a text input field and a multiline textarea?
Stakeholders
- Product owners
- Dev managers
- Developers
- QA testers
Skillsets required
- Product owners and developers must recognize HTML/native components
- Developers and QA have access to and understand how to use assistive technology
Product demos
- End of sprint ceremonies will now include a keyboard and screen reader demo of the product as compared to the acceptance criteria
What gets measured
- UI stories in your project management system will be monitored for acceptance criteria
- The accessibility team will also attend and monitor demos for compliance
- If a team is failing to stay committed, investigate the root cause
Expert level: Remediating existing products
Attempting to fix old code before understanding accessibility basics will end in disaster.
Developers with a shallow understanding of accessibility (i.e. what they googled about tabindex and ARIA) will almost always make the situation worse.
Only after developers have demonstrated an ability to interpret annotations and acceptance criteria should they begin fixes on existing products.
Remediation may need to begin with your component library. If that is handled by a specific team, prioritize their buy in and training.
Stakeholders
- Product owners
- Dev managers
- Developers
- Component library managers
- QA testers
Skillsets required
- Developers must be able to test their own work
- QA testers must be able to use assistive technology
What gets measured
- There must be a pre and post remediation assessment conducted by the same methodology (and preferably the same people).
- It is not advisable to let product teams declare remediation complete.