The role of Product Owners in creating an accessible experience is vital. Product Owners should lead, support and facilitate to ensure we create experiences that are usable by everyone.
We need to understand the people who use our products and the different ways they interact with them. We also need to remember that accessibility not only helps people with disabilities – it helps us all.
We aim for all components to meet the Web Content Accessibility Guidelines (WCAG 2.2 AA) and all design decisions to be inclusive. Product Owners should expect accessible designs coming in, and accessible build going out. Here’s how they can do that.
Build into the workflow
Include accessibility requirements
An important goal for every feature or product should be conformance to the Web Content Accessibility Guidelines (WCAG 2.1 AA) at a minimum.
Requirements relating to accessibility should be part of every project and should cover these 5 key areas:
- Design: Use accessible colours (contrast & colour blindness), font size, layout, motion & interactions
- Content: Copy is written using plain language with clear and unique links & CTAs, ALT text & hidden labels
- Keyboard only: Using only a keyboard (no mouse or touch), navigation is in the correct order & all interactive elements are reachable
- Screen readers: Works well with a screen reader with meaningful focus order, heading tags, image descriptions & hidden labels
- Magnification: Can zoom up to 400% (or down to mobile size 320px) without losing content or functionality
For smaller features and fixes, not all may be relevant, but the more detail you can provide here, the better.
Allow time
Solving accessibility bugs and retrofitting solutions is far more costly than reserving time at the start of a project. Allow team members to research, design, develop and test for accessibility during their standard processes.
If you fail to plan, you are planning to fail - Benjamin Franklin
If there is time pressure then accessibility may be one of the things that may feel easier to take out. Don’t descope it.
It’s estimated that it costs 3-5% additional effort if accessibility is built in from the start, and >20% if retrofitted afterwards. A study from the IBM Science Systems institute found that bugs are 100 times more costly to fix after release, so make sure everyone considers accessibility up front to save you time and money in the long run.
Create accessible user stories
As part of the acceptance criteria, write accessible user stories to ensure accessibility considerations are covered, and the team considers these considerations when estimating the stories.
For example:
- As a visually impaired screen reader user, I need to understand what the image means
- As a keyboard-only user, I need to see where I am on a screen
- As someone with low vision, I need to be able to access site navigation without having to scroll horizontally
Help identify and prioritise the critical user journeys, ensuring we remove barriers and that no blockers are in place.
Test for accessibility
Every member of the team plays a part in testing their work is accessible. Testing helps uncover unintentional barriers.
- Designers should check that contrast requirements are met, colour alone is not the only way to perceive the content, and that their designs include alternative ways to interact with or absorb the content
- Content Designers should check that text is easy to understand, and text alternatives are provided to images and video
- Researchers should test with a diverse group of users, including people with disabilities, especially for key flows
- Engineers should integrate tools into their workflow to check their code during and after writing it
Including an accessibility champion, primarily, but not exclusively, during the Product Design Review (PDR) can help prevent barriers from being introduced.
Integrate into Definitions of Ready and Done
Before moving forward with a story, make sure the feature meets Level AA success criteria from the Web Content Accessibility Guidelines by including it in your squads DOR and DOD.
An example of tasks in the handover checklist could be:
- Check automated accessibility tests pass
- Conduct manual checks using a keyboard, screen reader and magnification
- Perform usability tests on critical user journeys
Keep team accountable
Understand responsibilities
Product Owners play a crucial role in communicating accessibility requirements and ensuring that every team member knows their responsibility in helping to create accessible products.
Expect:
- Designers should provide design specs which are marked up with accessibility annotations
- Content Designers should write inclusive content, including visually hidden text for screen readers
- Researchers should source and include people with disabilities in research & user testing
- Engineers should write accessible code and test for accessibility
Monitor accessibility & fix bugs
Product Owners track the progress of many things, and the accessibility of their part of the product should be one of them.
Accessibility is already being measured, so being aware of how and where to find the results is key.
- Web accessibility – Accessibility data is available on our Engineering Scorecard in Databricks, and is reproduced in tribe OpEx Reports. We're regularly testing our desktop & mWeb products using the AQA auditing tool, and we send weekly emails linking to accessibility bug lists to each squad. Check out our "How to" guide in Confluence to help find the issues and fix them. Note that these are automated tests, which only cover up to 40% of potential issues.
- App accessibility – We commission external audits of our apps as often as possible and share the results with all squads involved. Bugs could then be tackled by either taking a number into each sprint, running a separate accessibility sprint, or tackling them during events like hackathons or “Spring Break”.
Help the team achieve their goals
A Product Owner can help their team meet their goals by:
- Buying the team time to include accessibility considerations throughout the product or feature lifecycle
- Pushing back on aggressive deadlines
- Holding parties accountable
- Highlighting training needs with the business to improve and fill knowledge gaps
- Getting access to tools needed to help achieve the goals
- Sourcing accessibility expertise whenever required