A technical perspective on accessibility: 13 WCAG recommendations explained

When you hear the word accessibility you may not be sure how it applies to your website. We’re all very familiar with how things in the physical world may accommodate disabilities, such as elevators, closed captioning, hearing aids, glasses or audio-visual equipment. But how do you translate those accommodations online?

The easiest way is to follow a pre-made set of guidelines.

If you live in the United States, government and federally funded websites are required to be Section 508 Compliant. Internationally, the rest of the world follows the Web Content Accessibility Guidelines (WCAG) of which we are on version 2.1. Ultimately, these use a very similar set of guidelines to assess accessibility.

WCAG 2.1 has 13 guidelines, most of which can be scanned for automatically, but still require a human touch to determine if it is accessible in a useful way. These scans usually check to see if something exists in the front-end code, and a human should verify that the solution in the code actually makes sense.

For example, a tool can scan to see which images have or don’t have alternative text, or alt text. But, it takes a person to make sure the alternative text provides a useful description of what the picture is, or to determine if the picture even needs a description.

At a high level, here is a summary of the WCAG checkpoints and what they mean:

1) Text alternatives

Make sure your website is written using text (instead of images of text), and include a text-based alternative for any visual content. This could be as simple as including alt text to describe images and including transcripts for videos. This lets screen readers parse through the information and read what is on the page out loud, which is essential to visually impaired users. This also allows users to adjust the font size to make it easier to read, or convert text into another format entirely, like braille.

2) Time-based media

This normally refers to videos, where you have a visual and auditory element paired together. Provide an alternative way to digest this content, such as captions that are synched with the video. It’s also helpful to include audio descriptions, which use short sentences – spoken quickly between the recorded audio – to describe what is happening in the video. This lets non-visual visitors have the ability to take in the full experience of the video.

3) Adaptable

All information on your website should be easily ‘read’ by software in different ways, whether that is visually, audibly, tactilely, or otherwise. This would allow screen readers to logically navigate your website, and make sure your site still works when the orientation of the screen is changed. Think about how important orientation can be with mobile screens!

4) Distinguishable

Make it easy to separate information in the foreground and background for all the senses. If you have background sounds in your audio content, make sure the main audio is loud enough to easily tell it apart. If you rely on color only, like highlighting errors in red, add a text cue stating the error in case someone is colorblind or uses a monochrome display.

Avoid playing audio automatically since it can make it hard to hear the screen reader and figure out how to disable the sound. Make sure the contrast between the foreground and background is high enough for text to be readable throughout the site, especially on top of images.

5) Keyboard accessible

You should be able to navigate your website using a keyboard. Many assistive devices are keyboard controlled and provide the flexibility to navigate the site a number of ways, such as summarizing headers and links. If a screen reader user needs to temporarily turn on a cursor to point and click on something, it is not accessible, even though screen readers have that functionality (as a last resort). The goal is to allow the user full control and full functionality without needing a point-and-click device.

6) Enough time

It takes different people different amounts of time to complete a task, so let users extend the time limit, or don’t have a limit at all for time-sensitive content unless it is absolutely necessary. Research shows that providing 10x the normal time to respond is enough time for almost all users. Time-sensitive content includes automatic browser updates, popups asking users to re-authenticate, or a clock ticking down while you book your reservation.

7) Seizures and physical reactions

Some people are sensitive to flashing visuals, even if it’s just for one or two seconds – called photosensitive seizure disorder or photosensitive epilepsy. There are actual thresholds set for TV and computer viewing that should be met, and the general rule of thumb is to not introduce visuals that flash more than three times in a second or take up a 10 degree angle of viewing. Reducing the size of the flashing content can help reduce this, as well as providing a warning and a way to control the flashing content before it starts.

8) Navigable

The user should be able to tell where they are in the website at any given time. The easiest way to accomplish this is to properly label your code for page titles, headings, labels, input fields, and by being explicit about the purpose of links. Since screen readers go through content linearly, include a ‘skip to main content’ link so the user doesn’t need to hear the entire menu read out at the top of every page.

A screen reader user can also scan content by bringing up a list of all the section headers or all the links. This is why descriptive links are important – instead of ‘For the main office, click here’ consider ‘Contact the main office.’

9) Input modalities

In addition to having your site accessible by a keyboard, it should also be accessible by a pointer device, like a touch screen with a stylus. For more complicated interactions, like a drag-and-drop or long press, give users an alternative way to accomplish that task.

With a pinch-to-zoom interface, you might also have zoom in/zoom out buttons. For a drag-and-drop, maybe you have a way to lock the dragging function and disable accidental clicks. Keep in mind that devices like this are normally less precise than a mouse, so use larger link targets where possible.

10) Readable

Do what you can to make sure your site content is readable and interpretable. This includes spelling out acronyms and abbreviations in case they aren’t familiar to the user, avoiding the use of idioms that don’t translate well, and even having phonetic information for characters in other languages.

Additionally, screen readers may mispronounce a word – such as “I like to read” vs “I read the book,” so ideally the full sentence should provide context to what the word really is.

11) Predictable

Try to avoid surprises on your website. Instead, keep things predictable and familiar so users know how to interact with it. Assistive technology that removes stylesheets will present content linearly, so try to group information together so the thing in the left column will still be next to the thing in the right column.

With interactive content, like form fields that automatically move your cursor to the next box and format your input, screen readers may not register the update. Users with screen magnifiers focus on one small part of the screen at a time and might miss the popup that just appeared unless the focus is set properly.

12) Input assistance

If you’re giving users an error, make sure they know what it means and how to fix it. Error messages should be specific, such as ‘Please select a country’ instead of ‘Error submitting form’.

When you highlight the fields that had errors, use visual cues like icons and written instructions instead of just color to show where the error was and how to fix it.

And most importantly, if the user does encounter an error, make sure they can recover from it. This could mean not clearing the whole form to make them start over, or having them confirm all the information they provided before finalizing a purchase.

13) Compatible

Since technology is always changing, do what you can to follow conventions and up-to-date standards to reduce the risk of your website not working with assistive technology.

This is where properly labeling code comes into play, and why a subset of code to help label dynamic content, called ARIA (Assistive Rich Internet Applications), was introduced. ARIA provides a framework that lets you define how assistive technology will interact with additional coding languages, such as AJAX and JavaScript.

In Conclusion…

As you can imagine, there are many more details and ways to fix each of these checkpoints, and a great place to find this information is the World Wide Web Consortium (W3C). They outline all the different success criteria to effectively meet each checkpoint by including examples and information about how each checkpoint affects users.

Accessibility is an easier issue to tackle than it seems, it just takes a little time to adjust your templates and code to keep accessibility in mind, and a little extra coordination to remember which pages have already been tested. The first go is the toughest, but eventually accessibility becomes common sense and promotes clean code. Plus, once your site is accessible, you’ll be helping to take the lead in making a universally accessible internet.