Website accessibility & ADA compliance

gavin’s headshot By Gavin, 1 Aug 2019

You’ve probably heard of the Web Content Accessibility Guidelines (WCAG), a set of recommendations to help ensure your website’s content is accessible to people with disabilities.

Here we'll provide an overview of the WCAG guidelines, why they matter to you and how to best implement them moving forward. To see this in action head over to our OC case study. Meeting WCAG guidelines to make your website more accessible is easier than you think, and will benefit all your users.

WCAGADA508W3C

There’s a lot of acronyms out there, but let's tackle the ones that really matter:

WCAG 2.1

The current version of the Web Content Accessibility Guidelines. They’re published by W3C, the international body who creates web standards. They have three levels:

A: the bare minimum. If your website is in good shape you’re likely already achieving this level.
AA: the middle ground. Most companies concerned with accessibility work towards this level, one you should aim for too. In some countries it’s a legal requirement for certain organizations (e.g. government body websites).
AAA: the most in-depth level. Generally only used for specialist websites that have complex requirements (e.g. sign language translations for audio content).

ADA

The Americans with Disabilities Act, a law prohibiting discrimination based on disability. While it doesn’t explicitly reference website accessibility, a legal precedent has been set that non-accessible websites could be considered discriminatory. There’s an equivalent in UK law called Section 20 of the Equality Act.

Section 508

Law in the U.S. which requires (amongst other things) government websites to be accessible to all, as defined by meeting WCAG Level AA. The European Accessibility Act within the EU is similar to this.

Why bother?

As referenced above, there is a legal case for making your website accessible, but hopefully that’s not your only motivation. In the U.S. alone 12% of the population reports having a disability – over 37 million people. While that number is large, not following WCAG guidelines may create unnecessary obstacles for people that fall outside that category as well. Our default should be ensuring our websites are inclusive for all, without needing further justification. However, there are tangible benefits for businesses who work to achieve WCAG guidelines: your website will be easier to find and use, increasing your audience; you’ll have a competitive edge over rivals who haven’t prioritized accessibility; and your visitors will have an easier path to achieving their goals when they arrive at your website.

But here’s the best part: building an accessible website benefits all users. Despite years of going to gigs – including the infamously loud Mogwai – my hearing is okay (for now). But I still prefer skim reading a transcript over listening to a podcast. You might have perfect eyesight but prefer listening to an audio book. And what if you’re on your phone in bright daylight? Or on holiday visiting a website that’s not in your primary language? You may have bad internet, feel overly tired or are in a rush? The WCAG guidelines make life better for all users in these situations.

So, how do you approach your next web project with an emphasis on achieving accessibility?

Decide early and get everyone on board

At the start of your project decide which accessibility level you’re aiming to achieve (most likely WCAG 2.1 – AA). Accessibility isn’t a line item to tack on at the end of a project, so communicate this goal to all stakeholders from the beginning. It affects all stages of the project, including content creation (using more descriptive link text than 'Click Here'), design (ensuring proper contrast between text and background color) and development (more on this below).

Audit your existing site

If you already have a website then completing an in-depth accessibility audit is a good start, which should include testing real users with ‘assistive technologies’ (like the JAWS screen reader). However, even a quick, simple audit using automated tools will help identify big issues. Wave, Pa11y and Google Lighthouse are good auditing tools, and will quickly scan your website and flag any issues.

Technical implementation details

While some WCAG requirements are tricky to implement (especially for complex components like multi-level dropdowns or carousels), you can make substantial progress relatively easily. Below are a few quick wins to make your site more accessible.

Get the fundamentals right

We wrote about this in 2015 and nothing has changed:

The magic bullet to a successful digital project is readable content, usable forms and intelligent website structure. Nail these basics and you’ve nailed your digital project, whatever it is.

Use semantic markup and appropriate elements

We have many HTML elements at our disposal. Use them appropriately to give screen readers the best shot at understanding your page structure.

Many elements come with free, built-in accessibility features. Make use of these where possible instead of recreating them with Javascript. A native checkbox input is keyboard and screen reader accessible, offers keyboard events, communicates its state and behaves in a way that's universally understood. It’s now possible to style most native form inputs consistently using only CSS (see WTF, Forms? and Styling a Select Like it’s 2019).

Use just enough ARIA

Using good markup means you shouldn’t have to lean too heavily on ARIA very regularly. For example, using a nav element is better than div role=“navigation”.

A common mistake is using role=“menu” for a navigation list. This was intended for building application menus, not website navigation. Using role=“menu” will require adding a lot of complex keyboard navigation support. An appropriately marked navigation needs no ARIA and can be used with just the Tab key. More on that here.

There are still a few cases where ARIA is useful: we make frequent use of aria-hidden, aria-expanded, aria-haspopup and aria-labelledby.

Ensure headings are in the right sequence

Heading levels should descend in a logical sequence reflecting the depth of the content – one h1 element per page, no h4 before an h3 and no skipping levels.

One way we help enforce this is by ensuring the heading levels we make available to content editors (in Craft, our CMS of choice) take into account the rest of the page content. A common example is a blog post template where the h1 is populated by the post’s Title field, and the body of the post is populated by a Redactor WYSIWYG rich text field. In this case we’d use the redactor config code below to make only heading levels 2–6 available:

{ 
 "buttons": ["formatting", "bold", "italic", "unorderedlist", "orderedlist", "link" ],
 "formatting": ["p", "h2", "h3", "h4", "h5", "blockquote"],
 "toolbarFixed": true
}

Provide good labels to screen readers

A great example of this is a social network link, made up of that network's icon. Sighted users will see the icon and know to click; however, screen readers will only register an SVG icon with no description. To fix this, add a descriptive label and use CSS to hide this from everything except screen readers. Use aria-hidden to prevent the screen reader from getting bogged down on the SVG icon.

/* HTML */
<a href="https://facebook.com">
 <span class="u-sr-only">Find us on Facebook</span>
 <svg class="icon icon-facebook" aria-hidden="true">...</svg>
</a>

/* CSS */
.u-sr-only {
 position: absolute;
 width: 1px;
 height: 1px;
 padding: 0;
 margin: -1px;
 overflow: hidden;
 clip: rect(0, 0, 0, 0);
 border: 0;
}

Provide useful image alt text (or don’t)

All images should have an alt attribute. If the image is only used for decorative purposes then leave the alt attribute blank. Otherwise, provide a useful description of the image.

In Craft we usually use the asset’s title field for the alt content, and add a note to the field instructions to nudge content editors into making this useful: Recommended image size: 2500 x 975. Double-click on the image to set a title, which should be a short description of the image.

Provide a text version of non-text content

Audio content should have a transcript provided. Videos should include closed captions, have a transcript provided, or both. Wistia, Youtube and other video-hosting providers can offer automated captions, though they’re unlikely to be 100% accurate. Alternatively you can create your own, or pay a third-party service.

The best advice: cheat!

In the introduction we mentioned that some components are tricky to make accessible, like carousels and multi-level dropdown navigation. The quickest fix for this is not using them. For example, carousels have a many well-documented problems, and the best solution might be simply presenting that content in a different way. This is another good example of how ‘designing for accessibility’ is beneficial to all users.

Checklists & tools

A11Y Project Checklist: a simple, easy-to-digest version of the full WCAG guidelines. This is an excellent starting point.
W3C ‘How to Meet WCAG’ checklist: a filterable list of all the WCAG guidelines with in-depth descriptions for each, including suggested techniques and what classes as failure.
Pa11y: a command-line interface which loads web pages and highlights any accessibility issues it finds.
Wave: a browser extension from WebAIM, which gives quick feedback on a page’s accessibility.
Google Lighthouse: a Chrome tool which audits performance and accessibility.