Enterprise Web App Accessibility (feat. React)

Accessibility in the Wild

Marcy Sutton Todd

Marcy Sutton Todd

Principle Studios
Enterprise Web App Accessibility (feat. React)

Check out a free preview of the full Enterprise Web App Accessibility (feat. React) course

The "Accessibility in the Wild" Lesson is part of the full, Enterprise Web App Accessibility (feat. React) course featured in this preview video. Here's what you'd learn in this lesson:

Marcy reviews some examples of accessibility in action on various websites. They discuss the importance of considering the user experience for accessibility and highlight both good and bad practices they observe. The lesson emphasizes the need for developers to strengthen their understanding of accessibility and to test websites with keyboard navigation and other assistive technologies.


Transcript from the "Accessibility in the Wild" Lesson

>> So let's look at some demos, some examples. What are people doing with accessibility out in the wild? So I just picked a few kind of like good or bad, the ugly, let's go see what people are doing. And I think there are some really thoughtful, sophisticated touches on websites, and we'll see.

Sometimes I feel that that goal, that purpose of how is someone gonna use this? Even when the care is there, the attention is there, sometimes that gets lost. So kind of keep that in mind of thinking through the full workflow, put yourself in someone's shoes and think about, okay, if I can't use a mouse, am I really gonna be able to use this?

Not just like, it kind of works, but really, cuz that's the stakes. We can't go part way, we really have to think through the experience and working with people with disabilities, that can be helpful. We'll talk about that. But I think as developers, we have to get those muscles, I guess we have to strengthen those muscles of like thinking through the user experience for accessibility.

So let's start with Stripe, stripe.com, pretty influential finance startup on the bigger side. Gorgeous. They have great gradients and colors and type and it's just like their brand is so consistent. They do a lot of really thoughtful things with their design system. And so, let's test it. I think they've been working on accessibility a little bit.

It's not been the best, historically, so I was very curious to see what's going on. So the first thing I always do is Tab, Tab through the keyboard. So they've got a mega menu. They open it when I Tab through, but they don't force me through all of the sub items, so that's nice.

I can use the arrow keys to navigate through instead of Tab, I can hit Escape. It moved me back somewhere, but my focus was lost. So that's one little improvement we could make is show the focus outline when your focus goes back. Cuz the Escape key is a convention for focus management to put me back where I was.

I always try it even if it isn't wired up. [LAUGH] So, now if I hit Tab again, somehow I think maybe the focus didn't get put back, because my focus is down below the header now, and I didn't actually go through all the items. So I think we might have lost focus.

And what Chrome will do, not all browsers do this, but it will try and replace your focus in the, I think it's called the sequential focus access point, something like that. And if you delete a node that you're currently focused on, that's their API to figure out where to put it, instead of they don't kick you all the way back to the top.

So I'm kind of close, but not really where I need to be. So if we manually manage that, we'll guide the user back to where they need to be instead of just leaving it up to the browser. So there's our first focus management lesson. But they do have focus outlines.

That's great. I mean we're fine-tuning something that has some accessibility mojo going already. That's a good start. So, now we're down to an auto animating widget. It's really pretty. It has all these icons, they're focusable, but they are automatically animating. There's no pause button, so that's an accessibility violation, actually.

We have to allow a way to pause, stop or hide, and auto moving animations, auto playing video. So also, I love that I can focus on these, but they disappear. I'm gonna watch it for a minute. So I'm focused on one, I guess that one's still visible. But if I Tab around, yeah, I don't know that these all need to be focusable.

And they actually go to places, these are links. I got one that I can't. So if you do Tab around, sometimes you Tab on one that you can't see. So it's just interesting. Yeah, there's a lot going on. So kind of last thought on the motion is if I open my system settings and I go to Accessibility, Display, there's this setting called Reduce Motion that I had turned on, but the site is not stopping the motion.

So that's one thing they could do is only animate if that is unchecked or if there is no setting for it, that's another way to do it. But it would be kind of distracting if you're really affected by motion, it gives you seizures at worst, or people with ADHD sometimes have a very hard time staying focused.

So any time that you can opt in to reducing motion to just not animate, do it. [LAUGH] It's pretty easy and it can really help with people's distractibility and not cause harm. And these icons, unless you hover, you don't see what these are. So they're really cute icons, it just it's not always intuitive what they are.

And if you can hover on them to see what they are, you should be able to see what they are when you focus with the keyboard. So, yeah, a lot going on here. And we could keep going, but i wanna go to the next site. So, another one, we have a question.

>> So really quickly, i guess i just wanted to get some information on what's generally expected when navigating with arrow keys? Because when I was trying to navigate through the mega menus, I tried pressing left and right and it wasn't always working. I wasn't sure if there was like a general, I don't want to call them best practices, but I guess expected conventions for people navigating through things.

>> Great question. So question about the arrow keys. So, when we hit Tab, I'm gonna go back to the top. I just clicked up the top and it set my focus point up there. So when we have links, and default buttons, and form controls, they are reachable with Tab.

And the arrow keys are more for appy desktop menus, like the Chrome desktop menu. Or if you have something like a date picker where you don't wanna tab through every day in a month. That we wanna use something that we will learn about a little later called roving tab index.

Some of this depends on what roles things have. So we don't wanna just wire up the arrow keys for every mega menu. It really depends how it's marked up for that to be clear to a screen reader user and to work properly. So we could go and look.

I think they probably made the top level not work with the arrow keys because of how it's marked up. So I'm looking in the DevTools. And I see some tab index on a div, so I already know that could be an issue because a div is not an interactive element.

We can put tab index on it, but in a screen reader it's still a div. So in our initial kind of keyboard test, I'm really glad you asked this because we only looked with the keyboard. I didn't test it with a browser extension yet or with a screen reader yet.

It is possible to make things that work really well with a keyboard and don't work at all on a screen reader. So, we kind of have to do this multi-pass testing on it. But if we start with the keyboard and we test with a browser extension like Acts, a lot of the time we can catch some of the stuff before we even fire up a screen reader.

But we will do that too. So for this one, I think they didn't include the arrow keys for some of the items, but yeah, if I were gonna work on this, I would evaluate kind of the overall picture. What roles do we have? How should it work? When you are looking for those conventions, the ARIA Authoring Practices Guide can really give you some ideas.

So these patterns and components, the ARIA APG, these are meant to show you how to do some of these patterns, I will caution they're not production ready. [LAUGH] But you can at least see what's the expected patterns for, say, a menu or lists of links. They do a really good job of differentiating those things.

>> Will we be talking more about solutions for examples like the animation you showed? I'm realizing this is a very common example, and I think it would be difficult to encourage stakeholders to make any changes to exciting landing page animations that are core to the actual design.

I'm curious about alternative approaches.
>> Great question. I mean, in this workshop, we're not diving too deeply into motion. I will say that my web app workshop, we did. We had a whole exercise with motion. So I think we are gonna talk about providing alternatives with user interfaces when we talk about minimum viable products.

>> Yeah, for that, you showed prefers reduced motion, right?
>> Correct. Yeah, there's a CSS media query. So I guess for the motion piece, one piece of advice I could say is that you can use that media query for people who say, I don't want motion. And for anyone else who doesn't even check that setting, it'll look the same.

So I think for people, stakeholders that you have to convince, you could say, well, if you never turn on reduced motion, then you won't even see it being static [LAUGH], you won't even know. But the people who need that setting will benefit. So yeah, maybe that argument could help.

Okay, so another one from Stripe. This is their checkout kind of use case example. So we have one for one time payments. And so the examples themselves, that's part of evaluating these things. Sometimes the examples have components around them that are just part of the demo. So you kind of have to differentiate which pieces am I really evaluating.

But for this one, I think they use components that are available throughout. So there are some radio buttons here. There's some little toggles. So what I wanted to show you here is that there these dropdowns that I can reach and operate with the mouse, but I can't use a keyboard.

So that's like when you're testing with the keyboard, if you skip past things like that, you know immediately, I need to dig in. What's going on here? So that's your first or one of the first gonna get like, what should make your spidey senses go off? And we have a whole section on that later, [LAUGH] but this is one of those things.

And I inspect it and the Chrome DevTools, guess what? It's a div with no interactive role, nothing like button or, I mean, it's a plane div, it's a generic element, it has tab index of zero on it. So I can reach it, but I can't understand what it is if I'm in a screen reader cuz it's just a generic element.

So yeah, there's other pieces that you have to think about, especially when you're making interactive widgets. Let's do one more. GitHub. They've done a lot of really great work for accessibility. I think a lot of organizations have, and sometimes they'll be stronger in some aspects than others, but I think GitHub has a lot of really neat interactive widgets that are more on the advanced side.

They have a skip link at the top, so that's super helpful. They have a lot of these interactive widgets that you can Tab onto. If you hit the Enter key it will open. You can hit Escape, it sends you back. I see my focus outline of where I was placed.

They have these really neat kind of like, not list box, these pop-ups that trap your focus in here so I can use arrow keys. That focus style on these items is pretty faint. I think the blue might have worked a little better. But I can cycle around through all this list of items, I can get to all of these things and I can use them.

I'm not getting stuck behind this layer, and I can hit Escape to go back again. So as you're navigating around the keyboard, I can highlight so many issues just with the keyboard, before I even open a browser extension. So if we do that as our kind of our first workflow step, we're gonna catch a lot of stuff.

And do some of these workflow steps on sites, and we'll detail some of those steps a little bit later. But that's like a little introduction.
>> Got a question. So companies that are big like Stripe, how is it that they can miss some basic stuff like not being able to focus a drop down, for example?

Do you think it's just speed of deployments or there's no solid QA process or maybe all of the above? Or, yeah, we don't really know, right, but how could that be missed?
>> Yeah, I think it's all the above, but I think the biggest thing is that when there isn't a culture of testing it, people just don't think about it.

And people reviewing it, don't test it. It's just like, it's not part of the definition of done, we'll talk about that. So yeah, there's kind of just like a lack of accountability, and that is so common. I'm definitely not singling them out. I think they do a lot of really beautiful work, it's just kind of the way things go.

So we have to find those processes that do make it repeatable and that do get that people thinking about it, cuz some of this stuff is not that hard. You just take a little bit of time, get in the habit, you do it regularly, you find all kinds of stuff.

And you don't have to be a super expert at accessibility either. I mean, it helps to gain your knowledge and that's what we're here to do. But I think there's some really basic stuff that if you know what to look for, it's pretty easy to find.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now