More than visuals, designers define the actual user experience for everyone

Why this matters

Starting with a UX/UI design that considers people with disabilities makes the development process faster and will lead to fewer problems later.

Team alignment

Can explain why accessibility is a requirement

Team members possess varying levels of understanding.

The minimum level garners compliance. But when the reasons are taken to heart, your team’s performance can dramatically improve.

Accessibility isn’t just the right thing to do, it’s the smartest thing to do.

Living your organization’s values

Every organization has a set of values, often including core ethical tenets like treating people with respect and doing the right thing.

How does accessibility fit those values? How does ignoring accessibility breach them?

A tool for innovation

Accessible design and development builds better products for everyone. When teams put accessibility at the beginning of their processes, they create more valuable products for your enterprise.

Competitive advantage

26% of the US population has a disability that requires accommodation, making people with disabilities the largest minority in the United States. This adds up to billions of dollars in combined purchasing power.

Accessibility is the law. Designing and building accessibility into products also helps the enterprise avoid legal risk and liability due to a customer complaint.

Can use assistive technology

It is important designers know the basic functions of a screen reader. They don’t have to reach the competence of developers and QA testers.

Screenreader basics

  • Shortcut to browse by headings
  • Shortcut to browse by links
  • Shortcut to browse by landmarks
  • Browse content with the arrow keys
  • Focus interactive elements with the tab key

Knows where to find requirements and policies

It will sometimes fall to designers to explain requirements and policies to developers, especially if they are contractors or 3rd-party partners. Advocating for policies gives weight to what otherwise might be seen as a preference.

Includes people with disabilities in personas

In the UX research phase, designers should capture and describe the goals, needs and any barriers for people with disabilities.

Annotates deliverables with accessibility notes

Include notes for the desired user experience for people using assistive technology in your design deliverables. Don’t let that experience be left to defaults.

Basic layout and structure

The good news is a lot of accessible patterns have been adopted by designing for mobile first.

Keep elements vertically stacked and grouped by proximity

Form inputs and labels should not be spread across the page. Establish a vertical stacking of labels and inputs in the design system.

Stacking content vertically on the page does not represent a challenge for people because it’s customary to scroll up and down.

However, people with low vision may zoom in on their screen, meaning they only see a portion of the desktop layout. This makes it easy to miss required inputs on other columns of the layout.

Research consistently shows that stacked vertical layouts convert better and are more intuitive.

Screenshot illustrating form with vertically stacked labels and inputs

Consider simpler ways to convey content

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

  • Carousels are almost always bad ideas.
    • Interaction with any slide beyond the first visible content is invariably low.
    • Read Should I use a carousel for more information
  • Tooltips are always a bad idea
    • Tooltips are indicative of poor UX copywriting practices.
    • Information contained in tooltips is better served rewritten as a visible hint or as a modal.
  • Modals are often unnecessary and interruptive.
    • Don’t use a modal where an accordion expander or a straightforward link to another page will do.
  • Dropdown select inputs should be used sparingly.
    • Only use where the content order is immediately recognizable by convention (alphabetical or numerical).
      • Ex: Choose a state
      • Ex: Choose a year
    • Use radio inputs if the content contains mixed options (not alphabetical, numerical or logical). instead
  • Be wary of interactive mashups of controls.
    • Combining controls, buttons and interactions is risky.
      • Ex: Text inputs between radio buttons
      • Ex: A link inside a checkbox label


Define headings logically

Headings create a skimmable outline

Headings are more than bigger, bolder text. They 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 exceedingly long or extremely complex pages will need <h5> or <h6>.

Define alt text for images or icons

Precise alt text conventions should be fine-tuned in your copywriting style guide.

Each image should have alt text for screen readers, unless including it would be annoyingly repetitive.

  • Define alt text for images or icons when the image adds editorial meaning to the page.
    • Good alt text allows anyone who can’t see the screen to describe it to someone else.
    • Leave the alt attribute empty if an icon doesn’t add meaning or would be repetitive.

More of an art than a science

The copywriting style guide should determine a consistent voice for writing alt text and when to leave alt text undefined.

For instance, questions of when to call out gender, race, sexual orientation, etc., can be difficult to answer.

Practical examples

  • Describe a banner image of a model using your product.
  • Describe an image of your product in a specific color or configuration.
  • Don’t describe a generic shoe icon next to a headline that says “Shoes”.

Define aria-label for clear interactions

Adding context with aria-label can help a customer using a screen reader understand the action of ambiguous links, buttons and inputs.

Practical examples

  • A link to purchase coffee has the visible text “Shop today”. An appropriate aria-label might be “Shop coffee today”
  • A “Find my location” button features a map pin icon, but no visible text. An appropriate aria-label might be “Find my location”
  • A site search input’s only visible label is a button with a magnifying glass. An appropriate aria-label for the search input might be, “Search this site” and the search button could use an aria-label of “Submit search”

Define name, role and states for custom components

Components that modify or combine interactions need clear direction on keyboard and screen reader interactions.

Example: Password input

A well-designed password input will include a “show password” option. Upon clicking the button, the password is toggled between visible letters and •••••.

The designer should be able to answer:

  • When should the screen reader user be notified their password is visible?
  • What language should describe the hidden or visible state of the input?
  • How will the screen reader declare the “show password” is visible?

The designer should be able to answer:

  • Will the arrow keys operate the carousel?
  • Does the spacebar pause the carousel?
  • What interactions should be documented with testing instructions?

Designing for Low vision

It’s easy to only think about people using a screen reader and not consider people with low vision.

People with low vision often use zoom application tools to enlarge portions of the screen. (Note: This is different from using the browser’s built in zoom settings.)

Associate controls visually

Two interactive components often fail for people with low vision:

Toggle switches

  • Toggle switch visuals are often placed on the far right side of the control.
  • Instead, place the switch visual on the left side, the same way a checkbox or radio input would be placed.

Accordion expander

  • Expander controls are typically a chevron or a +/- button on the far right side.
  • Instead, place the visual indicator on the left side, the same way a checkbox or radio input would be placed.

Stack form inputs

  • It is a generally accepted best practice to stack labels and form inputs vertically rather than horizontally.
  • When forms spread across the page, people with low vision have difficulty finding and completing all the inputs while using a zoom application.

Paragraph typeface should be no smaller than 16px

This helps all people consume content, not just those with low vision.

Typeface scaling may differ

This precise measurement may have to be adjusted to the scale of the actual rendered typeface.

For example, Arial produces a capital letter “M” that is rendered true at 16px tall. Another typeface may render on screen at 14px, even though the code stipulates font-size: 16px.

Justify text left, never fully justify text

It has been known for years that left justified text is easier to read because the difference in line lengths provides a visual cue to selecting lines for reading.

Fully justified text creates “rivers” of white space in the paragraphs and interrupts the reading experience. Do not fully justify text, no matter how cool the product owner thinks it looks.

Ensure color contrast meets guidelines

All components should be able to be mixed and matched and still meet contrast requirements.

For people with low vision, high contrast between text and background makes content consumable. Keeping text a comfortable size helps everyone.

Avoid pure black

Don’t use black (#000000) on white (#ffffff) or vice versa as this can create glare, seem to flash or appear to vibrate/move.

Practical examples

  • Text size for paragraph text never goes below 16px and has a contrast ratio of 4.5:1 or higher.
  • Large text (20px and above) has a contrast ratio of 3:1 or higher.

Screenshot illustrating paragraph text that does and does not meet contrast

Designing for color perception

Don’t use color as the only means of conveying content.

Practical examples

  • A status indicator cannot solely display a green or red dot to indicate being on-track or blocked. It will need text labels to reinforce the meaning for people who may experience color blindness.
  • Don’t display color swatches without text labels

Designing for motor disabilities

Design accounts for keyboard and switch devices

Not everyone uses a mouse or taps their screen to navigate their device. Some people use their keyboard.

Others with limited mobility may use a switch device, akin to a game controller, mapped to keyboard functions:

  • Arrow keys browse content
  • Tab key focuses interactive controls
  • Spacebar or enter keys are used to activate controls

They traverse the UI sequentially to “focus” on one interactive element at a time.

Focus order defined for custom components

It’s important elements come into “focus” in logical order, and those focused items need to be 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.

If designers don’t precisely define the interactions, the feature may not make sense to people using their keyboard or screen reader.

Design for focus states

Include keyboard focus as a default in your design system along with hover, active and other states.

Example: checkbox

At a minimum, a checkbox must have the following states defined:

  • Unchecked
    • Unchecked + hover
    • Unchecked + focus
  • Checked
    • Checked + hover
    • Checked + focus

Screenshot illustrating radio inputs in hover, keyboard focused and checked states

Clickable area minimum of 44x44px

Encourage generous click/tap target sizes for people with motor disabilities.

The minimum size is 44x44px, but merely meeting the minimum is not the goal.

Designing for photosensitivity

Respond to reduced motion settings

Moving features should be stopped but content should still be consumable

Flashing content shouldn’t sequence more than 3x per second

Rethink your decisions if you’re relying on flashing content to emphasize part of your design.

Video or animations should have controls to be able to quickly pause

Video or animations need controls to be able to quickly pause, stop or hide content.

Designing for cognitive differences

Use plain language

Not everyone understands content the same way. Emphasize being clear before being clever in your style guides. Plain language makes content easier for all customers to consume and understand.

  • Avoid using idioms or implying jokes. This can be difficult for people who don’t speak english as a first language.
  • Avoid technical jargon if a simpler explanation will do

Align names and labels with purpose

  • Never use “click here” as a link.
  • Name core functionality according to conventions.
    • Ex: Don’t name your e-commerce “Cart” “Shopping sleigh” for the holidays.
    • Ex: Don’t label a link to purchase a product as “Check it out.” Be clear about the purpose of the link.

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

Customers will try to click on it and become frustrated if content sounds or looks actionable.

For example, don’t have a headline that says “Buy coffee” without making it a link to coffee products.

Your checklist

Download checklist
Team alignment
Basic layout and structure
Low vision
Color perception
Motor disabilities
Cognitive differences
Download checklist