Inclusive design

No two users are identical. We all differ in our ability to see, perceive colors, hear, control our motions, concentrate, or understand concepts. Inclusive design makes room for every user.

Table of contents#


Best practices#


Assume nothing is perfect#

  • Provide context-sensitive help.
  • Prevent error conditions where possible.
  • Highlight error conditions when they exist.
  • Provide clear guidance when errors occur.

Make room to adapt#

  • Provide targets large enough to see and interact with.
  • Label and describe objects.
  • Enable interaction by mouse, keyboard, pen, fingertips, voice, accessibility API, or other means.
  • Embrace responsive web design. Accommodate web page sizes down to 320px.

Give users a choice#

  • Allow users to customize their experiences inside the app.
  • Respond to system-wide user preferences (e.g., captions, large fonts, high contrast).
  • Ensure that every task can be completed in a logical order using a keyboard alone.

Avoid distractions#

  • Don’t place animations near paragraphs of text.
  • Allow users to turn off unnecessary animation.

Be consistent#

  • Prefer common components for well-defined tasks over new ones.
  • Use common shortcuts across applications.

Involve marginalized users#

  • Include people with diverse ranges of ability in user testing.
  • Document all accessibility-specific features and workflows (keyboard shortcuts, support for operating system features, etc.) and make it easy to find in product help.

Checkpoints#


Structure#

  • Ensure that complex components (e.g., lists, forms, panels) have a logical reading order.
  • Ensure that the keyboard tab order has been defined in a logical progression.
key example of three fields correctly ordered in logical progression, name, email and then password.
key example of three fields incorrectly ordered in illogical progression, email, password, and then name.

Color#

  • Test your interface using the soft-proofing settings for colorblindness in Photoshop and Illustrator. (See View > Proof Setup > Color blindness – (Protanopia/Deuteranopia)-type)
  • Avoid referring to objects by color (or location) alone. Instead, refer to the objects by name or the grouping in which they belong.
Key example of a dialog correctly referring to its destructive action as the "delete" button.
Key example of a dialog incorrectly referring to its destructive action as the "red" button.

Animation#

  • Avoid making portions of the screen flash more than three times a second to help prevent photo-epileptic seizures.
  • Avoid creating content that moves or blinks for more than a couple of seconds to help prevent users from being distracted.

Text alternatives#

  • Include a textual label for all elements. There might be a few exceptions when the context sufficient (e.g., document zoom level “100%”).
  • Include aria-label in HTML (“aria-label” or “aria-labelledby”, depending on the context).
  • Make sure labels are concise and have a clear association with its objects.
  • Ensure that objects in a table or list can be identified by the structure around them (e.g. using a table header).
  • Label all images when possible. In all cases, include a short, meaningful text alternative. Exceptions are for decorative images as outlined in Guideline 1.1 Text Alternatives in the WCAG 2.0 standards.
  • Provide a long description for any object that requires more information to understand or operate (e.g., in a tooltip and coach mark), so that users of assistive technology can read it in context.
Key example of a text field that has been correctly labeled above the field, and icon-only action buttons that have a tooltip to show the label upon hover.
Key example of a text field that has been incorrectly left unlabeled.

Fonts and text#

  • Use Spectrum typography and colors to ensure proper type scale, line height, weight, and contrast for your blocks of text.
  • Ensure that column widths are no longer than 80 characters wide (or 40 CJK characters).
  • Don’t fully-justify text. It leads to irregular spacing and/or tracking that makes it more difficult for readers with dyslexia to parse.
  • When possible, provide options for users to adjust font size, color themes, and contrast either manually, in-app or through OS preferences.
Key example of a block of text that is left aligned to ensure proper readability.
Key example of a block of text that is incorrectly fully-justified, which inhibits readability.

Error prevention and correction#

  • Avoid error dialogs by designing workflows to prevent the error state from occurring in the first place.
  • Anticipate spelling mistakes in search queries.
  • Use appropriate click/touch zones to leave enough space between elements. This minimizes click/touch target errors.
  • Understand that lifting a mouse/finger can be imprecise. Design drag and drop experiences with care.
  • Make errors visually and semantically different from other messages (e.g., including icons, colors, and placement).
  • Associate errors with the field or element that needs to be corrected.
Key example of a text field, correctly communicating an error with both red color, an alert icon, and an in-line text alert.
Key example of a text field, incorrectly communicating an error with only red color.

Keyboard equivalents#

  • Use built-in keyboard focus states defined in Spectrum components.
  • Ensure that users can complete any action using a keyboard, including on mobile (e.g. iPad smart keyboard) by using keyboard equivalents.
  • Set a tab order so that users can move back and forth within a view using the Tab key.
Key example of three components showing their keyboard focus states. Keyboard focus is typically shown with a 2 px blue border around the focused component.