Accessible design checklist

At Sage, we use an accessible design best practice checklist to ensure we are making our products and communications accessible for all types of users. It is vital that our designers consider accessibility from the start of the design process, and throughout development at Sage – considering as many angles as possible to include users of varying abilities.

We ensure that as much of this information as possible is passed to the people who build our Sage products and for our website so that we can create accessible experiences.

Our accessibility checklist is continually reviewed against Web Content Accessibility Guidelines (WCAG) to prevent pages, patterns, or components becoming inaccessible.

We encourage using our checklist as part of your own design process, to help make your designs more accessible for all.

Labelling and displaying content

It is important to consider how all on-page content is presented to users. For example, images, buttons, and form fields will require you to take extra steps to make these more accessible. The below points should be included:

  • All buttons with icons should have a visible text label
  • Images should have a text alternative that accurately describes the content or meaning of the image
  • Avoid describing components or on-page elements by position, colour, size, shape, etc
  • Display all content on-page i.e. not hidden in tooltips
  • Designs must be responsive to viewport size – this should account for user behaviours such as zooming in, applying custom styles for text spacing, and different device or window sizes
  • Dynamically updated content will need to be communicated to screen reader users
  • Content like pop-up messages should not disappear until the user dismisses it
  • *Use vertically ‘stacked’ or listed form labels such as hints/help, error, and input layout
  • Avoid ‘placeholder’ text inside form inputs; especially for labels or hint/help text

An example text input showing four vertically stacked components; first the form label, then some hint text underneath it, followed by the error message, then the input box itself. Because the input is in an error state there is a red line highlighting the error message text and the input box, and the border of the input box is red.
*Use vertically ‘stacked’ or listed form labels such as hints/help, error, and input layout

Formatting and styling content

Formatting and styling on pages can be distracting or may dilute messages. It’s important to ensure that your designs consider format and styling elements when making content inclusive for users with varying accessibility needs.

  • Use sentence case text for labels and headings, rather than title case or all-caps
  • Consider how the information will be presented and marked up. For example, is the information better presented as a table or a list, and is this being marked up with the correct Schema?
  • Do not rely on colour to communicate meaning
  • Text and other user interface (UI) elements must have a sufficient colour contrast between their backgrounds and adjacent text and/or elements
  • Buttons must not look like links, and links should also not look like buttons
  • Always check your designs with a colour blindness filter to ensure it is still readable

Navigation and user experience

Many users with physical, motor, and cognitive disabilities often use the keyboard to navigate. This is often in place of a touchscreen, track pad, or mouse. For this reason, we must ensure that everything we produce, from digital products to web pages and communications, are accessible to keyboard-only. This allows users to perform tasks like browsing or clicking through content more easily, using the functionality of a keyboard to access the content as intended. When creating components, the below points should be considered:

  • All components are configured to be accessed via keyboard reader
  • When using the tab key to navigate buttons, links, and form fields, ensure the order of focus is expected, and the focus indicator is clearly visible.
  • Keyboard shortcuts should use modifier keys
  • Drag and drop functionality should be an enhancement of a button-based mechanism for reordering – and not the only way to reorder
  • Target sizes should be 44px × 44px wherever possible; 24px × 24px at a minimum
  • Navigation can be skipped by keyboard users
  • Page titles must describe what is on each page
  • Navigation must be consistent from page to page
  • Components that do the same thing must look and work in the same way
  • Ensure multiple ways to navigate from page to page (for example, navigation and on-page links)
  • Page content should not change significantly when a form element value (like a radio button) is changed
  • Page content should not change significantly when an element receives focus
  • Related content and controls must be grouped closely to help users know that they’re available, if using screen magnification
  • Headings must be used to help the user identify groups of content on a page
  • Links, headings, buttons, and form field labels must be descriptive
  • Links must be underlined

Prompts for form or task completion

Accessibility for in-product or on-page task completion is crucial to ensure that errors are minimised for users who may have disabilities that make inputting data more challenging. Accessibly built-in prompts for form submission or input fields can help all users interact with these components as intended, allowing them to provide more accurate, correct information.

  • Errors must be flagged using text
  • Suggestions can be given within error messages to help the user complete their task
  • Help and hint text must be used where necessary
  • Notifications or flagging should be used to help users check and confirm important information before submitting
  • Supporting content or help resources should be accessible from every page, should the user need it

Audio, visual, and animated on-page elements

When including interactive on-page elements such as audio files, video content, or animations, extra considerations will be needed to make these accessible to all users.

  • All videos must have captions
  • Include closed captions and transcripts, and audio descriptions
  • Auto-playing animations or video content should have the ability to be paused
  • Flashes in video or animation should be kept to a minimum, or avoided completely
  • A static alternative to any animated illustrations should be designed and included in the assets for development

The above checklist has been created in line with the WCAG (Web Content Accessibility Guidelines), 2.0, Level AA and was last updated in September 2022. We ensure that all of our Sage products and web pages are aligned with this checklist to better serve our Sage customers.

For further information about our accessibility pledge at Sage, head to our accessibility hub to find out more about what we do. For notes on our specific products, please view our accessibility statements.