We strive to meet the WCAG 2.1 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
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.
- 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
> 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.|
- 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
- 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-labelon 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.
alttext descriptions to describe the content.
- Never add “picture of” to the
- Remember that our big desk power users also benefit from keyboard use !
- When possible, make everything operable from a keyboard.
- Follow WAI-ARIA authoring guides 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