Accessibility
Eufemia aims to be WCAG 2.1 compliant
HTML elements are by default good at accessibility. Eufemia components and its building blocks are also made to include all the needed features to make them accessible.
WCAG 2.1 and Universal design (UU)
From year 2021, all new and existing web solutions has to follow WCAG 2.1.
On uutilsynet.no you can find an easy to read WCAG guide (Norwegian).
Main focus
You as a developer has the responsibility to have the technical knowledge about accessibility. You have to implement and use best practices to make applications accessible for every user. We talk about all kinds of users, people who have temporary or permanent disabilities, so they depend on what you put into the application - as code. Therefore, you have to:
- Test keyboard navigation during development
- Test with screen readers during development
- Test with 200% in
font-sizeduring development
Keyboard users
Should be able to navigate the application by their keyboard only. For those it is extremely important that active focus management is done right and has the required focus ring in place.
2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
Your responsibility
You as a developer has to make sure your application supports keyboard navigation. This will also make your application more assistive technology and screen friendly.
The @dnb/eufemia and it's building blocks are supporting keyboard usage.
Read more about focus management and the helper tools.
Screen reader users
Should be able to use the most common used screen readers like VoiceOver (Apple devices) and NVDA or JAWS on Windows. Read more about screen readers.
4.1 Compatible: Maximize compatibility with current and future user agents, including assistive technologies.
Your responsibility
Good keyboard support is crucial to make web application accessible on for assistive technologies. So - think landmark and semantics first. This includes also typography and best practices for images and illustrations.
200% in font-size {#font-size}
The WCAG 2.1 document is describing it clearly:
1.4.4 Resize text: Text can be resized without assistive technology up to 200 percent without loss of content or functionality.
1.4.8 Visual Presentation: Text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text.
Your responsibility
This means; every application has to be made responsive. Even if the application lives in a static sized container (960px). Use your browser or system settings to change the font-size for testing purposes.
Read more about responsive layouts.
The @dnb/eufemia and its building blocks are build from ground up to support font-size adaption automatically.
Tooling tips
- Use ESLint with eslint-plugin-jsx-a11y in your Code Editor setup.
- Use axe in integration tests
- There are several integrations for Developer Tools, including axe-core
- Testing semantics is never enough, use actually screen readers