Jonny Harper17/02/2020

UK Government have released legislation concerning the accessibility standards of all public sector web content. Our Technical Director, Jonny Harper, explains what you need to do next.

The Web Content Accessibility Guidelines (WCAG) have been in place since 1998 and set out requirements to ensure that websites and the content that they house are accessible to all users. Unfortunately for those with disabilities, people haven’t taken much notice because compliance usually requires some extra consideration during production. It’s a bit inconvenient, but probably not as inconvenient as being a visually impaired person trying to access a website with a screen reader and not being able to move around. The UK Government have noticed that many public organisations could do more when it comes to accessibility so they’ve helped things along. With some exceptions, it’s now mandatory for the existing content of all public sector organisations (I’m looking at you, universities) to comply with the most recent version of the guidelines, WCAG 2.1, by 23 September 2020. Any new content that’s generated should already comply.

I’ve summarised the guidelines below, as well as explaining what you’ll need to do. This post doesn’t include all of the details that you’ll need to review to ensure compliance but it’s a good starter for ten. It will take you about 5 minutes to read and I’ve broken it into the four Principles stated in the guidelines. Now is probably a good time to mention that RV are very clued-up on WCAG 2.1. If you book a new project with us, we’ll deliver it to AA standard.

Principle 1 – All information must be presented in ways all users can access
Principle 2 – All components and navigation must be operable to all users
Principle 3 – Information and operation must be understandable to all users
Principle 4 – Content must be robust enough to be interpreted by a wide variety of agents, including assistive technologies

Principle 1 – All information must be presented in ways users can access

1.1 Text Alternatives

All non-text should have a text alternative.  You should alt-tag your images. You do this for SEO anyway.

1.2 Time-Based Media

If you have video-only or audio-only content, provide a transcript including visual cues and/or audio description. For pre-recorded video with audio you need accompanying captions and audio description. We don’t typically capture it but if you do, live broadcasts also need captions.

1.3 Adaptable

Make sure your content can be presented in a simple way without losing information. This means you need to build a website with a logical structure and a clear hierarchy of information. You’ll need to think about this from the design stage. 

Achieving this is for a developer to worry about but it means they will need to use code to explain what’s on a page. Elements like <header> and <article> denote the page structure in code. Where you have existing content, complying with this one can be a BIG job because each page template essentially needs rebuilding from scratch.

Content should work on portrait or landscape screens, unless a specific display orientation is absolutely essential.

Build your website with a logical hierarchy (image by Gerd Altmann from Pixabay)

1.4 Distinguishable

Make it easy for users to see and hear content.

If any audio plays for more than 3 seconds, the user should have the ability to control the audio, either by changing the volume or by pause/stopping it.

For text, this is quite a biggie. Firstly, the contrast ratio between normal size text and background must be at least 4.5 to 1. For this reason, you should be wary of writing text over pictures. If you’re using larger text (18pt+ or 14pt bold), the minimum contrast ratio is 3 to 1. Your designer needs to know about this and here’s a helpful contrast checker. You should also never use colour as the only means of conveying information.

Users need to be able to resize text to 200% with no loss of function and changing text style properties (e.g. line height, letter spacing) shouldn’t break the page. They also need to be able to browse a 320 pixel-wide screen without having to scroll horizontally.

If elements appear on hover, they need to be dismissable.

Finally, (and you’re already doing this for SEO anyway), don’t use pictures of text.

Principle 2 – All components and navigation must be operable to all users

2.1 Keyboard Accessible

Your users need to be able to get around your website using only a keyboard. Make sure they don’t get trapped somewhere that would need a mouse to escape.

If you use keyboard shortcuts anywhere, there should be an option to turn this off. Your motor impaired visitors use their keyboard to move the mouse. The dash ‘-’ is equivalent to a left click and the number keys move the mouse all over the page. How very annoying if you override these keys with a command of your own! If you’re interested in the key functions like I was, here’s a blog outlining some Windows accessibility features.

2.2 Enough time

Give your users enough time to read and use your content.

If you have time limits, make sure your users can control these. If you’ve got moving content like auto playing background videos, make sure there’s a pause button.

2.3 Seizures and physical reactions

Don’t include content that flashes more than three times per second. You might cause someone to have a seizure. As you’re a university not a nightclub this is unlikely to be an issue, but I’m including it anyway it be safe.

2.4 Navigable

Help your users to navigate. You’re doing this anyway because you want people to find out all about the great content on your site. Just a reminder then that users need clear, helpful page titles and headings, clear context to links and access to a menu or navigation bar on every page. They also need to be able to easily skip between sections and to see what’s in keyboard focus when tabbing around the site.

compass lying on top of map book

2.5 Input modalities

If your content requires users to perform a complex gesture (e.g. pinching to zoom), give them a simpler alternative too. A double tap or long press will do it. If you’ve put text in buttons, all your users need to be able to access these buttons so make sure they are readable by assistant technologies. This is one for your developer.

Principle 3 – Information and operation must be understandable to all users

3.1 Readable

All pages should have a (human) language assigned to them. I know this one’s a bit weird, because you’ve written it in a language – likely English if you’re reading this blog. Assistive technologies are better at rendering text if they know from the start what language it is, so developers just need to make this clear. You also need to make sure that if the language is changed, the user knows this. These are both dev things. You don’t need to start each page with “language = English” or anything like that.

3.2 Predictable

When elements receive focus or input, don’t change their context. A bit tricky to understand, so here are some examples of bad practice:

Focus

You’re a mouse user filling out a form. When you focus on a field, a help dialogue describing the field pops up. This is great for you but it’s not great for a keyboard user tabbing their way through the form. They get to the field and immediately the help dialogue pops up. They didn’t want this to happen and now their keyboard focus is the pop up not the control, so they can’t tab past it.

Input

An example of this is a form that automatically completes when the last field is completed. Your keyboard-navigating users or users with tremors might make a mistake causing the form to be submitted and taking them to the wrong destination before they can correct it. Just put a button in.

While we’re here, you should make sure menus, icons and buttons are consistent and have the same functionality.

Don’t make your users feel like this! (Photo by energepic.com from Pexels)

3.3 Input assistance

When content requires user input, you need to label elements and give instructions. You’re probably doing this anyway but it’s worth reminding your designer so this can be incorporated early on. If users make errors and you know the fix, suggest it. For transaction and legal data submissions there are a few extra rules which I’m not covering here but you should be aware of if they apply to you!

Principle 4 – Content must be robust enough to be interpreted by a wide variety of agents, including assistive technologies

4.1 Compatible

This is one for your developers. They need to build all elements of a site for accessibility and ensure there are no major code errors. If content is updated dynamically, you must notify to users of assistive technologies. A good example of this is using a search bar. The page will update to show five search results. How would you know that had happened if you were blind? Well, thanks to WCAG 2.1, you’d know because your screen reader would be told to announce “five results returned” before reading the rest of the content.

To conclude

Thank you for sticking with me to the end. I hope you found this a helpful overview, and if you’re keen to find out more then here are some useful links:

Accessibility requirement legislation on the government website
Web Content Accessibility Guidelines 2.1

As I mentioned at the top of this article, RV are a safe pair of hands when it comes to accessibility. If you’re a public sector organisation and we work on a project with you, we’ll deliver it to AA accessibility standards. Get in touch to find out more.

I’ve talked a lot about legislation here. It’s important but also, the RV blog isn’t always drier than the Gobi Desert. Check out our other posts by clicking the button below.