Design is not the most important deliverable

Your design is a conversation with the developers

The most important artifact from the design process is the conversation the designer can have with the rest of the team about the experience you want all people to have.

Your UI is a conversation with your customer

The UI is a 2 way conversation between your product and a person.

Everything we add to the app needs to enable the smooth flow of that conversation. Anything that interrupts or places barriers in that conversation should be avoided.

When we consider all the ways people will experience that conversation and curate it for people who have a motor, vision, hearing or cogntive disability, we have made sure that conversation is open to everbody.

Designing for blind or low vision

People who are blind or low vision may use screen readers which are apps that read what’s happening on screen to them.

For people using a screen reader, code is the UX

Designers don’t have to learn to code, but they do need to understand that the code is the UX for people with disabilities and it’s the role of the designer to define the desired experience for all of your users. This cannot be left up to the developers.

You’ll need to define

  • Heading structure in a logical way (not just by appearance)
  • alt attributes for images when it’s appropriate
  • Meanginful aria-labels for buttons and controls when the purpose isn’t clear
    • Ex: Repetitive instances links on the same page like “Learn more” or “Terms and conditions” may need an aria-label description in the code.
      • Ex: aria-label="Learn more about treadmills"
      • Ex: aria-label="Treadmill offer terms and conditions"
  • Focus order (the order in which interaction occurs) when it’s not clear from the design
  • Component types:
    • Is an element a link or a button
    • Should a toggle switch be a checkbox or a radio button?

People who are low vision may use zoom tools that enlarge the screen to extreme levels to consume content and increase contrast.

Following best practices for people with vision disabilities creates a better experience for all people.

Designing for color perception

  • Ensure color contrast meets guidelines
  • Don’t use color as the sole means of conveying content
    • Ex: Don’t use red/green for status messages without text labels
    • Ex: Don’t display color swatches without text labels

Designing for physical disabilities

Keyboard and switch devices

  • Not everyone uses a mouse to navigate their device
    • Some people use a keyboard or switch device that may be as simple as a game controller
    • They traverse the UI sequentially to “focus” on one interactive element at a time

Focus order

It’s important that elements come into “focus” in logical order and that focused items are clearly defined.

  • Complex or compact features may need focus order identified for developers
  • The order in which controls logically come into focus matters
  • The default is top to bottom, left to right — just like reading

In this simple looking example, the developers will have a serious technical challenge to construct radio inputs with interactive elements inbetween that follow logical focus order.

If you don’t define precisely what you want, you will end up with a product that doesn’t make sense to people using their keyboard and screenreader.

Radio inputs with accordion expander inbetween

Focus states

  • Design for focus states
    • In the same way you design for hover states, you need to design for keyboard focus

Motor disabilities

  • Interactive elements need a minimum clickable target size
    • Human interface guidelines puts this at 44x44px
    • (If your design is set to 16px (1rem) as a baseline hierarchy, you’ll find that 48x48 fits in nicely)

Designing for cognitive differences

Use plain language

  • Be clear before being clever
    • Not everyone understands content the same way
    • Some people may not speak english as their first language
    • A cogntive difference can affect understanding

Align names and labels with puprose

  • Buttons, links and other interactive features should be conventionally named according to their purpose
    • Never use “click here” as a link
    • Name core functionality according to conventions
      • Ex: Don’t name your “Cart” “Shopping sleigh” for the holidays
      • Ex: Don’t label a “Buy a phone” link as “Check it out”

Don’t write actionable sounding text that isn’t actionable

  • Ex: Heading: “Shop new washing machines” will sound like a call to action rather than a headline

Layout & structure

The good news is that we’ve adopted a lot of accessible patterns without knowing it by designing for mobile. We just need to carry those best practices to desktop.

Design mobile first

  • Small screens force the design to simplify and elevate the core functionality
  • A properly built mobile experience is often accessible by virtue of the limitations of small screens

Define headings logically

Don’t select headings by their size/appearance. Instead select headings based on the structure of the page.

Headlines are more than just bigger bolder text. They should contain meaning that forms an outline of the page.

  • Start with a single <h1> per page.
    • This is the meaningful title of the page
    • There should be only one
  • Title major sections with <h2>
  • Subsections of the <h2> should be an <h3>
  • It should be rare that <h4> and beyond is required.
    • Only very long or extremely complex pages will need <h5> or <h6>

Headings are a skimmable outline

By reading through the headings, you can easily give a summary of the contents of the page.

  • <h1>My favorite taco recipe</h1>
    • <h2>Ingredients</h2>
    • <h2>Steps</h2>
      • <h3>Preparing the protein</h3>
      • <h3>Chopping the vegetables</h3>
      • <h3>Assembly and plating</h3>
    • <h2>Nutrition information</h2>
    • <h2>Related receipes</h2>

Keep elements vertically stacked and grouped by proximity

  • Stack form labels and inputs vertically
    • If a person has low vision and is using a zoom tool, they may not be able to perceive objects on the far right of the page.
    • People will naturally and intuitively scroll up and down, but not left and right
    • Don’t spread components wide across the page.

Stacked text inputs

Consider simpler ways to convey content

Don’t use a complex interaction when a simple one will do.

  • Carousels are almost always a bad idea.
    • Interaction with any slide beyond the first visible content will invariably be quite low
    • Read Should I use a carousel for more information
  • Tooltips are always a bad idea
    • Information contained in tool tips is always better served re-written as a visible hint or as a modal
  • Modals are often unnecessary and interruptive
    • Don’t use a modal where an accordion expander a straightforward link to another page will do
  • Dropdown select menus should be used sparingly
    • Only in cases where the content order is immediately recognizable by convention
      • Ex: Choose a state
      • Ex: Choose a year
    • If the content is mixed options (not alphabetical, numerical or logical) use radio inputs instead
  • Be wary of interactive mashups of controls
    • Ex: Avoid placing controls inbetween radio inputs if possible
    • Ex: Don’t put a button inside a link


  • Paragraph font size no smaller than 16px (the default HTML size)
  • Legal text no smaller than 14px
  • Justify text left, do not fully justify text

Pro tips

  • Use REMs (instead of pixels) to set type sizes
    • REM is the Root EM, meaning the html default font size.
    • If you decide that your Root EM is 16px, 2rem = 32px
  • Decouple semantic headings from default styles
    • Headings have default styles that should be overwritten by a reset stylesheet
    • This allows for page structure to be independent of styles

Images and media


  • Define alt text for images or icons where it adds editorial meaning to the page
    • Good alt text would allow anyone who can’t see the screen to describe it to someone else
    • If an icon doesn’t add meaning or would be repetitive, the alt attribute should be empty


Some people with vestibular disorders or epilepsy can be made seriously ill by animations. These people may use reduced motion settings on their devices, but assume they aren’t using it.

  • Plan how to honor reduced motion settings
    • Moving features should be stopped but content should still be consumable
  • Video or animatinos should have controls to be able to quickly pause
  • Flashing content shouldn’t sequence more than 3x per second
    • If you’re relying on flashing content to emphasize part of your design, please rethink your design decisions