Building Digital Accessibility into your team’s Product Development Lifecycle

Why Digital Accessibility Matters?

Diversity, equity, and inclusion are mentioned as business priorities more and more in the past few years. Ensuring your business and its products and services are more accessible to all creates a more inclusive society.

Digital accessibility is a big part of creating an inclusive environment. When leadership and team members understand the importance of inclusion and why digital accessibility matters, it’s much easier to implement policies and practices that your team will adhere to.

At least 20 percent of the population * self-identify as living with one or more disabilities that affect their day-to-day lifestyle. And this number is growing, due to an aging population, due to COVID-19 and the related increase in long-term and chronic health issues, and due to reduced stigma in self-identifying as a person living with a disability.

Businesses already need to comply with accessibility and human rights legislation. They also don’t want to exclude approximately one-quarter of the population as potential customers.

Accessible design is not just for the “disability market.” Curb cuts at intersections were originally designed to assist people using wheelchairs and walkers cross the street safely. Most people would agree that these “accessibility features” work better for everyone. Accessibility features in technology work the same way – they create more options and better experiences for all users.

As a project manager or software developer, It’s important to ensure that digital accessibility is built into your team’s product development lifecycle. The key is to start at the beginning of the process and make sure you consider accessibility at each step along the way.

Here are some hints and tips to help ensure you’re creating more accessible and inclusive products.

Accessible Product Development Starts with Shift Left

With a traditional create, break, then fix approach, developer resources often go towards fixing or redesigning issues late in the process or after software is released. This can be an inefficient and costly use of resources, keeping businesses in a reactive cycle of addressing problems and complaints.

When product development stages are viewed as a left-to-right linear process, incorporating testing earlier in the process is a “shift left” from the traditional development cycle. Shift Left has become more common for developer teams because it can deliver better quality code and lower the cost of creating digital products.

For developers to avoid creating accessibility barriers, you need to build digital accessibility into the entire product development lifecycle. Start early, with research and planning, product design and development, user testing and QA, marketing, training, and customer support. This creates a more efficient, user-friendly, and budget-friendly process.

Why Accessibility Matters at Every Stage?

Even before a project is confirmed, it’s important to consider how accessibility for all users can be addressed in establishing a project’s goals and objectives. Before a commitment is made to launch a new project, take time to research current accessibility requirements and best practices.

1. Start at the planning stage

The project manager sets the tone of the project. Their attitude and communication, their decisions and actions, guide the rest of the team. They need to understand both legal requirements and organizational goals and priorities related to accessibility. And they need to communicate these goals and priorities clearly to team members.

Is the project manager familiar with WCAG standards, AODA (or ADA or other legislative) requirements, current technology used by people with disabilities, team members with training and/or lived experience with dealing with accessibility barriers, and how and when to test for accessibility during design and development?

Developers, testers, and team leads assigned to a project must be familiar with accessible product design. If no experienced or trained resources are available, it should be a requirement that new hires are sought or that the time and resources will be available for project members to receive adequate training prior to project launch.

Nothing communicates a priority as much as where time and money are invested. Leadership (and money) comes from the top.

2. Build an inclusive team

Do your HR team and hiring managers understand how to build an inclusive team with members who understand the need for digital accessibility as a priority? Do they include “knowledge of WCAG” or “an understanding of accessibility best practices” in job postings, interview questions, training and performance management goals, and evaluation processes?

Make sure your organization is building a diverse and inclusive team and that you don’t stop growing because you’ve identified one or two “accessibility people” on hand for short-term use.

Every team member should be aware of accessibility barriers they might be contributing to and what they need to do to remove or prevent those barriers.

3. Know your audience

How will your customers use the product? It’s important to understand different input and interaction styles, and different settings of various assistive devices. Which browsers, operating systems, and devices are you designing for and supporting? Are these compatible with current and common assistive devices and accessibility tools? What software will be used to design, development, and test the product?

How many of your developers have actual experience working with people with disabilities as they test a product? How many have seen how various assistive devices or tools work (or don’t work) with the software they’re developing? Direct contact with end users helps create better products.

4. Include accessibility as a success criteria

What does success look like, for your organization, your project, your product, and your users?

Who is involved in determining acceptance criteria for accessibility? It takes more than just adding a Web Content Accessibility Guidelines (WCAG) checklist or style guide to the testing process to create truly accessible and inclusive products. But a few more steps are needed to ensure user-friendly, engaging, intuitive, and effective online products.

WCAG 2.1 AA is considered a minimum requirement by most legislation, but higher standards are becoming more common and expected when adopting best practices. Is your team including accessibility features such as creating style tags with CSS rather than HTML elements; ensuring videos have captions and, ideally, transcripts available; or providing accessibility troubleshooting information to customer support teams?

5. Accessibility is an ongoing goal

After the product is developed and is being used by customers, it’s important to continue monitoring its success. Does the product work for its users? How do you know? Is the process for users to provide feedback and complaints accessible and easy to use? How are complaints tracked, monitored, and resolved?

Do your customer support and software maintenance teams understand potential accessibility issues or barriers with the final product? Have they been trained on how to communicate with people with various types of disabilities? Are they aware of how to assist users facing barriers with problem solving or workarounds?

6. Ensure that accessibility is part of every product development process

Following a project, project reviews or post-mortems are often held. Feedback and learnings from mistakes are not always applied to create improvements in future projects.

When it comes to identifying accessibility mistakes or barriers that have been created during product development, it’s important to acknowledge them and work to prevent them from happening again.

Accessibility issues can be identified during product testing, through user accessibility complaints, or from costs arising from discrimination lawsuits. The important thing is to make the changes needed to improve the next product development process.

This could mean that accessibility features move from the “should have” to the “must have” column in product checklists during design, budgeting, training, development, and testing stages. It could mean that more time and resources are provided to ensure developers are trained, that appropriate software or hardware is purchased, or that adequate testing from accessibility professionals and those with lived experience becomes a priority.

Building digital accessibility into your team’s product development lifecycle does not happen overnight. Recognizing that accessibility is a priority and taking steps to make changes throughout an organization takes leadership, knowledge, and resources.

If you want to remove barriers and create inclusive products for all, Shift Left, start early, and consider how accessible your product is for all possible users, at all stages of the product development lifecycle.

* Footnote: The source is indicative of Canada, but similar percentages (20% or more) apply internationally.