Making services accessible, accessibly

---

Contents:

• About me (Career squiggle)
• Red flags (Deceptive patterns)
• Why don't we just fix it with AI?
• Culture
• What does good look like?
• Testing: when, what, how
• Making accessibility accessible
• Takeaways
• More reading

---

About me

Career squiggle

Spoken: After returning home from Japan not quite sure what to do with myself, I did some admin jobs and fell into working with a team doing software testing for Halifax.

Highlights included sticking pencils in ATMs to see how they’d respond, managing the test team’s intranet page and a cheap mortgage. I never got to meet Howard though which I’m gutted about.

The testing work set the seeds for what I do now - caring for users and trying to anticipate what might go wrong. I’m a natural worrier, so testing was an accidental but good fit.

Around the time of the financial crisis and Halifax takeover in 2008, there was a lot of pressure as well as a lot of outsourcing and offshoring going on. While I absolutely loved so many aspects of working with teams based in India, my own job became more of a “checking rather than doing” role and I was keen to boost my technical knowledge further.

In 2012, although it was a high point for the country (OK there were the Olympics but the big one was the creation of GOV.UK), I went through some particularly difficult times personally.

Luckily I had a lot of support around me from home and work. This whole period really taught me the importance of good mental health, kindness and maintaining a good work life balance where possible.

After some time recovering and biding my time I moved from Yorkshire to Bristol in 2014 with a new job at the Environment Agency, thinking the public sector might be a better fit for me culturally.

It was!

So many people keen to make the world a better place, and a more forgiving, collaborative culture. I started on “traditional” waterfall style projects and (arguably) a bit more planning and tracking than doing.

While planning has its uses, my first chance to work on a GOV.UK style agile project really opened my eyes - I was working on teams that were actually getting things done well, at pace. I worked in service teams who genuinely cared for users, and a key part of that which really interested me was finding and removing barriers for disabled people.

Spoken: Here are the services I worked on in Defra covering flooding, water, waste and fish.

I have a particular fondness for the waste carrier service as we managed to remove the need to sign in to renew your registration, doubling the number of people happy to do it online rather than through the call centre. I’ll talk more about phone calls later.

I was a Quality Assurance lead specialising in accessibility and then in 2021 the opportunity came up to make accessibility my full time job at Government Digital Service, which I took with both hands - I’ve always kind of worshipped GDS from afar.

---

Red flags

Spoken: With all this testing, what kinds of accessibility red flags do we come up against?

The most serious myth I hear is:

Spoken: The UK parliament says nearly 1 in 4 people are disabled and not all disabilities are visible, or disclosed.

And while it’s vital to centre disabled people when talking about accessibility, most of us will have some kind of access need in our lives - for example, when my daughter was a baby I had to do a lot of things one handed while holding her.

Another potential red flag is:

Spoken: Firstly WCAG 3 doesn’t really exist yet - it always seems to be at least 5 years on the horizon by which time the web will have probably been entirely replaced by AI hallucinations.

While it is possible for services to be fully compliant with WCAG 2.2, and I’ll share an example later, you can often disprove this by quickly tabbing through the home page and uncovering issues.

One more red flag:

Spoken: There are two ways this statement can be interpreted.

On the one hand, installing an accessibility overlay tool on your site, particularly one which claims to magically make your site completely accessible, can risk increasing the number of access barriers on a site.

That’s not to stop you adding options and flexibility to your service - I’ve added a colour switcher to my own website which I believe is accessible. But don’t rely on a tool to fix all the underlying accessibility issues on your service.

On the other hand, automated testing tools are much more useful. They can generally detect around 30-40% of issues on a website. You still need to test manually though.

---

Deceptive patterns

Spoken: A common one is that all the information you need is online - until you need to cancel a service.

Of course companies want to make it hard for people to cancel things, but I think it’s a false economy.

If you insist on a phone call to cancel a service, it’s instantly going to discriminate against Deaf people. And some autistic people can find phone calls particularly anxiety-inducing.

One I’ll say is really good is Netflix, I’ve found it so easy to leave, which ironically makes me want to keep rejoining.

Spoken: A slight tangent but related to this...

Spoken: … and I highly suspect that a lot of those overconfident people are white, nondisabled men. I’ll pretty much steer clear of any advert without a figure.

In a wider sense, the Government Design Community identified a set of Universal Barriers which can exclude people from services. These are…

Spoken: I recommend having a read through these. Tying back into the previous slides, if you don’t trust an organisation due to their use of deceptive patterns, you may be excluded.

---

Why don’t we just fix it with AI?

There’s a lot of poor accessibility out there and that’s just what I see in the public sector. There’s a lot of work still just to get everyone up to the minimum legal standard. So why don’t we just fix accessibility with Artificial Intelligence (AI)?

Firstly, on attitudes to disability, here’s a powerful quote from Robbie Crow via LinkedIn:

Spoken: At the same time, AI has great potential...

Spoken: But one thing AI cannot do is...

Spoken: There’s a company who has recently developed an AI tool to simulate how disabled people might experience a service, but this has experienced some backlash. As Ashlee M Boyer says in their post which I recommend reading in full,

Spoken: So AI can be useful but you need to be careful.

Spoken: ...and those biases include ableism. So while it's an area for a lot of potential I would recommend doing the following...

---

Culture

Spoken: I’ll shift a bit now from the technology, to the culture behind it.

Spoken: Again, take any opportunity to listen to disabled people’s experiences - a lot of people are happy to share.

Just bear in mind though that if you’ve met one disabled person … you’ve met one disabled person. One disabled person don’t represent all disabled people.

Another thing I think helps you improve accessibility...

Spoken: (An accessibility statement is legally required in the UK public sector.)

Spoken: People (myself included) often promote the 80:20 rule as a way to get 80% of the work done with 20% of the effort.

That’s all well and good for some things, but the 80:20 rule must not apply to people - we mustn’t devalue people for whom accessibility is essential. It’s not an enhancement to include everyone who wants to use your service.

As I mentioned earlier with the “phone to cancel” antipattern, having an alternative to phonecalls doesn’t just benefit Deaf people, it benefits autistic people, people with busy lives who don’t happen to be free between 9:00 and 5:00, and people who just don’t like phonecalls - so that’s probably most of generation X, Y and Z.

Lou goes on to explain how by testing for users with “edge case” needs (with heavy quotes) you automatically design for those with “standard” needs (heavy quotes again, there’s no such thing as the “normal user”). The example they provide is the Oxo Good Grips swivel peeler, which was designed by someone with arthritis and sells millions.

I’ve heard this concept worded as “Design for the edge, get the centre for free” although my Google skills fail me to attribute that to anyone.

And one more point from Lou is that if your team doesn’t represent society, it is likely to inherently exclude groups of people.

Spoken: I know I’m not exactly part of the solution in who I am but I will try to use the privileged position I have to advocate for greater diversity in teams. I’m proud that GDS does pretty well in that regard, though there’s always more that can be done.

---

What does good look like?

One example:

Spoken: Another example:

Spoken: And a general observation (personal opinion here):

Now this is not a hard and fast rule and I’m very biased. I do find that accessibility tends to improve the closer you get to central government. The UK, Scottish and Welsh government website teams all have dedicated accessibility processes and design systems, which make it harder to go wrong. There’s a lot of good stuff in the NHS too.

Spoken: Those were some quick examples of good services, but can you know how well you're doing in accessibility? I'll now move onto testing.

---

Testing: when, what, how

Spoken: You’ll be at a big advantage if you start with accessible components, preferably based on native HTML.

(Hypertext Markup Language is often accessible by default. Frameworks and custom components … often aren’t.)

Spoken: This quick and early testing vastly reduces the number of surprises you’re likely to get when you do a full accessibility audit later.

Spoken: We always recommend you test prototypes with disabled people wherever possible - we tend to use the GOV.UK Prototype Kit as it provides quick but realistic and interactive mockups.

Spoken: Once you’ve eliminated the issues you can find yourselves, it’s a great time to involve specialist disabled testers and gain insight that you might not otherwise get. It’s even better if you actually fix the issues the testers find!

Spoken: I will always advocate for dedicated Quality Assurance specialists, we can be a bit pedantic sometimes but it’s all to prevent issues further down the line.

---

Making accessibility accessible

Testing for accessibility is great, but you need to bring people along with you on the journey. Just talking in technical language won’t help. In order to do that, the way you present accessibility needs to be accessible in itself.

Spoken: At its core, I believe:

Spoken: brat meets the AAA standard!

Spoken: This spells POUR. You could test principle by principle, criterion by criterion...

Spoken: So to me at least it makes sense to group all of your keyboard tests together. And while how you group your tests can be a personal thing, I reckon there are about 7 common themes…

I love maps, so I made a transport style map. The full map and description are on AndrewHick.com/wcag.

Spoken: These are all the WCAG criteria that form the legal standard which I’ve made into a transport style map with 55 criteria across 7 lines. You can check that:

KEYBOARD (blue)

Things fundamentally work with a keyboard, and nothing weird happens on focus or input.

ZOOM AND LEGIBILITY (red)

Text is legible - works when you zoom in, has enough contrast and isn’t just embedded in images.

SENSORY (yellow)

Information doesn’t rely on particular senses or cause distractions.

CODE & LABELS (black)

Things have appropriate labels for assistive technologies like screen readers and voice control.

FORMS (green)

Forms are usable, with helpful instructions and error messages. Particularly useful for services are things like error prevention, redundant entry (not asking for the same info twice) and accessible authentication (reducing the cognitive load of logging in).

GESTURES (light blue)

Things don’t rely on gestures, like dragging or having your phone in portrait or landscape.

WHOLE SITE (pink)

Labels and positioning are consistent across a whole site, and there’s more than one way to find things.

There is a bit of crossover between lines. For example you’d probably test Focus Visible with a keyboard, but there’s a sensory element to how visible a focus state is.

---

Takeaways

Spoken: The most important takeaway which I’ve said a couple of times is to listen to disabled people, understand what kind of barriers society puts in place and how people use technology to navigate services.

Spoken: Being open about your accessibility commitments, as well as the things you're learning, is more likely to build trust than defensively saying "we're fully compliant".

Spoken: While the main focus of accessibility needs to be that it’s essential for disabled people, everyone benefits by things being easy to use - this is often called the “curb cut effect”.

Curb cuts benefit people who use wheelchairs but also people with pushchairs, and delivery drivers.

Another example is the fact that while captions on TV are essential for Deaf people, a lot of hearing people use them too.

Then, a lot of the advice I see about accessible services often boils down to:

Spoken: But technology is only part of the journey.

Spoken: Accessibility expertise is great but a positive accessibility culture is vital to embedding it into an organisation.

If people are questioning the importance of accessibility, it’s worth delving into why, and challenging negative attitudes.

An accessibility expert won’t go very far without a team of people who have empathy and want to do the right thing.

Spoken: ... and that's a good note to finish on.

---

More reading