Notes

Conduct an Accessibility Audit

5 min read

Conduct an accessibility audit

This guide is my preferred order of evaluation when conducting an accessibility audit. You will also find an audit template based on the Web Content Accessibility Guidelines (WCAG) 2.1 (w3.org) criteria, as well as some examples of finished audits.

What an audit provides

An accessibility audit provides a detailed report, in the form of an Excel spreadsheet, of a product’s compliance with the Web Content Accessibility Guidelines (WCAG) 2.1 (w3.org). A product can be a web page, part of a web page, or a collection of web pages. The report lists every WCAG criteria, and for each web page, whether or not each criteria was met.

An accessibility audit may take a week or more to complete.

When should you conduct an audit

You should conduct an audit if you need to formally certify a product’s level of accessibility compliance, for example to deliver to clients. You may also need to conduct an audit to formally report a product’s lack of accessibility compliance, for example to request modifications from a subcontractor.

You should not conduct an audit if:

  • you want to cover accessibility best practices in addition to the WCAG
  • you want to track the discussion and remediation of accessibility defects
  • you want to begin addressing accessibility defects immediately
  • you want recommendations for remediation of defects found

If any of the above apply, consider a more informal accessibility review process

Before you begin

INFO

You may wish to set up a separate document for notes and recommendations that don’t fit in the compliance audit.

  1. Download the WCAG 2.1 audit template (TODO) or visit WCAG-EM Report Tool (w3.org)
  2. Determine compliance level (A, AA, or AAA)
  3. Select pages to evaluate
    • For anything with more than five pages, select a representative sample

Perform the audit

WARNING

Verify that you have correctly interpreted each success criteria. The failure indications suggested here are generalized, and there are many exceptions that may apply.

Refer to How to Meet WCAG (Quickref Reference) (w3.org) for details on each success criteria.

The following steps are my preferred sequence when running through a page. You may choose to ignore these suggestions and instead go through each success criteria in any order.

1. Tab through the page

  1. There should be a skip link. If not, comment in 2.4.1 Bypass Blocks (Level A)
  2. The focus indicator should always be visible. If not, comment in 2.4.7 Focus Visible (Level AA)
  3. The focus should reach every input element. If not, comment in 2.1.1 Keyboard (Level A)
  4. A focused element should be usable with the keyboard. If not, comment in 2.1.1 Keyboard (Level A) or 2.1.3 Keyboard (No Exception) (Level AAA)
  5. The focus should go through the whole page without getting caught in a loop. If the focus gets stuck, comment in 2.1.2 No Keyboard Trap (Level A)
  6. The focus order should match the reading order. If not, comment in 2.4.3 Focus Order (Level A)
  7. The page context (i.e. url) should stay the same when an element receives focus. If the context changes, comment in 3.2.1 On Focus (Level A)

2. Check use of colour

Check colour contrast using the browser’s DevTools or WebAIM: Contrast Checker.

  1. The colour contrast for text should be at least 4.5:1. If not, comment in 1.4.3 Color Contrast Minimum (Level AA)
  2. The colour contrast for text should be at least 7:1. If not, comment in 1.4.6 Contrast (Enhanced) (Level AAA)
  3. The colour contrast for the borders of buttons, etc. should be at least 3:1. If not, comment in 1.4.11 Non-text Contrast (Level AA)
  4. If any instruction says something like “click on the green button to continue” or “the red items apply only to situation A”, comment in 1.4.1 Use of Color (Level A)
  5. If there is a colour-coded graph and the labels aren’t also associated by some means other than colour, comment in 1.4.1 Use of Color (Level A)

3. Check for alt-text

  1. If there’s missing alt-text, comment in 1.1.1 Non-Text Content (Level A)
  2. If there’s text displayed as an image, comment in 1.4.5 Images of Text (Level AA) or 1.4.9 Images of Text (No Exception) (Level AAA)

4. Check the markup

  1. If the title of each page isn’t unique and meaningful, comment in 2.4.2 Page Titled (Level A)
  2. If there are no headings, comment in 2.4.10 Section Headings (Level AAA)
  3. If the headings don’t use semantic markup, comment in 1.3.1 Information and Relationships (Level A)
  4. If labels, buttons, tables, etc. don’t use semantic markup, comment in 1.3.1 Information and Relationships (Level A)
  5. If control elements such as buttons, inputs, etc. have an accessible label that doesn’t begin with the same text as its visible label, comment in 2.5.3 Label in Name (Level A)
  6. If a form input doesn’t have a label, comment in 3.3.2 Labels or Instructions (Level A)
  7. If a form input has a label, but it’s not properly associated, comment in 1.3.1 Information and Relationships (Level A)
  8. If a form input would normally be auto-populated by the browser, but isn’t (e.g. firstname, lastname), comment in 1.3.6 Identify Purpose (Level AAA)
  9. If the DOM order doesn’t match the reading order, comment in 1.3.2 Meaningful Sequence (Level A)

5. Fill in the remaining criteria

You’ve covered most of it by now. Fill in what remains with PASS, N/A, or a reason for failure.

Examples

(TODO)

Graph View