Accessible Product Development Starts with Shift Left
Using a Shift Left method to improve product development outcomes isn’t new or novel. Shift Left has been adopted for decades to lower software development refactoring time and costs and streamline time to market by testing software earlier in the design process and not just before it ships. “When the software development process is viewed as a left-to-right sequential process, doing testing earlier may be seen as “shifting it to the left.” The term itself can be seen as a misnomer since we are not simply ‘shifting’ but doing tests at all stages of the process,” according to Devopedia.
This methodology has the same benefits for the design of digitally accessible solutions. When implemented, it can deliver better quality code and lower the cost of creating digital experiences for the disability market. Adopting the Shift Left method at the beginning of product development can catch accessibility ‘bugs’ in content creation (e.g. poorly written alternative text for images), within visual and user interaction design (e.g. relying on color alone to convey meaning), and in code (e.g. web pages missing landmarks). Identifying and resolving issues before the quality assurance check is key to reducing refactoring costs.
Today, there’s greater adoption of inclusive design because of the increase in Diversity, Equity, and Inclusion (DE&I) programs by organizations and the recognition that the global disability market consists of 1.85 billion people with $1.9 trillion in annual disposable income.
Accessible by Design
Designing for digital accessibility by implementing Shift Left hinges on a team’s decision to develop for inclusion from the start. More and more, we’re observing organizations committing to digital accessibility. With one of our global OEM clients, our teams work together to ensure web and mobile applications are accessible to meet the needs of its diverse global audiences. Part of the success of our collaboration is our Shift Left approach, which includes things like design reviews by our designer.
Initiating Research
In an earlier blog (Designing Accessible Digital Experiences), I mentioned that you need to set aside assumptions about the ideal web user who never encounters issues accessing online information. The same applies to creating inclusive and usable experiences for persons with disabilities (PWD). Start by setting aside assumptions about PWD and begin by asking questions such as: who is my user? Which of our client’s target audiences would benefit from inclusive design choices? What is the user experience we want to improve? Which technologies are they using, and how and why are they using them?
There are multiple user research methods to understand target audiences and get those answers. User interviews, surveys, diary studies, observation, and combing through clients’ chat logs and research data are all great ways to surface meaningful insights.
It’s common for design teams to rely on the Web Content Accessibility Guidelines (WCAG) and its 50 Success Criteria to checklist their way to compliance. Product development teams may use a subject matter expert (SME) to steer the accessible design process. These approaches can improve the accessibility of a web experience, but they do not ensure usability (i.e. effective, efficient, engaging, easy to learn, and error-proof – W. Quesenbery).
The User Story of Ali
Let’s examine a sample user, Ali. If we interviewed Ali and observed how she uses her mobile device, we would learn more than making initial assumptions about her capabilities, needs, and pain points or using the WCAG checklists. It’s not apparent she has low vision or that she has created an adaptive strategy for herself with the help of VoiceOver (Apple’s built-in screen reader) to add events to her calendar. And by the way, her right wrist is injured from a strenuous workout, so tapping or swiping is a challenge. This temporary disability should be considered in designing an accessible experience. Not everyone has fine motor skills.
Another key decision when designing for disability is thinking about people’s different interaction styles and settings (e.g., voice, braille, zoom, tap, scroll, dark mode, etc.), the various devices they use, their input methods, and their preferred operating systems and browsers.
User research enhances every web experience, but excluding persons with disabilities makes all research methods meaningless. Start the product development lifecycle with Shift Left. And remember, every team member has a part to play in research, even if it’s observing PWDs using a prototype or website in production and offering insights on improving the overall user experience or fixing a specific issue.
So, What Comes Next?
Adding accessibility in the product development lifecycle with upfront user research is the first step your teams must take to help ensure your digital experiences are inclusive and accessible by design.
For further information on how to make your design understandable to your audience, contact our experience design experts, check out our Accessibility IQ for your website, download our guide Digitally Accessible Experiences: Why It Matters and How to Create Them, read more from our UX for Accessible Design series, and stay tuned for the next installment: Setting Product Requirements: Accessibility in the Product Development Lifecycle Part 2 of 4.
