Resonance Design System
☰

Accessibility Resonance adheres to WCAG Level AA accessibility guidelines.

Table of contents

Designs built with Resonance should support people with a wide range of abilities, including people with visual, hearing, physical, cognitive, and neurological disabilities.

There is no accessibility team responsible for ensuring that our products meet these guidelines. If you contribute to our platform, accessibility is your responsibility.

Guidelines

We prioritize clarity and accessibility in every step of the product development process. Review the Vox Media Accessibility Guidelines for more details.

Design

Make sure there is enough contrast between text and its background color

According to the WCAG, the contrast ratio between text and the text’s background should be at least 4.5 to 1 to help those with low vision. If your font is at least 24 px or 19 px bold, the minimum drops to 3 to 1 (though, worth noting that numbered sizes aren’t always reflective of the visual size type). Be careful with text over images.

Color should not be the only indicator or prompt for important information

Include another visual indicator (such as icons to accompany color coding, or an underline on linked text) so that people who cannot easily distinguish colors can follow along.

Pair color hues and values together to increase contrast

When you strip out the color information from two hues and compare the values, there may not be much difference. Pairing different values creates contrast.

Interactions

Design focus states to help people navigate and understand where they are

Don’t hide focus states. When people use the keyboard to navigate, there should be highly visible focus states. All Resonance components have focus states.

Provide clear labels and instructions for inputs

Content

Write good alt text for your images

Be as consistent and clear as possible

Be consistent across functions, layout, placement, and labeling. Components with the same functionality should work and be identified consistently. Use section headings to organize content.

Use descriptive links

Assistive technology can find all of the links on a page and present them in various forms, but these links are useless (to humans and search engines!) if they say “click here.” Links should always describe where the person will go if they select it, giving them an idea of what’s coming next.

Code

Use the right HTML element

HTML elements communicate to the browser what kind of content they contain and how the browser should render or treat that content. The accessibility tree is built off of assumptions about the elements and their structure. This is the browser feature which powers screen readers. Choosing the correct element for the current context is a simple way to create a good foundation.

Be aware of keyboard flow

Browsers support tabbing through link, form, and button elements. This is a quick way to move around the page, but it’s very easy to accidentally hinder someone's ability to navigate this way.

Understand and use HTML landmarks

People who use assistive devices may not want to peruse your content linearly, instead preferring to use an outline view (generated from markup) to find the relevant content for their current needs. These landmarks, like main and form and navigation help define specific areas that someone might want to seek out and can save them a lot of time.

Use ARIA attributes when applicable

ARIA stands for Accessible Rich Internet Applications. It is an optional but helpful spec to define ways to markup HTML that has dynamic experiences (typically controlled by JavaScript).

The goal when using them is to communicate to the browser and assistive technology how content is going to change or what the purpose of the content is. Dynamic error messages can be called out to screen readers; buttons can be linked to content they affect; and other helpful states can be expressed on a code-level.

Skip content links

For people using keyboards as their only input devices, it can be helpful to give them a way to skip past top level navigation to get to the main content. This is typically a button at the top of the page (it can only be visible if active), that, when click, shifts the current focus from the button to the top of the main content of the page. This saves them from having to tab through many elements of navigation.

Avoid text in pseudo elements

Assistive technology relies on HTML to find the content to present to people. It’s possible to create pseudo-elements with CSS to add content to elements, and this added content is visible to assistive technology (except for IE, where it isn’t). So if you use pseudo-elements for things like icon fonts, you should add aria-hidden=”true” to those elements so that screen readers don’t attempt to announce the high-Unicode characters that the icon font is creating behind the scenes. And if you’re using a pseudo-element to convey information that isn’t already in the page (like certain icons), you should provide alternate screen-reader-only text.

Hide decorative elements from screen readers

Decorative elements, such as dividing lines, pull quotes, or non-informative icons, can be hidden from screen readers to ensure that someone only receives relevant information as they peruse the page. This is done by adding aria-hidden=”true” to the element.

SVGs should be assistive tech accessible

SVGs are often used as icons on interactive elements in sites. When this is the case, the SVG should have a title or embedded text (that is visually hidden but available to assistive tech) to ensure that the information of the icon is available programmatically.

Resources