Testing Overview, Linters & Dev Tools

[00:00:00]
>> So some screen reader stuff, you can dive way deep in this obviously, we just scratched the surface. What I really want you to know, kind of going forward, are some tips for debugging. So screen reading might be one aspect of debugging. So debugging, you could also call web accessibility testing.

[00:00:21]
It's something all devs should do. It's regular automated testing or learning concepts about security or performance. I think accessibility is even more foundational than some of those things because of the direct impact on how our user interfaces affect people's lives. I guess yeah, all of these concerns are important.

[00:00:43]
But I think accessibility testing should be part of your regular workflow. And once you get in the habit of opening up the tools, testing it, hopefully, it will just lodge in your mind like it has for me so that it just becomes a matter of habit of, okay, I'm going to test with the keyboard.

[00:01:03]
Okay, I'm going to test with the axe extension. So that's the first step I take is, I use my tab key to navigate through a page. It's as simple as it sounds. You hit tab and tab through things you see, can I reach and navigate? Or reach and operate every interactive control on a page.

[00:01:24]
So if a mouse user can click on it, as a keyboard user, I should be able to do the same task. It might not be the exact same element, I might have a click event on a wrapper element or something that only mouse users use, but then within that, I have a focusable link, or a button, or some other way to do the same thing.

[00:01:47]
So I wanna be able to accomplish every task as a keyboard user. And if you ditch your mouse completely, like just don't use it for a day, maybe you could put some paper over your trackpad or it seems a bit extreme, but you know what I'm saying? If you can have a process where you cannot bail out and use your mouse, you're probably gonna find some issues that need to get fixed.

[00:02:12]
Yeah, because it's pervasive, but it's something we can address and a lot of cases. So can you reach and operate every control? Can you see where you are on the screen? Is there a focus outline? We have the default blue. I will say the slide materials that we have right now, the whole sidebar is a series of components that I really want to contribute back to.

[00:02:36]
It's not exactly how I want the keyboard accessibility to be. So sometimes you have to go open up an issue or a pull request on an open source library and say, hey, can we make this configurable or can I just contribute a fix for this? That's probably what I'll do.

[00:02:55]
Because when these menus over here on the left are closed, we should be able to skip by them, it's It's actually forcing me through every single link in the sidebar, which can get tedious. As a sided user, I can skip by those sections cuz they're collapsed. But as a keyboard user, it's opening them to try and be helpful, but it ends up being kinda annoying.

[00:03:18]
[LAUGH] So that's why we have to test it. So I'm just trying to get through here, some skip links could be helpful too. If I could skip past this sidebar, I think that's a feature that I'd like to add to this. So I've got a little theme picker on the bottom left of the screen so I can get between dark mode and light mode.

[00:03:39]
If I hit enter on that, it opens up a little dark Light mode, dark mode picker. And it said focus to that, so it opened that interactive widget. And then I can use my arrow keys to go through these items, that's pretty slick. Can I hit the Esc key?

[00:03:55]
Yes, I can, so Esc took me back to the button that prompted that to open. And then I can skip on by, I can get to all of the interactive things on the page. Something you don't want to have happen is you don't wanna get stuck behind any layers.

[00:04:12]
If there's a modal dialog, we wanna send focus into it and replace it when it's done, and I shouldn't get stuck back there. Cuz mouse users aren't stuck back there, they can mouse around and do things. But keyboard and screen reader users are often literally left behind. [LAUGH] So we can avoid that with some focus management.

[00:04:32]
And can I use other common key commands like Esc or the arrow keys or the space key? So we tested with the Tab key. The next thing that I would do is open a browser dev tools extension like Axe for Chrome or Firefox or Edge, and we'll do all of these steps in a minute.

[00:04:51]
I also zoom the page to at least 200% on my Mac keyboard, that is Command Plus, and I can zoom weigh in. It conveniently mimics my responsive breakpoints and stuff. So anything you do for responsive design will work for zoom and magnification, something we call reflow which is very awesome.

[00:05:19]
That that just works together. So I can zoom back out with Command minus, I think it's control plus, control minus on the Windows keyboard. So by zooming in regularly, you can see, do the layouts, reflow. Are there any components that are straight up broken, like interactive things are happening off screen, or you have horizontal scrolling where you shouldn't?

[00:05:43]
And that is so that people who are low vision, who zoom way in, can still navigate. And there's some exceptions, as we'll talk about a little bit later, like some interfaces are just going to have horizontal scrolling and there are exceptions. But for the most part, it should be responsive and reflow these days.

[00:06:02]
We wanna test other visual modes. So like on this site, I have light mode and dark mode. I had to fix a few things, I think in light mode, it didn't look great, but in dark mode, it was great. So I just had to add some CSS for that.

[00:06:19]
I have running a screen reader, is pretty far down the list. So it's It's not the first thing, conceptually, we wanna know about it, but it isn't in my even top three things of how I test. But when you do, because you should, pull up those cheat sheets for whichever screen reader you're testing.

[00:06:39]
Double check before filing an issue on Jira, maybe get another opinion or you can work with people who use screen readers regularly as well, and that's very important. We shouldn't just guess, we have all these biases, we're new to screen readers, we can see the screen. If you can work with people who use screen readers and pay them for their time, that's gonna yield way better results.

[00:07:06]
So whenever you can do that, you should. And then kinda just to make sure we don't miss this, for media content like audio or video, make sure that there are transcripts and/or captions. And make sure your media players can accommodate that content. So these steps could apply to any website or web application.

[00:07:29]
I got a great question, just like random email question, about someone who was curious about the accessibility of Microsoft 365. Just like randomly asked me that question, and I thought, that's a good question because people are evaluating. Tools to use and they wanna know how accessible it is, and so these techniques would apply to that.

[00:07:49]
It's cloud-based web software, it needs to be accessible. So these techniques are things that I would use to evaluate that if I were looking to procure a tool for HR or anything. And fortunately, there are some sort of crowd-sourced feedback on accessible platforms you could search for Microsoft 365 accessibility.

[00:08:16]
Microsoft might even have some of their own documentation on it, but just to kind of make drive home that like anything that's It`s web-based, can be tested with these techniques for the most part. So those are the steps, and we will use these steps in a little bit.

[00:08:34]
So Linters and DevTools, there's a ton of different tools that you can use, different browsers have built-in browser Devtools that are excellent these days. Chrome is my choice that I reach for all the time. I know sometimes the Chrome and their practices, Google, is not people's preferred browser.

[00:08:59]
So some people use Firefox, and there are awesome tools in Firefox now. Their color picker is amazing, it can help you identify the contrast ratio of different elements. That's one of my favorites, great layout tools as well in Firefox. Safari also has awesome tools, they're kind of forgotten about, but there's some accessibility inspector things and audit feature, the responsive design mode in Safari.

[00:09:30]
It's pretty excellent as well, built into Chrome is Lighthouse. It is an accessibility auditing tool built into the browser. It runs the Axe-Core JavaScript library and then we get into browser extensions. So within the browser, my number one, my daily driver is the Axe Chrome extension. It's by Deque, I used to work on that, so I am a little biased, but it's just solid, It's an awesome tool.

[00:10:00]
You can check how a page looks at runtime. And then if you have things like modals or other components, you could run it again and make sure it didn't miss anything. And we'll test it out to see things like, what labels are on the issues, are they best practices, or are they actually tied to violations in the Web content accessibility guidelines.

[00:10:26]
That's kinda good things to pay attention to. You can go straight from the results in that extension over to highlight elements and look at them in the Devtools, we'll check that out. And then there's kind of upsell tools within the extension if you wanna expand into tools that your organization pays for, they put a lot of effort into those.

[00:10:51]
Another tool we're checking out is Accessibility Insights for Web from Microsoft. It also uses the Axe-core library, or sort of see that come up again and again. It's an awesome tool, should definitely checked that one out. The Web developer toolbar for Firebox and Chrome, I'm gonna pull that one up as well, it's pretty awesome.

[00:11:14]
It's really the best tool I found for looking at heading structure. So we could install that one, and then when it comes to linting for ESLint and text editors, there is one for React applications called ESlint-Plugin-JSX-A11y, sort of a standard ESlint plugin. There's another one from Deque called Axe Linter.

[00:11:38]
I used it a while back, haven't used it super recently, but it could be an option for projects that aren't JSX or React-based. One thing I will say about linters is, you might need to tweak the settings. Sometimes they have rules that just come up again and again.

[00:11:55]
And if you ignore them because they don't apply to your situation or it's just kinda guessing wrong, you can turn that rule off. You don't wanna have the team kinda get used to ignoring results. It's better to fine-tune the tools [LAUGH] so that they're relevant, and then if something comes up, you actually pay attention.

[00:12:15]
Kind of a similar theme with automated testing as well.