Accessibility

Introduction

The Web can be accessed and experienced in many different ways; if you have content or a service that is available on the world wide web, then you have a responsibility to ensure that is as accessible to everyone. If you don’t, this could be seen as discrimination under the Equality Act 2010, in the UK at least.

Web content can be consumed and interacted with in many different ways by users, for example:

• Screen readers are a type of assistive technology which will read aloud the content of the page and provide the user with unique, often keyboard-based, methods for interacting with the content.
• Dictation software allows the user to speak commands to their device in order to interact with it, rather than using a mouse or keyboard.
• Reader mode is a feature in many browsers that allows the user to strip the page down to a more basic, text-only layout to aid readability.

In addition to this, we have little to no knowledge of the user’s context as they browse: their viewport size, their network quality and speed, their confidence and/or ability with digital technology to name a few.

For these reasons, it is vital we design and build inclusive experiences that are flexible and resilient enough to adapt to our users and the technology they’re using to access our services.

Guidelines

The Internet standards body, the World Wide Web Consortium (or W3C for short), maintains and publishes a set of guidelines for producers of digital content to grade their services against, known as the Web Content Accessibility Guidelines (WCAG). At the time of writing, WCAG 2.1 is the latest version of the guidelines.

There are 3 levels of compliance: A, AA and AAA, with “AAA” being the highest and “A” the lowest. The guidelines build on top of each other, meaning a site cannot be rated AAA if it does not also satisfy all of the criteria for levels AA and A. In general, aiming for AA compliance offers the best balance between visual design and accessibility requirements.

Discussing all of the criteria and how to meet them is beyond the scope of this post, but the following articles can help:

• Official W3C documentation: Understanding WCAG 2.1
• The Paciello Group: Understanding New Success Criteria in WCAG 2.1

Things to consider

In this post, we’ll cover off some key things to consider and point out some common gotchas, too

Text

• Are you using a legible typeface? The ability to use web fonts has greatly increased designers’ options in this area but it’s important to make sure any fonts used are still readable.
• Is the font size large enough? 16px is considered a good minimum size. Google will now penalise sites in search rankings if they deem the font size to be too small.
• Can the font size be increased without breaking the layout of the site? Users have long been able to set custom font sizes in their browsers, so it’s our jobs to ensure that these overrides don’t impact the usability of the site. Make use of proportional sizing in your CSS as much as possible.
• Line lengths: if you have a lot of long-form content, don’t let your line lengths run too long as this can make reading more difficult. As a general rule, line lengths should be between 45 and 75 characters.
• Colour contrast: is there enough contrast between the text colour and the background it is against? You should be especially mindful of text which is overlaid on top of imagery. Tools such as Contrast Ratio by Lea Verou can help you check this.

Structure

• Headings: all pages should at the very least have a unique and meaningful <h1> element. Not only does this help screen reader users determine if the page content is likely to be useful to them, it also benefits your SEO rankings
• Sub-headings: ideally, the rest of the content will be separated into logical sections, each with their own correctly ordered heading elements – <h2> to <h6>. Assistive technology users can navigate through a page via headings, so well-ordered and meaningful headings allow users to get a good overview of the overall page. And again, this helps search engines to get a better understanding of your content.
• Semantics: developers should be using semantic HTML elements as much as possible. Elements such as <main>, <aside> and <nav> help to separate your content into logical regions which are understood by assistive technology and allow users to navigate the page more easily.
• Layout: if you turned off your stylesheets, would the page still make sense? Search engine crawlers and assistive tech work best when the page is laid out logically.

Navigation

• Keyboard only: can users navigate and interact with your site using only the keyboard? Not only do a lot of assistive tech users not use a mouse, neither do a lot of phone and tablet users. If you have functionality which relies on a mouse hover, you may need to rethink it or provide alternative interactions.
• Cursor focus: if the user is navigating by keyboard, will they know which element on the page is currently in focus? Use :focus styles in CSS to ensure interactive elements stand out when tabbed into.
• Skip to content link: all pages on your site should feature a “skip to content” link that allows keyboard and screen reader users to jump to the main information on the page, bypassing any header and/or navigation. If this isn’t present, the user would have to tab, or have read out, all your global navigation on every page they visit.
• Meaningful links: would someone know where a link would take them if they read the link out of context? Screen readers can show lists of links on the current page to help users find what they’re looking for more easily, so links saying “click here” or “buy now” can be very unhelpful.

Content

• Comprehension: can your copy be understood by a broad range of people? For example, have you avoided jargon and long, complicated sentences? Using Flesch-Kincaid readability tests can help you check this.
• Images: Any images on your site must have an alternative text attribute set which explains the content of the image. However, if the image is for decorative purposes only, then an empty alt attribute should be used as this tells screen readers they can ignore the image. If no alt is present, a screen reader will read out the image’s filename which can be disorientating.
• Audio and video: You should aim to provide transcripts of all audio and video content, as well as subtitles for video. This doesn’t simply benefit deaf or blind users but anyone who may not be able to use sound, for example someone in an office environment. Additionally, providing a transcript of a video means people can choose not to download a potentially large video file if they’re on a slow network or have a limited amount of data. Text versions of A/V content also expose the information contained within them to search engines.
• Animation: Animation can bring life to site but can be distracting to some users with cognitive disabilities or even dangerous to people with photosensitivity. Some browsers and operating systems allow the user to disable motion effects so don’t rely on animation for critical parts of your site.

Useful tools

If all of this seems overwhelming, don’t worry, there are a number of useful tools available to help with checking and maintaining the accessibility of your site:

• Browsers such as Firefox, Chrome and Safari feature built-in accessibility checkers within their respective Developer Tools.
• The Wave Toolbar browser extension can be added to Firefox and Chrome and gives you detailed accessibility reports on a page by page basis at the touch of a button.
• The Inclusive Components blog provides boilerplate, accessible code for common interactive web components.
• Learn to use and test with a screen reader:
  • On Windows, the most popular screen reader is called JAWS, but is expensive to buy especially if it is for testing purposes only. To that end, NVDA is a free-to-download alternative.
  • If you are on Windows 10, Windows Narrator is built into the operating system.
  • Similarly, on macOS and iOS, Apple provides VoiceOver.
  • On Android, Google provides TalkBack
• Microsoft’s design team has produced and excellent guide to inclusive design principles.