Check out a free preview of the full Design Systems with Storybook, v2 course
The "Accessibility Testing" Lesson is part of the full, Design Systems with Storybook, v2 course featured in this preview video. Here's what you'd learn in this lesson:
Steve highlights the accessibility testing features within Figma that are enabled by installing the addon-a11y package. Violations will be listed, and the issues can be visually highlighted in each story.
Transcript from the "Accessibility Testing" Lesson
[00:00:00]
>> Let's talk about some various ways. There is an add-on, it's not in there by default, which seems criminal. But there is an addon that will both show you actually how these look with either blurred vision or various different color, things. I'm not entirely sure what the right word is, so I'm just gonna be vague.
[00:00:27]
And so you can kinda see what it looks like, which is super useful. But then if you have this on the bottom bar as well, which you would argue that I would have shown earlier, you can move this to the bottom. You've got interactions that are accessibility. And for running X-Core, will show you some of the basic, does it have the right ARIA attributes?
[00:00:49]
Does it pass color contrast? That is the one, who thinks my text area was good enough? I don't think. Dark mode, though, wasn't right in dark. Yeah, violation. Right, a violation, it was fine in light mode. In dark mode, there's not enough contrast on that character count, right?
[00:01:09]
So let's pretend that I did that on purpose and fix it. So we can go in now. I totally did it on purpose. So go in here. So slate-600 is probably not enough. One can literally, Still not enough. 400 did the trick, right? And this is great on a component level because when we did the accessibility, Death March, right, just fix the issues.
[00:01:49]
You have a lot of other things like h1, h2, h3 headings in the right order. In a world where you're not writing a web page, and everything's broken up into columns, might be the end of me at some point. And that's the thing, but actually being able to see it on an individual component level.
[00:02:05]
And then theoretically, if you run it through Playwright, every page fails for the same reason, right? And so we checked at the very end and we did a manual audit with the design team, but checked at the very end, but it was untenable to take the overall site ones because yeah, that's a component layout in an app.
[00:02:25]
The same header failed on every single page. It is easier to have the header and storybook in your design system. Go triage it there, get that one working, move on to the next component. Again, the fun of being both a manager and an engineer is you go into your component library, you do ls, right, to get all the files.
[00:02:46]
And then you use multi-cursor and create the title for the JIRA ticket called fix Excel issues in this file in your design system, and then you put them into a sprint and you all regret choices you made in your life, right? And but having as an individual component one by one in a way that we could check off, and not just having to stare at a page and go for it, is probably the only reason we were able to get it done super fast, right?
[00:03:12]
And so some of these structures, yes, for design system, for sharing design consistency, all of the things that every designer who has ever talked about design system tries to sell you on. As an engineer who has to do stuff, also these same tools make my productivity as an engineer way better.
[00:03:33]
All right, the other thing that we can do with the accessibility testing, I'll kinda show you this real quick. Is turns out there is a magical third file in that .storybook directory that you can create, and that is called test-runner.ts, which are some configuration options for your test-runner.
[00:03:56]
I am not gonna type this in by hand. So if you need to add it, that is the addon, it was already included in there for you. Let's look at this, which is basically you can configure the test-runner, which is, again, playwright effectively. So we've got axe-playwright, axe, which is the accessibility auditing tool, playwright, which drives the Chrome browser.
[00:04:22]
Side comment is on the paid versions of Chromatic, the free, you run Chrome. But Chrome's not the problem, you were using Chrome when you developed. What browser broke?
>> Safari.
>> Safari, right? You can also have it run Safari. And that is, for me, as a person who has access to my own budget, [LAUGH] that's why I opened the first strings, because three people at my company, I have the stats of how many people visit my site in Safari.
[00:04:57]
It's not a lot, but people I work with who are loud, one uses Firefox, one uses Safari, don't wanna hear it. Also, a certain company that makes Safari might use the open source version of a product, anyway, so I've heard. Can't confirm or deny that. So, yeah, those things are important.
[00:05:18]
And so you can run with Safari. But anyway, as I was saying, you injectAxe, this is really effectively Playwright code that's running through the Storybook configuration. And to say, as you leave each story, all right, go ahead and run the accessibility audit test. I don't have a lot of components.
[00:05:42]
If when we were to load in the badges, the dark mode danger badge, maybe that one was intentionally low contrast until I realized I differently, intentionally made a mistake. Not a mistake, an intentional choice as well but it will also run through. So again, the fear is always that, it's always the little things.
[00:06:04]
Nobody intentionally, doesn't do these things. What happens is one well meaning change at one point causes a regression. If you don't have automated tests, they build up until the next time someone goes through and does an accessibility audit and realize that all systems decay into entropy, right, including your best of intentions.
[00:06:29]
And so if it's not an automated in your CI/CD, it ain't happening. So cool, I don't know if anything will fail at this point since we did fix the issue we had, but we'll find out together. We did have one accessibility violation found in LengthTooLong, so let's go take a look at that one and see what our issue is.
[00:07:05]
Possibly my red, but something, again, is not, the cool thing that you can do, I think it's just my window a little bit too, yeah, my window is a little bit too crammed. Show me, there it is. This checkbox, it's worth the price entry right here. Where it says highlight results, I check that box.
[00:07:27]
It shows me exactly where the issue is, right? Again, it's my count that I added at the last minute, because I thought it'd be fun. That is, again, not meeting the accessibility contract, but that ability to highlight the change and actually see it is huge. Do I wish I had that a long time ago, and it's one of the reasons that I think developing in Storybook is also incredibly powerful on top of all the design system, accoutrements that you get.
[00:07:54]
That is worth the price of entry right there. Let's be good people and fix it. So we've got that. Cool, cool, cool. And so let's brighterize that one, too. 400 did the trick last time. I'm hoping 400 does the trick this time. Zero violations. We're good. So yeah, but super helpful because it did catch something I wasn't even aware of.
[00:08:21]
I can hand-wave you, tell you, and it'll catch things you're not aware of. It's really great when it catches something it was not aware of.
Learn Straight from the Experts Who Shape the Modern Web
- In-depth Courses
- Industry Leading Experts
- Learning Paths
- Live Interactive Workshops