Read Part 1 of this series here: Plan to be Accessible by Design: Accessibility in the Product Development Lifecycle.
Forward-thinking product teams will plan for and implement inclusive user experiences at the start of the design process to achieve better outcomes. More commonly known as Shift Left, this method advocates ‘baking in’ inclusive user experience features in a digital product at the start of product development. Designing for accessibility from the start minimizes refactoring time and associated costs because accessibility issues are identified and corrected before the product reaches the QA (quality assurance) stage.
For teams who didn’t plan for digital accessibility from the start or who rely on manual inspections, automated audit tools, or QA to catch accessibility issues, consider this:
“It is possible to develop an accessible web resource by retrofitting accessibility at the end; however, the effort required can be considerable and the resulting level of accessibility can vary substantially,” says David Sloan in “Case Study: Designing for Web Accessibility”.
Informing product requirements through audience research
To recap from Part 1, a key first step in the product development lifecycle is web user (target audience) research. Getting to know your web users starts with asking a series of questions such as: which user experiences do we want to improve for our target audiences? Which technologies do they use, and how and why are they using them? The User Story of Ali is a snapshot of the nuances of designing for inclusion.
Getting Requirements Off the Ground
With user insights in hand, a product team can start defining initial requirements to satisfy the needs and goals of web users with disabilities. Here are three areas to think about when planning requirements:
Estimating resources
Define team roles and responsibilities. Determine which software will be used to execute the design, development, and testing of the product. Also, decide which browsers and operating systems to design for, which devices to support, and which types of automated tools to use for accessibility evaluations (e.g., developer unit testing to QA tests). Acceptance criteria also need to be decided, as does which type of issue management method to use.
Adopting appropriate accessibility standards and best practices
Web Content Accessibility Guidelines (WCAG 2.1 AA Success Criteria) are globally recognized as the standard to adopt, and they are also best practices. For example, it’s important to include captions and transcripts within live and pre-recorded videos (think of them as text versions of speech) to support users with hearing loss, deafness, and cognitive disabilities, and to offer an alternative such as a PDF of the video content if captions and transcripts are not available. When these best practices are not followed, it creates inaccessible user experiences. In Christina Evans’ article Get Ahead of Headings: How to Correctly Use Headings for Accessibility, she cites a common problem:
“Often times, web developers and designers will use the ‘out of the box’ styling of headings to achieve a specific look of page headings without considering the negative repercussions for accessibility. Using certain <H> tags to style web page titles puts assistive technology users (e.g., blind, and low vision users) at a big disadvantage to visual users as it becomes very difficult to understand web page structure and content. This can lead to assistive technology users becoming so frustrated that they leave your page altogether…to achieve the desired visual look of headings, always style with CSS rather than using HTML <H> tag styling. Doing this will help ensure your site’s information is accessible and inclusive for all users.”
Budgeting for team training
Most teams are comprised of individuals with varying degrees of expertise, so expect teams to routinely upskill. Plan for training by assessing and defining team training needs and goals. Develop a plan to include types of training aligned to team and/or team member goals. Obtain leadership buy-in and routinely monitor and reward or acknowledge success.
So, What Comes Next?
To follow the series, check out Part 1 Plan to be Accessible by Design: Accessibility in the Product Development Lifecycle for more insights.
For further information on how to design for inclusion, contact our experience design experts, check out our Accessibility IQSM for your website, download our guide Digitally Accessible Experiences: Why It Matters and How to Create Them, and read more from our UX for Accessible Design series.
Stay tuned for the next installment, Part 3 of 4: Design for Diverse Users: Accessibility in the Product Development Lifecycle.
