Design systems & Accessibility: the Good, the Bad and the Frustrated Unicorn

A presentation at role=drinks @ CSS Day in June 2019 in Amsterdam, Netherlands by Damien Senger

Slide 1

DESIGN SYSTEMS & ACCESSIBILITY: THE GOOD, THE BAD AND THE FRUSTRATED UNICORN. role=drinks • Amsterdam, NL • June 15, 2019

Slide 2

When discussion about design system, this is one of the regular exemple mentioned by people: Atlassian Design. atlassian.design

Slide 3

A really nice design system with an extensive component technical documentation. atlassian.design

Slide 4

And an even more complete design documentation. atlassian.design

Slide 5

At the same time, what I am seeing most of the time, or what even my projects are having component libraries more looking like this. Castor EDC Component library

Slide 6

Hi! 👋 I’m Damien.

Slide 7

Hi! 👋 I’m Damien. I am a queer digital designer, specialised in accessibility. 🌈 I work for Castor EDC in Amsterdam as a Design systems & Accessibility Lead. Oh, and my pronouns are they/them/their.

Slide 8

I am a designer, and I write & show code 🙀 !

Slide 9

Let’s talk about crushing dreams.

Slide 10

Let’s talk about frustrations.

Slide 11

So basically, let’s talk about design systems & accessibility.

Slide 12

Design Systems & Accessibility: a reality check. 1.

Slide 13

Design systems and accessibility improvements have a common point: it’s a never ending work, and you should not too much time to make it pretty. Photo by Balázs Kétyi on Unsplash

Slide 14

Slide 15

Design systems will not make accessibility less or more complex. role=drinks • June 2019 • @iamhiwelo

Slide 16

Even with amazing component libraries, accessibility can not rely only on it. role=drinks • June 2019 • @iamhiwelo

Slide 17

On the design side: your designs should be accessible. role=drinks • June 2019 • @iamhiwelo

Slide 18

On the component library side: your codebase should be as accessible as possible. role=drinks • June 2019 • @iamhiwelo

Slide 19

React is offering a lot of accessibility features and support… but React will not magically solve every issues. !

Slide 20

Even with this principle, so many things can go wrong. role=drinks • June 2019 • @iamhiwelo

Slide 21

Let’s do a test!

Slide 22

✍ Is there any user generated content? ♿ Are your teammates trained on accessibility? 🎨 How accessible is the brand colour palette? 🕹 Do you have a device lab with screen readers? 🎪 Is there a corporate website not using components? role=drinks • June 2019 • @iamhiwelo

Slide 23

Slide 24

You’re doomed. role=drinks • June 2019 • @iamhiwelo

Slide 25

Slide 26

Relax, breath, :smile: there is solutions. ) role=drinks • June 2019 • @iamhiwelo

Slide 27

How to maintain accessibility in the long run?

Slide 28

I like to consider design systems project as open-source-within-a-company projects. role=drinks • June 2019 • @iamhiwelo

Slide 29

The main flaw with this idea: You can quickly start working in isolation. role=drinks • June 2019 • @iamhiwelo

Slide 30

Slide 31

Slide 32

This button is a completely legit one. This door could be hard to open for a lot of people, making this button useful. But is the icon the good one? Is it really fulfilling its accessible purpose with this misleading label? role=drinks • June 2019 • @iamhiwelo

Slide 33

Accessibility is about the global experience. Accessibility is about details. Accessibility is about everything. role=drinks • June 2019 • @iamhiwelo

Slide 34

Within the component library, you can care about a lot about details. role=drinks • June 2019 • @iamhiwelo

Slide 35

Outside of the component library, accessibility is mainly about the bigger picture: accessibility is about moving users’ focus. role=drinks • June 2019 • @iamhiwelo

Slide 36

Between components, mainly two challenges: moving focus logically & sharing current state. role=drinks • June 2019 • @iamhiwelo

Slide 37

What can we do?

Slide 38

First things first: automise DOM variations as much as possible. role=drinks • June 2019 • @iamhiwelo

Slide 39

A good component should adapt the markup depending on the content provided, magically ✨ role=drinks • June 2019 • @iamhiwelo

Slide 40

role=drinks • June 2019 • @iamhiwelo

Slide 41

role=drinks • June 2019 • @iamhiwelo

Slide 42

Build your components in a way that it avoids not accessible usages of it. role=drinks • June 2019 • @iamhiwelo

Slide 43

role=drinks • June 2019 • @iamhiwelo

Slide 44

role=drinks • June 2019 • @iamhiwelo

Slide 45

role=drinks • June 2019 • @iamhiwelo

Slide 46

Create an environment where HTML & CSS are valued. role=drinks • June 2019 • @iamhiwelo

Slide 47

You are mainly delivering HTML and CSS to users. Please care. !

Slide 48

Create opportunities to learn. role=drinks • June 2019 • @iamhiwelo

Slide 49

Develop a team of accessibility champions with members in every teams. role=drinks • June 2019 • @iamhiwelo

Slide 50

role=drinks • June 2019 • @iamhiwelo

Slide 51

This team is here to help finding solutions or mentor colleagues around accessibility. role=drinks • June 2019 • @iamhiwelo

Slide 52

#shareTheLove role=drinks • June 2019 • @iamhiwelo

Slide 53

Develop and document a series of manual tests everybody can and should do on their work. #contributing.md role=drinks • June 2019 • @iamhiwelo

Slide 54

⌨ Did you test your work with keyboard navigation? 🕹 Did you test it with an assistive technology? 🤖 Did you run Accessibility Insights for Web? 🗺 Did you check your landmarks in the Web Rotor? ✅ Are all tests successful? Any limitation to mention? / Do you know where the device lab is? role=drinks • June 2019 • @iamhiwelo

Slide 55

How can we document our systems for a11y? 3.

Slide 56

WCAG is… not the most readable document. role=drinks • June 2019 • @iamhiwelo

Slide 57

Your documentation should give context-aware guidance on how to deliver an accessible product. role=drinks • June 2019 • @iamhiwelo

Slide 58

And you should start with an accessibility policy. role=drinks • June 2019 • @iamhiwelo

Slide 59

An accessibility policy is an important document about the goals, what’s supported and what’s not. role=drinks • June 2019 • @iamhiwelo

Slide 60

It will make clear what, when and how to test accessibility. role=drinks • June 2019 • @iamhiwelo

Slide 61

And it is a good starting point for the documentation. role=drinks • June 2019 • @iamhiwelo

Slide 62

Let’s talk about component documentation

Slide 63

role=drinks • June 2019 • @iamhiwelo

Slide 64

Each component should support and showcase all possible state. role=drinks • June 2019 • @iamhiwelo

Slide 65

butterfly.com.au role=drinks • June 2019 • @iamhiwelo

Slide 66

You should provide product-specific guidelines. role=drinks • June 2019 • @iamhiwelo

Slide 67

This Atlassian page on Accessibility is interesting: a lot of information about all accessibility good practices. ALL of them. Honestly, would you often re-read it?

Slide 68

role=drinks • June 2019 • @iamhiwelo

Slide 69

Having a page with all information can quickly be over-whelming and difficult to maintain. role=drinks • June 2019 • @iamhiwelo

Slide 70

Prefer accessibility requirements per components: it is context-aware and actionable. role=drinks • June 2019 • @iamhiwelo

Slide 71

Slide 72

How can we test our systems? 4.

Slide 73

0 Snapshot tests are a must have role=drinks • June 2019 • @iamhiwelo

Slide 74

role=drinks • June 2019 • @iamhiwelo

Slide 75

0 Snapshot tests are a must have 1 Each default properties should be tested 2 Each custom properties/states should be tested role=drinks • June 2019 • @iamhiwelo

Slide 76

role=drinks • June 2019 • @iamhiwelo

Slide 77

0 Snapshot tests are a must have 1 Each default properties should be tested 2 Each custom properties/states should be tested 3 Magically resolve conflicting properties role=drinks • June 2019 • @iamhiwelo

Slide 78

role=drinks • June 2019 • @iamhiwelo

Slide 79

0 Snapshot tests are a must have 1 Each default properties should be tested 2 Each custom properties/states should be tested 3 Magically resolve conflicting properties 4 Check that your component handle events correctly 5 Run your component through tools like aXe role=drinks • June 2019 • @iamhiwelo

Slide 80

Automatic testing catch only 15-20% of accessibility issues. !

Slide 81

It is important to regularly run accessibility auditing tools like Accessibility Insights for Web role=drinks • June 2019 • @iamhiwelo

Slide 82

Working with the atomic design principles allows you to split tests to be more readable role=drinks • June 2019 • @iamhiwelo

Slide 83

Atomic design by Brad Frost role=drinks • June 2019 • @iamhiwelo

Slide 84

Atoms are perfect for DOM-related tests role=drinks • June 2019 • @iamhiwelo

Slide 85

Molecules are working nicely with accessibility tests like aXe role=drinks • June 2019 • @iamhiwelo

Slide 86

Organisms are the place to be for focus and event handling tests. role=drinks • June 2019 • @iamhiwelo

Slide 87

Templates can be the higher-level of your tests with a focus on DOM order & sections’ interactions. role=drinks • June 2019 • @iamhiwelo

Slide 88

Ensuring accessibility within a design system is pushing you to create an extensive test culture. (a test culture a bit different than the usual React one) role=drinks • June 2019 • @iamhiwelo

Slide 89

🎉 In conclusion…

Slide 90

Accessibility is as fun as frustrating. 1.

Slide 91

Setup an accessibility policy. 2.

Slide 92

Offer ways to learn more about a11y. 3.

Slide 93

Build a team of evangelists. 4.

Slide 94

Propose a documentation adapted to the product 5.

Slide 95

Develop a series of manual and automated tests. 6.

Slide 96

As a last though: more I work as an accessibility specialist, more I think our job is not about the code, it’s about making accessibility accessible. role=drinks • June 2019 • @iamhiwelo

Slide 97

Merci beaucoup ! 7 Thank you! 8 @iamhiwelo Tack! 9 Bedankt! :

Slide 98

Damien Senger Digital designer, specialised in accessibility. raccoon.studio • noti.st/hiwelo @iamhiwelo