Skip to content
Gusto’s condensed “G” logoWorkbench

Accessibility

Whether you’re starting your own business or beginning a new job, at Gusto, we strive to be there for the moments that matter. As the people platform, inclusion is at the heart of everything we build. We want to create a world where work empowers a better life, for everyone

We strive to meet the WCAG 2.1External link Level AA of accessibility compliance. WCAG is the accessibility foundation, but following the guidelines doesn’t create a great experience. The guidelines must be combined with inclusive and usable design.

All new features and product work should meet these requirements, and over time we plan to help correct any existing functionality that falls short.

  • Accessible design means better design, for everyone
  • We care about creating a product that supports business owners from all walks of life, accessibility is a critical aspect of that
  • It’s a best practice for designing and building software
  • It ensures legal compliance

Gusto uses a tool called tota11y2External link to help anyone at Gusto identify accessibility issues in our local and staging development environments.

tota11y2 layers additional functionality on top of the original version of tota11y, which was developed by Khan Academy to provide an easier solution to uncovering accessibility issues. It doesn’t require additional downloads or configuration and it doesn’t require a great deal of effort—it brings the errors to you. tota11y2 is installed into the Gusto app and enabled by default.

tota11y2 logo
Click the purple accessibility logo on the bottom left-hand side of the page to get started.

Here are some general guidelines on how to best design and build accessible experiences. For component specific accessibility information, check out the individual component’s page.

  • Don’t use color as the only visual means of conveying information.
  • Avoid using red and green together.
  • Use color to highlight or complement what’s already visible.
Example of a good use of color
Example of a bad use of color
  • Many users with low vision still read content on their devices, so providing good contrast is essential for all important information
  • Check contrast for body copy, links, buttons, headers, icons, images with functional text
  • Elements that don’t need to pass contrast: logos, disabled states(inactive menu or buttons).
Level AA Large
> 3.0 Contrast		Level AA Small
> 4.5 Contrast		Level AAA
> 7.0 Contrast
Text or images of text >18 Book or >14 Medium.

Input fields, functional objects, graphical objects, labels		Text or images of text <18 Book.

This includes placeholder or ghost text.		Aim to use for any copy that requires long-form reading.
Example of a good use of contrast
Example of a bad use of contrast
  • For gestures, use simple pointer gestures and avoid complex interactions.
  • Use motion to increase clarity or draw attention to a result / action, but be mindful of strobing effects, which can trigger folks with photo-sensitive epilepsy.
  • Ensure large enough touch target sizes for mobile use(44×44 pixels ).
  • Provide confirmation and success states after input and place errors or alerts in context.
  • Content on hover or focus should be dismissible and persistent
Example of a good use of interaction
Example of a bad use of interaction
  • Use plain language that simplifies complexity wherever possible
  • Use bullet points, headings, and lean on structured content where possible
  • Give users enough time to read and use the content—avoid content that disappears or is animated
  • Write descriptive labels for headers, buttons, links, and input fields
  • Avoid obscure, out of context copy such as “Learn more”
  • On buttons and links, use a verb + noun format (eg: Save form ) wherever possible so people know what action they’re taking—where this isn’t possible use an aria-label on the link target with the verb + noun format. Screen readers may navigate through all the links of the page directly, so if link text does not have enough context on its own it may be inaccessible.
  • Place labels or instructions outside of form fields
  • Don’t use placeholder text as a label
  • Think about it as supporting all senses when possible.
  • Provide text alternatives for media(images or video ).
  • Video transcription or captioning.
  • Allow for viewing at multiple speeds, or the ability to pause or turn off.
  • If it’s purely decorative, no description is necessary.
  • Add alt text descriptions to describe the content.
  • Never add “picture of” to thealt text description.
  • Remember that our big desk power users also benefit from keyboard use !
  • When possible, make everything operable from a keyboard.
  • Follow WAI-ARIA authoring guidesExternal link or use design systems components to ensure standard keyboard interactions
  • Provide visual focus indication for keyboard focus.
  • Make sure keyboard focus order matches the order of the layout visually
  • Never use positive tabindex. Instead, order your HTML in accordance with tab navigation. If tab order does not match visual order, use CSS and not HTML tabindex. - If content automatically hides after a timeout, make sure to provide users enough time to tab to the relevant content or ensure that there is an alternative way to perform the same task which is persistent - Avoid programmatically moving focus, except in very specific situations
  • Dialogs are an exception where focus must be trapped and managed to maintain context