Let’s meet a few people and see how hard it is for every one of them and how we can make life easier for them; because at the end of the day, we want everyone to be able to implement accessibility without necessarily having to be experts.

Meet Julian and Alexandra: they are visual designers and think accessibility is hard. From what they’ve heard, it’s technical, it’s got to do with obscure HTML tags and attributes, with “pausing capacity” in “timed media” (er… what?). Moreover, they feel it’s going to constrain their work because they won’t be able to use a broad range of colours, and there goes subtlety. Also, most of what they know is related to their visual-oriented background; they don’t know how to take into account many difficulties users may have, such as motor or cognitive disabilities. In short, accessibility looks to them as a lot of overhead.

Meet Victor: he’s a project owner and thinks accessibility is hard. From what he’s heard, you have to “take accessibility into account at every step in the project”. Also, since he’s been working on the project for a while, like most people in his case, he can’t envision the intelligibility of the interface as if he were a first-time or infrequent user, nor the project’s drawbacks, e.g. a lack of focus highlighting when navigating the site with a keyboard. Most of the problems are blind spots that he’s learnt to work around without noticing them anymore. Accessibility looks like a lot of extra work, and this extra work often outweighs the benefits he perceives in the short term.

Meet Berenice: she’s an accessibility audit expert and thinks accessibility, although it meant a lot to learn when she started in the field, is necessary. She’s used to listing every kind of problem on a website and sending accessibility TO-DO lists to project managers. She now finds it quite easy and mechanical to do audits and write reports.

Meet Nathalie: she’s an accessibility management expert. She takes Berenice’s work and turns it into manageable, prioritized points according to a project roadmap with the help of project managers.

Meet Robert: he’s the Quality Assurance manager for Victor, keeping tabs on what works and what doesn’t– security analysis, server response time, you name it. He has never heard of accessibility and thinks it has to do with the server availability (as in “accessible any time, 24-7”).

Going to the source is too much work

We said in the introduction that accessibility is often seen as a Himalaya of sorts. Sure it’s hard to grasp the whole shebang: Victor, our project owner, tried to look into the guidelines, but they are dense and numerous. He tried to make a PDF out of them and ended up with a document that was several hundred pages long. He gave up, although he wants to do the right thing.

Also, let’s face it: doing things the right way calls for diverse sets of skills and hard work, say by bringing together User Experience expertise, User Interface design, front-end development, and project management. The good news is: you already call for all those skills when you build a website. Half the hard work is already done by putting those together! Let’s all give each other a pat in the back and go down into the trenches.

Climbing the Himalaya

Come to think of it, Julian and Alexandra, our designers, do not need to know the jargon (“What do you mean by user agent?”). They need to assess the accessibility level of the project, and this is where Berenice can help them; they also need to be able to prioritize, and this is where Nathalie can help them.

Robert, our QA manager, has to know the criteria and how to check them. How can he take them into account without being submerged by the task? Or, as a first step, how can he integrate automated testing into his process? Again, Nathalie can help him by discussing which criteria can be automatically tested and which have to be reviewed manually by Berenice.
One of the main difficulties when projects want to deal with accessibility is the idea that the lists provided by Berenice are so long that our project team can be discouraged. On the contrary, we learned in other domains through baby steps.

Julian and Alexandra learned the basics of designing things in visual tools, and these days they’re using the tool du jour. Along the way they progressively learned about User Experience, Fitts’s Law, Gestalt theories, etc. Now they have to learn accessibility only when it’s relevant to their job. Once they have the gist of colour contrast, pause buttons on video/audio elements (oh, and carousels too), form design (and how best to help users by applying basic methods like label-field proximity) and a few other things, they’ll be all set to deal with most of the accessibility requirements for their position.

Let’s use this approach to accessibility: some of us only have to know a subset of all the accessibility criteria out there (Julian and Alexandra), some of us have to have “broad picture” view (Victor), some of us have to know when and where to apply them (Robert) — and some of us are experts and can help put everything into place (Berenice and Nathalie). We know Rome was not built in a day, but we also know some people had to know how to build it, and some houses crumbled or were aslant, but slowly houses became sturdier palaces and lasted longer because people built up skills along the way.

Enter the Accessibility Responsibility Matrix

Five years ago, the WAI-Engage Community Group at the W3C came up with the idea that yes, knowing everything pertaining to accessibility is hard and should not be a setback to implementing accessibility in projects. They decided to build a big table, with job titles as columns and accessibility criteria as lines. It was not easily readable for the layperson though. Also, it was just a prototype that was never finished and its references were simple “1.1.1.”, “1.1.2.” labels, admittedly not the easiest way for non-specialists to grab the subject.

I wanted to take up the table and replace criteria with human-readable text, as a first step towards broader adoption. Thus “1.1.1.” can be read as “Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below” (if you wondered, this means that all visual and audiovisual contents are not sufficient by themselves and must come accompanied by various ways of conveying the meaning: alternative text for an image, subtitles for a video, etc.).

But why stop at updating a wiki page? The tool now produces desktop documents in Excel and LibreOffice that you can play with, filter, and edit. You can customize them according to your needs, including put them into a stepped process to integrate accessibility progressively, for example.

Download the Matrix in Excel form

Download the Matrix in LibreOffice form