Too often, accessibility becomes an afterthought. Sometimes it’s because those prioritising the work aren’t aware of what needs to be done. In other cases, it’s because it’s decided that “it will be done at a later stage”.
If we are focusing on user-centric design, we need to do everything we can to make the products and services inclusive and accessible by thinking about accessibility from the get-go.
Below are some projects I’ve worked on with a focus on accessibility.
typerighter
2020
Typerighter is the Guardian’s grammar and house-style checker extension. It’s available on article pages through our in-house CMS –Composer— and it’s used by our writers, subs and revisors.
The challenge:
→ The results appear on the right sidebar and are also underlined within the body text, using a traffic-light colour code to signal what is ok, what needs reviewing and what needs to be changed. There is only a slight issue with this approach: green and red look the same to colourblind users, so the meaning of what’s ok and what needs reviewing is completely lost for them.
My role:
→ To improve the accessibility of the already-existing product.
The process:
→ Coming up with different solutions
→ Running the user testing sessions (with both colourblind and non-colourblind users) to validate what was the best approach.
→ It was also key to keep engineers involved throughout the whole process so we understood how it could be implemented and its implications.
If you aren’t colourblind, this is how red (top), green (middle) and orange (bottom) would appear if you were.
The solution:
→ By changing something as simple as the underline texture, we are able to signal to all users the different types of results.
→ Colourblind users can tell all types of results apart.
→ The experience remains seamless for non-colourblind users.
Adding icons, a subnav with labels and clear toggles in the sidebar list view is also beneficial for everyone, regardless of their vision.
Daily app /
editions app
2019
If you think about the Guardian Daily and Editions app, who would you say are the users? The readers? The production desk? Both?
→ When we created cover cards for the app, we also created a tool for the production editors to put them together: the editions card builder. This tool allowed the production desk to easily create cover cards for each edition without having to rely on a designer.
Editors could add headlines, kickers, byline and standfirst directly, and select their size, colours and position within the image.
→ There are some risks with that approach. Mainly that non-designers might not be as aware of things like composition and contrast.
→ It’s also important to think about the possibility of someone on the production desk being colourblind. But after the 2015 dress situation, we should all know by now that colour is subjective.
The challenge:
→ How do we make sure that all cards are created with accessibility and legibility in mind?
The solution:
1) All colours in the tool were labelled by pillar (the Guardian’s way of structuring content: news, opinion, lifestyle, culture and sport) and by tint (dark, main, bright, pastel, faded).
→ Semantic labelling turned out to be one of the main things that helped us have a succesful production process. It’s easier to reference “Opinion” colours and have the matching labels rather than say “orange” when colours are subjective.
2) By creating a cover card builder guide with do’s and don’ts.
We focused on the following principles:
a) Image selection: quality, composition, crop.
b) Text: Hierarchy, placement and size.
c) Colour: contrast and colour-blindness
What’s next?
There are some obvious flaws that we still need to work on:
→ By embedding text on an image (like in the cover card builder) we automatically cancel the ability of voice readers to read out any text included, we rely on the alt text of the image (and people adding an alt text to begin with).
→ We need to improve the tool to a version that allows voice readers to “see” the text.
→ If we (the Guardian) want to be an inclusive newsroom, we need to make sure our tools allow people with different levels of vision, hearing and motion skills to do their job, not get in their way.
→ Q4 2022 will allow the product and engineering team to work alongside an accessibility consultancy firm so that we can set a plan.