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:
- Low vision
- 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
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.
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
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.
Important information should not be in or over images. Make sure to always caption your image.
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.
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.
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
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.