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

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

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

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

And an even more complete design documentation. atlassian.design

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

Hi! 👋 I’m Damien.

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.

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

Let’s talk about crushing dreams.

Let’s talk about frustrations.

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

Design Systems & Accessibility: a reality check. 1.

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

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

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

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

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

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

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

Let’s do a test!

✍ 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

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

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

How to maintain accessibility in the long run?

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

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

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

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

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

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

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

What can we do?

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

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

role=drinks • June 2019 • @iamhiwelo

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

role=drinks • June 2019 • @iamhiwelo

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

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

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

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

role=drinks • June 2019 • @iamhiwelo

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

#shareTheLove role=drinks • June 2019 • @iamhiwelo

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

⌨ 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

How can we document our systems for a11y? 3.

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

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

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

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

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

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

Let’s talk about component documentation

role=drinks • June 2019 • @iamhiwelo

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

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

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

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?

role=drinks • June 2019 • @iamhiwelo

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

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

How can we test our systems? 4.

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

role=drinks • June 2019 • @iamhiwelo

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

role=drinks • June 2019 • @iamhiwelo

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

role=drinks • June 2019 • @iamhiwelo

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

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

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

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

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

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

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

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

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

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

🎉 In conclusion…

Accessibility is as fun as frustrating. 1.

Setup an accessibility policy. 2.

Offer ways to learn more about a11y. 3.

Build a team of evangelists. 4.

Propose a documentation adapted to the product 5.

Develop a series of manual and automated tests. 6.

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

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

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