Skip to main content

Accessibility

Recommendation
Updated
Moved
USE
2022-04-27

What is it​

Accessibility (a11y for short) is the technique of making web pages usable to as many people as possible, regardless of their abilities.

Why we use it​

Around 15% of the world's population self-identifies as having a disability. By not making web pages accessible, a huge amount of people will either find it more difficult or impossible to access the web.

Equal access for all is not only good philosophy, but it is also enforced by laws and regulations around the world.

When to use it​

Einride strives for W3C WAI's Web Content Accessibility Guidelines 2.1, Level AA conformance.

Accessibility should be taken into account in every interface we build.

How to learn it​

The full WCAG 2.1 documentation is a good but long read. WebAIM's WCAG 2 Checklist is a good start to get a feeling for what is required in a shorter format.

Here are some other useful resources:

How to use it​

Follow this guide when reviewing interfaces for accessibility.

Design​

Up to 2/3 of accessibility issues can be avoided by making it a consideration in the design process. Here are some checks to do related to design:

  • Ensure link and button labels are descriptive. Avoid labels like "Next", "Read more" and "Click here".
  • Ensure color is not used as the only visual means of conveying information.
  • Ensure foreground and background colors meet minimum contrast ratio.
tip

Here are the minimum contrast ratios for WCAG AA:

  • 4.5:1 for normal text
  • 3:1 for large text (defined as 18.66px and bold or larger, or 24px and larger)
  • 3:1 for graphics and user interface components (such as form input borders)

There are many tools for computing contrast ratios. WebAIM's Contrast Checker is a good one!

Development​

While a lot a accessibility issues have to do with design, others need consideration in the development stage. Go through these steps related to development:

  • Ensure navigation order is logical and intuitive.
tip

Test navigation order by tabbing through the pages in your app.

  • Ensure all focusable and interactive page elements can be navigated to and interacted with using only a keyboard.
tip

If an element is scollable with a mouse for example, it needs to be scrollable with up/down arrow keys as well. Here are some common components and patterns with related expected keyboard interaction behaviors: https://www.w3.org/WAI/ARIA/apg/patterns/

  • Ensure transform animations are only used when the user does not prefer reduced motion. Examples of how to configure it:
import { usePrefersReducedMotion } from "@einride/hooks"

export const Component = (): React.JSX.Element => {
  const prefersReducedMotion = usePrefersReducedMotion()

  return (
    <Wrapper>
      <Line
        animate={{
          rotate: 180,
          transition: {
            // This is done by default for Framer Motion transform animations
            // when using <EinrideProvider>
            repeat: prefersReducedMotion ? 0 : Infinity,
          },
        }}
      />
    </Wrapper>
  )
}
const Wrapper = styled.div`
  // Use transform animations when the user does not prefer reduced motion
  @media (prefers-reduced-motion: no-preference) {
    animation: vibrate 0.3s linear infinite both;
  }
`
// Showing a visible label is good practice for input components. The label is the accessible name of the input component.
<TextInput label="City" />

// In some cases, a visible label is not desired because the topic is implied by the visual context. Make sure to provide an accessible name with `aria-label` instead.
<SearchInput aria-label="Search for cities" placeholder="Search..." />

Automated testing​

Here are some tools that can be used to make understanding and detecting accessibility issues easier.