Accessibility Linters & Dev Tools

[00:00:00]
>> So I think the last things that I just wanted to talk about are like kind of where do we go from here? And we already kind of brought this up a lot, like how do you get started with doing accessibility work in an existing code base? Or how do you set a good foundation like folks are asking about, are there good boiler plates?

[00:00:16]
Or are there good rule sets or, yeah, how do you just start going on this stuff? So I think about it in three different approaches. And for each one, I've put a couple of links in there, not necessarily the packages that I'm advocating for or involved in. But just trying to cover a spectrum of plugin for each main JavaScript framework, some design systems buy some big companies, stuff like that.

[00:00:40]
So I kinda think about it in three phases. One phase, I think that linters are great for this type of stuff. I think adding an accessibility linter, the first one for React, the second one for Angular, the third one for Vue could be really, really powerful. You can configure them to only run on new or edited or saved files, and it'll really give you that experience right in the editor.

[00:01:04]
When you make an image without an alt tag, it'll warn, you run your CI, it'll go really fast. So I'm really a big fan of linters for this stuff, especially because so much of it can be linted. Checking for alt texts, checking for the right, you use a div with an onclick event that's not focusable, these things can be very easily statically analyzed.

[00:01:24]
So, I think step one would always be adding a linter to whatever project you're working on using whatever linting technology you're using. Step two would be, and this is optional, if you're able to making use of these existing code systems, design systems, that are very good about accessibility already.

[00:01:44]
So I linked to Adobe's React Spectrum, and also Google's Material Design. Twitter Bootstrap is another great example, Foundation. All of these big projects, for the most part, spend a lot of time and energy on accessibility. And so if your project allows it by using their modal, their drop-down, their navigation, these things like that, you'll get a lot of freebies, which will be really nice.

[00:02:06]
So you won't have to build tab trapping yourself. You won't necessarily have to build skip links yourself. They have a class, Bootstrap comes with a skip link class. Things like that can be really helpful. I understand that's not for everybody, that you can use another design system. So step three is starting to find some ways to run audits and to automate those.

[00:02:24]
And so my two favorite things right now, we kinda went through this area where there were a lot of tools. There was a big diversity of tools for accessibility testing, and then over the last few years, they've all sort of merged or sunset themselves. And so they're kinda two big players right now.

[00:02:41]
There's Deque, which is this really great company that does exclusively accessibility work. So they do consultations, they do a full audit, they work with you. They do all this cool stuff. But for today, they have a free Chrome DevTool, which does accessibility testing. So this is really great, it gives you a number score, 1 to 100, but it gives you a ton of suggestions, and they spend a lot of energy on this.

[00:03:08]
So it's very, very good just to add it to Chrome and then to be able to run it. So we'll go ahead and just add the extension. And then we can go back to our site like here, and let me pin it and then just run the Axe extension here.

[00:03:28]
So open up DevTools, and then you'll have a new tab in the DevTools. You click this, you can kinda select, so I'm a developer, I accept the terms of service, start using it. Not sign up for a free trial right now. So I'm gonna scan the whole page.

[00:03:47]
And so it'll go ahead, I see, sorry. Yeah, this is one other thing that's worth noting. The DevTools will often struggle when you're using the file protocol. So if you just find an index.html file on your page and you open it in Chrome, a lot of DevTools stuff, Lighthouse included, won't work on those.

[00:04:05]
So if you wanna do it locally, you'll need an actual server running, like a Python server, a Node server, or something like that. But for today, we can just use the Netlify app that I had deployed, which is the exact same site, but it's learn-ally@netlify.com. So I'll go ahead and I'll scan the page here.

[00:04:21]
And then it says okay, it detected these two automatic issues. So it's got a coupe of things. The element location of HTML does not have a main landmark. So it's looking for this landmark of main, the HTML, so we could add landmark main to that. And then I think that's everything.

[00:04:48]
Ensure all page content is contained by landmarks. I think it's the same thing, the container also needs to be one. So these are kind of cool. The thing that I don't like about these which I like about the next one that I'll show better, is the solution to solve this is a little bit confusing here.

[00:05:05]
Whereas the Lighthouse ones, which we'll see in a minute, take you to some really good documentation about how to do it. But Axe is really cool, it catches things that Lighthouse doesn't. And I do use it quite often. So the other option is actually built into Chrome DevTools.

[00:05:20]
So if you just open Chrome DevTools on a modern version of Chrome and you go to Lighthouse, this does a ton of things. I covered a lot in my Chrome DevTools class, so it does performance auditing, SEO auditing, all that stuff. But for today, we're just gonna get it down to just the accessibility test.

[00:05:34]
So just select accessibility and generate a report here. This takes a second, it runs, and then it comes back with this report here. So you can see as far as the Lighthouse goes, it passed all of the audits that were applicable. But we could do things like if we had color contrast, it would catch that, images without alts.

[00:05:52]
Like for an example if I go to, let me close DevTools for a second and go to the screen readers one and let's go to this, oop, not that one, sorry. Where's the second exercise, accessible HTML. And I go to this exercise, which we knew had some broken stuff on it.

[00:06:09]
And I opened DevTools again, and I do an accessibility audit right here. This can be a great way of kind of figuring things out. So these are the things that we did manually together cuz we kinda knew what we were looking at. But it found hey, there's an image without an alt attribute.

[00:06:23]
And hey, all these form elements don't have associated labels. What I really like about this, if you ever run into one that's confusing to you like that landmark one was confusing to me in Axe, they always link to this really good Chrome documentation. So if you say, well, what does it mean to have an associated label?

[00:06:40]
I can click here on the Learn More, and it'll take me to a special page on web.dev that's just like forms like this are failing, how to add a label. All the stuff that we covered in this class, but they'll have a page for each specific rule that might fail, which is really, really helpful.

[00:06:56]
So yeah, so that's the multiple step approach that I always suggest, is getting some linters in place right away, that'll help a lot. If applicable, if doable, using a design system can be really cool. Some of the modern design systems like Adobe's React Spectrum system, you can actually take components without their UI.

[00:07:14]
So you can build your own actual UI on top of them, but you get all that functionality and accessibility with it. So that might be a thought. If you already have a very strict design principle that you're sticking to, sometimes you can use these without the UI level, but it's not always doable.

[00:07:28]
And then also doing these developer tools. One thing that's also cool about Lighthouse is, depending on your build flow, you could add a Lighthouse check into your CICD, so through a GitHub action. So that can be really cool, I've had that at work before, where let's say we have a Lighthouse run and then we'll say fail an EPR that lowers the performance score or the accessibility score, something like that.

[00:07:51]
And then those will automatically get run and flagged, which can be pretty cool if you wanna set up something like that, Lighthouse is very good for that. So the question was, can you show how some of these design systems like React Spectrum allow you to grab functionality without the UI?

[00:08:08]
So for example, I know that the team at Vercel that build Next.js and things that, are using React Spectrum minus the UI. Okay, so here, so they have, okay. So it looks like the React Spectrum itself is with UI, but it also looks like they have sub packages.

[00:08:30]
They have a React Aria package which looks, let's see if I can see what's in it. So here, so for example, if you install React Spectrum button, you'll get the UI and the accessibility. If you install React Aria button, you'll get just the accessibility stuff, and you can style the button however you want.

[00:08:49]
It won't come with CSS. Yeah, it's really cool, yeah, it's like a kind of new thing. I was really impressed when I first heard that, so I worked really closely with the Spectrum team at Adobe. And then when I heard that other teams were using it with their own UI, I was like that's really cool.

[00:09:05]
But I didn't know how they did it, so yeah, this is really neat idea of kind of breaking it out that way.