Is your website accessible? Here’s a handy checklist to find out.

Design

Web accessibility can be a dense topic if you’re exploring it for the first time! If you find yourself reading through the WCAG 2.0 accessibility guidelines, you’ll likely feel overwhelmed. What follows is a much simpler checklist-based introduction to help you understand whether your website is accessible.

We should mention at the outset: This is only a summary. The WCAG 2.0 guidelines have over 60 different requirements between the various compliance levels, so you need to get an expert involved if you want to ensure full compliance. (Luckily, we can help.)

But, we’ve distilled this down into a list of the most important items that impact actual accessibility on most websites. You won’t necessarily be WCAG compliant if you can answer “yes” to all of the items below, but you’ll be well on your way—and more importantly, anyone using accessibility software should be able to navigate your site with ease.

If your site uses a content management system (CMS), as most sites do these days, the accessibility responsibilities will be split between the web developer and the content editor. Accordingly, we’ve broken out the requirements into separate lists, although there is a lot of overlap.

Content Editor Responsibilities

These items are content-based and fall within the responsibilities of the site editors. Each person editing the site should have proper training so that the overall accessibility of the site isn’t compromised.

1. Do all images have alternative text?

Alternative (alt) text is required for all images, describing it textually for someone who is blind or visually impaired. If the image is purely decorative, it must still have an empty alt attribute (e.g. alt=””) to indicate to the screen reader that it should be ignored.

2. Do all heading levels (H1, H2, etc.) follow a proper outline hierarchy?

Heading levels (H1-H6) should always be nested like a document outline. For example, an H3 would designate a sub-section within an H2 section—meaning you should never come across an H3 that is not preceded by an H2.

3. Do all data tables have correct header designations?

Tables can be either vertical or horizontal, with header cells describing either the column that comes below it or the row that comes after it. As a result, table cells must be properly marked with a “scope” attribute so that the screen reader knows how to match the heading to the data.

4. Is all link text appropriately descriptive?

Screen readers usually have a mode where they can pull all of the links off of a page and put them into a list for easy navigation. Accordingly, each link must be descriptive so it makes sense out of context. Don’t make links that say “click here” or even “view more.”

5. Do all videos have closed captioning?

Videos must be closed-captioned so they can be experienced by visitors who are deaf or hard of hearing.

If you use YouTube, they get you most of the way there by using speech recognition technology to add closed captioning automatically. However, these captions are often inaccurate, so they should always be reviewed and edited before the video is published.

Developer Responsibilities

These items can typically only be edited directly in the code, so if your site fails any of these checks, they will need to be fixed by a web developer.

1. Do your pages have a straightforward document structure, readable without a CSS file?

HTML is a structural language, while CSS is presentational. Accessibility software, for the most part, uses only the underlying HTML document to present the content to the user, so it is important that the content as viewed in the HTML code itself is arranged in a logical manner. It should also be free of errors, which may be smoothed over by a normal browser but could cause failures in accessibility software.

2. Can all links and navigation drop-down functionality be used without a mouse?

Most web users will navigate a site with a mouse, and both developers and content administrators will often fail to test that the site works using only a keyboard. However, most accessibility software is keyboard-only, so it is extremely important to ensure that nothing about the site is inaccessible to keyboard users.

3. Is a “Skip to main content” link present before the navigation when tabbing?

A medium-sized site with dropdown navigation menus may easily have 80 links in the header. Without a “skip to content” link, a keyboard user would need to tab through all 80 of those links on each page before the screen reader begins reading the content, making the site very difficult to use.

4. Does the site use ARIA landmarks and other assistive technology indicators where appropriate?

ARIA landmarks are like bookmarks within the page, and are typically denoted with the “role” attribute (for instance, role=”navigation”). HTML5 elements like “nav” and “main” are directly mapped to ARIA landmarks, so they can be used instead.

5. Does small text (18px or smaller) have a contrast ratio of at least 4.5:1 against the background?

A minimum contrast ratio must be maintained between the text and its background so that people with low vision can read it.

There are no official guidelines about calculating the contrast ratio for backgrounds that vary in color, e.g., background images or gradients, so our policy on this is to just take the average color that is directly below the text and treat it as an honor system.

6. Does large text (bold > 18px, normal weight > 23px) have a contrast ratio of at least 3:1 against the background?

This primarily applies to headings. Bold text that is 19px or larger must have at least a 3:1 contrast ratio, as well as standard-weight text 24px or higher.

Blog