Design systems

Why this matters

Accessible design is about good design for everyone.

When the design system and its team align with accessibility requirements, it’s natural for best practices to become embedded in your products.

Team commitment KPIs

What commitments must the team agree to meet if your organization is going to be successful? What obstacles must be acknowledged and removed for your design system to create inclusive experiences?

It’s more than visuals, it’s about processes

Design systems need to do more than just look accessible. There are key actions the team must take to ensure accessibility actually happens.

What’s covered

• Design system onboarding
• Expectations for review deliverables
• Accessible design patterns

Design system onboarding

As new designers are trained as employees or outside contractors are engaged, it’s important they are briefed on accessibility and what their responsibilities are.

Too often a collection of design assets are shared without the benefit of proper onboarding to predictable results.

Includes best practices and accessibility briefing

In addition to knowing design best practices, designers need to know that the design system team is there to support them when stakeholders resist accessible design principles.

Requirements and policies included

The design system’s requirements should mirror the accessibility policies and serve as a structure to support designers if accessibility priorities are called into question.

Design systems support designers

A design system doesn’t exist to limit creativity, it exists to free designers up to do their best work within the greater ecosystem of products and experiences without having to reinvent the wheel.

Defining and publishing a rigid but adaptable design system means the designers can lean on those requirements and policies to do great work for customers, even when a product owner wants to deviate from the design system.

An incomplete list of why stakeholders desire to deviate from design systems:

• They saw something they thought was cool on another website.
• Standing out from the other product owners seems like the way to get ahead.
• Having never been briefed, they misunderstand how design systems work for them.
• They seem themselves as a true design visionary.
• They want it to pop.

It is important that the design system team feels empowered to advocate for accessibility policies and requirements because there may be times when stakeholders will disagree with design system patterns or be unwilling to prioritize accessibility.

Expectations for review deliverables

Design is not your most important deliverable.

I’ll say that again.

Design is not your most important deliverable.

The most important artifact from the design process is the collaborative conversation the designer should have with the rest of the team about the user experience you want for your customers. The design itself is just the outline of that conversation.

1. Accessibility first approach

You make better products for everyone when you put people with disabilities first in your design considerations.

Designers should show up to design reviews having considered accessibility features, which may include conducting well-rounded research or considering use cases for people using assistive technology.

2. Annotation layer and stickers

Designers will need uniform tools for describing basic accessibility features of pages. Common annotations will include:

• Heading
• Link
• Button
• Alternative text
• aria-label
• Focus and reading order
• Naming of chosen UI components (ex: button vs toggle switch)
• Page title
• HTML landmarks

Stickers are usually placed on a file layer devoted to accessibility annotation in the file deliverables.

3. Defined interactions for custom components

Specialized components modifying or combining interactions need clear direction on keyboard and screen reader experience.

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 team 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?

Example: Carousel

The team 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?

4. Contrast meets requirements

All text and interactive elements should meet contrast requirements. You can easily check with automated tools.

Accessible design patterns

Ensure the design system accounts for accessibility by default in the individual components and the way it is used.

For example, it’s not enough to simply meet contrast guidelines if the headings are in illogical order.

Logical headings

Headings are more than bigger, bolder text. They contain meaning that forms an outline of the page.

• Start with a single <h1> per page. There must be only one.
• <h1> is the meaningful title of the page.
• 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>.

Headings example

  <h1>Taco salad recipe</h1>

    <h2>Ingredients</h2>
    
    <h2>Steps</h2>

      <h3>Vegetable preparation</h3>
      <h3>Grilling the protein</h3>
      <h3>Plating and serving</h3>
    
    <h2>Nutrition information</h2>
    
    <h2>Related receipes</h2>

Decouple headings from styles

Component libraries must decouple styles and style names from heading levels, allowing h1, h2, or h3 to be sized with CSS independent of their headings.

When heading level is directly coupled to size, developers will use headings out of logical order to simply make text bigger or smaller, rather than using them with their semantic purpose.

Naming conventions:

• NATO alphabet (alfa, bravo, charlie, delta, echo, foxtrot)
• Greek letters (alpha, beta, gamma, delta, upsilon, zeta)
• Size based (gigantic, huge, large, medium, normal)

This kind of pattern allows for text other than headings to be sized large without adding unwanted semantic meaning.

Practical example:

<h1 class="large">About our coffees</h1>

<p class="gigantic">All beans are on sale</p>

Using 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

Vertical layout for forms

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.

Alt text conventions

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”.

Sufficient contrast & text size

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.

Color perception accommodation

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

Large clickable target size

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.

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

Responds to reduced motion settings

Reduce, pause, or eliminate animations when a device’s reduced motion settings are active.

Practical examples

• Replace an animated background with a still image.
• Flashy interaction effects are reduced to minimal transitions.