Simplified guide to the Web Content Accessibility Guidelines

Stop and think of the things that build a sense of place in your built environment. The rattle of keys in the doorknob, the smooth surface of the railing, the squeaky stair, the low hum of the refrigerator’s condenser, the light and cool air when you open the fridge door, the fan whirl and startup tone when you start your computer.

They’re sounds and sensations that, after a while, fade into the background, let us know everything’s working as normal, and keep us from being startled when someone walks in the room. And when they’re missing, when the power goes out and everything goes strangely quiet and dark, you notice them for their absence, like a silent siren alerting you something needs to be fixed.

Build your apps and websites around accessibility standards, and they’ll feel right at home for everyone, humming along as expected. Neglect standards and screen readers, and your app might look fine, but its silence—or misplaced sounds—will betray your oversight, and keep the people who need your product from being able to use it.

Here’s how.

A quick summary of WCAG:

• Use text for everything
• Design your site to be responsive
• Make everything stand out
• Build for keyboard shortcuts and more
• Outline your content
• Sometimes slower is better
• Lend a helping hand
• Do things the expected way

An intro to the Web Content Accessibility Guidelines

It all started when Tim Berners-Lee published the first website from his CERN workstation in 1990. Like Gutenberg and his printing press, the World Wide Web transformed how content was published. But an information highway without standards would swiftly descend into chaos, so four years after publishing that first webpage, Berners-Lee helped organize the World Wide Web Consortium (or W3C), as a standards organization. It defines what makes valid CSS and HTML, sets internalization standards around Unicode, and more.

It’s also what defines and updates the Web Content Accessible Guidelines, with WCAG 2 as today’s standard for building accessible websites. The standard was built to “explain how to make web content more accessible to people with disabilities,” in the W3C’s words. As the Mozilla team distilled it, WCAG is focused on making your site “perceivable, operable, understandable, and robust” for all.

You should take the time to read the entire WCAG 2—it’s a critical part of ensuring that your site is built well for all of your customers (and is compliant with accessibility laws in your jurisdiction, too). But to get started, here are the basics distilled into easy-to-follow guidelines while building your website.

All quotes below are copied from WCAG 2.1.

Use text for everything

“Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.”

You know you should add alt text to every image. Don’t just add any text, though. Describe what the image shows in the alt text, enough that someone with a vision impairment can understand the images as well as anyone else. If text is included in the image itself, write that out fully as well—something that’s helpful for all users, especially if the text in the image is faint.

Images aren’t the only thing to consider, either. Audio and video should include transcripts, and CAPATCHAs and other image-centric tools should include audio or other options that are accessible to everyone. Buttons shouldn’t be images with text in them; they should be HTML button elements, with their description written in real text. If they use icons, make sure they also include alt text (ideally that displays on hover, to help those who can see the icon but don’t know what it means) or aria-labels to tell screen reader software how to describe the icon. And your company’s logotype should also include alt text with your company’s name—good for SEO as well as for screen readers.

Design your site to be responsive

“Create content that can be presented in different ways (for example simpler layout) without losing information or structure.”

Responsive design ensures that your website works well both on desktop and mobile, on small windows as well as large ones. It also helps you build accessible sites, too.

Say someone increases their font size far larger than you thought to test for. If your site’s responsive, with menus moving out of the way in smaller windows, it should also respond to that user’s larger text size needs. Or if someone is using a screen reader, the responsive hierarchy should also mean they can navigate your site as they’d expect, tabbing through your menus and jumping to content based on logically-ordered headings.

Make everything stand out

“Make it easier for users to see and hear content including separating foreground from background.”

Contrast is important—and easy to break when putting text on top of images. Don’t just pick any colors that look good to you. Remember they might not look as distinct on other screens, and check them first on the WebAIM Contrast Checker to make sure they have a contrast ratio of at least 4.5:1.

That applies to color throughout your site, too. Are buttons and scrollbars too faint? Check all of your colors against their backgrounds, and make sure everything stands out enough to be visible. While you’re at it, make sure color alone is never used to convey information; don’t mark a required field in red, say, without also including a “required” text label.

Build for keyboard shortcuts and more

“Make all functionality available from a keyboard.”

“Make it easier for users to operate functionality through various inputs beyond the keyboard.”

It’s not just a power-user move, doing everything from a keyboard. It’s a faster, more accessible way to use your computer. At a minimum, your app and sites should respect the default keyboard shortcuts like copy/paste, page up and down, and so on. If possible, you should build in more, with shortcuts like Gmail that let you do almost everything in the app without touching a mouse.

That way, no matter how someone is using your software—with a mouse or touchpad, through a keyboard or screen reader, or with a workflow automation tool—it will work the same for them as for anyone else.

Sometimes slower is better

“Provide users enough time to read and use content.”

“Do not design content in a way that is known to cause seizures or physical reactions.”

Ever seen a message flash by your screen quicker than you could read it?

A screen reader tool couldn’t have read it in time, either.

You don’t want notifications and other temporary items to hang out in your app for longer than is needed—but don’t make them go away too fast, either. Only show a loading screen, say, if the average user would see it long enough to read it. Make notifications disappear on their own, but only after they’ve been visible long enough for anyone to read them–and then consider adding an option to increase the time if needed. And while thinking about fast things, don’t make things blink and strobe, at least without a warning first for those who flashing lights might affect.

Outline your content

“Provide ways to help users navigate, find content, and determine where they are.”

Site maps are a somewhat-dated way to tell search engines where each page on your website lives—but the idea behind them could help your customers, too. They need a sense of place to find their way around your website.

You can build that with breadcrumbs, which list a short sitemap at the top of a page, showing, for example, that the help page you’re on lives at Home > Help > How to create a document. On longer content, you could include an outline at the beginning, so people can quickly jump to the section they want to read.

Lend a helping hand

“Help users avoid and correct mistakes.”

Ever typed your password in the username field because they were in the wrong order, or deleted a file without meaning to because the instructions weren’t clear?

WCAG section 3 suggests what could be a golden rule of software, that everything should be easily correctable. If people fill out a form and, say, their email is invalid, don’t simply highlight the offending field in red. Add text that says what went wrong—and how to fix it. If it’s been too long and the user is logged out but doesn’t know it yet, prompt them—in text, again—before they click save and inadvertently lose their work. And when things really break, when users hit a 404 page or get a 500 error, include an option to email your team to get hands-on help. Do that every time, and you’ll both help customers fix their own mistakes and let them know that your team cares.

Do things the expected way

“Make Web pages appear and operate in predictable ways.”

Then, perhaps, as the web developer’s equivalent of the physician’s “first do no harm,” WCAG reminds us that the default way is typically the best.

The basics of accessibility aren’t all that complicated. If anything, they’re the same best practices recommended for building apps and websites. It’s just this time, instead of thinking of them as an ideal way to build, think of them as the only way to build, as rules, not guidelines, for building successful apps.

A single H1 headline is best for SEO and accessibility. A correct hierarchy of H2 then H3 then H4 headings helps everyone navigate your website better, whether skimming visually or aloud. Using default HTML elements for buttons and lists instead of custom-styled DIVs makes your code clearer and easier to maintain for developers, while also making it more consistent for users. Making your content reflow well makes it mobile and zoom-friendly at the same time. Adding descriptive alt text to images makes them easier to discover with screen readers and search.

Do things the expected way, and they’ll work better for everyone, whether they’re looking at your site or listening to it through a screen reader.

Start small. Build from there.

With a bit of practice, building accessible sites from the start will become second nature. You’ll fire up your screen reader to see if anything needs to be fixed—and will be pleasantly surprised to find that it works perfectly since you built standards-compliant from the start. You’ll make accessibility testing a key part of your team’s development workflow to start shipping every new feature accessible from day one.

You’ve got this. We’re going to build a better web for everyone, together.