Accessibility Tools

[00:00:00]
>> Jon Kuperman: Coming up on our kind of final section here, and I think a lot of this is now that we got all this great information about focusability and ARIA roles and tab content and all this stuff. How do we ensure that our code bases are up to par and how do we ensure that they stay up to par?

[00:00:15]
So kind of broken this section of testing and tooling down into a few different subsections. One of them being like, how do you manually audit your website? How do you check that things are working? One of them being, how can you set up CI/CD to guarantee that your website stays accessible as you keep building things?

[00:00:34]
And then another one is Linters or Authoring tools, basically, as you're kind of writing your code, what tools are out there to help you stay accessible? So gonna talk about a lot of things, there's quite a lot of competition in this space and honestly I've used most of it and it's all great.

[00:00:53]
So if I recommend a certain auditing tool and you have another one that you like to use, please don't, I try to go by most popular, not by best necessarily. So if you've got some workflow that works for you, that's great, the standard is the standard, so if they're auditing the standard, then that's fantastic.

[00:01:09]
>> Student 1: Cool, so one company that I just like a lot is Deque.
>> Jon Kuperman: They've been in the space forever, they do all sorts of cool tools. They have a browser DevTool called Axe DevTools. They also have a JavaScript library that does the same things, I just can't say enough good things about them.

[00:01:29]
They do accessibility consulting, they make all sorts of cool tools, they give cool conference talks. If you're looking for accessibility experts, I think they're one of my highest recommendations, they're great. So they have this tool called Axe, I find it extremely good. It catches as much, basically as much as you can catch automatically as far as accessibility violations go and it's free.

[00:01:51]
They have premium services where you can hook things into regular runs and testing, but it's just a very great tool. So you can go ahead and get this as an extension for Opera or Firefox or Chrome or whatever your browser is and it's very nice. Google DevTools, which now applies to the Edge DevTools and all of the Google based browsers like DuckDuckGo on Brave.

[00:02:12]
They come with Lighthouse and we'll do a little Lighthouse look soon. But essentially via Lighthouse you can run an accessibility audit. Here is a screenshot I took of just a page where it is giving you a score out of 100, as well as detailed instructions for what it considers the kind of accessibility violations.

[00:02:29]
And each one of them links to a nice documentation page where you can kind of see how to fix it. These are quite similar acts in Lighthouse, they're both great. There's also this really cool one and some of these more fun ones, the WebAIM, which is the non-profit that we've been using for our rules and instructions, has this great wave tool.

[00:02:48]
There was a really other cool one, which I think is called totally by the folks at Khan Academy. I think they've stopped supporting it as much, but I kinda like these ones where they decorate your website with where the violations are, kinda makes it very easy to reason about and see.

[00:03:02]
Again, not recommending one over another, but just really like the idea of having some tool in your toolkit that you regularly use to audit your site. And it'll catch a lot of these easy to spot and easy to automate errors, which is nice. Moving on to like, okay, so let's say we've got that done.

[00:03:19]
We've done some audits, we fixed some things. We know our website's in a pretty good spot and now we wanna keep it that way. So there's lots of cool things that you can add to your CI/CD, whether it's like a Jenkins job or a GitHub action, different things like that that will run a similar suite of automated tests and give you a report.

[00:03:34]
The caveat before we go further is accessibility testing. To do a really good job is always going to need a certain degree of manual testing, like we did the tab trapping that's very hard to automate a test for. But these tools are so much better than nothing, so I think that having these CI/CD tools is fantastic.

[00:03:53]
But ideally you would still spend a bit of time manually testing your features with the stuff that we've learned today, like turning on a screen reader, trying to access every workflow with the keyboard, that can go such a long way. But Deque, the same team that makes Axe also makes a product called Axe-core.

[00:04:08]
And Axe-core has this, you can plug it in with whatever your CI/CD system is, like Jenkins or whatever, where you just do a run and then it returns results and they either do or don't have violations. So you can hook this up with whatever your current CI/CD is and they have full instructions on how to do so on their GitHub.

[00:04:25]
In a similar vein, Lighthouse also offers Lighthouse CI. So for those that have used Lighthouse, maybe for performance or SEO audits, it also has accessibility audits, and you can hook those up in a similar way. They also offer it as a GitHub Workflow, so it couldn't be easier.

[00:04:40]
If you're already on GitHub, you can just add this Workflow and on push you can just spin up a Linux distro, do your install and run again. This is all on their GitHub repo, so we can kinda give that a check as well then. Authoring tools these are abundant if you're using a framework.

[00:04:57]
If you're using one of the main frameworks like Vue or React or Angular, that already come with great accessibility plugins. So they'll analyze your jsx, they'll do things like, if you make an image tag, they'll require you to have an alt tag for it. Or if you are making form elements that don't have labels, they'll flag that all as you're developing for you, which is very nice.

[00:05:17]
Going a step further than that, there's also design systems that come with a ton of accessible functionality. So the two that always stand out to me are Adobe's React Spectrum and Google's Material Design, which has libraries for a variety of frameworks. These will give you things like really customizable dropdowns and input boxes and sliders and complex UI components that come out of the box with a huge amount of accessibility.

[00:05:42]
Whether it's color contrast, keyboard accessibility, live regions as things update, all of that stuff kind of bundled for you. So if it's possible, I highly recommend checking these out. Again there's nothing stopping you from rolling your own, especially armed with the knowledge that we have now of how to kind of test these things out.

[00:06:00]
But yeah, there's quite a lot of authoring tools that I think are really great, and you should be able to find one that fits very nicely in whatever your current stacking code base is. At the very minimum, you can get an HTML accessibility Linter that will just at the very least, lint your raw HTML.

[00:06:17]
Cool, so, yeah, these accessible component libraries are really nice, I've used React Spectrum for a long time from Adobe. They have a really nice website, you can play with all their components. Again, this isn't about how your component will look visually, you're free to style your component however you'd like.

[00:06:31]
This is about all that other stuff, just making sure that the screen reader works well, that updates are read aloud, that it works really well with the keyboard and the arrow keys and Escape closes it and Space triggers it, all of these different things. So they basically offer on the right a whole list of pickers, collections, buttons and then you can implement those and style them however you'd like.

[00:06:52]
Google's material design is very similar.
>> Student 1: Yeah, they might not be related to this, but when we were talking about the forms generally, what's the best way way to handle validations to screen reader?
>> Jon Kuperman: That's a really good question. Yeah, so form validation is quite a big topic in general as far as like with the screen reader, I would say that you've got a few different things.

[00:07:13]
So making use of these semantic components are fantastic because for example input type email or input type password, different things like that they will register to the screen reader and read aloud when you violate. So they'll inject, I think it's like yellow on Chrome it says invalid email that will read aloud to the screen reader by default.

[00:07:33]
So I think the first step I would say is trying to use those kind of semantic elements whenever possible because they come with so much functionality on top of that. More than that, I would say probably the thing to do would be make sure that your form has a label that there's some kind of DOM change that happens when you fail a validation.

[00:07:51]
And, and to wrap that in a live region would be really good. So if you have a little span that's empty, you wrap it in a sort of live region and then you put invalid password in there, whatever your validation is that'll read aloud to the screen reader.

[00:08:03]
But always my first thing I grab for is these standardized built in APIs because they do all of that for you. Great question.
>> Student 2: And just to add on to that, in Marcy Sutton's web app accessibility course, she does a little bit more with JavaScript accessibility and also form interaction and kind of making landmark elements and some of the built in form elements.

[00:08:27]
>> Jon Kuperman: That is awesome, yeah. I actually do have a shout out to her course at the end of this course, so yeah, that's great, great.