Skip to content
search icon
clear
Component Status

Accessibility

All digital interfaces should be inclusive and accessible for everyone---regardless of impairments or abilities. Improving accessibility is not only the responsible thing to do, it also enhances the usability for all users. Please use this section as a guide to help ensure your experiences meet or exceed the standards for accessibility.

The UI components for all Equinor's internal digital interfaces are built to meet the WCAG 2.0 and Difi.no AA level requirements. While the components built are accessible, as a customer of the EDS there are things you need to remember when creating layouts and prototypes, and combining components.

What is accessibility?

Accessibility ensures that users of different abilities can understand, navigate, interact with and contribute to the digital interface in a meaningful way. This means:

  • Keyboard interaction alternatives for all mouse-based actions are provided.
  • All button and input fields are properly identified.
  • Images, SVGs and videos have text-based alternatives.
  • All components are built to convey their identity, operation model and state to assistive technologies.

What are different abilities?

There are many different types of abilities that need consideration:

  • Age
  • Blindness
  • Low vision
  • Colour-blindness
  • Hearing disabilities
  • Physical disabilities
  • Cognitive disabilities
  • Situational disabilities (such as a broken arm)

There are also different types of situations that need consideration:

  • Physical location
  • Limited screen size
  • Lighting issues

Guidelines

Spacing

To comply with accessibility guidelines, all interactive components must have at least 8px between them. This is to prevent users from accidentally clicking the wrong place.

Consistent headings

Strive to make your menus and hierarchies consistent. Use H1, H2, H3, etc., in the correct order. This helps all users navigate and browse the page efficiently.

Form validating inline

Make sure to use the helper text when validation fails. Keep the helper text short and to the point.

Text and its meaning

Remember that text can be both visible and invisible alt text. Make sure all text is meaningful in its context.

Call to actions

Provide descriptive labels---action verbs are good.

Here is an example:

Acceptable: See all platforms Indicates what will happen
Not acceptable: All platforms Does not indicate what will happen

If a button's text says "See all platforms", make sure you send the user to a page with all platforms. Be consistent with how you use verbs and which terms you use.

Images

Important information should not be in or over images. Make sure to always caption your image.

Colour

Use the colours provided in the EDS. They have been tested to make sure your work will be WCAG 2.0 compliant.

Many users have trouble distinguishing colours from each other, so make sure colour is not the only way you convey certain information. For example, danger should not be indicated by red colour alone.

Exceptions

If you need to use additional colours for domain-specific requirements, charts or graphs, make sure to test your colours for contrast. Use high contrast, as this both increases readability in general and assists users with impaired sight.

Navigation Order

Place components on the page in order of importance---the order in which the element receives focus should be logical and predictable. Try to keep navigation to a minimum of steps and make all steps clear.

Try navigating your own solution by only using a keyboard. Can you navigate? Can you perform all the important tasks? Can you tell where the keyboard focus is? Do your items follow the order you think? Generally, focus travels up to down, left to right. Test it out by using your tab key.

Validating your work

The EDS is only a foundation for accessible design and development. Accessibility is the responsibility of the entire team---designers and developers have specific responsibilities listed in the related sections.

Please familiarise yourself with the guidelines from WCAG 2.0 and Difi.no to verify your interfaces meet the AA level requirements.

Tools and resources

Here are some resources to help validate your work:
WebAIM
Are my colours accessible?
The A11Y Project

✏️ Edit this page on GitHub