What is accessibility and why should you prioritize it?

Accessibility (hereafter abbreviated to A11y — as in, ‘a’, then 11 characters, and then ‘y’) is the body of work involved in (i) making your application available to all and (ii) in providing equitable experiences to users, context and abilities notwithstanding.

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.

WCAG Map - In the center it says WCAG 2.1 and is surrounded by Perceivable, Operable, Robust and Understandable. Perceivable has a cartoon blind user and is defined as Information and user interface components must be presentable to users in ways they can perceive. Operable has a picture of two hands using a tablet computer and is defined as User interface components and navigation must be operable. Robust has an image of a laptop, headphones and braille display connected by arrows and is defined as Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. Understandable has a cartoon woman using a laptop with a light bulb above her head as if she had a good idea and is defined as Information and the operation of user interface must be understandable.

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.

As an application developer, remember to make it possible and seamless for yourself to toggle between enabling and disabling a11y controls for your application as you develop it, much like a light switch gives users autonomy over the decision to have their bulbs on or off. Configuring your devices so it is quick and easy to test with assistive technologies, removes friction and saves time. You will find yourself testing more and more often.

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.

This guide assumes you have some understanding of a11y at a foundational level. At any point, should you need further reference material, the World Wide Web Consortium (W3C)’s Web A11y Institute has published the Fundamentals of A11y resource covering a range of topics and in-depth contexts also relevant to this guide.

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.

Jason Dippel's illustration of Bake-In accessibility. Image shows the Software Development Life Cycle (SDLC) against a yellow background. Different stages of the SDLC are represented as blue quadrilaterals (squares and rectangles) and connected with black dotted lines. From Left to Right, the stages of the SDLC in the diagram are Wireframe, Product Backlog, Sprint Backlog, Shippable Product and Deployed Product. Accessibility is represented as a navy blue circle, and juxtaposed against the dotted black lines between different stages where Jason recommends baking in accessibility into the SDLC.

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: