We aim to make our software accessible to the widest audience possible. Empowering all people to easily and successfully use our products requires taking an inclusive, Accessible by Design, approach to both Product Design and Engineering.
Accessibility compliance goals
For all of Sprout's web applications, we strive to achieve the Web Content Accessibility Guidelines 2.1 AA level of compliance. This ensures:
our products exhibit our core company values
we are using internationally recognized standards for benchmarking accessibility compliance
we are building our software using industry best practices
Accessible by design
Accessibility is for everyone. Accessibility is about ensuring equitable access to our applications for all people. This includes people with disabilities, and also has many other beneficial aspects such as accommodating a user's personal preference or temporary limitations, power users, SEO and more.
We practice Inclusive Design to make our applications accessible to, and easily used by, the widest possible audience, without the need for special adaptation or specialized design. We follow web accessibility best practices such as semantic HTML and the proper use of ARIA to ensure robust support for Assistive Technologies.
An Accessible by Design approach means we consistently focus on these aspects of Product Design and Development:
Semantic markup with robust support for Assistive Technologies (ATs)
Always use HTML5 tags semantically
Use ARIA (Accessible Rich Internet Applications) roles and aria- attributes to provide Assistive Technology support, but only when necessary
Use components from Seeds to ensure maintainability across the entire application
The focus order of elements within a page should be logical and intuitive
Any important non-text content should be accompanied by a text alternative (alt-text)
Simple and intuitive design
An intuitive and logical design lends itself well to being developed semantically—consider the "outline" version of a page
Experiences should not overwhelm users or behave in unexpected ways
The experience should be functional using only a keyboard
Considerate usage of color
Color is never used alone to indicate meaning, such as validation errors or prompting user action
Text and User Interface (UI) elements should have sufficient color contrast with their backgrounds
Clear and concise copy
The Sprout Social web app is currently accessible to speakers of English, French, Spanish, Italian and Portuguese. In order to best accommodate these audiences, keep copy short and to the point. Translations are more likely to increase in size (character count) and lose clarity from a verbose English source.
Acronyms - must always be defined out upon first-use
The Guiding Questions
Equitable - Is the design is fair and impartial?
Flexible - Does the feature allow for multiple input/output methods to accommodate user needs/preferences?
Perceivable - Can the information be easily consumed? Either visually, through audio, or through other Assistive Technologies?
Understandable - Is the information and experience easy to understand?
Low Physical Effort - Is it physically easy to use?
DO: Consider Accessibility practices as a continuous responsibility for all team members
DON'T: Allow Accessibility features to be an after-thought
DO: Understand expected keyboard navigation before beginning development.
DO: Understand what parts of the feature/product need to be read aloud for screen readers and which parts are decorations that need no explanation.
Keyboard navigation
We aspire to meet the WCAG 2.0 AA standards.
Expected Keyboard Navigation Interactions
Interaction
Keystrokes
Notes
Navigate to most elements
tab
- navigate forward
shift
+
tab
- navigate backward
Clear focus outlines must be present on focused element
Navigation order should be logical and intuitive
Links
enter
Buttons
enter
or
space
Ensure elements with ARIA role="button" can be activated with both key commands.
Checkboxes
space
- toggles checked / unchecked
Radios
tab
- to enter/leave the radio group
↑
↓
- change selection when radios are stacked
←
→
- change selection when radios are in a row
Radio selection should update automatically on keyup
Select (Dropdown) Menu
space
- to expand a select (sub)menu
↑
↓
- to traverse menu items
Consider each element in a Select Menu to be a button, thus
enter
or
space
will activate that item.
If the menu item will open up a submenu, focus on the first element in submenu upon opening.
Autocomplete
Type to begin filtering
↑
↓
- to traverse options
enter
- to select an option
Upon selection of an auto-complete option, focus should go back to the autocomplete text field
Dialog / Modal / Takeover
esc
- to initiate teardown
This will usually just close the modal unless a confirmation/warning modal is required to fully dismiss
Sliders
↑
↓
OR
←
→
- to increase/decrease slider value
Range Sliders
tab
and
shift
+
tab
- focus on either slider handle
Standard interaction for sliders once focused on a slider handle
On PCs, it is standard for
home
and
end
to send a focused slider handle to the lowest/highest value.
page up
and
page down
can also be used to change slider's values by larger increments (usually 10)
Tab Panel (Tab Group)
tab
- to enter and leave the tab panel
↑
↓
OR
←
→
- to change tab selection
This is specifically for "application" tabs that do not require a page reload, if the tab group will reload the page, then consider them as a list of Links, where
tab
and
enter
are more appropriate interactions
Tab content should update automatically upon change of the selected tab
Tree
tab
- to enter and leave the tab panel
↑
↓
- navigate previous/next menu options
←
→
- collapse/expand submenu, move up/down one level
Scrolling
↑
↓
- vertical scroll
←
→
- horizontal scroll
space
/
space
+
shift
- vertical scroll by page.
Always minimize or eliminate horizontal scrolling within our supported viewport sizes.
Accessible design checklist
Visuals
Account for all visual impairments in your use of color and imagery.
Color
Large text (18pt or 14pt bold) can have a 3:1 contrast ratio.
Essential UI elements are “any visual information provided that is necessary for a user to identify that a control is present and how to operate it”.
e.g. active controls, icons without text labels, input borders, etc.
Non-essential UI elements or pure decoration do not need to achieve a minimum color contrast.
e.g. disabled UI, spot illustrations, icons with text labels, etc.
If a piece of UI has text with sufficient contrast against its background, it will not need other elements to have contrast with their backgrounds.
e.g. a button’s fill or border doesn’t need to have 3:1 contrast against its background so long as the button text has 4.5:1 contrast with the button fill.
Essential images should be accompanied with alt text.
Essential icons should be accompanied with an aria-label.
Icons without visible text labels are considered essential.
If an icon has a label that appears on hover, the icon is still considered essential.
Images/icons marked as non-essential/decorative in code (e.g. null alt text, aria-hidden, etc.) will be skipped by screen-readers to not read duplicative information.
Work with your engineers to ensure the desired focus and tab order. The order is best determined by placing elements in the correct order in the DOM, not by setting tabindex values.
Best practices around managing focus:
For forms, bring focus to the first input.
For opened dialogs, modals, menus, etc., bring focus to the top of the container or the first focusable element.
For dialogs and modals specifically, “trap” focus, meaning don't allow interaction with anything outside of the dialog/modal.
When these opened elements are closed, focus should be brought back to the control that triggered it.
Most of the app uses semantic HTML elements, which provide default ARIA landmark regions and roles. This helps assistive technology users get a sense of the page structure. If creating something net new that doesn't use semantic HTML and might need landmarks, refer to the following list of landmark roles:
Banner: header, page's header
Complementary: aside, supports main content e.g. sidebar
Content info: footer, page's footer
Form: forms on a page
Main: main, page's main content
Navigation: nav, page's navigation
Region: section, different sections of important content on a page
Seeds form components are accessible, but there are a few best practices to keep in mind.
Using the “form field” Seeds component will include a label but implementing individual components such as “select”, “input”, or “listbox” will require inclusion of one.
Because it's only visible when the user hasn't entered text, placeholder text is hard to remember. This affects people with cognitive disabilities.
Seeds form input components have “required” as a property.
Including error instructions at the point of error is important to helping users understand where the error is.
Multimedia provided as a text alternative, like a video tutorial, should have proper transcripts and controls. Content that is solely audio or moving, such as background music or animation, should also have proper controls and not auto-play unless it's for a few seconds.
Multimedia as a text alternative
Audio or moving content
e.g. accompany success sounds with something like a success notification on the screen.
If the content is essential, e.g. animating loading state, then this may not apply but you should still consider it. When in doubt about whether an animation might be inaccessible to a user with cognitive or visual impairment, reach out to the DS team.
Changing opacity of content (fading in/out) is normally a good alternative to having it move or scale.
