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.
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.
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.
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...
There are many different automated tools but I’ve personally found that
aXe
works really well for a lot of use cases, and it’s what we use on the Design System
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.
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.
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.
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.
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.
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.
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.
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.
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.
You can read the beginnings of GDS and GOV.UK in
"A GDS story"
↩
In Martha Lane Fox’s report
"Revolution not Evolution"
"Number 10 feel it is preferable to go from 750 top level website domains (eg www.cabinetoffice.gov.uk) to a single top level website domain for all of central government."
"The user should not have to navigate the departmental structure of Government before finding the service or content what they need."
↩↩
If you query
GOV.UK’s Search API
it will give you a total, as of writing this is 376,518.
↩
You can see how many services there are with the
Service data dashboard.
As of writing there are 780 services, with 1.03 billion completed transactions per year. (384 services out of 780.)
↩
Microsoft Inclusive is really well referenced, their new toolkit is really good and worth a read,
even if it’s confusingly in a PDF...
Microsoft Inclusive Design↩
I’ve learnt so much from the Accessibility team at GDS, and this guidance is amazing, which is the basis for the middle section of my talk.
I highly recommend you read this:
Making your service accessible: an introduction
.
↩
The quote on screen I actually made up because the real one was not grammatically correct, so this is a bit cheeky but we have consistently seen this in research.
Some real quotes:
“[...] the things that would make a service not accessible, the work has already been done by GDS so we don’t have to keep doing it.”
"Once we have the first prototype, my starting point is the GOV.UK prototype kit, I trust that I know it’s been built with accessibility in mind."
"Having the prototyping kit now means that it is accessible"
"Things like design patterns, 80% has already been done and tested by GDS or other services."
Thanks to Katie John and Bekki Leaver (GDS User Researchers) for these quotes.
↩
This criticism has come from multiple places, and I wanted to highlight it in this talk.
“These are platforms for us to look at harder problems. [I’m] just cynical of things like design systems seen as ‘the design is done’” – Simon Wilson (@ermlikeyeah)