Sprout Social

Patterns

Accessibility

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: Use our custom focus ring mixin on focused elements.

  • 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

InteractionKeystrokesNotes
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

Related Seeds pages

  • Theme
    • Adhering to our themes should ensure that all your colors are accessible.

Tools

Images and icons

Related Seeds pages

Content

Create a logical flow of information to guide users no matter how they view your interfaces.

Responsive design

Structure

Tools

Copy

Tools

Controls

Help users reach destinations and perform actions.

Interaction

Navigation

Links

Related Seeds pages

Forms

Seeds form components are accessible, but there are a few best practices to keep in mind.

Related Seeds pages

Tables

Structure data tables following accessibility best practices.

Related Seeds pages

Timed events

Ensure experiences aren't relying on timed events.

Multimedia

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

Related Seeds pages

Resources