Fronteers — vakvereniging voor front-end developers

What is the Business Case for Accessibility? by Alice Bartlett


(Alice Bartlett) Thank You.

Thank you, Bruce, that was lovely.

So, yes.

There's my slides.


So I was at GDS until a week ago.

Right now I'm in between jobs, as they say, but I'm staffing at the Financial Times on Tuesday.

So I can answer plenty of questions about GDS, but, like, I can't fix anything for you.

So, none of it is my problem anymore.

So, yes.

So I just left GDS.

This is-- This screen is so big.

OK, sorry.

So there's a really massive picture of us.

And I mostly-- GDS does a lot of stuff, but the thing that I mostly work on-- or worked on-- was GOV.UK

And the talk that I'm about to give is called, "What is the business case for accessibility?" Which is a really boring-sounding talk, but that's kind of my speciality, is boring-sounding talks.

And those quotes there are important, because this is not something that I have ever asked-- well, until I decided to talk about it-- it's something that I got asked a lot.

And at first I was like, ugh, why would you need a business case for accessibility? That's grim.

And that was because I'm very motivated by the moral case for accessibility, which goes something like, the web offers great potential for equality, and furthering equality, and furthering equality of opportunity, but only if we don't continue to propagate the systemic biases that we have by building things-- by me building something that only works with people who are like me, by you building something that only works for people like you.

We need to focus on accessibility, in order to not just fuck up this huge opportunity we have, and Tim Berners Lee did a better job of saying that which is, "the power of the web is in its universality.

Access by everyone, regardless of ability, is an essential aspect."

Anyway, that's my pinko liberal views, which I'm allowed to say now, because I don't work at GDS anymore.

But it's not-- "what is the business case for accessibility" isn't a bad question.

It's quite a good question, because if you work in a capitalist society, as we probably all do, sometimes business are like useful tools to get things that you believe in through, because they promise financial gain, when, maybe, you're not being given the opportunity to do accessibility for the moral case, because money doesn't care.

So this talk is going to cover four things.

What is GOV.UK?

What I mean by "accessibility."

Why writing a business case for accessibility is actually really hard.

And then, I'll go into why it's probably not actually that important to have one, which is like my get-out for the fact that I actually failed at writing this talk, basically.

Um, here now, though, so-- So first up, what is GOV.UK?

So, it is the best place to find government services and information for the British government.

We have things like, when is the next bank holiday? What is the current foreign office's travel advice for traveling to Egypt? And then some weirder stuff, like, if someone from the government is coming to inspect your pig carcass, what can you expect? That's a topical joke about our Prime Minister that I can make, now, because no one can fire me.

So-- so we did this.

So we had-- these are all of our-- those are all the old designs for the websites, and we had about 2000 websites that were all designed in their own way.

They had their NCMS's, they had different looking field, different navigation.

And we took them all, and we made them into one single design, which GOV.UK.

And GDS did a bunch of stuff, but, you know, GOV.UK is sort of one I'm

just going to tell you about.

And we have 19 million visits a week, which makes us the 30th most popular site in the UK.

That's more popular than Tumblr,,

which is at number 33.

Um, we like-- I like telling people that.

We're home to 330 departments and organizations, and we saved the taxpayer more than 1.7 billion pounds

last year.

And that's just by cutting out all of those-- well, doing lots of stuff, but, like, a lot of it is cutting out supplies for crappy government websites, because we now have a single supplier, and it's us.

Well, actually, we have other suppliers-- anyway.

So we tried to make GOV.UK

as accessible as possible, but it hasn't always been like that, actually.

When we made the-- so, first thing we did with GOV.UK

is we made an alpha.

And that's this.

And we didn't really try and make this accessibility at all, and it was bad for accessibility, really.

And we did that because we were trying to make a sort of shiny prototype, to motivate people in government to give us money to make a better website.

And so the point of it was not to be a sort of fully-formed thing, but it sent a really, sort of, troubling message to our users.

Even though we didn't have very many users at that time, there were a lot of people that were still paying attention to us, and we got into a lot of trouble for it.

So this isn't actually-- this is just a statement of fact, which is that the AlphaGov prototype doesn't make any attempt-- significant attempt at achieving accessibility.

That is true.

We hired her as our head of user research, after this.

And not-- I don't think because of this, but maybe.

Another quote that was slightly less charitable was, "it is a crying shame that good money has been wasted on this run-of-the-mill, unimaginative, and pointless website.

Stop wasting my money.

We didn't hire that person, I don't thing.

So this is the beater.

And this version, we built for inclusion.

And Tom Loosemore, who is one of our senior strategy people, said, "we want to make the most easy to use and accessible government website there has ever been."

Which is great, because crowbarring accessibility in at the end of a project is actually really hard, compared to just building as you go with it.

And so, building for inclusion became part of how we worked.

We do regular user research with people with a broad spectrum of abilities.

We have screen reader training for designers, for the product people, for developers.

We hire in for expertise in accessibility.

So we have a head of accessibility, but we also look front-end developers when we're hiring, for front-end devs, and look at where their, um, understanding of accessibility is.

And we put it into our design principles.

We put building for inclusion into our design principles.

And this is from our design principles.

"Accessible design is good design.

We should build a product that's as inclusive, legible, and readable as possible.

And if we have to sacrifice elegance, so be it."

So that's GOV.UK,

and that's what we're doing with accessibility.

Now, I'm going to talk about what I mean by accessibility.

This is going to be more interesting than that title sounds, but, again, I like to aim low and then exceed.

So according to WebAIM, there are, like, four categories of impairment that might affect your ability to use a website.

They are visual-- so that's blindness and color blindness-- hearing, that would be people who are deaf or hard of hearing, motor-- which would mean you might have limited fine motor control or a slow response time-- and then cognitive, which is things like learning difficulties or difficulty focusing on large amounts of information, and those kind of things.

And we have technologies that can help with many impairments.

These are called assistive technologies.

And there are loads, but screen readers is the one most people are most familiar with.

Dictation software.

Keyboards, actually, are often used by people with-- more heavily used by people with motor problems, because they're easier than a mouse.

We also have things like particular fonts.

So Saran Davies gave a really interesting talk, recently, about her dyslexia how it affects how she reads.

And she told me, and told the audience, about this font called OpenDyslexic, which is really interesting, I think.

So this font is designed for people with dyslexia, and it's meant to be easier to read.

So the way Saran uses a web page is, she has a plug-in that will change the font to OpenDyslexic.

And, like, it's a funny looking font, right? But it's the weighting along the bottom there, is the most, like, obvious, thing that, to me, visually, thing that they've done there.

And that's because people with dyslexia sometimes experience letters flipping, and so having a sort of heavier weight along the bottom helps prevent that.

So if you have a chance, there is a recording of Saran's talk, and it's very interesting.

And then there are some improvements that you can do to website that aren't, like, aren't to accommodate various technologies.

And those are, like, color choices, or sentence length, or language, or information architecture.

And, like, as a developer, I feel like those kind of fit into design and content stuff, but GDS, certainly, we view user experience as a team sport, so we don't have any practitioners of UX, we just-- everybody is kind of involved in that.

And so it wouldn't be a problem for me to say, I think we need some more attention on this content here, because I could think it could be written better.

So making your site or component accessible, therefore, would mean supporting a variety of technologies, but also designing your site thoughtfully.

So no single person-- well, if you work in a team, it's everybody's responsibility to make things accessible, not just a developer's and not just a designer's.

And this is going to mean some tricky decisions, because when you're looking at accessibility so fully as that, you will sometimes find yourself in a position where you're going to make a decision-- you need to make a decision, and it will further the experience of some users, but lessen the experience of some other uses.

And that is where pragmatism and judgment come in, and that is also why having a team of people together making these decisions is really good.

But it's also where things like a design principle will help you.

Because at GDS, we don't tend to get into these very long-form arguments about design or technology, because we have a design principle that says, sacrifice elegance to make an accessible website.

That's fine, and that's very helpful.

And making sites accessible is also really-- I mean, this talk is about the financial sense of making an accessible website, but I really wrote it for the private sector, because for GDS and for governments, it's actually really straightforward.

It makes very solid financial sense for governments.

And that's because uses of government services are in, like, a closed system, right? So if you ignore their needs, they don't go away and find some other government, they just contact you through different means.

So if you-- you know, benefits claimants, no one's going to not claim benefits because your website doesn't work, they're just going to phone you, or they're going to come into a job center and try and get benefits that way.

And call centers are way more expensive than web services.

In a sort of policy document from 2013, the minister for the cabinet office said, "transactions online can already be 20 times cheaper than by phone, 30 times cheaper than postal, and as much as 50 times cheaper than face to face."

I would say-- citation needed, but, you know, he is member of parliament, so that's probably fine.

I don't know.

There was no citation for that fact, and I couldn't find one.

It's probably true.

It sounds true, right? Anyway, I made up this cool graph, v which is how this works in government.

But it only works when your users are in a closed system, right? Because if they are free to just leave, then you have to make a decision about whether it's more financially sensible to support them or to let them leave.

And that decision will be based on, like, how your website is currently performing, with regards to accessibility, and how gnarly your code base is, and loads of stuff that I can't know, in giving this talk to you.

And so that's-- this is the graph for private sector accessibility stuff.

It's even more made-up, and there's just a question mark there.

So now we're at Section 3, which is writing a business case for accessibility.

It says in my notes, here, pause, that's because I knew I would need-- yeah.

I'm nervous.

So, done some scene setting, this is the good bit.

This is the business case.

You guys are all about to get really, really rich.

So I wanted to come here and say, this is your magic answer for why making your site accessible is going to make you really wealthy.

You were going to be ha ha business meme man, Mr. Ha ha business

meme man, and I was going to be really popular.

But that was actually, like, just really tremendously naive of me, which was sort of sweet, but also annoying.

And I'm not going to spend ages talking about why this was a very difficult to write.

There are several versions of this talk that I had to discard, before getting to this one.

But if you've packed your tiny violins, then meet me in the bar later, and I'll tell you why this was difficult. But I

can talk about why writing a business case was hard, and hopefully that will be of some value.

So a good business case should take a problem you can prove that you have, and solve it in the most cost-effective way.

And a good business case should go something like this.

You have a problem, step one.

That could be, we need more money, we need to do more ad impressions, we need more-- we need people to think of us favorably, we're currently at a high risk of being sued, we need to spend less time on maintenance, those kind of things.

And then, you need to come up with some solutions to that problem.

And they'll include, basically, data, but, you know, cost-benefit analysis, case studies, things that have happened before.

And then step three is-- because we're doing a business case for accessibility-- you conclude by saying which of those solutions is the best, but in our case, because it's a business case for accessibility, it'll be accessibility.

So your best solution will be, we should solve x by improving the accessibility of our site.

And when I say accessibility, I understand that, like, accessibility is not this, like, nebulous lump of stuff that you can, like, have a scoop of.

You know, that's going to involve, like, sort of tactical decisions.

But let's just say-- let's just imagine accessibility is like a soft serve ice cream, and you can just have a little bit or do all of it, for the purposes of this.

So let's look at the things that we could possibly solve by doing accessibility.

So anecdotally, there are lots of problems that can be solved by making your site most more accessible, and the ones I'm about to go over are all from the W3C's Web Accessibility Initiative pages, which are about writing a business case for accessibility.

So we need better SEO.

We need to lower our maintenance costs.

We're missing out on revenue from seniors.

We're missing out of revenue from people with accessibility needs.

We need to improve our public image.

And then there's, like, 11 or 12 of them.

It's quite a lot.

But when you start writing a business case for all of these, it gets kind of harder.

Because the thing you want to do is find a case where accessibility is the most cost-effective way of solving any of those problems.

And I can go into why accessibility is not the most cost-effective way to solve, like, lowering your maintenance costs, but it would just be half an hour of me stood onstage, yelling, someone is wrong on the internet, and you just being very bored, so I'm not going to.

But if you are interested, Karl Groves has done a very, sort of, thorough dissection of why those business cases don't really add up to actual business sense.

And that's what-- so what a business case should be doing is finding a cost-effective solution, the most cost effective solution, to a problem you definitely have.

And as I look at it, the only well evidenced business case I can find for making your site more accessible is avoiding litigation.

And depending on where you are, the risk of mitigation is higher or lower.

So in a litigious society, like America, it's quite high.

In the UK, it's not that high, but we have-- it's definitely not-- you can definitely be sued for not having an accessible website in the UK, because we have the Equality Act of 2010, which places a duty on service providers, i.e. anyone who

provides a website, to make reasonable adjustments to allow disabled persons to access that service.

And there was a further code issued in 2011, which elaborated on this, which said that it requires that service provider's anticipate the needs of potential disabled customers for reasonable adjustments.

So that's not something you can do reactively.

You have to actually build an accessible service, rather than, like, make it accessible when someone says, oh, I can't actually use that.

In the public sector, we're also bound by the Public Sector Equality Duty, which requires us to have due regard for the need to eliminate discrimination and advance equality of opportunity.

So, like, GDS is like, it makes financial sense, we legally have to do it, there's kind of no question about making sites-- our sites-- accessible.

I don't understand Dutch, I'll just say that, but I did have a look at some Dutch accessibility law.

I don't know what that says.

But this is your Equal Treatment Act, and it basically-- I mean, look, OK, if you coming to a conference and getting legal advice about accessibility in the Netherlands from someone who doesn't speak Dutch, like, you have problems.

But I wanted to understand where you guys were at with this, so I had to look.

And Anna van Kesteren helped a little bit.

But Google Translate's really not there, in terms of translating Dutch equality law into English.

So I made-- what I'm trying to say is, I may have got this wrong, but it seems like you have the Equal Treatment Tax, which means that you can't be-- you can't discriminate on the grounds, in the areas of, employment, education, and public transport.

So you don't have that provision for service providers.

But it does mean that if you are a company and you hire someone who has accessibility needs that you're not currently meeting, then they can sue you, because-- and if you have, like, a hiring page, as well, then that needs to be accessible.

In the public sector, here, you have-- [TRYING TO PRONOUNCE DUTCH WORD].

That's good, right? Which is kind of interesting, actually.

So this was-- this was set up in 2007, and it's based on actual technical standards for accessibility, which is really cool.

It's based on WCAG, and it means, public sector websites must comply with this.

I don't-- I could really find how that's going.

Like, 2007 was a long time ago, and I sort of had a look, and I couldn't find how Dutch public sector websites are faring under WCAG 2 But this is quite advanced, particularly for 2007, I think.

So, it seems to me, anyway, from my not-very-good understanding of Dutch, that no case of an inaccessible website has ever made it to court in the Netherlands, which is very similar to in the UK.

In the UK, we have the RNIB, which is the World National Institute for the Blind, and they are a very large charity who will bring class action suits against websites quite frequently.

I know of a newspaper that's currently being sued by the RNIB.

But the thing that happens, generally-- well, in fact, in all cases so far-- is that the large company is so embarrassed by the prospect of being sued, that they fix their site before it ever makes it to court.

So you don't really hear about it.

But if you're a high profile company, then it is quite likely that you-- that the RNIB, in the UK, will come after you.

And so, you should make your site accessible, because otherwise, they're just going to force you to do, and then it's going to be quite embarrassing.

Outside of the UK, there have been several cases of sites being properly sued.

Sydney Olympics was the first one.

That was in 2000, and that was-- they had to pay the plaintiff 20,000 Australian dollars.

Target was sued in 2006 by the National Federation for the Blind, and they settled for six million.

Netflix was sued in 2013, for not close captioning their videos, and that was by the National Association of the Deaf, and they had to pay $795,000.

So these are all, like, the monetary values of being sued, but there's also, like, the embarrassment, and that kind of non-financial cost to a company as well.

The Royal National Institute for the Blind, in the UK, is also suing the Department of Work and Pensions at the moment, on the grounds of accessibility.

And maybe that one has made it into the public sector, which shows a sort of deterioration in the relationship between those two companies.

But, again, it's not-- I'd be-- it'd be quite exciting, if one made it to court, but I don't think one will, in the UK.

So these companies are all big, and you've heard of all of them.

But if you're a low-profile company, doing not very well-known work, then the chances of you being sued are quite low, actually.

Especially in the Netherlands, it seems.

And the litigation angle, in terms of a business case, rests on balancing the probability that you'll be sued against the cost of making your site accessible, which could be quite expensive, if you haven't built with accessibility in mind, or if your code base is huge and old.

And so, actually, I can't say that there is, maybe, a business case for accessibility, if you're doing small company work.

Which is a real downer, because when I was, like-- went to this guy.

I was like, of course there's a fucking business case for accessibility.

And then I looked, and I was like, holy shit, he's right.

Oh, no, and now I have to give this talk.

Anyway, so this is the bit where I turn it around.

So I don't-- the final-- I mean, I don't think you need a business case for accessibility-- which is lucky, because I couldn't find one-- because if you're building a site from scratch right now, definitely, then why wouldn't you make it accessible? It's not super hard, once you know what you're doing.

And as Scott said earlier this morning, access is part of our job, you know, as developers.

And as a front end developer, if you're not making your sites accessible, currently-- well, I mean, you can add it to your list of ways you know you've finished that piece of work, is that you've tested it.

And you can definitely sneak in accessibility, if you have to, as well.

I make plenty of choices at work that don't have, like, a direct line to a business case at the back of them.

And so, you know, to me.

When someone says.

what's the business case for accessibility? What I hear is, I don't want to do accessibility, so give me a financial incentive.

So at GDS, there are kind of four-ish levels to accessibility and how much-- there's a guy asleep in the front row.




There's four levels of accessibility, and-- that we do, and I'm just going to go through them now, from, like, lowest effort level to highest.

So the first is, don't scrap the HTML.

Basically, like, a lot of web stuff comes with HTML, and with accessibility baked in.

And then we, as developers, just kind of undo it, either unknowingly or because we don't think it's important.

I've seen this statement before.

Obviously, another citation-needed situation, here, but "properly structured HTML will get 90% of the way to an accessible site."

And if your site is 90% accessible, it's probably, like, 85% better than most of the sites out there.

That's a made-up statistic on top of a made-up statistic.

So let's look at some more bits GOV.UK that concern pigs.

So this is how to keep a pet pig, or micropig.

It's got some cool advice about, like, getting a license for walking one, which you need, apparently.

This is the rotor menu and voiceover.

And this is an example of how, like, HTML is already kind of quite useful to screen reader users.

So down the side, there, you can see the sort of heading numbers.

And people who use screen readers will often use the rotor menu to scan through to find the thing that they want.

So they won't read all of the text, they'll just looked for the headings.

And the same applies to-- so the rotor menu, you can move between, like, things.

So you've got headings.

You've got landmarks.

Interesting thing about landmarks that I learnt whilst I was at GDS, is that there's a kind of, really, patchy understanding of landmarks among screen reader users.

So the one thing that they mostly do use and understand is main.

So all of GOV.UK's pages will

have a main role, main, on it.

But in terms of the other stuff, it's like, well, some adoption, some support within screen readers is quite patchy, but also users don't necessarily understand landmarks either.

And then there's links, as well.

And links are a really good-- another good example of where it's possible to screw up the accessibility without meaning to.

So this is a thing that I've coded before, for sure.

And also Read More, like in page drop-downs, and stuff.

And this is bad for accessibility, because if you're scanning a page using links, then you end up with something like that.

And that's really-- that's really unhelpful, because you don't know what you're doing.

As a screen reader user, you can't see which one of those links you want.

And scanning a page for links is very common, as well.

It's like, we see sighted users do that, as well.

They don't-- if they're looking for something specific, they'll often look, and they think it's going to be in a link, they'll often just only read the blue underlined text.

And that's not the only complication with links.

So this is a link, but it looks like a button.

And this is a problem that we also, actually, legit fucked up on GOV.UK as well.

So this is technically a link.

And the reason it's styled like a button is because we wanted-- so we have these pages called start pages, and they have, like, a big call to action on the page, which is Start Now.

And we wanted-- and users who you go to Start Now, are, like, the start pages, they only really want to go to Start Now.

So when we-- even when we styled this as, like, a really, really big link on the page, people would miss it.

And it was only when we made it green and button-esque that it became, actually, very easy to find.

But you need to-- if you're going to take a link and style it like a button, you need to give it some-- you need to give-- it's basically dictation users that have the problem with this, because they will say to their dictation software, click the Start Now button, and your browser doesn't realize that is a button, because it's a link in the markup.

This is trivial to fix.

Add role = "button" to your link, and then you'll find.

But, I mean, honestly, we made that mistake on GOV.UK

less than two years ago.

And it's-- these are the things that, like, a good understanding of HTML and what you're kind of doing and semantics will just get you very far, without having to put in any extra effort or do anything else, in terms of accessibility.

The next one is, check with tools.

So there's no holy grail of accessibility testing.

Tools like WebAIM's WAVE or the Tenon from Karl Groves, the Paciello Group, are good, but they're not going to save you.

And there's no, like, hole you can throw a web page into, and then it comes back with, like, your job-- your work is done.

But WebAIM WAVE is very low effort, and so it probably is worth doing.

And there are plenty of other things like this available.

So here is keeping a pet pig and micropig WAVE.

And it-- there's an error on this page.

And it's saying that you've got two links there that go to the same place that are adjacent in the text, and that's a problem.

This is one of these things with accessibility that's really a judgment call, as to whether you would bother to fix that or not.

It's not actually an error.

It's only a warning, an alert.

But, you know, it's annoying for, like, that rotor menu context, but also, like, it's probably fine.

Tenon is the other one I'm going to talk about, in terms of tools.

Other tools are available, but-- I really like Tenon.

Is anyone using that in their stuff? Yeah, it's cool, right? So Tenon is actually an API, and it-- this is the Tenon web page at

that demonstrates it's API.

And there are no errors for the GOV.UK micropig page, there,


There are two things that really good about Tenon.

The first is that it's an API, and you post to it, and then you get JSON back, which means that you can integrate it really easily with your existing build processes, which means that your accessibility testing doesn't become a thing you do at the end, it can be a thing that you do, like, alongside with your unit tests.

And you can actually, effectively, break your build if you have an accessibility error, which is quite cool.

The other thing that is really good about Tenon-- I needed to find a web page that was broken and show you, and I looked at GOV.UK,

and, obviously, flawless.

I looked at my own website, also fine.

And then I was like, what's the next closest to this situation that I could use? And I went to the Frontiers website.

Anyway, it's fine.

It's really fine.

Before anyone in, like, jazzy trainers comes and tackles me off the stage.

But there is one error.

Sorry Frontiers.

And the error is, like, is really nothing.

It's not a big deal.

But there's a p tag and it's got no text in it.

It's got some inputs.

And this is another reason Tenon is good.

Let's look at this error.

So we've got a priority, there, which is cool.

Which means that you could set how much you care about accessibility.

Is not, like, a black and white thing, where you're like, all error is bad.

But then, also, maybe you care about the 86% ones.

And the other thing I really like about this is how good the explanation is of this being-- of what this error is.

So even if you're, like, a complete accessibility noob, you can still read that and go, yeah, I see why that's important.

And then you can make a judgment call about whether you're going to fix it or not, as the Frontiers guys can now do.

So there are plenty of other examples of tools that you can, sort of, throw your website at and get a rating for accessibility back.

But those are my two, the two I use, anyway.

Next one, next step on our four-level hierarchy, is test with assistive tech.

So let's be real here, you're never going to get as good at using a screen reader as someone who actually has to use a screen reader is, but the amount of insight you can gain from trying it is, like, invaluable.

So, I mean, you should do it, but also, don't think that it's going to be completely magic.

And especially, you should try it for things like components, or anything where you've got any kind of interactivity involved.

Because that's where you're really going to find that you have-- there are places you could improve what you've done.

And the reason I say screen reader, here, is because what you want to do is test the way-- test what your browser thinks your thing, site, or component, or whatever, is.

And one of the best ways to do that is to use a screen reader, because you can sort of probe at what it looks like it is.

That's just a sort of shorthand way of doing it.

But there are other forms of assistive tech, and if you have a preferred one, that also uses the accessibility API, then you should do that.

So there are a bunch of screen readers you can test with.

JAWS is very expensive.

NVDA is free.

VoiceOver is the one that anyone who has a Mac has, or anyone who has an iOS device has.

We're kind of at an interesting point in screen readers right now, which is that, for the first time ever, next year, it seems like JAWS is not going to be the most popular screen reader among-- for primary screen-- not going to be the most popular primary screen reader, and maybe Zoomtext or Window Eyes will overtake it, which is quite cool.

Well, I think it's quite cool.

And a side to this is, when you start testing things with a screen reader, what you'll find is a lot of bugs in browsers.

So if you like opening tickets against chromium, then really, this is for you.

So even writing this talk, I found a bug, which is, that link there says, KKkeeping sheep, goats, pigs and deer, which is wrong.

So I was like, man, that's funny, it's kind of funny.

And it's not what it says on the page.

There's only one K there, and it's not what it says in the HTML, either.

So it's definitely a bug with an accessibility API somewhere, I think.

And let's just have look-- like, a closer look at that.

So that's a definition list, and that's a link.

Like, that's really very ordinary.

And so, I was kind of looking at this thinking it's so weird.

Maybe it's that it's a link.

And then I tested all the links.

All the other links on the page worked fine.

And then i was like, maybe it's the definition list, but I sort of isolated that, and that was fine.

And them I was like, maybe we're doing something weird with the JavaScript.

And this element, here, is actually a component from our components architecture.

And I was like, shit, maybe we're doing something weird with how we're including that, and it's breaking something.

You know, when, like, you have a bug, and it's just so weird, and you go to all these crazy places trying to think what it could be.

Anyway, so I tested it in Safari, and it works in Safari, actually.

And I tested it in Firefox, and it worked in Firefox.

And so, then I was like, maybe it's a Chrome bug-- Jake.

So then I noticed that there's a first-letter pseudo element, with a text-transform to uppercase on that list, which seems, really, like-- we've had first-letter for a very long time.

It seems odd that there would be a bug there, but I managed to replicate it.

And it's like, if you transform it to uppercase, if you do anything that affects-- that can be applied by first-letter, right? You change it to red, it still breaks.

All those things.

And I was like, that's so weird.

So I double check this.

And Edd Sowden showed me this cool trick, which is that you can-- Chrome now have an accessibility tab.

So that thing I was saying earlier, about testing your website using a screen reader to sort of probe what your website's-- your browser's-- understanding of your site is, you don't need to do that anymore, because Chrome have this accessibility tab, and it's actually really kind of neat.

So for Tenon, you need to go to Chrome Flags Enable Dev Tools Experiments.

Click Enable up there, as I have done.

And then you need to go to this tiny cog, here.

Then you need to go to Experiments, there.

Then you need to go to Accessibility Inspection, there.

Then you need to restart your browser, but then you have this cool tab here called Accessibility.

And then you can click on, like, any part of the DOM, and it will say what it thinks that is, and whether it's interesting from an accessibility perspective or not.

And you can see, there, that it thinks the name of that is "keeping" with two Ks.

Anyway, so I filed a bug in Chromium about that.

So Jake just will fix that really soon, I guess.

The thing that's really crazy about this to me, though, is that that is a style that we've applied to-- like, it's a visual style, the uppercase letter-- and we've applied it using CSS, and it has broken our site for users of assistive technology, many of whom will be non-visual, and who would not have given the tiniest of shits about whether that was an uppercase or lowercase letter.

And this, like, seems like it a really insignificant bug.

But then, if you think about, maybe you're using a definition list, and you've got a telephone number, certainly that duplication there becomes a little bit more confusing.

Anyway, this is what you'll find with accessibility API's.

So step four on our hierarchy is ask an expert.

As I said, you're never going to get a good at using a screen reader as someone who has to, and so finding someone who's very good at accessibility testing will be really useful to you.

We have someone called Léonie Watson.

She is really incredible.

And she is a web developer as well, and so whenever she gives us any kind of feedback on our site, it's very technical, too, which is really helpful.

And that's how-- those are the four things that we do at GDS.

And this is partially-blind Josh's list of four things that, like, helps me to think about what I'm doing.

And the thing about this list is, those first three things, you don't really need a business case for.

Like, maybe that final one you do, because you need to get some sign-off for some money.

But those first three things, you can just do on the down-low, without having written any kind of business case.

Oh, just said that.

Karl Groves has a lot of stuff to say about this.

And if you're interested in a thorough dissection of why those business cases I listed weren't very good, he has really, like, clinically dissected why they're not good.

But he also says this.

"When accessibility becomes part of how you do things, of course is free."

And, therefore, you don't need a business case.

So on GOV.UK, building for

inclusion, doing accessibility, is how we work.

We share and discuss the accessibility of design patterns in a hack-pad that is publicly available at

It's cool working for government, because you don't really have any competitors, except, I guess, other governments, but mostly, we're not competing.

And so you could share, like, everything you do, if it's useful.

There's no, like, competitive advantage you're giving up.

So that's, you know, that's where-- even though I don't work at GDS anymore, that's where I'll continue to go to find any kind of research about input types and UX, and that kind of thing.

This is a fix to search pages that I blogged about over a year ago.

And that's just, you know, I found this problem, and it wasn't even an accessibility problem, really.

It was just a way-- it was an improvement that I could have made, and I did, by just opening a pull request.

And this is a pull request that my colleague @edds did, where he removed the-- he added aria-hidden to the horizontal rules on our homepage, because he was, like, just browsing it with a screen reader, not even looking for problems, and then he was like, huh, that could be improved.

You could start today.

You could go-- come to the party, obviously, but whilst you're on the loo, or whatever, get out VoiceOver on your iPhone-- or there is an Android one, as well-- and just have a listen to your own website, And just see what it tells you, and what you learn.

And eventually, that stuff will be how you work, and then it will be free.

So in summary, good business cases for accessibility are quite difficult to write.

They do exist, but there's not a lot of evidence for them.

And so, maybe don't bother.

Here's a list of links, and that's it.

Thank you, Alice.

Please join me on the Sofa of Interrogation.

I like-- I just-- so I've been sat here, all day, and-- no Bruce, I'm going in this seat.

And you-- well, because, look.

This one, you've got, like, your back or sides to most of the audience, whereas this one, you can see everybody.

So, you know.

That's why I always look at the person I'm talking to, because I don't want to look at these guys.

Here's your-- here are your questions.

So there's a fair few questions.

Number one is, you mentioned, after the party, going to the loo and listening to-- Yeah, just when you're having a little quiet time.

Yeah, but if, like, you're having a big poo, and you've got longer, what's the single best easy thing I can do to my website, to make it more accessible? Um, I mean, like, you need to work out what your-- like, if there are any accessibility problems, by listening to it with a screen reader, and then find those.

One of the problems I have with accessibility stuff, actually, and particularly with Area stuff, is that there's-- you get into these really odd edge cases with Area, where you can't-- Like that area search results example that I showed, it was actually very difficult to work out what the expected behavior for screen readers would be, there.

I actually had to ask Léonie what she would expect to happen there, because it wasn't immediately obvious how area-- although I knew I needed to use an area tag, I wasn't sure how it should work.

But yeah, like, listening to your web page will just find most of the problems.

And, like, there'll be some low-hanging fruit, there, I'd expect.

Got you.

How does GDS define accessibility? So, you know, everybody chases, or many people chase, the mystical WCAG 2.0

AAA compliance, which, in my personal opinion, is unachievable, because perfection is unachievable.

Except in me, obviously.

Yeah, well.

But-- so presumably, GDS had some kind of objective measure, rather than, sounded OK in a screen reader.

What was it? You know, we don't, actually.

Just, sounds good? Yeah, so, there are a couple of things, like, we support users and not browsers.

So if anyone ever tells us there's a problem, even an IE6, we'll fix that problem for them.

And likewise, with screen readers.

But also, you know, the majority of our patterns, we reuse.

And so, especially now, there's not a whole lot of new stuff, which means that-- like, to begin with, we were sending-- like, punting a lot of stuff off to Léonie to say, you know, we've checked this in the screen reader and it seems good, but can you just make sure that it is right? And she would almost always find some way of improving it.

And that was kind of our level, actually.

Got it.

Um, I think I know what your answer's going to be to this, but it came from the audience.

You said that, at GDS, there was a motto of, sacrifice elegance for accessibility.

And a couple of people asked, why can't we have both? It's not that you can't have both, it's that sometimes there'll be a-- not universally, that you can't have both, it's just that, sometimes, there will be a case where it's like, well, this is more elegant, but this is more accessible, and then you pick that one.

So, you know, there is always-- you'll always, as a developer, strive for elegance.

And I think elegance, in that case, actually refers to design.

But as design, there's also-- our designers are very keen for am elegant web page.

But, you know, when you're-- it's just good to have a priority list, basically, and accessibility tops elegance.

They can coexist.

I mean, I use-- excuse me-- I use GDS for renewing my tax disc, and various mundane things that British citizens have to do.

And the design of it is minimal.

I mean, I think it's elegant because I like that minimal simplicity.

But I guess my question is, but that's not purely because of accessibility? There are other reasons for that minimal design? Yeah.

Well, yeah, it's because, best case, when you come to GOV.UK,

you want to be compliant, so you're renewing your tax disc.

But worst case, something really bad has happened, and you need the government's assistance with that.

And, you know, it's why we don't have a goofy 404 page, or we don't have a goofy error page, is because, if your husband has just died, and you need to sort some shit out for him with the government, like, you don't want that stuff.

You want it to be as clear and straightforward as possible, and anything that would trivialize that is bad.

And so we look out-- you know, we design for those users, the users that are having the hardest time.

And then, you know, when the Daily Mail called GOV.UK, when we won

a design award, and that's fine.

Like, it doesn't-- we don't need to delight our users.

They don't have anywhere else to go, anyway.

So, you know.

Yeah, I guess a few people are going to find-- Except Amsterdam.

They could move to the Netherlands.

Few people are going to find filing a death certificate for their spouse a delightful experience, no matter how much design has gone into it.



Ladies and gentleman, Alice Bartlett.

Thank you, Alice.

Post a comment