Free training on the new UK accessibility law

Worried about the new accessibility law for UK public sector websites? This free 60-minute training session will tell you what you need to know in time for September's deadline.

Read transcript

Questions and answers

These have been expanded from the webinar, with many questions that we didn't have time for.

"Is there a recommended 'reading age' suggestion for public sector websites?"

WCAG Reading Level 3.1.5 – which is a AAA requirement, and so not mandated by this particular law – targets a "lower secondary education level", which we generally see translates to 13-14 years old.

"Do you have any specific advice regarding accordion modules and the principles of hiding content?"

There's an excellent website on design patterns that specifically answers this (complicated) question.

"Is your understanding that it is new websites that are applicable for the particular compliance states or new web content?"

The letter of the law is a little bit muddled because it's incredibly hard to be precise here. Imagine you had a website and you decided to change the CSS so the design looked different but the rest of the site didn't change. Did you just get a whole new website? 

In practical terms I think you'll find that it'll be relatively soft touch until such a time as the new deadline passes around September 2020. I think what they've tried to accomplish is not so much to police you rigorously on these deadlines, but to encourage you to procure with accessibility in mind first, and to make everything compliant later.

"Does the new compliance also include internal web apps, e.g employee intranets, back office apps only used by employees?"

Article 1 (2) (g) provides this exemption for some intranets:

This Directive does not apply to the following ... content of extranets and intranets, that is to say, websites that are only available for a closed group of people and not to the general public as such, published before 23 September 2019, until such websites undergo a substantial revision;

This loophole appears to allow you to ignore these until you procure new ones.

"Would just having non-accessible PDFs constitute non-compliance, how would that be policed?"

Regarding policing: GDS are using automated tools and manual checks. They're also presumably going to rely on people contacting them and reporting non-compliance. Non-accessible PDFs would constitute non-compliance, the only exception being older PDFs as defined under Article 1 (4) (a):

This Directive does not apply to the following content of websites ... office file formats published before 23 September 2018, unless such content is needed for active administrative processes relating to the tasks performed by the public sector body concerned;

"Are we responsible for making a third-party service / content that is used on our site accessible?"

The relevant part of the EU Directive (section 30) says:

"Embedded content, such as embedded images or videos, should be covered by this Directive. However, websites and mobile applications are sometimes created into which additional content may be subsequently incorporated, for example an email program, a blog, an article that allows users to add comments, or applications supporting user-contributed content. Another example would be a page, such as a portal or news site, composed of content aggregated from multiple contributors, or sites that automatically insert content from other sources over time, such as when advertisements are inserted dynamically. Such third-party content, provided that it is neither funded nor developed by the public sector body concerned nor under its control, should be excluded from the scope of this Directive. Such content should, in principle, not be used if it hinders or decreases the functionality of the public service offered on the website or mobile application concerned."

My reading of this is that although some third-party content is excluded, what matters "if it hinders or decreases the functionality of the public service offered on the website".

"Is alt text still required for images that are purely decorative?" and "What are the disadvantages of over-describing in alt tags?"

Sometimes specifying alternative text can be harmful to accessibility. WebAim has a great article on how to use alternative text properly which covers the nuance.

"Can we use ARIA labels to make text like 'read more' distinguishable?"

For example:

<a href="/news/article" aria-label="Man bites dog">Read more</a>

This is one of the safest and most common uses of ARIA, but old screen readers will read the link text. We use this because the alternatives

"Would an 'aria-labelledby' pointing to the heading also be considered OK?"

For example:

<h2 id="article-heading">Man bites dog</h2>

<a href="/news/article" aria-labelledby="article-heading">Read more</a>

Although this 'works' for about 91% of screen readers, compared to using "aria-label" is "aria-labelledby" will sometimes read both the link and the ARIA text.

The other concern here is the extra complexity: you need to give unique IDs to the headings you refer to, and it's more likely that you'll break something if code is shuffled around.

"Is 'aria-label' for an input box without label still accessible?"

For example:

<input type="text" aria-label="Name">

Quite a few screen readers still don't support this and ideally you should use a separate <label> tag.

"Does the orientation rule also include interactive experiences such as games etc?"

WCAG itself allows for exceptions here (see Orientation 1.3.4), for example:

"An example where orientation is essential could be a piano app that requires the device to be in landscape mode to allow room for enough of the piano keys to be functionally usable"

It is conceivable that this could apply to a game, if the design of the game demanded it. You might also be able to claim that complying in this case would impose a disproportionate burden.

"Is 'highlighted in yellow' accessible? Particularly alongside white text"

Assuming you mean "is text on a yellow background accessible", it would depend on the exact colours of the text and the yellow. WebAim provides a WCAG colour contrast checker you can use.

"Are sans-serif typefaces a requirement for on-screen text under the regulations?"

Sans-serif fonts are not a requirement, although generally they are simpler, and simpler fonts are recommended for legibility. WebAim has a good primer on accessible font choices.

"Is YouTube captioning good to go?"

Assuming you mean are their captions accessible, then yes. Be wary of overly relying on YouTube's automatic captions, as they can suffer from reliability issues.

"When do PDFs need to be compliant?"

It depends on the age of the website; if the website is "new" (created after September 2018) then you have until September 2019. Otherwise you have until September 2020. As mentioned earlier, determining when a website is "new" is not always clear, and is likely more a way of phasing in your implementation rather than a hard line for policing compliance.

Under the permitted exceptions you can ignore PDFs published before 23 September 2018.

"Are we required to show some kind of compliance certificate?"

No. However having some evidence of testing would likely help your job security in the event your accessibility is questioned.

"As accessibility keeps changing, are companies ever able to achieve full compliance?"

The WCAG 2.0 standard lasted for ten years and even WCAG 2.1 is mostly the same, with some additions. If anything, accessibility standards probably don't change often enough to keep up with the internet.

Although the standards themselves are not fast changing, the difficulty in attaining compliance remains high. Mostly because standard tools and technologies are not engineered with accessibility in mind. We test tens of millions of websites every year and right now only a microscopic fraction of these meet even WCAG 2.1 A compliance. With a clear standard now defined, we expect this will improve.

"Is there an ETA for my new book?"

Yes.

Transcript

This transcript has been lightly edited for reading.

Introduction

Good morning, and welcome to today's webinar on the new UK accessibility law and what to do about it.

My name is Oliver Emberton, I'm the CEO of Silktide and I'm also the author of the forthcoming book on "Web Accessibility Made Easy: A Guide for the Rest of Us." Today I'm going to be talking about the new law for UK public sector websites. And we're also going to be looking at the state of your websites specifically because before this we did some research on UK public sector websites and we identified the most common problems and challenges that you face.

We're also going to look at what you actually have to do about it. We're going to have a brief interval to totally panic about the results, and then hopefully we'll gather our senses and form some practical solutions and take some deep breaths at the end. 

The law

Okay, so where do we start? Well we start with this, this is the new EU directive, and I encourage you to read it in your own time. It's not a lot of fun, but the highly condensed version is you have two things you need to worry about doing. 

First is you need to meet this new accessibility standard, that is affectionately known as WCAG 2.1 AA. The second thing is you need to punish an accessibility statement about it. The accessibility statement is not too difficult, it's literally just saying this is the current state of our accessibility as we understand it, these are the people you should contact in the event you have a problem with your accessibility or any questions. It's fairly standard, we're not really gonna talk about that today, it shouldn't cause you too much difficulty. The first part on the other hand, well, that's gonna be a little bit more tricky. 

So let's look at when you actually have to get this done. If you have a new website – which is defined as a website that is published after the 22nd of September – that website has to comply by this September. If on the other hand you have anything else, which most of you will, you have until next September. So for the most part that means about 14 months. 

How hard can that be? 

Well you may not think it's that challenging, we did a little bit of research. So I would ask you to guess how big you think your website is. In my experience most people, most organisations actually don't know, and if you're say a university, you probably don't even know how many websites you have. 

Let's just imagine the primary domain for your website, so say example.com and imagine how many pages you have. So we looked at the three groups that are most represented on today's webinar, which are NHS trusts, councils, and universities, and we took a sample of those. So NHS trusts on average have about 2,100 pages and about 500 PDFs. Councils have a quite substantial 18,500 page average and about 3,300 PDFs. And universities go all the way up to 30,927 pages with about two and a half thousand PDFs. Which means that many UK universities have more pages than students, which is perhaps a little concerning. 

I should clarify these figures are only for your main domain, we didn't look for anything else, and in some cases we hit 100,000 pages for one site, we ignored those, so the real numbers will actually be a little bit higher, but it gives you some idea. 

So just as a full exercise let's imagine you've got, we'll take an average of 20,000 pages. We also measured the first 100 pages of your site, and we looked at a number of issues you had on those pages, and we discovered on average across the whole UK public sector, you had 44.1 issues per page, which sounds like a lot but it's actually pretty good, it's better than the majority of websites. Nevertheless, it's still quite a significant hurdle to clear. So you've got 20,000 pages, 44 issues per page and you've got 14 months, so times that by that and divide by that and you get 63,334 issues to fix per month, which is just about seven and a half per minute assuming you allow yourself weekends. So yeah, that's gonna be an interesting challenge for the times ahead. 

Now we actually forgot a few things, we didn't count your PDFs, we didn't count your sub-domains, we didn't count any prior login areas you might have, and of course this is a side project, this is usually not someone's dedicated day job, this is something you have to meet and maybe you don't have much resource available. That is what we'll be looking at today. 

We might well summarise this as the five stages of becoming accessible. I will be walking you through these throughout today. You may well be beginning with denial and the feeling that "oh no I don't have to do this", and we're working through anger, bargaining, depression, and hopefully ultimately acceptance. But to get there we're gonna start off with some fundamentals. 

Fundamentals

So let's take a brief moment to cover some jargon and find out how to keep up with your cool friends at parties when you're discussing WCAG 2.1 AA. 

So this is a standard, something like WCAG 2.0 or WCAG 2.1, that's standard. And you're probably at least partly familiar with the first one, WCAG 2.0 is the accessibility standard that pretty much everyone had to follow for about 10 years. And it was written for context at the time when the iPhone had not been invented and it released at the time the first iPhone was coming out. So the phones you see at the bottom of this screen are basically what people had at that time. The world has obviously moved on quite a lot since then. 

The main aim of WCAG 2.1 is to expand that standard to incorporate the many, many new challenges that occurred as a result of mobile and tablet devices in particular. So if you know WCAG 2.0, WCAG 2.1 is the same but it has extra stuff added. And you might think well why are you adding this stuff? It's commonly assumed that people who are using accessible technology are using a desktop computer and a screen reader, that's the kind of model that most people have in their heads it seems. And it's incredibly out of date. The truth we all know we've moved on in the last decade or so to using mobile phones first, but it's actually also true of people using accessible technologies. To give one example here, this is the percentage of mobile screen reader use over desktop, and you can see how dramatically that has changed, so basically think of your accessible users surprisingly as just regular users, they have many of the same technologies and challenges as you. And many of the approaches people are using are very much out of sync with that. 

So quickly, WCAG has three levels, this is basically how severe or important something is. Single A, Double A, Triple A. Must do, should do, and ideally do. Except – not really – because Triple A is basically impossible, you have about as much chance of complying with Triple A as Donald Trump has of winning a spelling bee. So we aren't going to worry about that for today, but we are going to need to concern yourself with the first two. 

And then our last piece of jargon – I promise – is a Success Criterion, which is a three digit number a little bit like this, 1.4.3. There are 78 of these and chances are you've actually come across them before but you didn't realise. The wonderful thing about these – I'm gonna quote a few for you throughout the talk – is if you're ever wondering about something and you're like "oh I need to learn more about that" is you can Google for WCAG and then the number and you will be easily able to access a wealth of free information on that topic. 

To give you an example you probably already know I'm going to talk very briefly about alternative text. So my expectation would be most people usually, especially in a public sector would have some idea of what this is already and you're probably already doing a reasonable job of it, so it's a good place to start. Also it has the convenient number, 1.1.1, so it's super easy to remember. 

So the idea here, this is a WCAG requirement that if you have images and other non-text you must include a text equivalent. So for example, consider this hypothetical web page at the top. "Please select from the following options" and then I have a selection of group to choose from. Now with my eyes I can easily see these specific items of food and then I can choose which one I would want, but assuming that I was for example using a screen reader or other assistive technology and I was having this read out to me, I wouldn't be able to see the images. This would be presumably something like this, which works just fine. This would be a good experience. Unfortunately not everyone does this. 

Now again my experience in the public sector has been most organisations are aware of this and they are taking steps to fill alt text. However, in reality, 76% of public sector websites are falling short in some way. One of the most common ways is either they don't specify alt text in which case the poor user gets this, or more commonly they specify really bad alternative text, something like this. It's three different examples here, but imagine these. So imagine you're choosing from these options, the first would be some technical name that someone has clearly copied, maybe it's the name of the file or something on their desktop and they've not really thought about it. So "pear-img-72" might mean something to you, but it's not very accessible. The second, well, it's not the end of the world, but it's somewhat overly descriptive and inappropriate in this context, and the third one, even though it's technically correct, labelling that third item a "Macintosh" probably has a different meaning for most of your users, and it could be considered ambiguous or confusing. So really just getting in the head of someone using these kinds of technologies, I'm gonna show you some specific ways to do that, can help you not just comply with the letter of the law but also really appreciate how to make a great accessible experience. 

So that was standards, levels, and success criterion. We're gonna move on to the meet of today's talk, and that is going to be on how you understand the law and actually comply with it. 

Abilities and barriers

So what we're going to do is we're going to look at a list of abilities and barriers. This is a convenient way of breaking up accessibility into sections that you can kind of get your head around, and we're gonna look at each of these four in turn starting with the easiest, see if you can guess what that is, and working our way down to the hardest. I should clarify, that's actually the easiest for you, because we looked at your site specifically. 

Auditory

We begin with auditory barriers. 19% of the UK suffers from hearing loss. But the truth is chances are you've already used accessible technology here every day. That 85% of Facebook video is watched without sound for example, that is accessible technology. Because you may well have hearing but you may well choose not to use it, and this is the pattern you'll see with a lot of accessible technology, it's not just for people with a quote-unquote disability, it actually improves the overall use of the site. 

So the requirement, as you can guess, is for captions, because that's what you probably see when you're using a Facebook video, right? If you're watching a movie trailer now on Facebook, it's pretty much 95% certain to have captions, and for good reason. Now under WCAG this is a requirement, so you need to take all of your video and your audio, well there will be some caveats in a moment, but your video and the audio and you need to either add captions or you need to add a text alternative. 

We tested at first 100 pages of all of the NHS Trust, universities, and UK councils, and in that sample we found that 21% of those websites were failing to include captions or a text alternative where they were necessary. Now we know the actual number will be higher because we only tested the first 100 pages, and chances are there are videos tucked away in the recesses of your website you don't know about. Anyway, so captions are fine. Another alternative would be a text alternative and this is actually my personal solution for a lot of things. So say you've got a podcast, right? This happens to be a podcast and a video, so a text alternative in this case is a transcript that's been included below. Now again like with Facebook video, this is great for accessibility, this is actually great for your users, this is just a really good user experience. Personally I like to be able to, for example, watch a webinar and then have a transcript of it later, and then of course in case you're wondering yes, there will be a version of this webinar which will be accessible in that way provided for you later. But it's useful not just for accessibility but also because you might want to look up something in that text and maybe chase down a reference. 

A brief note on the subtleties of subtitles and captions, because the two are often confused. Under the law you need to provide captions. Now subtitles are where you narrate the text of people speaking. So for example here, Anna is saying "what a beautiful day." Captions are where you're narrating the sounds that would add contextual information to that scene, so in this case a train approaching probably makes a bit of a difference. 

Now what video and audio is covered? Well all pre-recorded video and audio that is hosted after September 2020, so you do have a little bit of time to work on this. This doesn't affect video and audio posted before then. Live video and audio you will be pleased to hear has been excluded on purpose. It's not part of WCAG, that is a specific EU exception. And it will definitely make your life a lot easier. 

Cognitive

So that was auditory, moving on. We're gonna take a look at Cognitive. As a headline Cognitive covers a whole wealth of conditions but here are three: 10% of the UK are dyslexic, 3.6% of UK boys have ADHD, 7.7% of the UK speaks English as a second language. And there are many many more. 

Simulating this is difficult, but it turns out there are useful tools, and I'm going to show you one called Funkify which can help you understand, appreciate, and empathise with your users. Now this is at all nothing to do with us, so forgive the plug but it's not for ourselves. This costs about three and a half Euros a month, or – guessing the exchange rate – I think that's about £27,000. 

We're just gonna take a look at using Funkify to browse and example website. So I'm gonna open my browser here, so if you instal Funkify this is a little icon in the top right corner. I click on this and it gives me a whole range of experiences for disability that I can simulate. So I can for example look at the screen with blurred vision or with colour blindness which is quite cool. 

So what we're gonna look at right now is we're gonna look at dyslexia. And this is one of the most common conditions, so it's definitely worth having a proper appreciation of it. If you've never seen it before, dyslexia causes essentially the order of the letters or the structure of the words you're looking at to become jumbled up and to continuously change. So this has the effect of making text very hard to read. I recommend you try and read what's on my screen right now, it is possible, but you kind of have to think about it, it's just much more demanding on you. And so you can imagine if you had this condition that working through a website, you really start to appreciate certain design considerations and things that make your life easier or sometimes harder. 

So for example in this case, the fact that this text here is larger makes it so much easier for me to understand what I should be skimming first. I can see this heading. It's clear to me this is related to the image, I'm gonna try to make sense of that. On the other hand, the images which don't suffer from this scrambling would be really useful as a way of guiding me through the site, but in this case the images aren't entirely obvious. So I'm looking at individuals and it's a picture of a passport. Now it's not immediately apparent to me if I just look for the picture that would have anything to do with individuals. So I have to kind of focus a bit here and really pay attention to understand its page. 

Now another condition that I should draw attention would be distractibility. So this could cover things like ADHD. Now what we have here is a little web game developed by WebAim, it's made in Flash but it's still worth checking out. What they do is they give you the opportunity to play a game where bombs are falling from the top of the screen and you have to catch them, but at the same time you have to perform various tasks on a fictional website. This it turns out is very difficult, because it's extremely hard to divide your attention between this interactive experience on the right and the tasks you are trying to complete on the left, but I'm just gonna show you me playing a brief section of that. 

So you can se the character catching the bombs on the right hand side, I'm using the keyboard to try and catch those and I'm looking in the top right corner and I see these simulation tasks. So I need to click on the centre director's email address. Now I'm looking on the left and I'm trying to browse this page and oh dear I've messed it up. Because as soon as I'm reading the page of course I can't pay attention. Let's look on the contact us page. I've got a director, yeah I clicked the director's email address, I've done that, great. Now I need to complete the site's survey. I've found a survey and I'm trying to click on these options but they're not working, I don't understand why. I'm clicking, I'm clicking, nothing's working. 

It turns out I had to click on the radio button to the side of one of those options and that actually worked. But if I clicked on the text of the radio button, it didn't. Now that might seem like a casual annoyance and usually it is, definitely a bad design practice, but in this case it was so much harder for me to manage that because of the level of distraction I was undertaking. 

Now in WCAG there are an absolute tonne of checks, we couldn't possibly get through all of them today, covering this and many other areas. But just to give you some kind of headline areas to consider. 

Readable is a guideline which covers a whole tonne of things, but specifically you're looking at things like avoiding the use of unusual words or explaining them when you do, using generally simple language so that people can kind of understand your pages for example if they have dyslexia or any other cognitive impairment. And simple things like just actually saying what languages are used so a computer or assistive technology can help them if need be. We looked at these and we found at least 54% of public safety websites are failing to do any of them. 

It's the same for the second check which is looking at predictable aesthetics of your interface. This is things like using a consistent navigation structure. Now this is kind of good practice, you should be doing it anyway, but we found at least 49% of public service websites were failing to do so. And bear in mind in this case we can only check for some portion of both your web pages and the criteria, because some of it to be honest is just subjective, it's human judgement. 

The best solution to this generally is to just keep everything simple. GOV.UK who do a fantastic job here in pretty much everything, they make their website incredibly straightforward and that is a fantastic solution for all these problems. I'll also say we'll be coming back to GOV.UK but you should familiarise yourself with them because GDS who are responsible for that website are also responsible for policing this law. 

Motor

So let's move on, that's cognitive. Motor, so 12% of people have tremors or some other impairment. The easiest way to think of it is to assume that any input device you use can't be used by everyone. So for example not everyone can use a keyboard, not everyone can use a mouse, not everyone can use a touch screen. 

The most extreme example I'm gonna take is Stephen Hawking, who had an incredible career and was able to create many defining works of literature and science and he was able to do so with the most limited of motor control. And this is actually a fantastic testament to what accessible technology can achieve and one of the reasons why it's so important. But it's worth considering how on earth did he do that? 

The massively simplified version is that if you want you can reduce using technology to pretty much three buttons. And this is what we're going to do now, we're going to take a look at some sites with just three buttons. This is often known as tabs navigation, so you can use the Tab key to go to the next site and you can use Shift and Tab to go to previous and you can press Enter to select. 

So I am going to take my favourite website – again GOV.UK – and we're gonna use tabs here. So I'm just gonna press the Tab key, and I don't know if you can see that, but there's a highlight in the top left corner, skip to main content, and if I press tab... for some reason that didn't work, let me try that again. There we go, if I press tab, we get the logo highlighted and I get the search box highlighted. So I can press Tab and step through all the interactive parts of the page, I can press Shift and Tab to go back. And then I can press Enter to select something, and it's that simple. 

Now that seems obvious, but that was actually about the best possible experience you will see in the history of Tab browsing. I don't think I've ever come across one anywhere near that good. I highly recommend you try this on your own sites, you will probably want to be sitting down when you do. Nearly everyone will discover massive, massive, issues. 

I'm gonna give you one example. So this website is available in both English and Welsh, and when you load it starts with a popup window that asks you which of those two languages you would like to use the site in. So assuming that I'm using an accessible technology like we just saw, and I want to select the English button to access this site. How many times do I need to press tab to reach that button? Well I press it once and I don't actually see anything highlighted on the page. So I'm gonna press it again, and I don't see anything. I'm gonna press it again, and we'll skip ahead because you have to press it 58 times before eventually that English button in the modal is selected and then you can finally enter the site. 

So this is a terrible experience, but it's quite surprisingly common. There are two WCAG requirements here you need to meet. The first is that your focus, which is the selected area is visible, and this should happen by default. This is actually built into your web browser, it's built into your web sites. The only reason it doesn't happen is because you've chosen to turn it off, and unfortunately 86% of public sector websites actually do disable it, so that's not good. The second thing is the focus order should make sense, so know that a computer can't analyse this, although it is very obvious to us, we enter that site and I don't think it's acceptable that I should have to press the Tab key 50 plus times to access what is clearly the most likely first intent of a user on a page. So both very important, relatively easy to fix. 

A new requirement of WCAG 2.1 which did not exist before covers the orientation of your device. So you cannot force or require a user to have a specific orientation – so portrait or landscape – for your webpages. This works all the way down to mobile phones with the size of an iPhone five, which is essentially 320 CSS pixels wide, that is the WCAG standard for the smallest device you practically need to care about. And 62% of public sector websites fail to do this in one way or another, usually because their responsive designs are broken. 

Another new requirement, and if you're considering this in the frame of motor impairment, this is a really big deal, is automatically populating fields wherever possible. This is something that is great UX best practice anyway, and you should be doing this. But I'm sure you've come to a web form before where something like this happens, where it says can you automatically need to fill in my contact information and on my phone here I can press a button and it just types in my name and my email and whatever else for me. 

What you may not know is this is actually an international standard and it's really easy to do and now you have to do it under WCAG. So to give you an example for the more technically minded it's really simple, you're just gonna add a little bit of code like I've shown here in yellow. "Autocomplete=email" would fill in the user's email if it's known. "Postal code" would, see if you can guess, fill in a postal code and "tel-national" is just an example of a more tricky one, that would take their phone number and make it international for you and fill it in the field. 

All that's actually really easy to do, and really powerful. Imagine how much laborious work you are saving your users, especially those with motor conditions by doing this, and again 87% of public sector websites are not. 

PDFs

So that concludes three of the four areas, and you might well think well let's see, we're about half an hour in so this should be easy, what's left in the final point? Well before we get started with that I want to take a brief tangent into everyone's favourite topic, PDFs. 

Now I have to do a section on PDFs, it doesn't really fit anywhere else, but they're simply unavoidable because firstly the public sector has so many of them, I think even GDS said they produce 10,000 a month in sales on their own sites, and they're trying to avoid PDFs. But they're so common, but also because they're awful. We found 98% of the PDFs we tested for the public sector failed the most basic checks. We didn't even bother running the even more advanced check, it wasn't really worth it. 

PDFs are, I would say, basically Flash for print, which is to say that they're useless on mobile, they're inherently inaccessible unless you work really hard and unfortunately they are made for the creators, not for the consumers. The primary benefit of a PDF is you can take something you've already done for print and you can share it. And there is some value to that but from a consumer's perspective, they don't work as well. 

I want to show you a few quick examples. This is from a PDF my company actually made or was in the process of making when we saw this. So we had in the corner of our page, we had our logo as you see at the top, right? But the way that our art software had kind of exported that was as these three separate regions so there was the kind of glyph if you will, the symbol, and then the letter S was in part of it, then the I and the L was in another section, and last of all the K-T-I-D-E was in a box of its own. Now you couldn't see this because this is just the nuance of how the artwork was created, but it would cause us a real problem when you're trying to actually make that accessible. For one, you'd be trying to provide alternative text here and you're kind of stuck. Do you put alternative text of the letter S in this one box, I-L in this box and KTIDE in this one? That results in a terrible and fundamentally inaccessible experience. The correct solution is to combine them but that either requires modifying the original art asset or modifying the tag structure of the PDF, which is not fun and it's not quick. 

So that's one example, another would be this PDF here. This PDF, just a brochure for a university I think, looks good. If this was printed this is a good piece of design for someone to consume. But for accessibility, the PDF is fundamentally pretty much everything you shouldn't be doing. For one, there's no clear order here. It turns out by default this PDF will read the text you're seeing here. I don't think you can see, it's number one where my mouse is, but this is the first thing that will get read out. The second thing that will get read out is this image which doesn't have any text in it, and the third thing will be under here, and it is part of this map containing London, and then wherever it is, now this part of the map and then up to six, which is where you see the title of the page, which is probably what you thought would come first. So this would be a jumble, if you were having this read out to you this would be all over the place. If you're trying to make it accessible you have to provide an alternative text, and in many cases the PDF hasn't even figured out where the text actually is. This is very very common, it's extremely difficult to get around these problems. It can be done, but honestly my advice is don't bother if you can at all avoid it. 

As far as mobile experience goes, well yeah, PDFs are basically awful. If you've ever tried to view a PDF like that yourself on an iPhone, you know how bad that is. You basically can't make a good mobile experience and my understanding for WCAG 2.1, that's a requirement, so I'm not really sure how PDFs are ever really meant to be accessible as defined by WCAG 2.1. 

If you absolutely have to use them though, and I know of course they can't be avoided in some cases, a few things to know. Firstly, before September 2018, PDFs are considered essentially archived, you can pretty much ignore those. You don't need to make those accessible. You probably should, but you don't have to, as there's an exemption. You still might be asked to provide them in an accessible format on a case by case basis. 

If you have the choice, if you're creating a PDF through something like Word, you want to export it while understanding the export technology natively where possible. So for example, a lot of people don't know this, but Word actually contains an accessibility checker inside Word, which is actually surprisingly good. You can actually make accessible Word documents and as long as you do that, then export them into PDFs, they'll be okay. 

And then lastly I'm afraid you're gonna have to get Acrobat DC, and a whole lot of time because it's just, yeah, there's no way around it really, it's a pain. 

Don't take my word for it though, GDS who are policing the law themselves have posted repeatedly about why you shouldn't be using PDFs and you should just put everything in HTML, and I would say more succinctly, I would just say PDFs, kill them before they lay eggs. The consensus pretty much on this one is PDFs bad, try and avoid wherever you can. 

Visual

Right, so back to our four abilities and barriers. We only have one left to cover, how hard can it be? Well visual impairments affect about 3% of the UK with significant sight loss and about half a percent are legally blind. But of course, somewhere around 50% of all people have some visual impairment such as shortsightedness. You're also considering people for example on maybe a mobile phone who are reading in the sun, so there's a whole tonne of environmental considerations here, but visual creates its own special set of challenges because it affects pretty much everything, so we're gonna break it down into these three key areas. 

Magnification

We're going to start off with magnification. So it is a requirement of WCAG that people can zoom in to read things at 200% of their regular size, so they need to be able to essentially double the text size one way or another. Now you may recognise something like this where a website has a series of letter A's often written in larger sizes, and the idea is that you can click on one of these and you can enlarge the font size of that page. Well I have news for you, if you do recognise this, you are not a young person. But the good news is we don't need these any more. They've been made redundant because we have responsive design, which is wonderful. 

So responsive design allows us to build a page like this example from CNN and I can zoom into it and it still works, and I can zoom into it again, and it still works, and I can do this as much as I like. This results in a great experience for mobile, tablet, desktop, different screen sizes, etc. And therefore all of the requirements for that part of WCAG are completely taken care of. 

I'm kidding, obviously they're not. The problem with this is that surprisingly a large number of public sector websites are still not designed for mobile, they're still not using responsive design. So to give one example, the University of Bath who has an excellent website that is generally very accessible and well-designed and looks great on mobile and other devices that you see on the left, for some reason their home page has not been updated yet. And so as a result they're actually failing in this requirement. Now we found 67% of the public sector websites were in a similar position. 

So you need to support all the way down to an iPhone 5 without scrolling in both directions, and you need to support portrait and landscape, and it's not just that it's a good thing for you to do for your user experience, it's a legal requirement under WCAG as well. 

But even then when you do all of that you still have a problem, because it turns out 36% of the public sector websites then add a piece of code that turns off pinch to zoom. So you've already done all the work, you've got this ability for people to zoom into your text, and everything is great, but then a little bit of code like what you're seeing here that's highlighted in yellow will undo nearly all of this great work because you've just turned off the ability for someone to take advantage of it. There's literally no reason to do this, you should just remove this code, there are a few variations of this code, but it's really really easy to fix, and like I said, over a third of websites are doing it, so please don't. 

Blindness

Right, so onto our penultimate point, which is blindness. Now you would think that blindness would be the hardest issue to deal with, it's actually the second hardest, but we're gonna take a little bit of time here, 'cause a lot of people don't really know how this works. So you've heard the term "screen reader" but maybe you've never used one, or you wouldn't even know where to start. 

I highly recommend that you do actually take the time to use a screen reader which is a technology that allows you to use website or your computer without having sight, but it can be quite intimidating. So we built a free toolbar, which I'm gonna show you now which allows you to experience a web page as if you were using a screen reader. It's very much a simplified screen reader, but it will give you the idea of how a page works when you don't have the advantage of sight. 

So as an example is I'm going to open this page, and click on an icon in the top right corner here. So this is the Silktide screen reader simulator. I'm just gonna turn on audio. 

Essentially what a screen reader does is it reads out the individual parts of the page and it lets you walk through them and select them. So it's similar in principle to what you had earlier with tabbed browsing, but there are differences. It won't select the same things, because tabbed browsing was only designed to let you select what you want to click on, but with a screen reader you need to read everything, because you may not want to click on some text but you definitely want to read it. 

So to give an example I'm just going to step through a few of these buttons. So here's there's actually a link that you can't see on the screen, it's invisible, it's designed for people using a screen reader. So we've only clicked through a few links so far and you can already see this is kind of exhausting, and no person using a screen reader would normally go through what I'm doing. 

So what you do do is you use a range of shortcuts. Now there's a few of them here, and again all screen reader's have these, they're designed to help you navigate through the page more quickly. So for example, a common one is a "heading". So this is literally just reading the heading that is currently selected, so "BBC News navigation – heading", "Divers humbled by Cornwall jellyfish encounter – heading", and so on. So pressing H steps through these, and if I press Shift and H I can go back up. 

This is a very common action for someone using a screen reader, it means they can skip through a page much more quickly. Think about how you do it when you have your site, you look at a page, you can see headings, you can go next next next, you're skimming through them, this is the non-visual equivalent. 

The other shortcut that people definitely rely on is using, is navigating to the next link. So if I press K, I can skip through to the share link, I can skip through to this link in the middle of the content, and then I can skip through these additional links to other related articles. 

Now this is just a very quick superficial overview of how a screen reader works, but if I come out of here, I want to show you how that affects you and WCAG. 

So let's take a fictional webpage here, see if you can guess the problem with this page. I'm being asked to choose one of these three options. But what we have here are three links with the same text. So if I was using a screen reader and I was stepping through the links which is very common because I want to hear the things I could choose between, what I'm going to hear is "read more", "read more", and "read more". And this isn't particularly helpful, in fact it's pretty fundamentally inaccessible. It's very hard to understand what's going on. 

Because those links may make sense to you visually when you can see them in context, when you can't see this is this link is below that piece of text, all you have is the link by itself. The correct solution to this usually is to provide useful link text that makes sense in isolation, and to give you a really simple example of that, what you could do is you could just make the titles of those options a link. That actually makes perfect sense, it's actually simpler, and to be honest probably represents what a lot of you users are gonna do anyway which is click on that title. 

Another WCAG requirement is to make sure that a screen reader can actually understand your forms. We found 90% of public sector websites have forms that fail to do this. The most common of the many flaws here would be to use what we call placeholders. 

So the form that you're seeing at the moment is using a placeholder, and the placeholder is text inside the field. So you can see it's saying "email" and "password", but that text is written inside the field. Now if I compare this with using a label, a label would appear outside of the field. I am simplifying a little bit for the purposes of expediency, but the important thing here is you need to define specific text label for your fields and you need to link that label to your fields. This allows accessible technology like screen readers to say you are inside an email field or a password field, and that way the form can be used. If you fail to do this, all of your forms essentially become "input text field", "input text field", "input text field", "button", and that's completely inaccessible. So you really need to make sure you're using labels correctly. 

The other reason you should avoid placeholders is because they're just terrible. If you take this example here, just forget blind users for a moment, if I fill in this form on the left hand side, what you see here, I can no longer see what my fields are. This isn't good. A lot of times these fields are automatically filled in and I don't even know what's been automatically filled in on my behalf. So again, using a proper label above or to the side of your field is vastly preferred and pretty much a requirement now under WCAG. 

Contrast

Let's look at contrast. So contrast is our last point, and I've saved it for last for a reason. Because it is definitely one of the trickiest. 

We'll start off with a quick comparison of old and new design styles. What you'll see on the left here is a Google web app from some years ago, and you can see it's got a kind of retro design style, it's quite old fashioned, blue links and ugly text and so on. On the right hand side is a much more contemporary equivalent where it's all been redesigned to be soft subtle greys and beautiful backgrounds and so on, and as you can probably guess this is fundamentally totally inaccessible. I can show you exactly why. 

This is what a lot of people with a visual impairment would have seen on that screen, which is to say not a lot. Although it is still a little harder to read what's on the left, it is clearly legible. The right hand side has pretty much evaporated. 

Now under WCAG there is a requirement that the contrast between your text colour and your background colour ranges between three to one and five to one depending on the size and the boldness of the text. We found 87% of public sector websites were failing to do this. There are a number of ways of ensuring that you do, there are tools like this. If you Google for "WCAG contrast" you can simply provide the colours that you're considering using or that you already use, and they will tell you if they are complying. 

I would recommend that you don't try and just judge this by eye, a lot of people think that they can, but to give you one example, which of these two pieces of text here, the white or the black on that magenta, which is easier to read? Because as you probably guessed, it's actually the second, but most people would normally choose the first. Instinctively the white on the magenta seems easier to read, but actually under WCAG and a specific mathematical formula that they've calibrated on this, the second example is actually more legible for people with visual impairments. So this is really hard for you to intuit and you really shouldn't be bothering, you should be using tools to help you. 

Okay, next point, using colour generally as a means of distinguishing anything is pretty bad. And to give you one very focused example, that 85% of public sector website failed to do, when you have a link you want to make sure that the link is not just distinguished by colour. So you can probably see here that the text the link is in blue and is a link, but if I had a common form of colour blindness, this distinction would be very much reduced, and whilst you still might be able to just about make that out, imagine how hard that is to read in the midst of a large substantial block of body text. So what you want to be doing, or the easiest solution, is you want a non-colour distinction. You want something like an underline. The cliche is there for a reason and I know a lot of people don't like is aesthetically, but the advantage it brings is it makes it incredibly clear where text is a link and the surrounding text is not. 

Now to clarify that slightly, here's an example from our own website. And what we have here are some links at the top of the page, and you'll notice these are not underlined. I do not need to underline all of my links under this law. What I need to do is I need to underline my links or otherwise make them distinct when it's not clear what part is a link and what part isn't. And if you look down here where my name appears, it says "by Oliver Emberton" and the "by" is just regular text, but the "Oliver Emberton" is a link. Now it would not necessarily be apparent if Oliver Emberton was written in a different colour, it would be easy to miss that. To be honest it would be easy to miss that even if you were fully sighted. So adding the underline just makes that relationship more explicit, and again we have around 85% of the public websites that don't do that. 

You can guess that if you've got forms like this that they are fundamentally inaccessible for the same reason and it's a new part of WCAG 2.1 that you need to provide strong contrast for non-text, which means none of these weak grey borders on your form fields. 93% of public sector websites are not doing this. 

The same requirement extends to icons, so for example if you have star ratings like this, these would fail whereas these would pass, simply because the contrast on the yellow and the white is insufficient. And this even extends to things like infographics and charts where for example this chart here is actually fundamentally inaccessible because if you can't see the colour or your contrast on that colour is so low that you basically can't interpret the chart. The easiest solution is to just add percentages or some other, maybe a table beneath the chart, some other way of experiencing that data. Alternatively if you want to go through the hassle you can redesign the visual to ensure that the colours that are adjacent to each other are strongly contrasted or separated. This can be a lot of work but it is an alternative. 

So yes, told you it was easy. That was nice and straightforward, that's all four main sections we wanted to cover. 

What to do about it

Just wrapping up briefly with a few practical steps on what you're going to do about it. Mostly: don't panic, you want to measure where you're at and you need to, and this is crucial, measure yourself against WCAG 2.1. If you've done this kind of analysis in the past, chances are you tested against 2.0, most tools, most companies, even most books don't cover this. In fact, I'm literally writing the only book on WCAG 2.1 now because no one else has bothered. So make sure you're testing that standard. 

Next, focus on your biggest issues, start with level A first, publish an accessibility statement. It's easy, it's a great first step, and you can improve it as you go, and monitor your site and keep improving it. You will probably never attain 100% compliance across the board on every page if you have 30,000 pages on your site, but if you build a process and you set some systems up and you make sure everything is being taken care of. 

A brief word on your approaches for testing, some people like to say you should do manual testing, some people say to do automated testing, disclaimer, my company does automated testing, so I've got a bit of bias. But the truth is you need both. Manual testing is great, it means you get some experts to use your site with real screen readers and other accessible technology. They will fully test one part of your website incredibly well, you will get a level of insight that is profound, you should absolutely do that. Especially if you're doing a redesign or doing new components. But it's not practical to do that for say, tens of thousands of pages across your entire site. 

With automated testing, what you can do is you can test your entire site and you can automate that testing and you can be alerted when new issues occur, and so by combining those two approaches, it is possible to achieve pretty much perfect compliance around the clock, but honestly any one of those by themselves, you'll find yourself falling short. 

I would also recommend you tell your organisation use Tabbed browsing, seriously, load your website, use Tab, use Shift + Tab, Enter, that will tell you a lot. You'll probably want to sit down while you do it. And you should use a mobile screen reader. They're free, you already have one assuming you have a phone. Just Google for "iPhone VoiceOver" or "Android TalkBack", it's worth it, use your site, you'll probably again be horrified, but it's great. If you can't be bothered with those, Google for "Silktide toolbar" and we've got our own free one, it's simplified but it'll give you an idea of your experience. 

Teach your team. Get your designers to use contrast and fields, get your editors to use alt text links and captions, and get your developers to buy my book because what they need to do is very very long. 

That's really what I wanted to cover today: the five stages of becoming accessible. Hopefully I've helped take you from denial and maybe somewhere through anger, bargaining, depression, and one day we can all collectively achieve acceptance.