Skip to content

Accessibility

Workbench is committed to creating accessible experiences so that we can reach the widest audience possible. We believe that accessible design is better design for everyone.

Workbench follows the same accessibility standards as listed on Gusto's Accessibility StatementExternal link. Our current standard is to meet Web Content Accessibility Guidelines (WCAG) 2.1 Level AA.

The following table is used to display what screen reader + browser combinations Workbench uses for testing. This is not an exhaustive list of all possible combinations, but rather a list of the most common combinations used based on WebAIM's latest Screen Reader SurveyExternal link.
Screen ReaderBrowserOS
JAWSChromeWindows
NVDAFirefoxWindows
VoiceOverSafariMacOS
VoiceOverSafariiOS
TalkbackChromeAndroid

While Workbench does not attempt to meet all WCAG 2.1 AAA success criteria, there are some that we tend to meet to go above and beyond the minimum standard.

Here are some considerations Workbench follows when creating components, patterns, and/or other assets. This is not an exhaustive list of things we consider when meeting our standard of quality.

  • Don’t use color as the only visual means of conveying information
  • Do not use color as a means of direction (e.g., "Click the red button")
  • Use color to highlight or complement what’s already visible
The following table lists the minimum contrast ratios for text and non-text
CategoryContrast ratioExamples
Text or images of text4.5:1Paragraph text, labels
Large text3:1Headings
Non-text3:1Borders around interactive elements

Relevant WCAG 2.1 success criteria

Relevant WCAG 2.1 success criteria

  • Every form element should have a label
  • Avoid creating non-visible labels
  • Don’t use placeholder text as a label
  • Ensure errors are visible, associated to its form element, and provide a means of correction
  • When applicable, use the autocomplete HTML attributeExternal link

Relevant WCAG 2.1 success criteria

Relevant WCAG 2.1 success criteria

  • All functionality should be available from a keyboard
  • Reference WAI-ARIA authoring guidesExternal link when creating widget components (e.g., menus)
  • Avoid losing focus when navigating and interacting with a page
  • Make sure keyboard focus order matches the order of the visible layout
  • Never use a positive tabindex value
  • Avoid keyboard traps unless required for functionality (e.g., dialogs)

Relevant WCAG 2.1 success criteria