As Global Accessibility Awareness Day (GAAD) is coming up on May 19th, it’s a good reminder that we should always keep accessibility in mind.
I’m a service designer working on government projects so I need to comply with the service standard my projects fall under: the GOV.UK one or the Scottish Government one called Digital Scottish Service Standard (DSSS).
Both service standards have a very similar point:
This means we need to include disabled people and people who can’t use the internet.
Some definitions around inclusion
Inclusion often focuses on two main things: accessibility and assisted digital support.
It’s important to note that there is often an overlap between accessibility, assisted digital support and the other barriers to inclusion.
Assisted digital support
This term is mostly used in government. It’s about ensuring users aren’t excluded from a service if they can’t or won’t complete tasks online.
There might be many reasons why people need support online. It could be they:
- cannot access or afford the technology to go online
- lack, or believe they lack, the digital skills required to use the service
- lack the confidence to try
- lack language or literacy skills
- have mental health issues or learning difficulties that stop them from using a digital service
- don’t trust your service or internet in general
Accessibility
1 in 5 people in the UK are disabled. A disability can affect their vision, their hearing, their speech, it can be a physical disability or it can be a cognitive disability (this means it affects their memory, or how they process things and think).
It can also be a mix of more than one disability. In fact, it’s quite frequent that people have more than one disability, and they’re not always visible to others. It’s different for everyone.
“Accessibility means that people can do what they need to do in a similar amount of time and effort as someone that does not have a disability.
It means that people are empowered, can be independent, and will not be frustrated by something that is poorly designed or implemented.” — Alistair Duggin — GOVUK blog post
Why it’s important
People have a legal right to services from public sector organisations.
This means government has a duty to consider everyone’s needs when designing and delivering services.
And this is not just for external users. Your service should also be accessible for internal users. Quite often, internal users are overlooked. This can often be because it isn’t thought to be needed at the time the service is being created. While it might be true that there are no disabled internal users at that point in time, this could change: new people being hired or employees who become disabled after an injury or an illness. It’s also true that many people do not declare their disability to their employer, or their disability may not be visible.
Making your service accessible for internal users will also help people with temporary disabilities, for example:
- an injured arm
- home working while holding a baby
- an eye or ear infection
What does it take?
To meet government accessibility requirements, you need to meet the level AA of the Web content Accessibility Guidelines (WCAG). There are 3 levels: A , AA, and AAA and in government, you need to meet AA.
Your service needs to work on the most commonly used assistive technologies — including screen readers, screen magnifiers, and speech recognition tools.
You need to include disabled people in user research and to have an accessibility statement that explains how accessible the service is.
Think about accessibility from the start
Problems usually cost less to fix if you find them early. You should include the cost of making your service accessible in your budget and consider:
- recruiting disabled participants for your research
- planning more time for them to take part
- creating alternative material which works for your participant
- paying for an accessibility audit
For each stage of the delivery
In government, we follow an Agile delivery model:
At each stage there are different activities you need to do to make sure your service is accessible.
Discovery
Learn how people might use your service, the range of abilities they have and the problems they might experience.
Alpha
Start planning your future accessibility audit, ensure your design meets the WCAG 2.1 design principles, research and test with disabled people.
Beta
Do some accessibility testing and get an accessibility audit, use manual and automated tests each time you develop a new feature, test with disabled people, publish your accessibility statement.
Live
Carry on testing and researching your service, treat any new feature like you did in Beta, review your accessibility statement regularly, make sure your feedback mechanism includes disabled people.
Don’t forget the non-digital parts of your service, like your call centre, letters you are sending, training material. They need to be accessible too.
Who needs to be involved?
In a project team, accessibility isn’t just the job of one particular role. Everyone is responsible for making your service accessible.
It’s important that each person on your team understands how to avoid accidentally making things inaccessible.
Usually, the designers have followed best practice to ensure that their design is accessible.
You want to be sure:
- the business analyst has included accessibility acceptance criteria when relevant
- it’s coded by the developer(s) in a way that keeps the design accessible
- your tester(s) makes all the necessary checks (manual and automatic) before releasing the latest features of your service so it works as intended
You also want to make sure you’ve done the proper research:
- did you research with disabled people ahead of your design?
- did the user researcher made it easy for them to get involved?
- did you do some usability and accessibility testing throughout the project?
Remember, 1 in 5 people are disabled, so this should be reflected in the people you test with.
If you can, take others along to these testing sessions or record them. It’s a really good way to make people understand why accessibility is important.
Product and delivery managers should understand accessibility too so they can ensure it’s considered from the start and built into the service efficiently.
You can learn more about the responsibility for each role in the DWP Accessibility Manual or on accessibility.digital.gov, a US Government website.
Beyond your team
You may have considered accessibility perfectly throughout your project. However, if the comms team promoting your service has not considered things like adding subtitles to promotional videos, or alt text to images, people will be excluded.
The call centre, the support for users, the training for the staff — all must be accessible too.
Extras you’re adding to your service, like cookies, feedback surveys, or analytics tools like Hotjar for example — are they accessible?
How to learn more
If you’re on twitter or LinkedIn, follow disabled people or accessibility advocates. That way, you hear directly from them, about things you might never have realised otherwise.
If you are not on social media, the A11Y weekly newsletter do some curating for you.
By the way, if you don’t know what A11Y stands for, it’s short for accessibility (first and last letter of the word with 11 letters in between)
There are a few meet-ups you can join. More resources are mentioned in this blog post from GOV.UK: An accessibility reading list. There is also this free training from FutureLearn about Digital Accessibility.
Key takeaways
- accessibility is the whole team’s job
- think about accessibility from the start
- it’s not just for external users
- there’s help out there, so reach out!
Extra resources
- Making your service accessible: an introduction
- A website to give you’re an idea of how many people using your website have a disability
- Understanding accessibility requirements for public sector bodies
- What we mean when we talk about accessibility
Note: this blog post was initially written for the Sopra Steria blog where I was working at the time – The blog doesn’t exist anymore.