Action steps for product managers and development teams
The following is in response to a question I received in regard to the article, “Why Accessibility Matters in a Post-Pandemic, Majority-Digital World?”:
“How does accessibility come up in my role as a product manager?”
If you’re a part of a digital product development team — regarding accessibility and how I address it as a product manager, I’ve learned that it’s about incorporating the policies, guidelines, tools, and techniques throughout the entire development cycle.
Granted, this is very hard to do, but consider this — it’s even harder for the business if they end up in litigation over one of their digital products that lack accessibility, and it could have been avoided.
For teams, the big challenge is not developing accessible products per se. The challenge for teams and the business at large is to agree on the specific kinds of activities teams can implement to ensure they build accessible products.
When identifying these activities, the level of effort grows significantly across all phases of the development cycle, from requirements definition to coding, testing to launch and maintenance. Even the way you brainstorm product designs ideas gets impacted, because essentially you are no longer just thinking for “users”.
It’s Not Just About Typical Users
Historically, when we think about “users”, unless we have family or close friends in our lives that are physically or learning disabled — our default is to think about average or typical users, because we observe and interact with typical users all the time.
As you work to truly think about all users, begin by adopting the following mindset and change your tendency from “Building accessible digital products is a niche,” to:
“Building accessible digital products is the norm.”
A niche is a specialized segment of a given business for a particular kind of product or service, so if we say we are “building accessible digital products for everyone”, then how can we consider it to be a niche?
Project-Oriented vs Timebox-Oriented Cycles
As a product manager, part of your job is to collaborate with the development team to identify when and where accessibility-based activities can be applied to the work.
As you apply activities, don’t think of the development cycle as a sequential concept or “project-oriented”.
I mean — in your development cycle, the stages (or phases) can play out in combinations of two of these orientations:
- “Project-oriented” i.e. specific accessibility-related tasks or activities that can happen across an entire project delivery duration i.e. the total time it takes to complete a project measured in days, hours, weeks, or months.
- “Timebox-oriented” i.e. within an entire project delivery duration, specific accessibility-related tasks or activities that can happen within a particular timebox (“sprint”), or, across a series of timeboxes (“sprints”).
Include Accessibility In The Development Cycle
For an activity to be included in the development cycle, it must be sustainable and add value. This means — not all activities need to be a part of each sprint, some activities can be performed by individuals or certain groups within the team, and findings can be reported in a timely manner to the entire team.
The following are basically the tasks, activities or action items that are best to add to respective cycle stages. Some items below are processes, others are tools, but what is most important is the timings and mindsets one must have when putting them into practice.
Once you are able to establish as a product team the timings for the activities within the two orientations, you can cover more ground when it comes to ensuring the final product can be used by anyone.
Apply Activities With An Agile Mindset
As a product manager, you can recommend to the development team where and when to carry out these tasks or activities to ensure maximum impact.
Remember — just because the following is described in a list format, you don’t need to apply these activities in a linear or sequential way. Instead, approach it with an agile mindset.
Try These Agile Tactics
The following activities can be shared among the team, and you can make recommendations on when to make changes in the approach, especially in moments when unplanned work arises, or development work gets reprioritised, or information is discovered during daily builds, user testing, or end-of-sprint demos. All these situations affect how accessibility-based activities can be defined during sprint planning. By applying these agile tactics you ensure your team remains flexible, adaptive, and can work on tasks in iterative ways:
Stage 1: Planning
- Get familiar with accessibility laws .
- Decide for your project which accessibility guidelines to follow:
AA or AAA .
- Write a draft press release about the product, describe it’s features, and articulate how this product can help users with disabilities succeed in what they want to accomplish with product. Just keep in mind, you don’t have to explicity focus your messaging on users with disabilities. Write the messaging in a way that can resonate with all users .
Stage 2: Requirements and Acceptance Criteria
- Get everyone on the team involved in the requirements process early .
- When identifying user types or groups, go beyond just “user” and “administrator” .
- Break down your user types or groups according to the disability e.g. “dyslexic user”, “dyspraxic user”, “visually impaired user” . Identifying these users will ensure that you keep them at the forefront of your requirements analysis .
- Write user stories that describe how these specific user groups may interact with the product you are building .
- Get your UX researchers involved early. Ask them to tap into networks where they can interview people with disabilities .
- Write acceptance criteria that demonstrates what you have learned about how users with disabilities would need to use your product . Writing acceptance criteria for typical users could be easy because most of the time it is a typical person writing the acceptance criteria. This time, include the insights from UX research .
Stage 3: Design
- Review successful existing accessible digital products .
- Consult with UX researchers to find out if they already have a list of products .
- Test your mock-ups or prototypes for with users with disabilities .
- Hire developers or designers who have disabilities .
Stage 4: Coding and Implementation
- Review the accessibility guidelines for a list of tools that can support your coding activities .
- Perform research to identify tools designed to evaluate the code you write to ensure it meets accessibility standards .
- Hire developers or designers who have disabilities .
Stage 5: Testing
- Review the accessibility guidelines for a list of tools that can support your testing activities .
- Test your coded product with real users with disabilities .
- Ensure real users have access to all major web browsers .
- If possible, hire software testing engineers who have disabilities .
- Ensure that product team perform an accessibility audit and/or compliance check before deployment .
Stage 6: Deployment
- Ensure marketing and technical support documents are accessible .
- If any of these materials are expected to be provided in a print format, be sure to review print accessibility requirements .
Stage 7: Maintenance and Enhancements
- Executives will need to establish oversight for periodical audits .
- In these audits, take note of periodical accessibility maintenance .
- Perform periodical reviews of content to ensure accessible capabilities are not lost .
- Because technology changes, the accessibility of technology must be reviewed periodically .
- Periodical training should be provided to product team to ensure they remain familiar with WCAG .
- Make accessibility a priority by making executives and product teams accountable for the accessibility of the products. This helps in adopting accessibility as a mindset within the company culture .
- Continue to perform audits to ensure that user groups with disabilities are not being excluded .
- In user interviews and/or focus groups, include specific questions designed to measure effectiveness of accessible capabilities .
Stay Up to Date with Emerging Information
Expanding your awareness to consider questions of accessibility is the constant throughout all the phases and activities a product team must engage in. Expanding awareness also requires one to stay up to date with emerging information regarding accessibility standards in your business/customer locale, and any other places around the globe where you have customers.
You will tap into previously unknown customer bases, all because your team and business took the time to grow their confidence in building software services for everyone, which raises the quality of services overall, and keeps customers coming back for more.
Written by Tremis Skeete
This is our RSS Feed and this story was found here by our Project ADA. Make sure to visit the site and original post!