Common Accessibility Issues

[00:00:00]
>> What should make your Spidey senses go off? That's always how I think about it when I'm reviewing a PR. If I'm evaluating an open source library, component library or something, there's certain things that I can look at in code. I don't even need to test it, and I know it's gonna be a problem.

[00:00:15]
I still test it, I still go and check, especially if I'm opening up an issue or something or I'm giving feedback to my team. But my Spidey senses are going off a lot of the time when I see certain things. And so I would love especially as tech leads for you to kind of gain that intuition of like, I saw that.

[00:00:35]
I thought it might be an issue. So I opened it up on a preview URL or I I pulled down their branch, I opened it up in Storybook, and yeah, sure enough, my intuition was right. There's an accessibility issue here. You can get excellent code review feedback if you can do that quickly.

[00:00:54]
So some of the things that you should eventually, it takes practice, but you hopefully will spot from a mile away, and then have the curiosity to dig in and follow a regular testing workflow, which we will do in a few minutes. And we wanna bring kindness to these situations, right?

[00:01:10]
We don't wanna be judgmental. We want people to work with us. We wanna work with them. And that's how we can make this more successful. It's like, how to win friends and influence people that kind of thinking, it's like maybe a little cliché but it's not always fun to have someone give you feedback on a PR.

[00:01:28]
I don't know if you're like me and kind of like one negative comment can just kind of ruin your day, so we want to be helpful. We're all on the same team here, so form labels made with space Spans. Instantly, I know that's a problem because I have a text input.

[00:01:46]
I can use that text input if I'm not using a screen reader, but if it's marked up this way with span for the label text instead of a label element, I mean I have no idea what that field is for. I might be lucky enough where if a field has a placeholder or I guess placeholder.

[00:02:07]
Web browsers and assistive technologies like over time have learned that placeholder is better than nothing. So it actually, a placeholder will put a name onto an input if there's nothing else. But we don't wanna rely on that. Placeholders go away when you type in the field. So it's like, what was I typing?

[00:02:25]
So we want a visible text label whenever possible. So the easy fix with this one is just change that span to a label. Put an HTML4 in React, or a for attribute in vanilla HTML that points to the ID of first name on that input. Pair those together.

[00:02:43]
You will know that they're paired when you can click on the label and it will send focus into the input. So you increase the click target area and you're telling a screen reader user exactly what this field is for. Because placeholder might not even be the same as the label.

[00:02:58]
It could be an example of what they're gonna type in. And it goes away when you start typing. So that's a cognitive issue, like remembering, having to remember what that field is, that is an accessibility issue. Could be a WCAG violation even, but, yeah, so like that one I can usually spot and you'll start to see it too.

[00:03:19]
There are two ways to label or multiple ways to label an input. You can do what's called implicit labeling, where the label wraps the input. And if it has text in there, text content, it will automatically assign that cuz they're paired implicitly. The explicit is the foreign ID attribute paring.

[00:03:37]
You can also use aria label attribute on the input, but that won't make visible text. So we always prefer visible text when you can. And we're gonna dive way deeper into accessible names in the next section. So custom controls. Anytime I see a custom control that could be a default HTML element, I'm gonna dig in and go test it.

[00:04:01]
This has historically been a problem because form controls that we wanna customize, like radio buttons and check boxes, they've been really hard to style. So there's been some accessibility anti-patterns over the years of like, wow, we made it look really pretty, but you can't reach it or operate it with the keyboard even.

[00:04:20]
So I'm usually going to test those recommending, if we can use a core input that's more accessible that, might be customized, but it's one that is repeatable and centralized, or I might even recommend like the default HTML form element. But we are in a golden age of web development right now.

[00:04:41]
It's really exciting. We have a lot of new CSS features. Things are getting easier to style. And I have a talk resource included in here with my buddy Jason Langstorff and Una Cravats. I think she changed her name to Kravanov. She works on the Google Chrome Dev Rel team, and they have this video from Jason's, learn with Json show about what's new in HTML and CSS in 2023.

[00:05:04]
And it's really cool. There's a lot going on. So this is getting better, but we can't always use the newest, shiniest thing. So sometimes custom controls can be full of accessibility issues. Colors, contrast, sometimes you can just tell by looking at colors when you look at a design that they're too faint.

[00:05:27]
This can be programmatically determined so you can sample foreground and background colors. There's a ratio that you can calculate, but you can start to spot it with your eyes if you can see the screen some of the time. So I can usually tell if something's like way off, but automated tooling can catch some of the contrast issues too.

[00:05:48]
So when I run like the AKS browser extension, we'll see that in a little bit. That will surface contrast issues quite often. That's a huge one. Modals and layers like any time you have a custom modal, something that opens over the other content, there's a background layer that grays everything out.

[00:06:10]
Those kind of handmade modals can sometimes not have accessibility built in, so they might not have focus, might not send focus into it, or restore it when they close. Doing like a keyboard trap intentionally to keep you in the modal layer. Sometimes that's not present. Using a dialogue role on the modal dialogue and focusable and labelled buttons and calls to action.

[00:06:36]
Fortunately, there are a lot of really great component libraries now, like chakra headless UI, they have a lot of accessibility baked in, so this has gotten a lot better if you're using some of those libraries. But you wanna test them. Don't take their word for it, test it.

[00:06:54]
Then there's non-modal dialogues that are similar. The background's not grayed out usually, but we still want to move focus into those layers when they open, make them keyboard reachable and operable and all that. Sometimes skip links to get to and from non-modal dialogs can be nice. So here's the one eye is like always a red flag.

[00:07:16]
I can always spot this one. An on click event on a div. Just, that's it. And especially when it's like in a modal or in a component and it's like the submit, it's not like an extra click handler wrapping the thing, it's like the main call to action is a div with a click event on it.

[00:07:37]
I know that's gonna be a problem. So it should be a button. And there's all kinds of reasons why this happens. Sometimes it's like you have old style code, like old Sass or something that everyone's afraid to touch. I mean, you deal with the constraints. Like, if you have to make this into an aria div button, like we'll see in the next section.

[00:07:58]
Do the best you can. But like the goal is to swap those out for buttons cuz it's way less work. Was there a question?
>> Yeah, around colors, is there a special color palette or an accessible color palette to avoid issues with choosing colors?
>> Yeah, there is a lot of color palette generators and things online.

[00:08:24]
We talked about color quite a bit in the web app accessibility workshop, and I think it's that set of slides I have a bunch of links and things to read about with color. But I think if you search for accessible color power generator, you might find some stuff like that.

[00:08:44]
There is an article from stripe, interestingly enough, where they wrote about making a design system that had color contrast built in. That's very cool. It's super technical and geeky and I love it. So if you just search stripe accessibility design system contrast or something you'll find that one.

[00:09:04]
But yeah, there's a lot of really great resources out there for that kinda thing, question.
>> Speaking of striping colors their home page H1, it has this cool gradient overlay effect on it but the color is actually some dark gray, right? So I'm wondering how would a contrast checker check that?

[00:09:24]
Because visually it's like red and blue and green or whatever, but the computer value is actually gray. Is it checked against the visual color or the actual computed color?
>> That's a great question. Yeah, it does make sense. And what can make it even more complicated is sometimes those gradients are animated and they move so like what color you sampling?

[00:09:45]
Yeah, contrast checkers usually just skip those, like X. I used to work on it and that went into the can't tell fork, it would be like nope, can't tell it goes into this category called Needs Review, which is like the computer can't tell if it should be pass or fail.

[00:10:01]
So we're gonna put it into this queue for people to review manually. So, yeah, that one's tough because it might have a different color value in different areas. So I guess if I was testing that manually and providing feedback, I'd probably sample a bunch of colors and kind of take the worst case scenario.

[00:10:22]
Yeah, that's a pretty involved test. Of course a computer can't tell. Although I do think there are some tools now that use computer vision as opposed to JavaScript to evaluate that so they can sample pixels. Events is a tool company that's like a new startup, they do stuff around that and so there are new approaches to that, but it is pretty hard and it's computationally expensive.

[00:10:48]
So to run acts to test contrast in that way, as you'll see later on when we get to automation, some of that stuff you wanna only run in your page level tests, not in your unit tests.