<aside> 🚧 This is a new procedure and will be subject to change and interpretation. Please feel free to use your best judgment when applying it, knowing the end goals

</aside>

Overview

While accessibility is an amorphous concept, the WCAG guidelines provide a rubric of commonly-accepted accessibility measures which are a good starting point. If a site is compliant with WCAG’s ”AA” standard, it is probably reasonably accessible for most users. It is important for us to verify that this is the case on our own sites. We also want to be able to identify for other people what a site’s accessibility level is.

In some cases, the client may wish to deviate from the AA standard to achieve a specific design goal. But at the least, we should consistently know which parts of the standard a site is not meeting.

Over 50% of accessibility problems start in design. This is not the fault of designers: the design of a site is simply very early in the process, and thus exposed to most accessibility concerns. Thus, it is important that, whenever possible, we review designs for accessibility, so problems they can be addressed before we're too "locked-in" to any one decision, either by client approval, having it already in development, or otherwise.

Cantilever both handles new productions as well as ongoing support for existing sites. It is entirely possible a "design audit" could be of either a Figma/design draft early in production, or of an existing, supported site that would like an audit for accessibility retrofitting.

Assessing a Figma draft of a design is not too different from assessing an existing web page in that we still look for the same things. However, the process to check these are fairly different. This procedure attempts to cover both an audit of a Figma or site mockup, as well as a design check for an existing, developed site.

Who can do this

Familiarity with the WCAG and its nuanced rules is highly recommended. However, this procedure is intended to be relatively approachable and explain these rules, and many of the checks here are relatively simple yes/no binary checks.

What you need

Knowledge of which pages or resources are to be checked. This may be in the form of a Figma project, or a sample of pages (or individual page components) to check.
A group or todo list in Basecamp for reporting issues.
A tool to check color contrast. Any of these may work, depending on what is being tested:
- Colour Contrast Analyzer (CCA) - Standalone application for comparing colors.
- axe DevTools - Browser extension that, among other accessibility tests, will check contrasts. It is not perfect and requires manual review for complex or graphical backgrounds.
- There are many browser versions of contrast analyzers. Some links:
  - https://webaim.org/resources/contrastchecker/
  - https://dequeuniversity.com/color-contrast
  - https://colorshark.io/ - Also creates suggestions for color adjustment.
  - https://contrast-grid.eightshapes.com/ - Creates a pallet grid to check multiple colors at once

Steps

<aside> 💡 What discrete actions constitute the procedure? Make sure to nest them as appropriate.