Skip to content
Introducing Spotify's Guide for Developing Accessible Applications

Posted January 12, 2023

Serah Njambi Kiburu

We are pleased to share our new accessibility guide, written to help third-party developers level up accessibility in the applications and experiences they build with Spotify’s APIs and SDKs.

What is accessibility and why should you prioritize it?

Info: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 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.

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.

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.

What the accessibility guide covers

The guide is divided into three sections, all designed as task lists to guide you on your quest to create high quality and accessible applications. 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:

Happy coding, we cannot wait to see how you evolve your applications accessibility-wise!