Accessibility
While it’s recommended to have a full read of the guidelines linked above, this page serves as a summary and quick checklist of how existing and new components can meet our accessibility acceptance criteria. Each Atlas component must pass the A and AA criteria points listed below, before it can be used in a production environment. Please note that all Adjust products need to meet all A and AA criterias of WCAG 2.2, not just the ones relevant to Atlas, which are listed below.
Adaptable Criteria
Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
Identify Input Purpose (AA)
All data input control should make use of the correct type attribute (e.g. type="email", type="tel") to broadly specify the intention of the input field and allow browsers and other tools to provide scoped keyboards.
When applicable, the HTML autocomplete attribute should be used, which only accepts a certain number of specific well-defined fixed values. This allows a more fine-grained definition or identification of purpose than the type attribute, for example, by allowing the author to specify a specific type of name: Name (autocomplete="name"), Given Name (autocomplete="given-name").
Minimum Contrast (AA)
The visual presentation of text and images of text has a contrast ratio of at least 4.5:1.
Exceptions are large text (should have a contrast ratio of at least 3:1), logos, or text that is part of an illustration.
It’s recommended to use a Figma plugin to check for contrast ratios faster, or manually checking rations with a tool like Contrast Checker.
Resize Text (AA)
Text can be resized without assistive technology up to 200 percent without loss of content or functionality. Layouts of components should not break when browser zoom is being used.
Reflow (AA)
Components need to be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:
- Vertical scrolling content at a width equivalent to 320 pixels;
- Horizontal scrolling content at a height equivalent to 256 pixels.
Except for parts of the content which require a two-dimensional layout for usage or meaning.
Component (non-text) Contrast (AA)
User-interface components (e.g. input or buttons) need to have a contrast ratio of at least 3:1 against adjacent color(s). Adjacent colors means the colors adjacent to the component. For example, if an input has a white internal background, dark border, and white external background the 'adjacent color' to the component would be the white external background.
Elements that are in their disabled state do not have to comply.
Text Spacing (AA)
In content implemented using markup languages that support the following style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:
- Line height (line spacing) to at least 1.5 times the font size;
- Spacing following paragraphs to at least 2 times the font size;
- Letter spacing (tracking) to at least 0.12 times the font size;
- Word spacing to at least 0.16 times the font size.
Content on Hover or Focus (AA)
Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden (e.g. the Tooltip component), the following are true:
- Dismissible: A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;
- Hoverable: If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
- Persistent: The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.
Operable Criteria
Keyboard Support (A)
All functionality of the content is operable through a keyboard. This benefits:
- People who are blind (who cannot use devices such as mice that require eye-hand coordination)
- People with low vision (who may have trouble finding or tracking a pointer indicator on screen)
- Some people with hand tremors find using a mouse very difficult and therefore usually use a keyboard
No Keyboard Traps (A)
If keyboard focus can be moved to a component of the page using a keyboard, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.
Disable Animations from Interaction (AAA)
Transitions and animations that are triggered by user interactions can be turned off.
Focus Order (A)
Focusable elements within components (buttons, links, inputs) receive focus in an order that preserves meaning and operability.
Focus Visible (A)
Any component that contains elements the user can interact with must have a mode of operation where the keyboard focus indicator is visible.
For example: when a text input is focused, the gray border turns into a thicker vibrant blue border.
Focus Ring Visibility (AA)
When the keyboard focus indicator is visible (we call it Focus Ring in Atlas), the following are true:
- has a border-width of 2 pixels
- uses the color token
$color-focus - has a border radius that is the elements border radius plus 2 pixels
- fully encloses the element that is being focused
- encloses the element with an inner padding of 4 pixels (excluding elements that are contained in an overflow hidden container)
- when an element receives keyboard focus, it’s focus ring overlays any other element
Pointer Gestures (A)
All components that use multipoint or path-based gestures for operation can be operated without a path-based gesture, unless a multipoint or path-based gesture is essential.
Example
A slider component that allows you to choose a value between 0-100, which is usually adjusted by drag and drop, should also set the value when you click at a point in the slider bar directly. Additionally, you should be able to focus the drag handler and then calibrate the value by using keyboard arrow keys.
Pointer Cancellation (A)
Make it easier for users to prevent accidental or erroneous pointer input. People with various disabilities can inadvertently initiate touch or mouse events with unwanted results. The most accessible way to incorporate pointer cancellation is to make activation occur on the up-event.
- For interface elements that have a single tap or long press as input, the corresponding event is triggered when the finger is lifted inside that element.
- A drag-and-drop interface allows users to sort vertically stacked cards by picking up one card with the pointer (down-event), move it to a new position, and insert it at the new location when the pointer is released (up-event). Releasing the pointer outside the drop target area reverts the action, i.e., it moves the card back to the old position before the interaction started.
Label in Name (A)
Most controls are accompanied by a visible text label. Those same controls have a programmatic name. Users typically have a much better experience if the words and characters in the visible label of a control match or are contained within the accessible name.
Punctuation and capitalization
Avoid programmatic names like “Search…”, or “First Name:”. While it’s fine to include colons and other punctuation in the label, a name of “Search” or “First Name” is the better accessible name.
Minimum Target Size (AA)
The size of the target for pointer inputs (clickable area) is at least 24 by 24 pixels. A valid exception are links within a block of smaller text, which wouldn’t allow a height of 24 pixels.
Understandable Criteria
Help users avoid and correct mistakes.
Error Identification (A)
If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.
Information must never be communicated by color or imagery alone — eg. input validation does not only use color-negative but also a cross icon and a validation message.
Labels or Instructions (A)
To improve the accessibility of our components each input element should have a label. This label ensures that screen readers can properly tell what the input is about. There are multiple ways of labeling an element in an accessible way. At least one of these properties should be set. If none of the labeling properties is provided a warning is shown on the console.
Visual label through the label prop
Components like the button or input fields support a label prop, which either displays a label on or next to the component
Associated label through the aria-labelledby or id prop
Components that do not have their own label can be labeled by another element (e.g. an HTML <label/> or a Tooltip).
To connect the label and input element you have to provide a aria-labelledby property which accepts the id of the labeling element. Alternatively, provide an id property, which can be passed to a labeling element (for instance the htmlFor attribute on the HTML <label/>)
Non-visual label through the aria-label prop
If no label should be shown a non-visual label text should still be provided. This can be achieved through the aria-label property.
Robust Compatibility Criteria
Maximize compatibility with current and future user agents, including assistive technologies.
Parsing (A)
Elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. In short, write valid HTML.
Component Accessibility Checklist
When building a new component, or auditing an existing component in the Atlas library (both Figma and React), make sure that you check all of the points below before release.
Design
- All text has a contrast ratio of at least 4.5:1
- User-interface elements have a contrast ratio of at least 3:1 against adjacent colors
- The component still works at a maximum width of 320 pixels and maximum height of 256 pixels
- When using text zoom, text doesn’t break layout, but results in text escaping, line break, or scrollable areas instead
- There are examples of all possible keyboard focus area (focus rings) on the Figma component card
- If applicable, there are examples how pointer gestures work when using keyboard
- All clickable targets have a size of at least 24x24 pixels
Development
-
inputelements use the correct type and autocomplete attributes - The components layout doesn’t break when scaling the browser zoom to 200%
- Content that appears on
:hover(e.g. tooltips, dropdowns, etc.) is hoverable and dismissible - All interactive elements can be reached by keyboard navigation only
- There are no keyboard focus traps
- All animations and transitions are off when the reduced motion setting is enabled
- When navigating with a keyboard (tab and arrow keys), the tab order makes sense
- The focus ring is always visible when an element receives focus and never being overlaid by other interface elements
- Gestures such as drag and drop, swipes, etc. can be performed by single clicks as well
- If possible, all interactions utilize the mouse-up event
-
inputelements have a name attribute -
inputcomponents and buttons have alabel,aria-labelledby, oraria-labelattribute - The rendered HTML is valid