Design Tokens for Mesh have just been released!
Skip to content
Mesh

Accessibility checklist

This checklist is a set of recommendations for developers and testers to follow in order to meet WCAG 2 accessibility requirements.

Overview

Below is a checklist of accessibility concerns that should be completed before any release. This is by no means an exhaustive list, but it does detail the areas most relevant to us and should set the standard for web accessibility at nib. For a more detailed list, please refer to the resources below.

See our Designing for Accessibility guide for a more detailed overview of the importance of accessibility from a design perspective. We also have an accessibility statement which details Mesh's current position on web accesibility and any issues existing in our components.

Checklist

Content and layout

Content should be presented in a meaningful and logical order. When you disable styles on a page, all the content should still appear natural and intuitive.

1. Content is written and presented properly

  • Page content should be readable when the text size is increased to 200%. This should cause no content overlaps.
  • Relative units for text and text container sizes should be used (%, em, rem).
  • An attempt should be made to ensure content is written with plain language and at an 8th grade reading level.
  • Avoid using whitespace characters for layout purposes.
  • Regardless of screen size or device orientation, all content should be available.
WCAG Success Criterias

2. Use heading elements correctly

The following considerations should me made when using our Heading component.

  • Heading elements (e.g. <h1>, <h2>) are nested and used in a logical sequence.
  • Only one <h1> element per page.
  • Don't skip heading levels.
WCAG Success Criterias

3. Use semantic markup to indicate content regions

  • Page regions such as <aside>, <footer>, and <nav> should be used to create a semantic structure.
  • ARIA landmark roles should be used to assist screen readers in identifying significant page areas.
WCAG Success Criterias

4. Use list and text elements correctly

  • List elements (e.g. <ol>, <ul) should be used for all list content.
  • Emphasis or special text elements such as <strong> and <code> should be used where possible.
WCAG Success Criterias

5. Avoid ambiguous link text

  • When writing link text with <button> or <a> elements, avoid text such as "Click here" or "Read more" as the lack of context causes confusion when using screen readers.
  • The purpose of each link should be determined from the link text, or from the link text and its context.
  • If descriptive link text is not possible, you can include a visually hidden element to add meaning to the link for screen readers. This can easily be done with our Hidden component. For example:
jsx
WCAG Success Criterias

6. Consistent navigation

  • When a navigation menu is displayed on multiple pages, the links, position, and experience must be consistent.
  • Components repeated on or across pages should have the same functionality.
WCAG Success Criterias

Controls

Controls are the interactive elements that allow users to navigate pages, and perform actions. Without accessible controls, some users may have significantly limited experiences.

1. Correct use of links and buttons

The main thing to remember here is links "go" somewhere (a webpage, a file, etc.), whereas buttons do not.

We highly recommend that you use our Link and Button components as they come with a number of accessibility features baked in. If these do not meet your needs and a custom button is required, you can revert the default styling of the button. When doing this, remember to add the standard focus styling from our theme.

  • All links (<a> or Link) need an href. If none is used, a <button> should be used instead.
  • Never use a <div>, <span>, etc. element as a clickable link or button.
  • Buttons and links must have text content within it (or an aria-label if using an icon button) so that screen readers know what to announce.
WCAG Success Criterias

2. Use a skip link where possible

  • Skip links are links that provide a shortcut to the content of the page. It should be the first pirce of HTML after the <body> tag.
  • Mesh provides a SkipLink component for this purpose. In almost all cases, you should use our Header Footer Layout component instead as it includes the SkipLink for you.
WCAG Success Criterias

3. Avoid links that open new tabs/windows

  • Links that open new tabs or windows should be avoided where possible.
  • In cases that this is required, ensure that users are aware of the link behaviour.
WCAG Success Criterias

4. Ensure all controls have a focus state

  • All controls must have a visible focus state.
  • When using Mesh components, these are built-in but if you create custom controls you must add our standard focus styling.
WCAG Success Criterias

5. Control interaction instructions

  • Interaction instructions shouldn't rely on sound. Example: "After the beep"
  • Instructions shouldn't rely on shape, size, or visual location. Example: "On the right", "Click the square".
WCAG Success Criterias

Color

The use of color on a page is very important as incorrect implementation can negatively impact the experience for users with low-vision or color deficiencies.

1. Sufficient color contrast

Contrast between foreground and background colors must satisfy the WCAG requirements.

  • Check both normal-sized and large-sized text to ensure they match the constrast requirements.
  • Check the contrast of icons, images, or videos and any text that may overlap these elements.
  • Check the contrast of form elements, labels, and borders.
WCAG Success Criterias

2. Don't rely on color

  • Colour should not be the only method to convey meaning.
  • Links and other controls should not rely on color to indicate an action.
  • In forms, required fields and fields with errors must have a non-color indicator.
  • Focus and hover states are useful for providing additional indicators.
WCAG Success Criterias

Images and Media

Images, icons and media are helpful elements that provide an alternative way to convey information. When used, measures must be taken to ensure this information is available to all users.

1. Correct use of alt attributes

  • If the image is decorative, an alt attribute should be an empty string (alt="") or the image should be a CSS background image. This is to prevent some screen readers from reading the filename when no alt attribute is provided.
  • If it is not decorative, the alt text should be as descriptive as possible to describe the purpose of the control or the image itself.
  • The context of non-decorative elements should inform the alt text.
  • If the image contains text, make sure the alt description includes the image text.
WCAG Success Criterias

2. Providing media controls

  • Media elements must allow the user to pause with a mouse and keyboard.
  • Media controls (such as volume) must use appropriate HTML.
  • Make sure media doesn't autoplay but instead needs user input to start.
WCAG Success Criterias

3. Accessible audio and video

  • All pre-recorded audio snippets should include a transcript.
  • All pre-recorded videos must provide captions, unless the video is decorative.
  • Remove all seizure triggers from videos and other animations.
WCAG Success Criterias

General

1. Valid HTML

  • Ensure your HTML is valid for consistent experiences for all users. You can use this validator tool.
  • The language of the page or page sections is provided by HTML lang attribute to help screen readers with pronunciation.
  • Each page should have a descriptive and unique <title> in the document's <head>. This can be assisted with our React HTML component.
WCAG Success Criterias

2. Maintain flow order

  • Tab order should move down the page in a linear flow.
  • Remove tabindex attributes from elements that are not inherently focused.
  • Avoid using the autofocus attribute as it causes confusion for certain users and can be disorienting.
WCAG Success Criterias

3. Proper keyboard interaction

  • Ensure all interactive elements can be accessed by a keyboard and have visual focus styles.
  • Check to see that the keyboard focus order matches the visual layout.
  • When navigating the page with a keyboard, ensure the focus is never trapped on an element without a way to progress.
  • There should be no focusable elements that are invisible to the screen.
WCAG Success Criterias

Testing

Testing the accessibility of your site should encorporate the following:

  1. Run the page on multiple browsers to check that all work as expected. Consult our browser support guidelines for more information.
  2. We advise all developers to use a screen reader to confirm that users who rely on these tools can navigate the site as expected.
    • For Mac users: Apple's VoiceOver (also available in iOS)
    • For Windows users: NVDA

Useful Tools

  • WAVE browser extension
    • Runs a check on the page with information on aria-labels, color contrast, and reports any accessibility errors.
  • axe DevTools
    • A chrome-only developer tool for detecting accessibility issues and providing potential solutions.
  • Web Developer browser extension
    • Shortcuts to validate HTML, CSS, and accessibility (using WAVE), disable styles, and much more.
  • Google Lighthouse
    • Lighthouse audits on a page can reveal any outstanding accessibility issues that need to be resolved.
  • A11Y linting tools such as ESLint JSX A11Y can help enforce accessibility features during development.

Resources

Credits

Author: Jordan Collins

Reviewers: Laurie Jones, Michael Troy

Published: 28 June 2021

Edit this page