Plan
Product managers have two critical planning considerations. They first need to assess the relative risk if their product is inaccessible. Then they need to understand how to reduce the cost of creating accessible content by shifting effort into the design phase.
Assess your product risk
All projects must balance competing demands. Accessibility is one of those demands (and it’s a requirement at IBM). This page provides a rapid way of determining the relative risk to a product of being inaccessible.
We’ve created an exercise to help managers assess where accessibility may fit in project priorities. This can help inform your Pace of completion.
Regardless of the exercise results, the crucial message for a product team is to ensure every release of a product improves on its accessibility and user experience. It’s not a question of whether accessibility gets addressed, but of how much to take on in your next planning cycle.
Do you have:
If yes to any:
You are at significant risk if your product does not meet accessibility guidelines. Prioritize meeting all levels of accessibility guidance in this toolkit.
Government customers in many countries have regulations or guidelines requiring the procurement of accessible products. The financial, travel, health, insurance, and education industries face heightened requirements for accessibility in the USA, EU, and many other jurisdictions. Finally, a customer who has previously requested a statement or Accessibility Conformance Report (ACR) is likely to be assessing future products for accessibility.
Why?
Is your product:
If yes to any:
You face an elevated level of risk. Prioritize meeting Level one and Level two tasks in this toolkit and work towards completing all Level three tasks.
When you create a re-usable component, if you don’t make it accessible, all other products which use it also become inaccessible.
Any product directed at the public has a wider potential audience, which increases the chance that it may prevent users without business supports from completing tasks.
Finally, any products or websites that will be used at an organization with an accessibility policy are more likely to be assessed against standards or used by employees with disabilities. For example, IBM’s Corporate Instruction CI162 (IBM internal use only) requires that all IBM products be accessible, so any product used by IBM employees must comply.
Why?
Does your product offer:
If yes to any:
You face some additional risk from your product being inaccessible. Target meeting Level one toolkit tasks in the near-term. Also review authoring tool requirements such as 504.2 Content Creation or Editing. Work towards Level two and three tasks.
Products that allow users to create content (known as “authoring tools”) need to provide guidance to those users on how to create accessible content. Not only is it important for such products to themselves be accessible, but they must encourage those using them to adopt good habits, and be capable of producing accessible content.
Why?
If none of the above are applicable:
Your risk of litigation from being inaccessible is relatively low. That does not mean that it will affect no one. You might inconvenience users or prevent them from completing tasks if you do not address potential accessibility issues. Work towards meeting Level one toolkit tasks, with the eventual goal of meeting all Level two and three tasks.
Shift left for easier adoption
Development is the wrong place to begin accessibility. There are many historical reasons accessibility has usually fallen to developers. However, this approach turns accessibility into a piecemeal remediation effort that often requires a fair amount of redesign. The process is expensive, and the outcome is not great.
Accessibility needs a more holistic approach.
Design can address almost all the Web Content Accessibility Guidelines (WCAG). Designers can include accessibility considerations in their regular design process and specify them in their wireframes.
When designs include accessibility, developers can focus on following the design specifications, instead of fixing issues flagged by testers. Testers shift from discovering accessibility problems to verifying successful implementation.
By fully engaging designers, projects can “shift left” for faster and easier adoption. See How roles fit together for more details.
Other considerations
Project planners who have identified an increased product risk if not accessible should consider the following.
Gain context
- Determine market and customer need
- Review a product’s currently reported compliance
- Learn your staff’s accessibility experience
- Set expectations and assign leaders
- Hold empathy sessions
Increase team knowledge
- Discover the product’s current accessibility
- Include people with disabilities as sponsor users
- Consider appointing accessibility champions
- Plan education and training