Design Your Products for Accessibility Right from the Start

[irla]

Have you ever wondered how to include accessibility in your design language, so that everyone understands your intent in a heartbeat? Accessibility starts during the design phase, which is why SAP has created a library of assets to enable design annotation, and help ensure that its products are correctly implemented for accessibility. In other words: Design drives the accessibility experience. But before we go any further, let’s explore this combination: accessibility + design.

Designers demonstrate their concern for usability and its principles by attending UX workshops, discussing solutions in the design phase, carefully reviewing progress, and conducting user testing. So why is it that they rarely address accessibility? And, even if they wanted to, why do they so often lack knowledge about this topic?

Let’s start by stating the obvious: Accessibility is considered by many to be a bit of a ‘monster’ – perhaps not right away, but certainly once you start digging into the topic. This is how I felt - and still feel - about the subject. To locate myself in this learning journey, I adapted the Knowledge Growth Process (see image below). I noticed that this helped other designers to plan their own learning paths, as it provides greater visibility about the long journey ahead. It’s only 4 steps, but I assure you, it’s not easy to move from one step to the next. While many colleagues consider me to be an expert, I still see myself at step 2, principally because it’s not that straightforward to apply an intricate and often puzzling set of accessibility requirements to the design context. In a world where most accessibility material is focused on development, I made this my mission: make accessibility something tangible for designers.

 

Knowledge Growth Process

Usability principles take care of findability, layout, consistency, effectivity, efficiency, clarity, learnability and more. But the fact is that accessibility is also considered a usability principle – it’s just a little more complex. Just as usability is paramount to delivering great experiences during navigation, exploration and task execution, accessibility is equally important.

Design is part of the development lifecycle, and like all other roles, designers have accountability and responsibility to define an accessible experience. All roles face challenges to work on this topic, but a common challenge for all roles is ‘education’. Education enables multiple disciplines to speak the same language, align with each other, and define priorities together. Designers are responsible for communicating interaction design to developers – and this should include accessibility and the use of assistive tools. There are strategies to communicate all this. I propose a three-step process to create a product blueprint for accessibility. This is planning accessibility during the design phase, which also contributes to preventing mistakes during the development phase. However, it first requires a designer with sufficient knowledge about accessibility.

From experience, I’ve noticed that while designers are interested in this topic, most of them lack the relevant knowledge to apply its principles. In the absence of appropriate material dedicated to designers, the UX Design advocates for Accessibility from SAP Customer Experience set about creating a series of basic training materials. As these materials cover only part of Step 1 of the Knowledge Growth chart, I had the privilege of joining forces with stefan.schnabel from the SAP Accessibility Center from SAP Design to extend the scope of Accessibility by Design. Stefan was also looking for strategies to simplify design tasks and include accessibility specification for correct front-end implementation. We combined our findings to leverage the capabilities of a recently adopted tool for designers at SAP: Figma. Figma allowed us to create two solutions for designers to annotate accessibility. One was a library of reusable components, and the other a set of two Figma plugins.

Figma’s library contains assets (components) representing important, generic annotations for headings, landmarks, keyboard interaction, and invisible labeling, just to name a few. Some features, such as the order of elements for screen reading, and keyboard navigation are also available as separate Figma plugins.

The assets available in the library cover many aspects of accessibility, including screen reading, focus order and complementary annotation like tooltips, time limits and external content. Guidelines are available to explain how, when, and where to annotate designs in order to address these aspects. For screen reading, for example, the library delivers reading order, landmarks, headings, labels, messages, descriptions with examples, and explanations. The same applies to focus order, where the library delivers order of keyboard navigation, skipping groups, and shortcuts such as access and hotkeys.

I am invested in providing means for designers to deliver outstanding experiences to disabled people – especially blind people. Before code is considered for any application, designers use empathy, personas, and established usability principles to deliver outstanding experiences. Adding accessibility to this sauce requires us as designers to put ourselves in the shoes of our disabled users. For example, it means trying to use our products with just a keyboard rather than a mouse, and turning on the speech output to listen to the UI instead of only looking at it. It also needs us to expand our knowledge, enhance our vocabulary, and discuss the issues openly during design reviews, UX workshops, and user testing. There’s no doubt in my mind that accessibility starts during the design phase, but unless we equip designers with easy-to-use tools and comprehensive training opportunities, designers may well continue to feel reluctant or unable to address accessibility. I trust that accessibility will eventually become a natural part of the design process.