I was invited to speak at
Design Systems London, these are the slides with my speakers notes.
I’ve put together some of the tweets in a
Twitter moment, if you’re into that.
All the sources are linked from the speakers notes in the
YouTube: Design Systems London (note: there are no subtitles)
Open full size image for slide 01
Hey everyone, I’m Nick Colley, I’m a frontend developer at the Government Digital Service
Open full size image for slide 02
Today I wanted to talk to you about accessibility in the GOV.UK Design System
Open full size image for slide 03
GOV.UK is the best place to find government services and information online.
You might have used GOV.UK to...
Open full size image for slide 04
tax your vehicle
Open full size image for slide 05
to check guidance on keeping a micropig.
You're basically a farmer if you keep a micropig, you might need a license to walk it.
Open full size image for slide 06
or hopefully to register to vote
Open full size image for slide 03
I think it’s worth talking about how GOV.UK was put together to give context to why Government might need a design system.
Open full size image for slide 08
there were a ton of differents websites that looked and behaved differently but fundamentally served a similar purpose.
From the user’s point of view there’s no need for them to be different.
Open full size image for slide 09
We needed to go from
750 websites domains to one top level domain.
Open full size image for slide 10
While this has taken time, most content is now in one place with a consistent user experience and brand.
We now have more than
300 thousand pieces of content
from across government published and
GOV.UK now has
more visits in a single month than there are people in the UK.
Open full size image for slide 11
But government online is not just content, it also includes transactional services that rely on users inputting data.
Open full size image for slide 12
There are currently
780 services that account for over a billion transactions a year.
Open full size image for slide 13
So why does Government need a design system?
If merging a bunch of sites together gave a consistent experience surely we don’t need a design system, problem solved.
Open full size image for slide 14
From a technical perspective, content can be centralised, services cannot.
This means that departments across the UK are,
building services in different technical stacks.
On different domains.
That all need to look and feel the same.
Open full size image for slide 15
For example, a business wanting to hire their first employee needs
information and services from 5 different areas of government.
before they can hire them.
Open full size image for slide 16
Here’s a totally not fake or exaggerated user journey, to try to illustrate this.
Open full size image for slide 17
The user could
start on a content page,
which is run by GDS, then they could go through any number of departments running services.
Open full size image for slide 18
These departments all use different technologies but for the user it should look like nothing has changed
Open full size image for slide 19
Users should not have to understand how government works.
So how do you create a consistent experience for both content and services with distributed teams?
Open full size image for slide 20
This where the
GOV.UK Design System
comes in, it’s built from years of research and work from teams across government.
There were already volunteer led projects that laid the foundation but this is the first time we’ve had a dedicated team to work on this problem.
The GOV.UK Design System brings together styles, components and patterns.
Open full size image for slide 21
So for styles, we have things like color, spacing, layout and typography
Open full size image for slide 22
For components, we have things like buttons, tabs, and checkboxes. These tend to be used in many different scenarios.
Open full size image for slide 23
Then finally we have patterns, you might have heard these refered to as design patterns.
These patterns often give context to where components should be used, but patterns do not need components to exist.
Open full size image for slide 24
Something we spend a lot of time on is in the GOV.UK Design System is accessibility.
But why do we care about accessibility?
Open full size image for slide 25
20% of people in the UK have a disability
this could be a visual, hearing, motor or cognitive (affecting memory and thinking) impairment
Open full size image for slide 26
But if we think about accessibility in terms of exclusion and inclusion, we can think about people’s experience as a spectrum, which includes even more people.
The example I’m showing today is from
Microsoft’s Inclusive design toolkit.
It shows how motor based impairments can impact anyone.
Someone who has lost motor function in one arm might operating a keyboard to be difficult.
But if you broke your arm skiing, you could experience some of the same barriers.
This is called a temporary impairment, since over time your arm will heal.
The final end of the spectrum is a busy new parent who is holding their child, restricting the use of one arm.
This is a situational impairment, but by designing for someone with a permanent disability we make our services usable to everyone on this spectrum.
Open full size image for slide 27
One example of this I wanted to share with you is about subtitles, otherwise known as closed captions.
Ofcom did a study
which found that 80% of television viewers use subtitles for reasons other than hearing impairments.
We can see this too in social media, where often videos will autoplay without sound and include subtitles which is useful in situations where you’re on the go and can’t listen to a video.
Open full size image for slide 28
Raise your hand if you work in the public sector, or with charities.
Cool, this slide is for you 😊
In the public sector, there are also
two regulations worth knowing
The Equality Act 2010 legally protects people from discrimination in the workplace and in wider society.
But more recently there has been the introduction of an EU directive which is more specific to web and mobile applications, so can be enforced easier.
These useful to make a business case for accessibility in the public sector.
Open full size image for slide 29
Soooo I tried to make a meme, but the EU directive is so long it doesnt really make sense.
Cant remember if Darth Maul gets beaten or not, doesnt the long hair dude get killed? I guess that’s what doing accessibility work is like sometimes...
Open full size image for slide 30
How do we meet these needs?
For time, I’ve focused on just a few things we do.
Open full size image for slide 31
government accessibility requirements
, digital services must:
Meet Web Content Accessibility Guidelines version 2.1 at level AA
Test with assistive technologies
include people with disabilities in user research
Open full size image for slide 32
So I'm going to go through these one by one
Open full size image for slide 33
If you’ve not heard of
WCAG (Web Content Accessibility Guidlines)
before you can think of it like a standardized accessibility design manual.
They are an internationally recognised set of recommendations for improving web accessibility.
They explain how to make digital services, websites and apps accessible to everyone
Open full size image for slide 34
This includes users with impairments to their:
vision - this includes people with sight impairments and colour blind people
hearing - like people who are deaf or hard of hearing
motor - like those who find it difficult to use a mouse or keyboard
cognitive - like people with dyslexia, autism or learning difficulties
Open full size image for slide 35
If you’re new to WCAG, it can be a bit daunting, so one place you could start is by running an automated test for accessibility
Open full size image for slide 36
There are many different automated tools but I’ve personally found that
works really well for a lot of use cases, and it’s what we use on the Design System
Open full size image for slide 37
If you want to use it, it comes in every version of Google Chrome developer tools.
You can find it under the lighthouse audit option, and it runs as part of the accessibility step.
Open full size image for slide 38
Axe is also useful because it can be reused in many different circumstances, so here’s an example of a component within a component library that has accessibility warnings alongside the example which makes it easy to action.
Open full size image for slide 39
It can be also used in the command line, which is useful when writing unit tests that run on a continuous integration server as part of your development workflow.
Open full size image for slide 40
So you might be thinking, sweet, I can npm install this and it’ll solve all my accessibility issues.
Open full size image for slide 41
The accessibility team at GDS, built the least accessible webpage in the world, and tested as many automated tools on it as a possible.
They found that tools like axe can only pick up around 30% of issues
The other 70% needs to be done with manual testing.
Open full size image for slide 42
One example of manual testing is the work we do to make sure
GOV.UK works when users change their colours.
While high contrast is normally associated with good accessibility, for some users it can cause visual stress that means they prefer to customise the colours they use to read your website.
Open full size image for slide 43
In this example I’m showing a radio group, that asks if the user has changed their name.
And the first radio input is focused.
Since our radio inputs are custom elements for improved usability, we have to do extra to make sure the custom focus is not lost when users change their colours.
So in the second example, there is a separate outline, that represents this focused input so that it’s clear what is being interacted with.
Open full size image for slide 44
One other thing you might consider is to get an
external accessibility audit
this can be really useful to get an expert’s insight into what you’re building.
Open full size image for slide 45
The second thing I want to talk to you about is testing with assistive technologies
Open full size image for slide 46
Assistive technologies help people to overcome environments that exclude them based on certain disabilities or impairments.
Common assistive technologies include mobility aids such as wheelchairs or crutches.
On the web we have some less known assistive technologies, which are equally as important.
Open full size image for slide 47
We test in the
most commonly used assistive technologies.
JAWS, NVDA, and VoiceOver are all examples of screen readers.
Screenreaders can read out a webpage and are often used by people with sight impairments. However, they’re also used by people who have trouble reading english or people with dyslexia.
Often people with disabilities use multiple assistive technologies, which intersect with each other.
ZoomText is used to zoom pages often to over 400% their original size.
And finally Dragon NaturallySpeaking is used by some users that have mobility issues which allows a user to dictate commands with their voice.
Open full size image for slide 48
Has anyone seen bladerunner?
With the scene where Deckard is zooming an image with his voice?
Open full size image for slide 49
There’s this image he’s zooming into.
Open full size image for slide 50
Open full size image for slide 51
Enhance, he’s using his voice
Open full size image for slide 52
Dragon NaturallySpeaking has a mode called mousegrid which is basically the same thing
Open full size image for slide 53
We have put all these assistive technologies into what is called the
Accessibility Empathy Lab
so that these are easy to pick and test.
Open full size image for slide 54
Some of these tools are Windows only and cost money.
If you want to start, Anika from the Accessibility Team has written a
blog post on tools you can use at no cost.
Open full size image for slide 55
When using assistive technologies, it’s tempting to try and fix oddities around how the technology works.
We can’t make decisions based on what we might consider to be odd, that is a regular experience for a person who actually uses these technologies everyday.
Open full size image for slide 56
One frequent example of this is assistive technology mispronouncing content.
For example, We had one case where GOV.UK was being pronounced ‘governer’
Through our Accessibility community, we often get asked about how to create content that works well with screen readers.
[...] don't write content that works specifically for screen readers, write content that works well for everyone
Open full size image for slide 57
I think this quote from Robin is worth sharing where they say:
Designing programs to build compassion/understanding for disabled people in the total absence of consultation with disabled people is very silly.
Open full size image for slide 58
So this leads to the final step, including users with disabilities in your user research
Open full size image for slide 59
One of the best parts of user centered design is doing research with your users, this applies to doing accessibility itself.
Open full size image for slide 60
Our team doesnt build live services, so researching in a real world context can be difficult.
Open full size image for slide 61
Doing research with users can be expensive, so we don’t want to do a full round of testing for one addition to the design system.
In the past, we have tried testing components on their own, but it puts users in an unrealistic scenario.
One way we’ve tried to get around this is to put
multiple additions together and test them in a fake service.
This was really successful but is time consuming to put together.
Open full size image for slide 62
The best research comes from the real world usage of components in real services.
Open full size image for slide 63
This is why for some components we have an experimental label, which allows us to ship a pattern or component that we think could use more research to validate it.
Over time we may decide to make another fake service with multiple experimental additions, but we hope by building more community and being honest we can get this research by real services teams.
Open full size image for slide 64
I think with this all in mind, a design system is only as good as the community it represents.
Open full size image for slide 65
Design Systems can’t make services accessible on their own
Open full size image for slide 66
One thing we’ve noticed is that a design system
can mislead some people
into thinking they don't need to test their service.
Open full size image for slide 67
Cathy Dutton wrote about this in her article
‘Problem with patterns’
, where she says:
"Because patterns are built for reuse, they sometimes encourage us to use them without much question [...]"
Open full size image for slide 68
This is not a unique problem to accessibility, patterns in design systems can give people a false sense of security.
But they shouldnt replace the design process.
Open full size image for slide 69
Design systems are a
Everything I’ve covered here ideally should also be done by the service teams we support.
Open full size image for slide 70
By fixing the most basic accessibility issues we give service teams the time to focus on the harder problems.
Open full size image for slide 71
When building design systems we have a lot of responsibility, we can make inaccessible patterns wide spread or take the opportunity to make all our services more accessible by default.
But if you’re starting out, don’t worry about being perfect, as Leonie Watson says: “
Do just one thing to make it a little better than yesterday
Open full size image for slide 72