We strive to make our products and services intuitive and accessible for everyone. We are continuously working on ensuring the accessibility according to the European standard for digital accessibility (EN 301 549).
#Why Is Accessibility Important to Us?
Enhanced Usability for Everyone
Improving accessibility often enhances the overall user experience for all users. For example larger touch targets reduce misclicks, whether you're using your phone while walking, on a shaky commute, or just have larger fingers. Tooltips on icons clarify their meaning for all users, not just blind users relying on a screen reader. And keyboard navigation not only benefits users with disabilities, it also helps our digitec power users and anyone in a situation where a precise click isn't possible.
Legal Compliance
Complying with accessibility standards can help us avoid potential legal issues. The European Accessibility Act (EAA) aims to enhance the functionality and accessibility of products and services within the European Union. It covers a wide range of products and services, including e-commerce services.
SEO
Although Google doesn't officially rank sites based on accessibility, many accessibility best practices also improve SEO. For instance, semantic HTML and well-structured content help both screen readers and search engine crawlers understand the page better.
Wider Market Potential
By making our shop accessible, we significantly expand our potential customer base. Around 1.8 million people with disabilities live in Switzerland (Switzerland - Disability:IN) and an estimated 87 million people with disabilities in the EU (A new ambitious EU Disability Strategy for 2021-2030).
#How Do We Ensure Accessibility?
Accessibility is not a one-time effort. It's an ongoing process that requires continuous attention. It's much easier to build accessible features from the start than to fix them later.
We have to prevent issues on different levels. Similar to bugs, the fastest and cheapest way to catch them is during development.
#Automated Testing
We regularly run automated tests to catch as many issues as possible.
Field Reporting
We continuously collect feedback from employed power users through an automated validation system. This approach allows us to detect issues that are being deployed into production at a component level, giving each development team the visibility they need to resolve specific issues in our shopping experience.
To do so we connect a DOM mutation observer with our internal browser extension to continuously run @axe-core accessibility validations and report the results to Datadog.
Browser Extensions
Besides your browser's built-in Accessibility Tree Inspector (Chrome, Firefox) there are also helpful browser extensions to test for accessibility issues.
Linting
To catch accessibility issues as early as possible, while writing code, we use eslint-plugin-jsx-a11y in combination with eslint-plugin-styled-components-a11y (which also works with next-yak).
#Manual Testing
Not everything can be detected automatically. That's why manual tests (by designers, devs and product owners) and usability tests (with real users) are crucial to ensure usability for everyone.
Quick Checks
- Do all images or GUI components have meaningful text alternatives?
- Can users understand everything without relying on color?
- Do animations respect the "prefer reduced motion" option (see Accessibility And Reduced Motion )
- Are all interactive elements reachable with the keyboard by tabbing through the page?
- Do all interactive elements have focus styles?
Extended Checks
Testing on screen readers is recommended when launching new features.
- Are all interactive elements announced correctly by screen readers?
- Are there headings for important content regions?
- Are we using the correct semantic HTML elements?
- Are all elements announced correctly?
- Does the text output alone give enough context to understand the UI on a screen reader?
Example: A "Show more" button often lacks clarity about what content it reveals. Adding alternative text with more context can improve accessibility. For instance, you can use:
<button aria-label="Show more specifications">Show more</button>
#Screen Reader
iOS: Apple VoiceOver
Android: TalkBack
MacOSX: Apple VoiceOver
- Toggle on/off:
CMD + F5 - Default Voice Over Key (
VO):CapslockorControl + Option - Next/previous Element:
VO + Right Arrow / Left Arrow - Open rotor:
VO + U(then navigate withArrow keys) - Read all content:
VO + A - Interrupt reading:
Control
Windows
#FAQ
#1. What is the Accessibility Tree?
The Accessibility Tree is derived from the DOM. Assistive technologies like screen readers use this tree to convert content into speech or braille, making it accessible for blind users. To better understand screen reader outputs, the Accessibility Tree can be inspected in browser developer tools (Chrome, Firefox) similar to the DOM.
#2. How to add content just for screen readers?
The component VisuallyHidden allows to add content to the DOM and Accessibility Tree without displaying it in the GUI.
This is useful to provide more context or additional information on screen readers. For example headings are important anchors for orientation and navigation on a screen reader. Even though we don't visually show a heading before the search input, we should still include one since search is an essential part of our shop.
import { VisuallyHidden } from "@blocks/ui";
<VisuallyHidden as="h2">Search</VisuallyHidden>;
#3. How to remove content for screen readers?
To ensure content that serves no functional purpose (like purely decorative images) is not read out loud, you can remove it from the Accessibility Tree using aria-hidden="true".
For example, a decorative illustration:
<img src="decorative-image.jpg" alt="" aria-hidden="true" />
Be cautious: elements with aria-hidden="true" cannot contain interactive or focusable elements (see https://dequeuniversity.com/rules/axe/4.10/aria-hidden-focus).
Additionally, for elements used purely for layout (e.g., layout tables), use role="presentation" to strip away native semantics without removing the content from the Accessibility Tree:
<table role="presentation">
<tr>
<td>Layout Table Cell</td>
</tr>
</table>
#4. How do users navigate with a screen reader?
Screen readers offer various navigation methods, depending on the user’s needs. Common patterns include:
- Moving to the next or previous element (any type)
- Jumping to a specific type of element (e.g., button, input, heading)
- Using the “rotor” to jump directly to landmarks (navigation, main content, footer, etc.)
- Skipping through headings for quick navigation
For mobile users, swiping through headings is a common pattern. That's why it's important that content is well-structured with logical heading hierarchies, and even headings that are visually hidden should be used to help with navigation.