Like many developers, I have my own checklist I run through when finalizing an application — performance checks, cross-browsing testing, that kind of thing. Accessibility, the act of making a site functional for all users, was usually near the bottom, an optional extra that was nice to have, if I had the time. I understood its importance in an abstract way, but had no concrete knowledge about how a blind or visually-impaired person might actually use a web application.

I think this is probably a common experience — if accessibility is addressed at all, it’s usually an afterthought or box-ticking exercise, particularly with a deadline looming. So, given the chance to work on pet projects during the pre-Holiday period at Deezer, I decided to finally dig into the topic to learn how a disabled person might use the web in the real world and how Deezer could be made more usable for everyone.

This article, the first in a series, describes why accessibility is important and how we intend to change the Deezer web platform to ensure it’s as easy-to-use as possible for all our users.

What is Accessibility & Why is it Important ?

Accessibility (a11y for short) describes the process of ensuring that people with disabilities can use your software.

A common misunderstanding is that “disability” refers only to blind people. There are in fact a variety of visual, auditory and motor disabilities that make using the web hard, difficulties that may be shared with older people, those with learning problems or even users on low-bandwidth connections. An accessible website improves the user experience for all of these groups.

Focusing on improving the accessibility of a web site is often a hard sell. It can be difficult to explain the benefits, especially when the perception exists that the number of impacted users is small. It can be harder again to advise developers when online resources are confusing or contradictory. So what are the arguments in favour of a11y compliance, and how difficult is it to build an accessible application?

A hard-headed economic case can easily be made. In the United States, 23.7 million adults report difficulty seeing — or 10% of the population. In the EU27 50 to 75-million have some disability, of which 30-million are blind or partially-sighted. In France alone, 1.7 million report having vision problems. The number of elderly in both regions dwarfs all these figures — it’s projected that by 2025, 20% of the European population will be over 65.

There may be legal requirements, now or in the future. Section 508 in the United States, alongside directive 2016/2102 in the European Union, oblige public bodies to ensure their services are accessible to all users. There is every chance that work to complete the digital market in the EU will include moves to ensure that digital services are accessible to all its citizens.

Deezer also has an ethical duty to its users and to society in general; as music distribution moves increasingly to streaming platforms we should make our content available to everybody or risk abandoning all but the able-bodied to legacy media, or to our competitors.

Finally, it’s important to note that changes made for disabled users improve the website for everyone. A consistent and clear UI, correctly-labeled form fields and keyboard navigation make the site easier for everybody to use. Providing text-equivalents for media such as images not only helps those on low-bandwidth, but makes our content easier for search engines to index. Improving color contrast and readability assists those who are visually-impaired, but also some elderly people and those who suffer from color blindness.

The concrete steps required to make a site accessible are fairly modest, and often things we’re doing already, but have the potential to improve the experience of using Deezer for a diverse cohort of users.

How can we better cater for our disabled users?

There are two primary ways in which a visually-impaired person navigates the web. Blind or severely visually disabled users often use a screen reader, the most well-known of which are JAWS or VoiceOver (the screen reader installed with MacOS).

A screen reader will speak aloud the content of a website, from top to bottom, using clues from the HTML to determine the language, and the difference between plain text, images, form fields and other elements that are part of a standard website. It allows blind users to jump between different sections, to and from site navigation and to interact with media and interactive elements using keyboard commands alone — but only if the site is correctly structured. Our current website is not optimized for screen reader navigation; if you’re on a Mac, open Deezer.com in Safari and press cmd — F5 to give VoiceOver a try.

Those with some vision, or with motor disabilities, can often browse the web conventionally but are sometimes unable to use a mouse. Such users rely entirely on keyboard navigation. Again, this presupposes that a website has been designed to accommodate exclusive use of the keyboard; Deezer’s support is uneven, at best.

There are a number of actions we intend to take to improve the website experience for all users. Some are simple — like changes to the underlying HTML — whereas others are more difficult, such as managing the user’s focus as they navigate through the site via the keyboard. I’ve divided the work into the following steps:

1. Improving Semantic Markup for Screen Readers
2. Simple Keyboard Navigation, Tab Order and Focus
3. Element Outline & Color Contrast
4. Accessible Components & Aria Attributes
5. Making an Accessible Player

Each of these will be followed by a blog article explaining the changes and challenges involved.

Finally, as an able-bodied person, any testing I do will obviously be insufficient without input from the lived experiences of disabled people. Therefore we hope, ultimately, to test a refreshed Deezer web application with a group of real users to gauge the impact of the changes and to observe how a disabled person actually uses the website. In that sense, the completion of the above steps represents the minimum work required to ensure the site is accessible.

In the meantime though, and throughout this series, all feedback and comments are very welcome!

(Part 2 — Semantic Markup and Screen Readers — can be found here)