A presentation at role=drinks @ CSS Day in in Amsterdam, Netherlands by Damien Senger
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
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
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
Often, I can hear people saying that their design system will make their product accessible, that it will help them to enforce rules and to do more automated testing. But is it this simple? Will a design system make magically your product more accessible? Let’s see together the good things and the pain points of ensuring the accessibility of your product through a design system.
Here’s what was said about this presentation on social media.
for free. You
can too.