Accessibility in practice

A screen reader is an assistive technology for blind and visually impaired people that reads screen content aloud and/or displays it on a Braille display. Users can adjust the font size in their device settings and according to the Web Content Accessibility Guidelines (WCAG), it should be possible to enlarge the text up to 200 %.

To remove barriers and make Home Connect accessible to blind and visually impaired users, we began by analyzing the app based on the WCAG, focusing on the criteria relevant to visually impaired users. Since the app did not yet respond to font size adjustments, we defined responsive behavior for the most important components as the font size increased, ensuring that no text is cut off or overlapped. We achieved this, among other things, by avoiding fixed heights for components such as buttons and allowing them to grow flexibly depending on the font size. By hiding decorative elements at larger text sizes, we also gained space for the text, thereby improving readability. These improvements were then implemented by the software developers through an extensive refactoring.

A significantly more complex issue is the use of screen readers, which completely transforms how users interact with their smartphones. Through external audits and UX tests with blind users, we—as sighted designers—were able to better understand the interactions and requirements. Working closely with the software developers, we created initial specifications in Figma that describe the desired screen reader behavior. For this purpose, a role (type of element, e.g., button) and a label (e.g., the specific button text) were defined for each element. The order in which the screen reader navigates through the elements was also specified for each screen. Since we develop for iOS, Android, and the web, and certain attributes are sometimes named differently across the various platforms, these differences also had to be reflected in the specifications. For example, while a slider is called that on the web, “Adjustable” is the appropriate role on iOS. To keep the documentation effort as low as possible, we specified the behavior only for iOS in each case and defined elsewhere how this should be translated for the other platforms.

To ensure support for text enlargement and screen readers not only for existing features but also for new ones, the implementation of accessibility was established as a mandatory acceptance criterion for every feature ticket. For designers, developers, and testers alike, this meant acquiring new knowledge about digital accessibility during the implementation process. To support everyone involved, we created a comprehensive guide that presents the WCAG guidelines in an understandable and project-specific format.

We continue to work on improving accessibility, for example by simplifying the screen reader UX. However, based on current App Store reviews regarding screen readers, it is clear that our efforts are paying off.