Public services for everyone
How to integrate accessibility in the design process
There is the misconception that accessibility is “only for the disabled”. But accessibility usually makes a service better for everyone. Take subtitles — intended for the deaf, but the majority of people who use subtitles are not deaf at all. Many people use subtitles when they want to watch a video on the train, but have forgotten their headphones and do not want to disturb the people around them. Subtitles also help if the spoken words are in a foreign language or if there is a strong dialect.
There is the concept of permanent, temporary and situational impairments and the underlying idea that we are all only temporarily not disabled. Over time, the majority of us will be affected by certain design choices.
A web page can have poor colour contrast. A young, healthy person may be able to see the colours in the office. When this person goes outside into the sun and tries to read the same website in bright sunlight on a glaring mobile phone screen, it will be more difficult and they will be situationally impaired. If this person gets an eye infection, they will be temporarily impaired. If they get older, they could get cataracts and become permanently disabled. In all three cases, the person has similar problems with the colours of the website which a better contrast would help.
Accessible design makes websites better and more usable for everyone — it’s also the law in many countries. The USA has the ‘Section 508’ standards and many European countries have laws of their own. The recently introduced ‘EU Directive on the Accessibility of Public Sector Websites and Mobile Applications’ means that new websites must be accessible from September 2019 and old websites from September 2020. They are all based on the well-known Web Content Accessibility Guidelines (WCAG) which have been in use for many years.
These laws are important, but accessibility requirements can also be problematic. They are overwhelming and often lead to an avoidance of dealing with the topic. Accessibility requires specialist knowledge. WCAG is written in a very technical way and the number of possible barriers is overwhelming.
The supposed “solution” is often to simply order a WCAG audit at the end of a project and fix the reported issues. Unfortunately, this leads to several serious problems. Some mistakes cost a lot more time and money if they are resolved at the end of a project. The accessibility knowledge is not shared with the whole team. And teams usually get an audit when they’re running out of time and won’t have any time to learn anything from it.
It is better to think of accessibility right from the start. That’s why the recommendation in the Government Digital Service’s Service Manual is:
1. Use automated testing tools; this approach usually finds only 20–30 % of all issues, but it’s better to start with the issues that are easy to find
2. Use a manual checklist; a good place to start is:
a) test the page without a mouse just using the keyboard, b) zoom to 400 %,
c) test in high contrast mode, d) disable the style sheets in the browser, e) disable the images
3. Use various assistive technologies: at least a screen reader, a screen magnifier and speech recognition software; there are free versions available for all of these tools
4. Do user research with users with access needs; that’s the hardest thing to do, but it also provides the greatest insight
Anyone can do steps 1 and 2. Step 3 needs a bit of training and practice, but is easier than many people think. Step 4 is the hardest. Many teams especially struggle to find suitable participants.
Another way to better understand accessibility and the typical barriers we unintentionally introduce with our design choices is to use simulations. While this is not a substitute for user research and is never a true representation of an impairment, simulations are fast, easy, and cost-effective. Simulations can come from browser extensions such as ‘Funkify’, ‘Web Disability Simulator’ and ‘NoCoffee’. You can also use physical things like special glasses, gloves and magnifiers.
At the Government Digital Service, we use seven personas with different impairments for this. We set up laptops for these personas, where you can log in as them. Then you can use the corresponding simulation and the assistive technology for each persona. This allows you to experience websites from the perspective of various impairments. As a jump-start, we have a very short ‘persona mini training’ for each persona. We’ve had particularly good results with ‘persona testing’:
1. Create some typical tasks for the project
2. Invite an entire team for an hour
3. Each team member chooses a different persona
4. The team has 50 minutes to complete the tasks as the selected persona, some tools such as screen readers and speech recognition need a little help from accessibility specialists
5. Everyone writes down all the issues and observations they find
6. In the last 10 minutes, they all share their experiences and potential issues with each other
7. Accessibility specialists should then spend a bit of time evaluating the results because lack of knowledge of the assistive technologies can lead to ‘mistakes’ that are not mistakes at all
This activity is very effective and instructive. Not only can you find many issues early; it also sharpens the awareness and understanding of the whole team for typical barriers. And all this without previous special knowledge.
→More information on accessibility.blog.gov.uk.
———
Anika Henke is a web developer at the Government Digital Service in London. She works with a team that supports teams across the UK government in accessibility.
