Inclusive Design Guide
Tips and tricks to consider while building inclusive, accessible experiences for Twilio users. These guidlines are geared towards designers and developers alike.
Designing inclusive and accessible experiences may seem daunting. However, proper application of these practices can make your UX faster, more familiar, and available to the widest possible audience. It's also, quite simply, the right thing to do.
This guide includes a lightly modified version of the excellent Inclusive Web Design Checklist by Heydon Pickering. It also has observations and notes from the Design Systems team.
Note: This is not a comprehensive list. Product design and UX engineering are complex functions that can't be solved with a checklist. Instead, consider this as a way to spot areas of opportunity for your product.
We recommend using this guide in the following ways:
- Read through the guide once. We recommend starting with sections that relate to your role. However, reading the entire list will give you a richer understanding of inclusive design and accessibility.
- Share this guide with your design, product, and engineering peers. Engage with them in a conversation about how we could carve some space in our day-to-day work to make our Twilio experiences a little more inclusive.
- Revisit the guide at natural checkpoints of your product's design and development: we recommend doing so at the start of a project, before a UX review, and as a pre-launch checklist.
- Finally, keep us accountable: Track our progress on our GitHub Discussions thread as we apply these principles across this website.
Baseline tips that are useful for all builders of web based experiences.
Alternative text for media content
- Provide captions and transcripts for video content
- Provide descriptive captions for figures
- Provide transcripts for audio content
- Provide alternative text for images that convey information (Learn more about this)
- Ensure PDF content is accessible (include tags) (Learn more about this)
- Avoid images of text, since this text that cannot be translated, selected, or understood by assistive technology
- Provide alternatives and/or descriptions for complex visualizations
Other considerations
- Remove potentially insensitive or uninclusive language, and use "singular they" pronouns in UIs. Consider using a service like alexjs to catch any issues.
- Make sure controls do not elicit unexpected or jarring behavior (For example, do not change behavior or context unexpectedly when a user changes focusor adjusts a control
- Make sure text and background colors contrast sufficiently (Read more about why this matters)
The tips below are important considerations for the product design process. However, they are useful for engineers as well and must be considered at all stages of product development.
Form elements and composition
- Give all form elements permanently visible labels
- Give grouped form elements group labels
- Place labels above form elements
- Mark invalid fields clearly and provide associated error messages
- Do not auto-focus form fields, on page load
- Break up long and complex forms into discrete sections and/or screens
- Make forms as short as possible. For example, consider offering shortcuts like autocompleting an address by using the postcode.
Text and typographic considerations
- Make sure heading levels describe a logical section/subsection structure (Read more about this)
- Translate / spell out acronyms the first time you use them
- Employ well-balanced, highly legible fonts (not too complex or elaborate)
- Do not use very thin font faces (Read an article about why this matters)
- Underline links — at least in body copy
- Avoid justified body text since it creates rivers of spacing that can be hard to read. (Read more about why this matters)
- Provide enough spacing between lines of text (`line-height`) to allow for readers to track text (Read more about this)
- Avoid all-caps text (Read more about this)
- Ensure that content is written as clearly and simply as possible (Read more about why it matters)
- Warn users of links that have unusual behaviors, like linking off-site, or loading a new tab
- Make voice activation cues in your UI obvious with the use of text labels and / or visual affordances.
- Do not mark up subheadings/straplines with separate heading elements (Read more about this)
- Begin long, multi-section documents with a table of contents
- Make sure the purpose of a link is clearly described: "read more" vs. "read more about accessibility"
Visual design and visual affordances
- Include only clear, meaningful animations
- Do not rely on color as the only means of differentiation of visual elements
- Make UI controls look like controls; give them strong perceived affordance
- Avoid pure white or pure black shades
- Indicate swipe gesture support clearly, and provide simple tap-based alternatives
- Ensure primary calls to action are easy to recognize and reach
- Use well-established, therefore recognizable, icons and symbols
- Don't make users perform actions to reveal content unless completely necessary
- If content is meant to be hidden, ensure it is properly hidden to all users
- Inform the user when there are important changes to the application state
Other considerations
- Use the same design patterns to solve the same problems
- Label and describe the same things with the same terminology
- Do not trigger "infinite scroll" by default; provide buttons to load more items
- Avoid time constraints where possible; provide a clear warning and option to extend where not possible
While the tips below are geared towards developers, it is recommended that designers understand these concepts and have conversations about inclusive design with their engineering partners.
Performance considerations
- Minify CSS and JS, and remove unused/redundant code (Read more about why this matters)
- Compress raster images (Read more about why this matters)
- Optimize SVG path data. We recommend this tool for optimization.
- Make sure styles and scripts are not render-blocking Read more about blocking CSS and blocking JS here.
- Install a service worker and cache all applicable assets (Read more about why this matters)
- Lazy load large image assets
- Subset fonts to just the characters needed
- Use `srcset` to tailor images to devices and reduce bandwidth costs
Responsive design considerations
- Support "pinch zoom" (remove `user-scalable=no` if present)
- Use content-based, not device-specific, media queries (Read more about why this matters)
- Provide large touch "targets" for interactive elements (Read more about why this matters)
- Ensure content is not obscured through zooming (no fixed widths)
- Ensure the same content is available across different devices and platforms
Assistive technology considerations
- Use screen reader and keyboard-accessible HTML (Read more about why this matters)
- Honor requests to remove animation via the `prefers-reduced-motion` media query
- Do not recreate supported and expected browser behaviors with bespoke scripts
- Support Windows high contrast mode (use images, not background images) (Read more about why this matters)
- Apply `alt="` or `aria-hidden="true"` to decorative images (Read more about why this matters)
- Use data tables (`table`) for data only, not visual layout purposes
- Make scrollable elements focusable for keyboard users
- Ensure keyboard focus order is logical regarding visual layout
- Do not hijack standard scrolling behavior
- Move focus between dialogs and the controls that invoked them
- Provide status and error messages as WAI-ARIA live regions
- Provide clear, unambiguous focus styles
- Ensure states (pressed, expanded, invalid, etc) are communicated to assistive software
- Match semantics to behavior for assistive technology users
- Ensure disabled controls are not focusable
- Provide a skip link if necessary (Read more about why this matters)
- Make sure controls within hidden content are not focusable
Other considerations
- Use relative units (`em`, `rem`, and `ch`), especially for font metrics
- Do not include third parties that compromise user privacy (Read more about why this matters)
- Provide `title`s that name the site and the specific page (Read more about why this matters)
- Honour DNT (Do Not Track) header (Read more about why this matters)
- Provide a default language and use `lang="[ISO code]"` for subsections in different languages
- Make sure all content belongs to a landmark element (`header`, `footer`, `nav`, `main`, etc)
- Provide a `manifest.json` file for identifiable homescreen entries
- Make sure data tables wider than their container can be scrolled horizontally
- Make content easier to find and improve search results with structured data (Read more about why this matters)
- Provide a print stylesheet (single column, with interactive content hidden)