Enterprise Web App Accessibility (feat. React)

Accessibility Project Requirements Exercise

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 Project Requirements Exercise" 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 leads a discussion about the accessibility requirements for a type-ahead search component modeled after the one on Amazon. The participants discuss various aspects such as keyboard navigation, focus trapping, announcing information to screen readers, marking up images, and considering the backend and API requirements. They also emphasize the importance of early consideration of accessibility and user testing.


Transcript from the "Accessibility Project Requirements Exercise" Lesson

>> So let's do an exercise, a bit of a discussion. We're gonna look at a feature that we're thinking about building, and we're gonna talk about all of the components of this that we need to think about for accessibility. So we're gonna look at a typeahead search component modeled after the one on Amazon.

It has a lot of features built into it. So, what questions are we gonna ask up front? What would we need to include or not include to do this in phases? What's critical to business needs? What are the accessibility factors that we need to think about? So yeah, what are the requirements?

What would we need to cut if we had to? Like if we're just not going to get this shipped on time, what could we phase in? So kind of looking at the overall picture just to describe. So it's the search Amazon kind of omnibox, so it has searching recommendations, like random stuff.

It's Christmas time, so this is what Amazon suggested to me. But yeah, does anyone want to kind of take a first pass at talking about what you think the accessibility requirements would be? Sure.
>> So I guess keyboard navigation, so making sure that you can navigate through items with the tap keys, potentially the arrow keys, and then also making sure that you're trapping focus properly.

And if somebody presses escape, it goes back to where you were and you're not suddenly getting thrown somewhere else.
>> Love it, yeah, that's great. Any other thoughts?
>> When you are focused on the search box, is there a way to cue to the user that all that information is there?

>> Good thinking.
>> It's like if I'm thinking about it and I tab to it, I don't know, is it going to read the placeholder to me? I don't know. But then how do I know that there's like a bunch of trending stuff down there? Or maybe like my past searches might be there.

>> Totally.
>> If you use alert or something for that or.
>> Yeah, probably. Yeah, so the word I was struggling to find earlier is combo box. So there's list boxes and combo boxes, and this is probably a combo box. So it's in a text input or search input that might bring up a slightly different keyboard on a mobile device.

But when you type into it or even just focus into it, it opens all these suggestions. So there's also the scrollable region kind of in between, like I've been shopping for toddler Christmas [LAUGH] gifts obviously, but that needs to be reachable. So the kind of best practice for that is when you have a region like that with overflow, either X or Y to scroll, you put a tab index on it and then you can use the arrow key.

So you can reach it and then you can actually use the arrow keys for that. I didn't know that right away, I had to learn that too. But you've made a really good point that we have to announce these items somehow. So, combo boxes, there's a really great one that Kent C Dodds worked on called Downshift.

You could take some inspiration from that. I've contributed to this one as well, they're really great about open source and accessibility. But there's a live region in this one, so that's how I think the Amazon version could work is, in ARIA, we have this thing called Live Regions.

And so you can announce things to a screen reader without moving the user's keyboard focus. So I think a live region would be pretty important in here and we'd have to figure out what to announce. Like, should you announce all the items? I think a practice more of the time is to say, toddler toilet seat in all departments, 14 results.

And then the system should usually say arrow down to navigate through the items. The screen reader, if you're marking things up using standard patterns, it will often tell the user how to navigate with it, and that is configurable, like it depends what screen reader they're using. So, we don't want to be too prescriptive with our announcements.

And this would be a really great candidate for some user testing with people who use screen readers, people who have limited mobility. I mean, for something as like revenue generating as an Amazon search box, you've got the budget to do user testing. Like it really should be a part of it.

I mean, this is a core user flow, like as core as it gets is the Amazon search box, or if you're a retailer that's a huge way that people find products. But marking it up like we have lists of items, we want to mark those up in unordered lists, use headings if possible.

I guess have some design decisions on whether this is a modal or non-modal layer. Like should we trap people's focus in there? Probably, but that's something we think about.
>> Would you want alt text on those images or are the labels enough?
>> Good question. So we have some images under keep shopping for, there's some toy foods and books and keyboards that I'm getting my daughter for Christmas [LAUGH].

Yeah, so there's images and text. So if we look at what the images are, they're potentially more detailed than what the text is. It's kind of a squishy decision to make, cuz it's a little bit subjective, but I think sometimes the image alt text can be informative, where maybe it's a product name.

I recognize that product when I look at it, so if somebody's been searching for that type of product and we include that information in the alt text, it is a slightly different piece of content than the text label cuz the portable, an arranger, whatever that cut off keyboard thing is, the label for that, that's probably a category.

Whereas the actual product that's being shown is something I recognize visually. So there we can kind of see a potential gap. If we think it's best to hide information just because that's what we assumed, it might not be the right assumption. We think through, that's like why it's so important to think about people with disabilities early on is because I'm thinking about that experience of, well, no, I would want a blind person to be able to recognize a product also.

Even though, I mean, that's a visual thing, but we can kind of backfill have pixels with text by using alt text and images. So that's a really great question. But again-
>> It's something you need to consider very early on because if, for example, your content management system doesn't allow a place for someone to specify, what is this thing?

The A4 key Casio keyboard, it's X by Y, it's got these features.
>> Yeah.
>> Where is anyone gonna source that text from?
>> Exactly, yeah.
>> And the thought process too kind of reminds me of mobile first design, right? If it's not good enough for mobile, is it good enough for desktop?

And kind of think the same thing here where it's like, okay, if we don't think that describing the image, because maybe in this case not so much, but maybe in a different case where it's like describing the image might not be important for the screen reader, well then we need to make that assumption for somebody that's looking at it too.

Do we need the image there at all? Or is it, or, yeah, the image is really important. Okay, well then we should describe it.
>> Yeah, I think there's some cases where it is redundant. Like if it wasn't a category in that text it was actually the product name, then you could probably leave the alt text off the image because it's represented another way.

So that would be a slightly different case. But yeah, you have to look at the stuff and evaluate it up front. We had a great question in our last workshop about the back-end, for is there anything we need to think about on the back-end in our APIs? And here's an example, if you have image assets you need that alt text as well.

And hopefully it's just part of the schema for the data of any of these types of objects, those products, those thumbnails. You could use a product title for the alt text if you needed to but you want to be choosy, make sure it works for the use case.

So I love this stuff, I think it's really fun to think about, because I mean, it's also really freeing in this exercise. We don't have the real constraints that you'd be under, so it's like, thoughts are free, we can just talk about it. And so I think it is interesting to review designs and just talk about what are the requirements.

So if you can do this early on, yeah, do that. [LAUGH]
>> To your point, adding another text field when you're creating the schema and the API and all of that, not that expensive. Retrofitting one after you've already done it and needing to touch every system it flows through and so on-

>> That could be hard. Yeah, they're distributed. I mean, that's costly. But I think the design, even, if you had to make changes to that, I mean, with a big enterprise like this, that's not easy always.
>> Would it be like akin to progressive enhancement almost, where I'm just thinking of getting that data.

I was at Target, there was a huge issue where, sellers are uploading this information and expecting them to know how to properly describe their images for an accessible way is like a high bar. It's like, how do you get, is it acceptable to just be like, we're gonna consider these images like icons almost and where they don't add value, but is it just kind of a decision to talk about or is there a right answer there?

>> Well, I think we kind of highlighted what I think is the right answer, which is that there's some benefit in having the image, at least the product name, described here. So, I think there's maybe a way to satisfy a user need, even if the sellers haven't supplied all that alt text.

Increasingly, there are AI tools for user generated content for alt text, but they're not always great. I mean, it's not the same. It'll be like object may contain plastic fruit, I mean, that would be pretty [LAUGH] informative. But yeah, I mean, sometimes that's the decision teams are making.

I guess what I'm encouraging is to think through the use cases a little bit more of like, what's the experience? And sometimes you have constraints, there's no way around them. So you do the best you can, you mark it up so that there aren't accessibility failures. Like if there's image tags in there, if you absolutely don't have alt texts for them, put an empty alt attribute at least so that it's not reading out some totally gibberish cached file name or something cuz that's what will happen without an alt attribute.

But ideally we can come up with some sort of dynamic solution. Yeah, see what you can do, I guess.

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