What is accessibility and why should you prioritize it?
Our mission at Spotify is to allow billions of fans the opportunity to enjoy and be inspired by artists’ work. Because our applications are for everyone, product a11y is now a core focus for Spotify. As developers extending the Spotify experience to our communities elsewhere, we have the responsibility to our users to create a safe and equitable space for them, regardless of the manner in which they use our applications and interface with their devices.
Abbreviated version of The WCAG map by Intopia.
“Who might this experience exclude?” is a question we answer every time we make implementation choices in our applications. In everyday life, stores that can only be accessed by a staircase have actively made the decision to exclude wheelchair users, parents with strollers, shoppers with wheel bags. Every design decision is a stance on inclusion, or lack thereof.
Susan Goltsman, co-author of Play for All Guidelines and The Inclusive City, has popularly described inclusion as allowing a variety of ways for people to experience one thing (like your application), rather than availing only one experience for everybody.
If your end goal for the “who might this experience exclude?” question is to get to the answer “no one” - then this is the right guide for you to use to deliver a high quality application that is at par with Spotify’s core value of inclusion for all.
Testing accessibility manually is indispensable as automated tests will only catch a small percentage of issues and will not validate the experience as a whole.
Accessibility in the Software Development Lifecycle
A11y done right results in high quality applications. Prioritizing a11y early on in your development process reduces regression and ensures your application includes everyone from the onset.
The image below is Jason Dippel’s take on baking accessibility into the early stages of your software development lifecycle(SDLC). We agree with the recommendation that accessibility should be baked into the SDLC as follows: _ between the Wireframe and Product Backlog stage as part of the User Experience Design process, _ as part of Sprints that then inform the Sprints Backlog and between the Product Backlog and Deployed product as part of the User Experience Research process,
effectively saving you time and money down the road.
How to use this guide
This guide will focus on levelling up your skills so that you can identify a11y gaps in the applications you have already developed and work to fix them, or use the tools in this guide as you begin to develop a new application.
The guide is divided into three sections, all designed as task lists to guide you on your quest to create a high quality and accessible application. The sections are organized in order of ease of implementation, but all recommendations are equally important and should be prioritized in your application development. They are: