The role of Engineering in creating an accessible experience is vital. Engineers need to ensure that the code they make is usable and understandable by everyone.
We need to understand the people who use our products and the different ways they interact with them. We also need to remember that accessibility not only helps people with disabilities – it helps us all.
We aim for all components to meet the Web Content Accessibility Guidelines (WCAG 2.2 AA) and all design decisions to be inclusive. We base Backpack components and guidance on the accessibility considerations listed here.
Navigation
Include Skip links
A skip navigation link assists people with motor disabilities navigate a web page. It lets people quickly bypass content blocks and jump to the page’s main content.
Use landmarks
Landmarks help assistive technology users orientate themselves and navigate around a page quickly and efficiently. If you use multiple landmarks on a page, ensure they have an accessible name.
Build a logical and visible tab order
Some people may only use a keyboard. Creating a logical tab order means they can navigate through all the interactive components easily and in a logical order.
This is usually from left to right and top to bottom. It helps to annotate designs to show the tab order of more complex pages.
Understanding
Use semantic headings
Headings not only help people scan content to find what they need, but they also show the hierarchical structure of the page.
You can think of heading levels as a book with the main title, chapters and subheadings:
- Heading 1: The title of the page, there should only be one per page
- Heading 2: The titles of the various sections on the page. There can be as many as needed
- Heading 3: Subheadings contained within the sections
Don’t skip heading levels
Using correct heading levels helps screen reader users understand the hierarchy of the information on a page. It’s best practice not to skip levels to avoid confusion.
Label all interactive elements
The purpose of all interactive content should be clear to assistive technology users. Using accessible names helps communicate information. These include all form controls, buttons, links, and so on.
Include alternative text on images
Informational, functional or emotionally rich images require a text description to describe the essential information to screen reader users.
If an image or icon is decorative, ensure there is a null accessible name, for instance, a blank ALT attribute or an aria-hidden SVG.
Announce dynamic content
When important dynamic content is either updated or introduced, ensure that assistive technology users are aware of the change. One way to announce these changes is to use an ARIA live region.
Ease of use
Auto-filling forms
Forms that automatically fill out fields benefit a wide range of people, including people with motor, memory, or cognitive impairments.
Flexibility
Respect user preferences
People may change settings on their devices for many reasons. They may need a larger font size, a different colour mode, or to reduce motion effects. Consider how these choices impact the content they receive and respect their choices.
Allow zoom
People with low vision may zoom in or out to view the content easily. Check zoom to 400% without losing any content or functionality.
Technical guidance
Accessible mixins for the web
Within Backpack there are a number of Sass mixins available for use to enable content to be more accessible.
bpk-hidden
Used to hide content visually, and from assistive technology.
bpk-visually-hidden
Used to hide content visually, but make it still accessible to assistive technology.
bpk-visually-hidden—focusable
Used in conjunction with the bpk-visually-hidden mixin, it modifies it to allow the element to be focusable when navigated to via an input device.
bpk-invisible
Hides visually and from assistive technology, but maintains layout.
ARIA labels and patterns
The first rule of ARIA is do not use ARIA (if there is a native solution to what you are trying to achieve).
Often elements don’t need any extra labels or roles, so they shouldn’t be added.
Aria-label should be a last resort when there is no other way to represent the content using suitable elements.
Use aria-live on widgets that have a changing state, such as the progress bar.
Use aria-live=”polite” when a state change needs to be announced. Aria-live=”assertive” interrupts the assistive tech user immediately and can create a disorientating experience. Aria-live=”assertive” should only be used for critical announcements.
Use aria-expanded on toggles to indicate whether they are open or closed.
Use the HTML for attribute to link the label and the input field.
Use aria-describedby to connect the input field to any hint text.
If the role can’t be inferred from the component then add a role to make it clearer, such as, button, tab or menuitem
For other tips and support on complex components see the ARIA Authoring Practices.
Test your work for accessibility
Here are some checks that every developer can practise in their workflow:
- Unplug your mouse – just use the keyboard to navigate through the screen to test if you can see where you are on the page, whether all interactive content is reachable and that there are no keyboard traps.
- Use a screen reader – familiarise yourself with screen readers and how users might navigate content on screen. Testing your work with popular combinations such as JAWS with Chrome or NVDA with Firefox is preferable. VoiceOver with Safari will also help you to find any errors.
Testing guidance can often be found on the available Accessibility tab on the individual components pages.
Wrap-up
Accessibility is a journey, and there will always be new things you discover and more improvements that you can make.
Familiarise yourself with WCAG & ARIA to understand the problems we are trying to solve and uncover technical solutions. Finally, join the A11y Slack channel to learn more from the community.