Episode 008: Common Accessibility Failures

We kick off part one of our two part accessibility series, starting with semantics and dipping into more complex concepts like roving tabindex and focus trapping.

Transcript#

Claire:

Hi.

Steph:

Hey,

Claire:

I'm Claire

Steph:

and I'm Steph.

Claire:

And this is Word Wrap.

Steph

Today, we're bringing you part one of a two part series we're doing about accessibility. And our first one here we're going to talk about some common accessibility failure scenarios.

So I'd like to start with a little game. Your currently open project or your current work project has 50 points. Lose 15 if you tab around and visually get lost. Lose 15 if there are any contrast failures. Lose 10 for disassociated labels and inputs. Lose five for images or icons without alt text. And lose five for missing landmark roles and labels.

Now, if any of those terms were new to you, hold on. We're going to talk about them. But if you do this little test, be sure to tweet your score at WordWrapShow.

Claire

Yeah. So the game that Steph laid out, it sounds like it might not apply to certain, uh, websites and I can guarantee you, it applies to any website that's on the web right now.

Steph

Okay. So with those things in mind, we're going to talk about a list of other items, including components and foundational things that can go wrong in your project.

So the most foundational thing is HTML semantics. And a few highlights there are number one, when you are structuring the layout of your page, not using or misusing landmark elements. So a landmark element is a HTML element that has an implicit role that will be conveyed to assistive technology.
That probably sounded like word salad. So let's talk about a couple. Two of them would be a nav element and also the main element. So just by using those HTML elements in your document structure, a screenreader approaching those will automatically have it announced that that's the navigation and that's the main element. So that's again noted as the landmark roles.

Claire

Similarly, HTML elements, such as buttons have implicit roles that are essentially communicated to screen readers basically do an action or, you know, a link to trigger navigation. You know, that whole timely debate of links versus buttons. And also properly using heading hierarchy. Some folks will throw around the term document structure, which is yeah, it's a pretty apt term using an H2 right after an H1, not using two H1s in a row, et cetera. You don't want to skip heading levels, like going from H2 to H5 - not a good look. And if you're trying to change the visual size, you should definitely use CSS instead of just using the default styles. That's some of the first CSS that I write, actually.

Another huge thing is not tying a label to an input. Some folks will put an input inside of a label, which is actually fine. It's not the best. It's not like the semantically best, but it's still works.

Or images without alt text. And even if there is no alt text to give it, sometimes it's appropriate to use and alt attribute with nothing in it.

Steph

Yeah, absolutely. And the other good news about several of these, the heading hierarchy and not associating labels with inputs and images with missing alt texts, as well as the landmarks. Those are all conveniently items that can be caught by automated testing tools.

Now not everything can be caught by automated testing, something like 40 to 60%, depending on complexity of your project and also the tool in use. So something to be aware of, but we'll list in the show notes some extensions and other tooling that you can use to catch kind of these low-hanging items with automated testing.

So. Getting into kind of some more contextual examples, like components that you might be building or layout elements that you might be building that don't already have sort of those implicit roles, or don't already have an existing HTML element to handle them.

So starting from the top, as it were, let's talk about site navigation. So one of the first things you can add to your page that you might currently be missing is a skip link. Skip links allow users of assistive technology that are entering your page to hit the skip link as the first item. And that gives them the opportunity to skip past some of the boiler plate that might be present on your site. So your navigation, your header content, whatever you're kind of stuffing at the top of the page. And typically you would link this skip link to your main content area. So that may literally be the main elements or it might be just the main portion of your site, maybe like the first article or the first chunk of non boilerplate content.

So that's something you need to manually create. And often the implementation you'll see is that it is hidden until it is focused. So in other words, um, sighted users, um, users that don't use keyboard to navigate your site may never see it. And that's completely fine. But it is - for a content heavy site, for a site with a complex hierarchy, or one that a user frequents often like an application or a web app, like Facebook, for example, skip links can be hugely important.

So Facebook actually has a series of links that they've identified as appropriate for skip links rather than using one.[Correction: They used to do this - I'm off Facebook now and they appear to have remove those.]So. It can also be used for common actions again for your repeat users.

Um, but beyond skip links, which I mentioned are often hidden, another common need for sites is dropdown menus, and these can get very complex. Um, I have to laugh because this is something that I have attacked since nearly my first week as a web developer. And it has changed so much. And, um, you know, we used to attack this with jQuery or MooTools um, if you're really old like me. Um, you know, mega menus used to be a thing. And thankfully, you know, those have mostly gone away unless you have really complex e-commerce products, but anyway, there's several things that can go wrong here.

Claire

To add onto the dropdown menus topic. I usually think of those as modals or modal-esque because especially in a mega menu design, which does still exist, I literally just helped build one a couple of weeks ago. There's the need for like trapping the focus in there. So, and then. Speaking about modals. Uh, let's talk about modals for a minute. Modals are prevalent everywhere on the web, like any kind of action or secondary action might trigger a modal.

Modals. They break the web to a certain extent, and it's your job to kind of build it back.

So, what I mean by that is there are, you have to focus trap. You have to allow scrolling by an arrow key, kind of like what you could do with a normal webpage. And then you have to be able to actually hit escape to get out of the modal. It's like a mini web page inside - inside of a webpage. So a lot of really bad errors on, uh, websites with regards to like, you know, uh, screen readers and stuff like that are tied to modals because if you go into a modal and you can't get out, then it's as if you basically have to reload the page to get out of it, which is not a, not a good user experience.

Steph

Yeah. So one of the keys you said there a couple of times was focused trapping. Do you want to explain what that means?

Claire

Yeah. So let's say we're on a webpage and let's say we have 10 buttons. We can trigger all 10 of those buttons through, uh, uh, using the tab key. If we open a modal, let's say a modal - let's say our, our fake modal has five buttons in it. We shouldn't be able to touch those buttons until we open the modal. But vice versa, we shouldn't be able to touch the 10 buttons that are not inside the modal when we have the modal open. So when we're inside the modal, the user should only have to care about the five buttons inside the modal.

It should, it should be as if the page behind the model doesn't exist until you exit the modal. So when you hit tab instead of a modal you, when you get to the end of the items that you can tab through, you should get back to the beginning of the modal, which is usually the close button. And it should just repeat like that.

So don't want to go into solutioning right now, but that's kind of the idea behind focus trapping is so that you can reliably get out of wherever you're at.

Yeah. I mean, related to that is a lot about keyboard access. And so when we're talking about tabbing. And in addition to trapping once the modals open, you also need to manage the focus. So when you trigger the open action, you need to explicitly move focus to the modal in the first place. And that can be done in a variety of ways. Sometimes it's appropriate to attach to the first interactive element. Um, but sometimes if the modal content is extensive, think about like a terms and conditions modal, it may be appropriate to place the focus on the heading.

So in other words, you're taking a typically non-focused element and turning it into a focus element. And if you're unfamiliar with how to do that, um, the quick note there is to set tabindex -1 , at which point you can programmatically set that access, but it won't be included in the normal document tab order.

So. Um, in addition to focus though, on the keyboard access idea is also that you should enable the escape key for exiting out of a modal. You may, as a sighted mouse user, you may have been used to hitting a X type of a close button. Or you may be used to hitting, um, outside of a modal to try to close it, which depending on implementation may or may not work.

And there are reasons to not allow closing a modal. Maybe it's a critical action that you're like, maybe you triggered the modal cause you're trying to delete an item in which case, you know, maybe they want to bug you to make sure that you really meant to do that or give you the opportunity to cancel that. And so there's, there's reasons not to enable that. But if it is a dismissible modal, it also needs to be dismissible by escape key would be the main note there.

Another element that is probably something you're not properly attaching keyboard events to is a tabbing interface. So personally, this is one that I recently learned a lot more about, and specifically the concept of a roving tabindex. So what this means is that while it's appropriate to make your tab triggers into buttons, instead of making each of those buttons into a tab stop that you have to go all the way through before accessing tab content. Once a user has entered a tab trigger - so the tab button - you'll want their next tab focused stop to be the tab content itself. And the way to enable this, rather than again, having to go through all the other tabs first, is a roving tabindex. So this requires JavaScript. And using JavaScript, you will manage that focus so that instead of using the tab key to move between tabs, you enable the users arrow keys to move between tabs. So in other words, you're sort of turning it into a list type experience where they can use arrow keys to explore the available tabs. And then because their buttons use, um, either enter or space key to open the tab. And then again, returning their tab stops so that the next one is within the tab content. This helps to create that association between the two. And especially for a long list of tabs, you know, they're not kind of getting confused about what, what the tab was supposed to be by the time they actually hit the content. So again, a similar to modals that appropriate tab stop may be the first interactive elements, or it may be placing tab focus by the tabindex again on the kind of wrapping element around that tap content.

Claire:

You know, and these things that we're talking about, aren't just, they're definitely an accessibility thing. And that's really what we're trying to talk about here. But anyone that uses a keyboard will definitely appreciate these things.

I was complimented a couple months ago just by making any modal escapable, uh, with the escape key and someone who is very well sighted and uses the keyboard extensively asked why I did that. And he thought it was kind of like for keyboard users, because our developer culture has a very keyboard focused culture, um, mechanical keyboards and such, but that is that's a digression, but no, I actually said it was a accessibility thing. And, uh, it just kind of doubles up as a win for keyboard users.

Steph

So yeah, accessibility helps everyone, which is extremely important point to remember, you know, it's not just this thing that you add on at the end. It's something you need to incorporate the whole way through. It's going to help everyone.

One last thing on the keyboard topic, because it is extensive. Jumping back up to modals again. Another item that I recently encountered was with modals. So I'd gotten kind of clever, um, with using a flex solution to make a kind of sticky header footer in my modal and a scrollable content area. Well, then I went to test it for accessibility and specifically keyboard access.

And I found that within that arrangement, I could no longer use my arrow keys in a default browser way to scroll that main content area. I completely lost access to it, which means I completely lost arrow key access to it. The reason had to do with overflow and hiding that overflow and constricting it to that content area.

So the fix was to not do the clever solution of the sticky header footer. And instead, allow the modal window to be normally scrolled within the browser window. So a more kind of fixed implementation that was able to continue using the native browser scroll, which re enabled arrow key functionality.

That may have sounded a little confusing, but the point being you know, It's all well and good to try new things, to be inventive with your, with your layouts and UI elements to a point. But at the end of the day, you know, accessibility is all about making it available and perceivable, operable.

Claire

Yeah. I think that, um, something that you said Steph about the flexbox thing, I think, I mean, I've done that too. I actually. Like the model I just implemented does that, exactly that. And I think it's all in that, in that desire to like, keep the close button visible at all times, instead of like having it scroll with the content.

And it's one of those things where it's like, we might be, we might be fixing one problem, but we're actually adding another problem. And that's, it's kind of just the. That's kind of the whole thing with web development in general, like the web in and of itself was accessible at one point in time, just by default. Um, when you just wrote HTML and CSS and you know, didn't get crafty. Um, so. Whenever you are feeling crafty. Uh, you should definitely take into account what default browser behaviors or assumptions that the browser might make, um, and make those, uh, build those into whatever you're building.

Um, you know, the Flexbox layout can work, but you have to accommodate for it by, you know, listening to arrow keys. But when you do that, then it makes it a little harder for, you know, interactive elements with inside - inside that, to work with the arrow keys. So it's a cascade of breaking things. So it's one of those, "is it worth it" kind of things.

And, and really honestly, until literally what I just heard from Steph I thought that it was best to keep the close button in, in, in sight. And I, you know, I see it in multiple areas where the close button scrolls, um, like GitHub issues and other things. And I thought that it was just bad design, but it's not. It's not because at the end of the day, the holistic design with the code and everything makes it better.

Steph

Yeah, absolutely.

Claire

Learning things all the time.

Steph

You made a Missy Elliot lyric pop in my head when you talked about working it, but I will spare everyone. I'm singing that, um, by special request, um, maybe, but - buy me a coffee and I'll sing you Missy Elliott.

Um, anyways, um, yeah, so you reminded me of one last thought before we close up this part, um. Be sure to stay tuned to our next part, by the way, we're going to talk about more things you may be getting wrong, but more specifically how that relates to the actual accessibility criteria that exists.

But in light of everything Claire just said about modals and breaking user's expectations. Back to semantics, try to use native elements as much as you can. Don't think that you can bandage them by adding JavaScript and adding Aria roles, which we didn't even get quite to talk to yet. And that said sometimes JavaScript is required for the most accessible solutions. So we talked about a few ways in terms of our modal and, and ensuring keyboard accessibility. Same with our dropdown menu. It's - it needs some of the same things as the modal in terms of escape key, it possibly needs focus trapping.

So. Just - just being understanding of the limitations of what the browser gives you, but also the extensive capabilities that it gives you for free. Don't try to invent your own button, just use a button. So, um, anyway, we definitely hope you have a lot of takeaways from this episode today, and that you go and start to use some testing tools against your, your projects.

Um, probably a big takeaway here is you have a testing tool readily available to you, which is the tab key. Just use it everywhere. Um, fix any place that you lose visual focus or get trapped in hidden elements. Um, if you take that away, I'll be happy.

Claire

Also, I invite you to download a screen reading software, such as uh, NVDA or, or if you have a Mac, Voice Over is actually included in the Mac. And just turn it on and see, you know, try to utilize a website with your keyboard. And, and notice how much more - there's much more mental load with regards to like what you're, what you're thinking about and what you're seeing on a website, you know. And try to build that empathy because you know, it might be easier for you to make a div class button, but really that breaks so many things for so many different people.

And Aria roles and just roles in general, the attributes on HTML elements. Those are for those, those instances, when you need to create the most, um, accessible solution with JavaScript, they're not meant as a crutch and they're not meant as a replacement. They're - they're more of a noting - note-taking, or notation type deal for helping screen readers try to figure out what in the world you're doing, because you've already messed up the semantics.

So as always tweet us @WordWrapShow and let us know if you have any questions or things you want us to cover.

Steph

Stay tuned for part two about more accessibility things. And honestly, I think we brought up a lot of ideas that we may even have to do a part three in the future. So thanks for listening.

Steph

Thanks for joining us on another episode of Word Wrap. Be sure to subscribe on your favorite platform, or pick up the RSS feed on wordwrap.dev. You can also catch us as @wordwrapshow on Twitter. Until next time!