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
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:
What discrete actions constitute the procedure? Make sure to nest them as appropriate.
Testing Color & Contrast
Well-chosen colors make for a beautiful design. Color and color contrast are also vital to accessibility, as users, especially those with low vision, need to be able to clearly percieve content. These two needs are not necessarily in tension: Well-contrasting elements can make components visually "pop out" from the background, and clearly visible or readable components makes for pleasant browsing.
When we're comparing "color contrast", we're actually comparing the relative luminance of two colors. Relative luminance is defined as the relative brightness of any point in a colorspace: 0 is the darkest black and 1 is the brightest white. These luminance values are compared and presented as a ratio between 1:1 and 21:1. Fortunately, there are many tools that do these calculations for us.
The rules for contrast are extensive, but for Level AA conformance can be (over-)simplified as:
- 3:1 contrast ratio or larger:
- Text (and images of) that are at least 24px size normal weight, or 18px bold
- Interactive UI components
- Custom states for elements, such as hover, active, or focus
- 4.5:1 contrast ratio or larger:
- Text under 24px normal weight, or 18px bold
Process, Automated / Web Page Assessment
- Run axe DevTools. Report all issues. It is sometimes more expedient, for both tester and designers, to simply describe what color is consistently causing problems, rather than every individual element.
- Axe may request manual review of some issues. For manually assessing color contrast, refer to processes under Manual / Figma assessment.
Process, Manual / Figma Assessment
- Acquire color samples. Figma, being a design tool, keeps a record of colors used. There may also be a style guide section in the Figma itself. If you can otherwise acquire a list of colors used on the site, you can begin checking them immediately to see if there are any problematic pairings.
- Carefully examine all components of the page. Look at where text is present and what background is underneath it. Look at user interface components such as links, buttons, and form fields.
- If inspecting a Figma: Click on components and their backgrounds. Figma will often show the color used for a component on the sidebar, meaning no need to select a sample pixel. Use contrast analyzer tools to compare contrast. If comparing contrast of text, note the text's size and what the minimum viable ratio would be for that size and styling.
- If inspecting a web page: Use the inspect element tool to find styling information for both the element and background colors. Use contrast analyzer tools to compare contrast. If comparing contrast of text, note the text's size and what the minimum viable ratio would be for that size and styling.
For inspecting contrast of complex or graphical backgrounds:
Complicated or textured backgrounds, or backgrounds that are otherwise images, require manual inspection. If you are not using Colour Contrast Analyzer, you may want to take a screenshot of the web page or Figma and use an image editor software's "dropper" tool to collect samples.
- Collect a couple of colors samples of the background. You want to pick the darkest and brightest relevant pixels in the background. A pixel is a relevant pixel if it is immediately interfering with the text or elements in its foreground (within a few pixels of). We are essentially looking for the "worst case" pixel here.
- Compare sample colors to the color of the foreground elements. If the worst case pixel passes, then it is safe to assume all better-contrast pixels also pass.
Other Color Tests:
- Inspect all links on the page. Ensure links are visibly indicated and distinct from body text through means beyond color, including both default and hover states. An underline is a common way of indicating a link.
- Inspect any place where information is conveyed by color. Graphs and charts are a first place to look. Navigation menus or UI components are also worth special notice. Ensure there are non-color means of conveying information.
Inspection of Layout & Navigation
Cognitive disabilities can make navigation difficult. We would like it to be as easy as possible to both understand where you are on a site, as well as how to get where you need to do. Consequently, it is good practice to provide multiple ways to navigate through a site, so that users can choose whichever option they find the most comfortable.
There are some obvious caveats here, such as if a "site" only consists of, literally, one page.
- Inspect what navigation options are present for the site. There should be more than one way to navigate the site and find a given page. Look for at least two of: a table of contents, a site map, a search function, a list of pages related to the current page, or a list of all pages.
- Ensure that the user's location on the site is displayed. This can be through breadcrumbs, a site map, or an indicator on a navigation menu. It should always be clear "where" in the site you are.
- Ensure navigation is consistently presented, with options appearing in the same order each time.
- Ensure a "skip to main content" button is available on every page. It is okay if it is hidden by default. If it is hidden by default, it must be made visible and be the first focusable element on the page when using Tab (barring extreme exceptions).
Miscellaneous Layout & Format Checks
- Check for a highly visible focus style. If inspecting an existing web page, check multiple browsers for a high visible focus.
- WCAG does not have a definition of a visible focus, nor a highly visible one. It is safe to deem a focus highly visible if it is prominent, well-contrasted, and can be spotted by someone with corrected vision.
- Chrome has a highly visible focus by default. Do not confuse this default for the page itself having a visible focus! Browsers such as Firefox do not have a highly visible focus by default.
- Testing Sites: If the keyboard focus disappears while tabbing through the page, by definition we do not have a highly visible focus. Also, it should be reported that focus disappears, as that is an accessibility problem itself!
- Inspect text and images to check for "images of text", that is, text that are inside graphics as opposed to being plain text body. Logos are an exception.
- Inspect multiple pages, if relevant, for components used repeatedly. Are they consistently labeled? Are they in the same relative place, each time?
- If testing a site, check for components that automatically move, blink scroll, update, or otherwise animate. Check if these components have a way to pause or stop the animation.
As forms are an interactive component, it is not always possible to check interactive aspects such as errors or corrections when assessing a Figma. Do the best you can: while error styling should be present in a Figma, follow-up testing after development can be a better time for checking error functionality.
- Form fields must have visible, text labels. A placeholder alone is not an acceptable, visible text label.
- Labels should be placed consistently and visually associated with the input.
- Check for required field labeling. Required fields must be marked visibly, with means that is not color alone. The * asterisk symbol is minimally adequate.
- If a field has an error, it should be identified as erroneous with means beyond color alone.
Widgets range from the common carousel to things rarely thought of as "widgets" such as navigation menus, to completely custom interfaces for highly specialized needs. It is difficult to cover every base and the actual functionality of a widget depends on the developer's implementation. However, design is still an ideal time to check some common rules about how widgets, and controls in general, should behave:
- For all controls of a widget, a simple click or tap control option must be provided. An example: A carousel not only allows one to swipe left or right to scroll it, but also has next and previous buttons for tapping.
- The target size for interactive components must be 44x44 pixels in size. It is okay if the visual indication of a target is a bit smaller than this: this only relates to the "clickable" region.
- In general, there should be some form of immediate feedback on interactions: this feedback should be both visual and announced by screen readers. Pressing a button should visually indicate something has happened and a screen reader should announce such. If a feature's activation is obvious, such as a video playing, that is acceptable as feedback.