Accessible interactions in JavaScript apps
Sandrina Pereira focused on the importance of web accessibility, stressing the need for empathy when considering the diverse ways users interact with digital content. This talk highlighted the Web Content Accessibility Guidelines (WCAG), simplified into four principles, and touched upon various compliance tools available to developers.
Sandrina pointed out the limitations of automated accessibility evaluation tools, noting their effectiveness decreases as the interactivity of a website increases. The importance of manual testing, such as keyboard navigation, was underlined to ensure a comprehensive understanding of accessibility.
Techniques for implementing accessibility enhancements and improving navigation were outlined, with the use of Accessible Rich Internet Applications (ARIA) attributes and CSS techniques being described. Sandrina also addressed accessibility challenges in highly animated websites, proposing solutions to improve user interactions.
Accessible interactions were emphasized as being more than just about meeting technical standards; they require an empathetic understanding of the diverse ways users engage with content.
Share this talk with your friends
Transcript
So, accessible interactions.
For the next 20 minutes, I'm not going to talk about technical specifications, but I'm going to show you how you can use DevTools to help you, or not. But most importantly, I want you to learn through interactions and empathy. So let's start. Let's start with the elephant in the room, this page here.
This is the Web Content Accessibility Guidelines. And this is where all the technical specifications are. And I told you I wouldn't talk about it, and I will not. But I want to talk about this. Can you see it? Look. Look how tiny and innocent the scroll bar is.
The moment you land in this page, you know that you are about to start a rabbit hole. In fact, I think that this page is so big that I believe it's even bigger than on modules. No, don't take a picture just yet.
This is home page at scale. Come on. Okay. Jokes aside, let's all acknowledge the deep, massive work behind UCOG. It's thanks to this page that people with disabilities can enjoy the web.
So please clap to that as well. Still, it's a mess. We feel lost. So we kind of need a map. So that's what I'm going to try to explain to you. UCOG in a map, very quickly. So UCOG is split in four groups, what they call the four principles.
And each one of the principles can be a question that you ask yourself. So the first one, how do users perceive your content? Then, how do users navigate your content? And how do users understand your content? And last but not least, it's not about people, but about the machines.
All the machines understand the semantics of your code. And that's it. You know, then each one of the groups has a bunch of guidelines and criterias. And I like to see UCOG as a Pokemon game. You need to catch them all. That's it. Some are easier to catch than others.
So you start with level A, you know, the small Pokemons, the ones that you really need to catch. Then you evolve to double A, which is the standard recommendation. And then if you really want to be the best one, triple A. So that's it. That's the, you know, the simplest way I have for you to explain or to understand UCOG.
Now, there's a bunch of tools out there to help you catch all these guidelines. And before I talk about it, I want to run a little test with you. Ready? Okay. Which one is easier for you to read? White one or black one? Black one. Why white? Black one. Why black? Oh, wow.
A lot of people say black. Come on. We are on stage. How can you read the black one? Okay. Prefer. I prefer the white one. Anyway, guess what?
If you run a valuation tool here to check the color contrast, the white one fails. But the black one passes. So what's happening here? So this is an edge case. Okay.
So actually, there is a new color algorithm being developed where both cases would fail because both cases are not considered accessible. But either way, the point here is that, yes, you have evaluation tools to help you. But most of the times, they will not work. And for me to really explain when they work or not, I need to talk about the spectrum.
You know, there is this spectrum from static, simple websites to fully interactive websites. And the more dynamic or the more interactive your website is, the less the evaluation tools will work. Either way, I still recommend you, if you can, install AXCOR. You can integrate with Storybook, React, so on.
And if you wonder where to start with accessibility, start here. It's interactive. You know, you read the output. It's simple. It explains whatever you need to do, why it's important. It works. But as you can see, it's not enough. So next, you need automated tools to test your own, you know, custom attributes, custom
keyboard navigation, so on, so on. And with Playwright or Testing Library, both work fine. But the thing is, accessibility is about people. And you cannot automate people as you automate code. So you really need manual testing. And you can start with yourself.
Start, you know, using only the keyboard to navigate the page. But even better than that, try to watch videos on how people with disabilities use the Internet. That's way more effective than you trying to guess how the tools work. And I know. It's hard. I'm not going to lie. Accessibility can be hard.
But how can I say this? The more you practice, the more insights you have, the easier it becomes. You know? It almost comes as a second nature. And at the end of the day, remember, accessibility is not about you. It's about everyone else.
It's our duty, you know, as web creators to make sure that everyone can enjoy the epic web. Right? All of that done, let's move on for the example. So now I have five examples where you can make your interactions more accessible. And for it, keep this in mind. Every click is an interaction.
But not every interaction will be a click. Okay. So let's start with not the elephant in the room, but the jungle. Custom components. All of you have tried to, you know, build a date picker, dialog, tooltip, you name it. And I've done it, too. And actually, I have a story here.
So a few years ago, I built a dialog from scratch, and I was like, yeah, this is accessible. I'm confident. At the same time, I went looking for packages. I found a few, and I asked the author, look, what's the difference between yours and everything else? And the answer that I got was...
I don't know how to describe this. Where's the scroll bar? I'm lost again. Anyway, the point here is that, yes, build stuff from scratch. That's the best way to learn. But when it comes to production, probably you'll miss something critical. So if you can, go use Radix or React ARIA.
Both are library components done with accessibility in mind, and they are headless, which means you have full control over the styling part. So please try it. Now, the Internet, it's not just about web components or custom components. We have tons of other stuff to take care of by ourselves.
So let's talk a little bit about keyboard. You know, the basics of the keyboard is that every element needs to be interactive or needs to be accessible by keyboard. But sometimes the experience is... Let me show you an example. So here we have a page where I can see everyone who is on holiday, and let's imagine I want
to check the national holidays there on the right side. So I need to use the keyboard for this. Let's imagine that I can only use the keyboard for this. So I need to tab. Oops. Let's tab. Tab again, and again, and again. Ooh, everything is so accessible. Ooh, are you feeling the pain how much I need to tab?
There you go. I mean, it's accessible, but it could be better. So what if... Let's start from the beginning. I tab. Oops. Ooh, a new button. Skip timeline. Yes, let's skip it. There you go. One more. And voila.
So there were other solutions to make this more accessible, but this one is quite a quick win that I can't explain to you in under 20 minutes. So for this one, it's the concept called skip links, also very popular with the skip navigation,
but you can also use it to skip parts of your website that are fully or very interactive. And the idea here is you have a link that points to the anchor tag to the element that you want to jump to, and that's it. You don't need anything else.
Like, yes, you could do a button with JavaScript to focus the other part manually, but, you know, it's easy. No JavaScript here. And the really tricky part here, not the trick, but the secret for this is the visual part, because you need to hide the button, but then show it.
And you can do that only with CSS using a pseudo-selector called not focus, or two selectors, but the actual CSS to hide it, let me tell you, it's the biggest CSS hack out there. Probably you know it as visually hidden or SR only, and it looks like this, and I'm going
to skip that explanation, but this is it. If you are into Tailwind, it's also available there, like SR only, and then focus, not SR only. Could be better, but let's skip that as well.
Now, let's talk about keyboards and screen readers. There are a lot of misconceptions, but there is one I want to clarify. The people who use a screen reader do not navigate the page like tab, tab, tab, tab. It doesn't make sense.
They don't understand the page with links or buttons, but they also don't go one element by the time. It's like, it's boring, it takes too long. So instead, the most common way to navigate the web is through headings, you know? You just need to have the headings, then with a screen reader, it allows you to list the
headings. You can quickly read the headings and jump directly to the part that you want, and voila, almost like a skip link, but native. Guess what? You just need to use headings, and it seems like headings are also a way of interactive or a way of interaction, which is cool.
Now, another misconception is not every person who uses a screen reader sees like this. Sometimes they see like this, or like this, or like this. So whatever you have in mind for accessibility, take this into account, okay?
Now, talking a little bit more about screen readers, here we have a toggle button. You can clearly tell if it's active or not. The thing is, one tip that helps me with accessibility is to imagine the page without styles. So without styles, you have no idea if the button is pressed or not.
So this is a case where although the HTML is okay, it's not enough. It's missing the semantics. So one way to solve it is to use ARIA. In this case, you would use ARIA pressed with the value true or false, and then the
screen reader will tell you that this is not a button, but a toggle button if it's pressed or not. So this is a case where you actually need JavaScript to make your interactions more accessible. And the cool part, one thing that I really like about ARIA attributes is that you can use them to style.
So if for some reason you forget the ARIA, then the visuals also look broken. Now, most of you probably knew about this, but the thing is not every toggle button behaves the same. So let me show you another example, or let me announce another example.
The screen reader tells you, enable sounds, toggle button, not pressed. So far so good. This is the code. You press the button, and then it will tell you, mute sounds, toggle button, pressed. And this is the code. You change the ARIA pressed value and the label. But wait a second.
If it says, mute sound, already pressed, doesn't that mean that the sound is already muted, which is the same as enable sound? I can see your face of confusion. My head hurts. This is confusing by nature. You know, I'm going to be honest.
I was showing this talk with a few friends, and most of them told me, you need to remove this. This is confusing. I'm like, no. That's the point. This is confusing. You are creating confusing experiences without even realizing it.
Remember, the first rule of ARIA is, do not use ARIA unless you know what you're doing. And I've seen this quite a lot. So the bottom line here is, you either use ARIA pressed, or you change the label. But you do not do both at the same time. They don't make sense. OK?
Now, another example, a little bit more easier. Here we have a navigation menu, and visually, again, you can tell where you are. If you remove the styles, you're lost. For this part here, this is a little bit easier. You can use ARIA current. And current accepts a multiple, not multiple, but a few values.
One of them is the page. So the screen reader will tell you, this is the current page where you are. Cool fact, if you use Remix or React Router, the navling component does this for you out of the box. So that's cool. To clarify, ARIA current is not just about page, it's about any component where your
current location is important in the page, such as paginations, breadcrumbs, steppers, so on. Now, I have one last example for you, and it's my favorite. So I like animations. Actually, I love animations.
The thing about animations is, most of them, you know, the most of the most animated websites out there are the ones with the biggest accessibility issues, because you have a crazy DOM behind the scenes, and maybe it will mess up. So let me show you here an example.
With the keyboard, I can, you know, tab, open, navigate. Oops. Tab, open, navigate. I need to drop this. All good. Right? The thing is, if I close the menu, and now I hit tab, you'd expect to go to made without coffee. And yes, without coffee. The thing is, pay attention.
I'm going to press tab, and I'm lost. Press tab again. Nothing. Nothing. One more. One more. There you go. So what happened here? There's one last dev tool I want to show you that helps me to explain this. Is it? Oops. Not.
Wait. Here. It's this Chrome extension called Accessibility Insights for Web. It has a bunch of tools, and one of them is a tab stops. So it shows you the trace of your tabs while you were navigating. So basically, what was happening is that it was focusing the elements in the link while
the in the menu, while the menu was closed. So we have a problem here. Because we have our navigation, our button, and then our fancy navigation. The thing is, how do you hide this for keyboards and screen readers and everything else?
Well, ideally, you should remove it from the DOM, or you could also use CSS display none. But then it kind of messes up with all your fancy, you know, animations. And you need some workarounds. What if you could just use one attribute called inert?
When you use inert, whatever is inside that part of the DOM is totally ignored. So now, if I use a keyboard, and I press tab, it jumps directly to the next one. Shift tab. And there you go. Now, to make it clear, this inert is not just about keyboards and screen readers.
If, for example, I use it on the button, now the click does not work. Not even the hover. See? If you are wondering what's the difference between inert and HariHidden, remember, HariHidden does not work well with interactive elements like buttons, links, inputs, and so on.
Now, what I want to show you here is that I think that this inert attribute can solve a lot of problems when it comes to interactions, animations, like if you think about skeletons and stuff like that. Just one attribute. And another thing I want to tell you is that, you know, I love animations.
I love CSS. Yes, I love CSS. But I also love accessibility. And accessibility does not need to make your website boring. You know, accessibility is about making your website flexible. You know, about, you know, opening the doors to many preferences by your users, for example.
And you can still have fun with it, like here, if I open the menu and I reduce the motion, look how the animation stops at the moment of the motion. Like I had fun here. Like accessibility can also be fun, you know? So it's possible. Both can coexist, accessibility and animations.
To finish the talk, if you think that making the web is overwhelming, what about video games? That's the last thing I want to show you. Who knows The Last of Us? The game, not the series. The game. The game. Okay. Quite a few. To explain.
For those who don't know, this is an action game where you need to run, shoot, while survive. And this game, one of my favorites, is one of the most accessible video games out there. Let me show you. It has a bunch of color contrast modes and magnifications, like, what?
Then they have this concept called directional subtitles, where it has an arrow pointing to where the voice is coming from. This is what makes possible for deaf people to, you know, realize the surroundings while they play the game. Then you can remap all the controls, and this makes possible to people with just one hand
to play the game. And last but not least, it has a huge list of audio and vibration cues that, you know, that helps you understand whatever is going on in the game. And this, this right here, is what makes it possible for blind people to play the game. Like, what? Unbelievable.
I think there's a lot we can learn from the video game industry. Like, if they can make a video game accessible, we can make the web accessible, too. Right? Well, that's it. That's all I have for you today.
And remember, every click is an interaction, but not every interaction will be a click. Thank you.
