- [Kari] Good morning, good afternoon. Welcome. Just opening up the room. Letting people get enrolled and registered in here. And we'll get things kicked off momentarily. So just be patient with us for a minute. Again, just wanna thank everyone for joining us today. We still have another minute or so before we get started. So just to be patient. We will begin momentarily. All right, we're gonna wait one more minute. Give some time for everybody to get finished getting into the room. Thanks everyone again for joining us today. We will get started here shortly. All right. Again, good morning, good afternoon. Thank you everyone for joining us today. My name is Kari Kernen. And I am the senior manager of sales development here at TPGi. I just wanna thank everyone for joining us today. Just wanna go over a few housekeeping items before we get started. This session is being recorded. And we will email everyone the recording after the event. We have captions available. So feel free to use them as needed. We will have some time at the end for live Q&A. Please use the Q&A box. And we will answer as many of the questions as we can at the end of the presentation. Again, just wanna enforce. Please use the Q&A box and not the chat for any questions. Sometimes questions get missed when they get put into the chat. If for any reason we run out of time, we don't get to your questions, we will respond to you after the webinar is over. Lastly, I'd also like to mention. If anyone is needing any accessibility support, training, or usability testing, I'll send out an email after the webinar with a link to schedule time to speak with one of our experts. And with that, I am going to let Wes get started. Provide an introduction of himself and get things going. Off to you, Wes.

- Awesome. Thank you, Kari. I appreciate it. Hello everybody. Thank you for joining us today. My name is Wes Estes. I am an accessibility engineer at TPGi. And today, we're gonna be talking about "Pieces of an Accessibility Audit: What's in an Accessible Name?" Now, there's a lot of really good content out there to discuss how to modify an accessible name in the best way once you understand what an accessible name is. But I find I get a lot of questions on what is an accessible name? And Wes, can you show me how you figured out what the accessible name of that element was? Things like that. So that's more what this session is gonna focus on, is defining, hey, what is an accessible name? Why is it important? How do we see it? And at the end, I've got a series of examples that we're gonna go through to show you how certain changes to the accessible name happen. So let's get started. First off, what is an accessible name? Well, the W3C working draft from August 2nd of this year, "Accessible Name and Description Computation 1.2" says, quote unquote, "The accessible name is the name of a user interface element. Each platform accessibility API provides the accessible name property. The value of the accessible name may be derived from a visible, e.g. the visible text on a button, or invisible, e.g. the text alternative that describes an icon, property of the user interface element," unquote. Okay, so what that basically means is the accessible name tells us the context of the element that we're interacting with. Well, that makes sense. So what elements need an accessible name? Well, accessible name is needed to describe elements on the page with certain roles. So for example, buttons, links, images that are meaningful, tables, dialogs, various form inputs, text, radio checkbox, select, textarea, tabs, tab panels, comboboxes, listboxes. And this is not an exhaustive list. This is just the first examples that came to mind of potential elements that you might run into on a page that would require an accessible name to give the user additional context to understand what they're interacting with. Now, things that don't need an accessible name. Well, that's gonna apply to generic elements such as divs, spans, paragraph elements unless you've assigned a specific role to it. But that's a little more advanced than this session. However, this does bring us to the first of two key concepts to understanding the accessible name. And the first one is that no matter what your content looks like on the screen or how it style their position with CSS, it ultimately translates to a series of text, potentially with some interactive or meaningful elements at certain points. And this translation is referred to as the accessibility API, which is where the accessible name lives. And any of those interactive elements you may encounter need to have an appropriate accessible name to describe it to assistive technology and provide context. How you code your content ultimately determines how accessible the resulting accessibility API is or isn't. Even if it quote unquote, "looks right" visually to a sighted user, it may not make sense or be accurate programmatically to all users. Okay, so now we have a little bit of an understanding of what an accessible name is and that it's part of a translation to the accessibility API. But how do we figure out what the accessible name of an element is right now? Well, we can do that a few different ways. The first one is to view the accessibility panel in DevTools. Second would be to listen to the content with a screen reader. We could also display the accessible names and elements for speech input. And we could even use scanning tools like our toolkit to find missing or incorrectly applied accessible names. Today, we're gonna focus mainly on the accessibility panel and DevTools. And that's something that everybody should have access to. And many of you are already familiar with, I suspect. So to inspect an element with DevTools, we can do that a few different ways as well. You use DevTools to view all the technical aspects of each element. And you can use any of these options to open DevTools. You can right click the element and inspect it, which is what I've shown here on the page in a picture, shown right clicking the submit your inquiry button and inspecting it. You can alternatively press F12 or the keyboard command Control + Shift + C on Windows or Command + Option + C on Mac. Both of those will ultimately open up the DevTools panel on the elements tab, which I have an example of here on the screen right now. So this shows not only the DevTools panel and the elements tab in that panel, it shows the sub-panel under the elements tab where you'll find things like these styles or computed or event listeners panels. That's something maybe you are already familiar with. One of those panels is the accessibility panel, which I'm showing here on the screen. And we're gonna dig deeper into that panel today. So first off, the first thing you're gonna see in the accessibility panel is the accessibility tree. I've got an example up here on the screen. And it shows basically the entire structure of your page from the root all the way to whatever it is you inspected. And this could be very useful. This shows the accessible element structure of the page. Helps you confirm if you have a logical structure. And it helps you show how you've arranged your content. Now, there's also an entire section directly below this dedicated wholly the ARIA attributes as well. But today, we're gonna focus on the next section, which is the computed properties panel. So the computed properties panel shows various accessibility properties of various elements on the page. And it'll show you things like the accessible name, the role, and aria-describedby if present, other ARIA attributes if they're present, and various statuses such as is it focusable, dismissible, checked, et cetera. Now, this again is not an exhaustive list. And the properties that are displayed are gonna vary depending on the element type that you're inspecting. But it's always going to include a role and an accessible name. And on the screen, we've got a picture of that computed properties window. And it's showing the accessible name section along with some other properties. But let's drill down even deeper. Let's go and look at that accessible name section of the computed properties panel. So on the screen, we've got a closeup of that section where it shows the calculated accessible name along with several things underneath it. Well, why might that be? Well, that's because the accessible name is a computed value and it's computed based on a hierarchy of potential sources. For example, it could come from the aria-labelledby attribute, an aria-label attribute, the from label for ID attributes for like form field. It could come from the alt text for an image element, for example. It could come from the contents of a button or a link. And as a last resort, it could even come from the title element. But this is the second key concept to understanding the accessible name. So not only is the accessibility API translated from how you have programmatically created your content, the accessible name differs from most other attributes because it is a calculated value versus an assigned value, which can cause some confusion. The accessible name is not set in stone by simply applying a value to a particular element attribute like most other properties. Since the naming can come from multiple sources or be intentionally modified, we need a hierarchy to determine what naming sources take precedent over others. And so those things that are listed underneath the calculated accessible name are potential sources of that name. And they're in order of their hierarchy. And you're always gonna find that aria-labelledby is the top of that hierarchy. And the title attribute is the bottom of that hierarchy. The potential sources that come in between can vary dependent on the element that you're inspecting. Okay. That's all well and good, Wes. But why is the accessible name important? Well, it provides users of assistive technology a description of the element they are currently focused on or interacting with. And when no accessible name is provided, screen reader users only hear the role, but no description of what it is, given a visible text might be present. Additionally, speech input users navigate by speaking the accessible name of components on the screen. And so generic, insufficiently descriptive, or repeated accessible names can confuse users or make navigation difficult. All right. Going hand in hand with that, there is a variety of WCAG success criteria that can potentially be failed related to accessible names. And there's four areas of success criteria. And the accessible name spans all of those. You can have failures of 4.1.2, name, role, value, 1.3.1, info and relationships, 2.5.3 label in name, 1.1.1, non-text content, 3.3.2, labels or instructions, and 2.4.4, link purpose in context. All of these are gonna be dependent upon the context of what type of element it is and how you're trying to convey the accessible name of that element. Okay, so with this in mind, when we're modifying or updating an accessible name, what kind of things should we be keeping in mind? Well, ideally the accessible name should come from real text present on the page. Like a visible label and/or visually hidden text. For elements without a visible text, ARIA can be used to provide the accessible name by referencing other elements on the page using an aria-labelledby attribute with ID references or directly using an aria-label attribute. The title attribute provides an accessible name for iframes, but otherwise should generally be avoided in preference to other methods as it's the least reliable for assistive technology. And the browser based tool tips it creates have accessibility issues. This is part of why it's the last resort thing that the accessible name computation looks for. Now, as I mentioned at the start of this, this presentation is meant to be an introduction to the accessible name. For more technical details on what to consider when crafting a good accessible name, I advise you reference these recent articles by a couple of my colleagues. The first is "Good Intentions, Poor Context" by Doug Abrams, senior accessibility engineer, TPGi. The second is "Context is king: long live the king!" by Ian Lloyd, principal accessibility engineer at TPGi. So we've kind of got the basics in place here. I told you what an accessible name is. I've clarified where it comes from, that it's translated from the way you've coded things, that it's then calculated based on a series of higher potential sources. I told you who it affects, how to modify it. Let's go through some examples and see what exactly this looks like in practice. I have 12 examples prepared today. And they're all set up in the same format. It's gonna have a picture of the element type that we're inspecting in the top left. I'll describe that to us. Underneath that in real text is a modified code snippet. Simplified, if you will. So that may not include all the details. But it has the key points for what we're presenting today. In real text, the code there. And then as opposed to just a picture of the computed properties panel, I've gone ahead and included a real text representation of that as well. So you can see the computed properties panel on the same slide. And we'll go through and we can see where the various hierarchal sources of the name, you know, ends up resulting in the accessible name of that element. So here we go. Example number one. Very straightforward. This is a button with an accessible name from the contents. This is our bread and butter. So the visual example is a typical button with visual text Submit your inquiry. The code for this is going to be standard HTML button element with contents of Submit your inquiry. It's very straightforward, very simple. Nothing complicated going on here. And so when we look at the computed properties panel, we can see that the accessible name ended up being calculated as Submit your inquiry. We can additionally see where it looked for as potential sources to get that accessible name. It started with aria-labelledby and continued down until it found the contents section was populated. And the contents in this case show Submit your inquiry. So it used that as the accessible name for this button element. So what this means is when a screen user navigates to this button, they're gonna hear something similar to submit your inquiry button. They'll be given the context for it. It's the same as what's presented visually. And they can activate it. Similarly, somebody navigating by speech can say, "Click submit your inquiry." And that'll activate this button because the accessible name aligns. So there's no issues here. But example number two is something I see all the time. And it starts with the best of intentions. So example two is a button where the accessible name comes from the aria-label. That in itself is not a problem. But what ends up happening is, so we're using the same example here. Visually, we have a button with Submit your inquiry text present inside of it. And the code is the same except now, they've applied an aria-label to the button element itself. Okay, now why might somebody do this? Well, from my experience and why I see this so much and why this is example number two on my list is there seems to be some confusion amongst developers that you have to use aria-label to provide an accessible name when, as we've just shown, that's not necessarily true. It can come from other sources. And so what usually ends up happening is this button would've started off as a button with visual text of Go! And the aria-label in this case, being Go!, would be equal to the visible text. And there would be no issues. The calculated accessible name would end up being Go! The visible text is Go! Everything works as normal. But what's happened, or what I'm showing in this situation as having happened, is at some point, somebody came in, updated your content, and changed the visual text in that button from Go! to Submit your inquiry, but they didn't change the aria-label. And so now, what you have is a button that visually says submit your inquiry, but if we look at the computed properties panel and we figure out what the accessible name is, we can see that it's been calculated as Go! in this case. If we look deeper underneath there, we can see that it didn't have anything specified in aria-labelledby. But it did have Go! under aria-label. Nothing from the form label. And then it's crossed through the content that it had, that had submit your inquiry over with precedence for the hierarchy of aria-label. And so it's gone and applied the aria-label input to provide the accessible name for this particular element. So now, when a screen reader navigates to this button that visually says Submit your inquiry, they will instead hear go button, which is not accurate. It's additionally problematic for speech navigation users. 'Cause when they say something like, "Click submit your inquiry," it won't do anything because as far as the API is concerned, that button isn't called submit your inquiry. That button is called Go! And it's expecting the user to say, "Click go," which they're clearly not gonna do because they can't see that. So this is a problem. This is an example of our first failure. This is an example of a 2.5.3 failure, label and name. Okay, so let's move on. We're gonna stick with buttons for right now. And these examples are gonna get progressively more complicated as we go. In this case, we have a button with no accessible name, which I'm sure you're already guessing, yes, this is another failure. The visual example in this situation is a very common search text box with a button that is comprised entirely of a magnifying glass image. Okay, a sighted user might be able to look at this, figure out what's going on, click on the magnifying glass, and go on with their day. But that does not mean that it's programmatically marked up to make sense. And that's what we're gonna see here. So the code for this, that magnifying glass search button, it's a button with no text content in it. And the image, child image content has been hidden from assistive technology. So there's nothing exposed there either. So when all that gets translated to the accessibility API, the accessibility name computation looks for potential sources and it sees that none have been provided. And so therefore, the end result in this case is the accessible name is blank. So when a screen reader user navigates to this search field and then tries to activate that button, they're going to hear blank button instead of search button or something that makes sense and gives context. This will additionally be a problem for people navigating by speech. They'll be unable to activate that control without doing some extra hoops. So this is a failure. This is a failure of 4.1.2, name, role, value. But not to worry. We can fix this. Enter example number four. Button with accessible name from aria-label. Again, it's not necessarily bad to use these techniques. You just need to know when to use them. So here, it's the exact same visual example, the exact same search text box with the magnifying glass button. Only this time, the button element has an aria-label attribute applied directly to it of Submit Search. And so now, when the accessibility API gets translated and the accessible name goes to try to compute itself, it looks and it sees that one of its potential sources is populated. And here, we have aria-label Submit Search. So it uses that. And the accessible name in this case is Submit Search. This works out perfectly. So now, what ends up happening is when a screen reader user navigates to that control, instead of hearing blank button, now they'll hear submit search button. And then they can obviously activate it and everything works. They're given correct context. Similarly, speech input users can say, "Click search" and this will work. But let's say for some reason, your design team, your developer team, your environment that you're in, for whatever reason, you can't do this. That's okay. There's multiple ways to accomplish the same goal. Enter example number five. Button with accessible name from child image. In this case, instead of applying an aria-label directly to that button element, we are instead going to unhide that child image and we're going to expose it to assistive technology. We do that in the code by assigning it a role of image. And whenever you do a role of image, you have to give it an accessible name. And we do that with aria-label. So we've done that. We've exposed that magnifying glass as an image with role="img". We've used aria-label="Search". That's just to differentiate it from the aria-label on the parent button. And when we look at the resulting tree over here, computed properties panel rather, we can see that the accessible name was calculated as search and it got that from the contents. Now, just to clarify. Yes, aria-label is providing the accessible name for the child element. But the button element is getting that as content inside of it. So that's why it shows up under contents here and not under aria-label. If we were inspecting the actual magnifying glass image, it would show up under aria-label there. We're inspecting the button element. And so there, it shows up as a child content. But ultimately, this ends up with an accessible name of search. And similarly, when a screen reader user navigates to this control, it'll make sense. They'll hear search button. And likewise, somebody navigating by speech can say, "Click search" and this will work. Okay, let's say we got a little bit overzealous though. Let's say we combined the last two examples and we applied an aria-label to both the button element directly and we exposed that child image. What happens in that case, Wes? Well, that's what example six is here. It's the same visual example. Search box with a button comprised of a magnifying glass image. And in this case, we have that aria-label="Submit Search" applied directly to the button element. And we've exposed the image with role="img" and an aria-label="Search". And when we look at the computed properties panel, we see that the calculated accessible name is Submit Search. And going through the hierarchy underneath it, we can see where it got that from. We can see that it had two potential sources. One was aria-label, which was populated with Submit Search. And one was the contents of Search. And it, based on the hierarchy again, crossed out the lower hierarchy element in favor of the higher hierarchy element. And it used that to calculate the accessible name. So in this scenario, again, screen reader users can navigate. They'll hear submit search button. Similar for speech navigation users. So we're still a-okay here. But we see some examples of where that hierarchy starts to come into play. All right, different example this time. Visually. We're gonna move on from buttons. Like I said, these are gonna start getting a little bit more advanced as we progress through. Example seven, we're gonna use a link. This link gets its accessible name from visually hidden text. The image is what appears to be a button with text Read More inside of it. But it's really a link. It's just been styled to look like a button. And that's okay. It's also okay to style buttons to look like links. What really matters is the underlying functionality. Now, does it operate like a link or does it operate like a button? How you style it, yeah, it doesn't really matter as much. Now, to get the accessible name in this situation, you may want to provide additional context. This is something else we see a lot as auditors. So that Read More link is not terribly descriptive. But if it's the only Read More link on the page, you'll probably be able to figure out what's going on based on the surrounding context and be all right. But if you have 20 of these and they're all in close proximity to each other with, you know, maybe some visual headings in between, stuff like that, that information that is readily apparent visually needs to also be provided contextually programmatically. And we can do that a few different ways. In this example, we're going to do so by using visually hidden text. So while visually, this link says Read More, inside the actual code for it, we see the read more contents along with a span that we've set with a class for screen reader only to be visually hidden. Now, the contents of that is about your accessibility partner. And it's not displayed on the page, at least not visually. But it is still part of the content that's used to calculate the accessible name that gets announced to assistive technology users. So if we look at the computed properties panel and we look at calculated accessible name, even though, again, visually this link only says Read More, the accessible name is Read More about your accessibility partner. We can see that it got it from its contents. But again, it got that based on the visible contents and the visually hidden text contents. So now, when a screen reader user navigates to this link, they won't just hear read more link and have to wonder what they're reading more about. Instead, they'll be given the context of they're reading more about their accessibility partner. Now, when you're doing techniques like this, you still have to be careful. For example, that 2.5.3, label and name error, that could creep up here again as well. You have to make sure that the accessible name at least contains in whole or in part the visible text. In this case, read more. And you can't separate that. So you can't have read about your accessible partner more. It has to stay together as one string. Read more about your accessibility partner. And if you do that, then this will also still work for people navigating by speech. So saying, "Click read more" will activate that link. And it'll work. All right, moving right along. We have another link. Another common example. The example in this case is a, it's a visible logo. It's the TPGi logo. And it's been linked to the TPGi homepage. In this case, there's no text content. And so the accessible name is going to be derived from the alt text provided for that image. So the code for this is a link to the TPGi homepage. And the child content is just an image with alt text equals TPGi. So when we go over to the computer properties panel, we look at the accessible name, we see what sources it found potential naming from. We see the contents hold the alt text TPGi accessible name. And it's gonna use that as the calculated accessible name for this link. So now, when a screen reader user navigates to this link, they'll hear TPGi link. Similarly, if a person navigating by speech said, "Click TPGi," it would activate this link and everything would work as expected. Okay, moving right along. I told you we were gonna get more advanced. And we're gonna start to ramp up right about now. Just hold with me. Example nine is a form field. And it gets its accessible name from the label element. So whereas before, we were all operating under one element with potential child content and attributes that change that single element, now we're using multiple elements. And we're trying to programmatically tie them together. The visual example presented is visual text first name, asterisk, followed by a text box. And the code for that consists of two separate elements. The first is a label element with content First Name. And it's been given a for attribute and for an ID of firstname. The second element is an input element. And it has an ID of firstname so that now, these two elements are programmatically linked together. So when we look at the accessible name for the input element, that's what we're inspecting, we can see that the accessible name in this situation was calculated as First Name. And it got that by looking at the potential hierarchy choices there from the from label attribute. And it'll go so far as to tell you what the accessible name was for that element being referenced. So in quotes, it shows "First Name" in the hierarchy area over here, which matches what ended up being the calculated accessible name, First Name. And what that translates to is a screen reader user that now comes into this text field will be told what the visible label is for this text field programmatically. So when they get in here, they're gonna hear first name, text box, editable. Things like that. Similarly, somebody navigating by speech can say, "Click first name." And it'll put focus in that editable text box so they can start populating it. But they can only do that because we made this programmatic association. If we had just put those two separate elements up there, it might've looked fine. But they wouldn't have been programmatically linked. We had to use that for an ID attribute to make sure that the two were talking to each other. And that got translated in the accessibility API and provided an appropriate accessible name. Okay, example 10. This is a custom widget. This is a dialog. And specifically, this is a dialog where we're gonna use the aria-labelledby attribute to provide an accessible name. Now, the general rules for providing an accessible name for a dialog is if there is a visual heading present in the dialog, we want to go ahead and reference that real visual heading. That's the ideal way to do this. If there is no visual heading, which is sometimes the case, we can use aria-label instead. But the preference is for aria-labelledby looking at real text. So the visual example shows a dialog window. And in it, there's a visual heading that says add special instructions. And the way this has been coded up is we have a div that we have assigned a role of dialog to to make it a dialog. And then we've gone ahead and assigned an accessible name to it using aria-labelledby, which points to an ID dialog1_label. Well, dialog1_label needs to exist somewhere. And it needs to exist on the text that we're referencing. So the text we're referencing is an h2. And we've added id="dialog1_label" to that. So now, these two are programmatically linked. Even though they're child elements of each other, these are now programmatically linked in this manner. And this is the proper way to do this for dialogs. So when we look at the computed properties panel, the accessible name of this dialog ends up being Add Special Instructions. And it got this from the aria-labelledby attribute. It'll tell us that the ID that we referenced with that aria-labelledby attribute ended up finding this h2 with that ID, dialog1_label. And again, telling us what it thinks the accessible name is of that element. So that h2 element's accessible name is Add Special Instructions. And we're saying to link that programmatically and use that to announce the name of this dialog. So what that means is when a screen reader user opens up this dialog, if we hadn't done this, they would just hear dialog blank or something along those lines. They would've no context. But now, they hear add special instructions dialog. They know what the dialog is they've opened. They've been given the context. And it aligns with what's presented visually. All right, second to last example. We're getting close. This one is a combo box with list box. And we're again gonna use aria-labelledby to provide the accessible name. The visual example is visible text Favorite Fruit, followed by a combo box, which already has its associated list box opened. And the code for this consists of three separate elements. There's the visible text. There's the combo box. And there's the list box. And just like the previous example, we wanna programmatically associate these separate elements to provide a contextual accessible name with what's already available on the page. So we're gonna give that visible text, Favorite Fruit, an ID. And we're gonna reference that ID in an aria-labelledby call on the element with role label combobox. And so now, when we inspect the element with role label combobox, we see the computed properties accessible name, again, comes up with Favorite Fruit for the same reasons as we discussed in the last example. We programmatically linked these together. Otherwise, they just would've been separate things. And a screen reader user navigating to this would just hear combo box, list box. Things like that. They wouldn't have any context. But by programmatically linking these together, it gives the computer accessible name something to reference and it can announce that to users of assistive technology. Similarly, if a speech user was trying to activate that combo box, it has to have an accessible name. So if we hadn't done this and a speech user had said, "Click choose a fruit" for example, then it wouldn't have done anything. All right, last example. This is the most complicated one we're gonna go over today. This is a button with an accessible name from a recursive aria-labelledby call. That sounds really complicated, but it's not so bad. Bear with me. So the visual example in this situation is a heading that says Your accessibility partner and a button that says Read More. This is very similar to the earlier example where we provided additional context by using visually hidden text. And as I explained, if this was the only instance of this on your page, you might be fine. But if you've got 20 of these, you really need to give some context so that users of assistive technology can understand what they're trying to, in this case, read more about or whatever your control is named. So we're gonna do this, excuse me, again by linking programmatically these two separate components or elements. So we have the h2, Your accessibility partner. And we have the button, Read More. And we're gonna give each one of those an ID. We're gonna give the heading an ID of heading1. We're gonna give the button an ID of control1. And we're gonna use the fact that aria-labelledby does not have to point to just a single element. It can point to a whole string of IDs and then concatenate those together to create a more robust accessible name. It can even reference itself. And that's what we're doing here. So on the button element itself, we have an aria-labelledby that points to control1 and heading1. And if we inspect the accessibility panel over there, the computed properties accessible name ends up being Read More about Your accessibility partner. Just like in the earlier example, but done a different way. What's neat is here, it'll also show you every single ID reference that that aria-labelledby looked at to create that accessible name. So underneath the computed accessible name, we see the aria-labelledby hierarchy attribute there. And it has both the button that had the control1 ID tied to it as well as the h2, which had the heading1 ID tied to it. And it'll show us what each of those independent accessible names were calculated as. So for the button control, it calculated the accessible name as Read More about. And for the heading ID, it calculated that accessible name as Your accessibility partner. It then combine those together to create the accessible name, Read More about Your accessibility partner. So now, if you're a screen reader user, and you're navigating a whole bunch of these buttons like this that just visibly say read more, if we've used techniques like this, instead of just saying read more button, it'll say Read More about Your accessibility partner button and provide that context for you for what you're interacting with. And again, the same rules apply. You have to make sure that you don't fail things like label and name. So we have to have the read more in there as one string so that speech users can say, "Click read more" and this will still function for them as well. Okay, there was a lot of examples. And let's go and summarize. So we've learned that the accessible name gives context to interactive or meaningful elements. We've also learned that the accessibility API is translated based on how your code is structured programmatically, not how it looks visually, and that the accessible name is part of that accessibility API and the calculated value based on a hierarchy of potential naming sources. Also taught you how you can view the calculated accessible name of any element in the DevTools elements tab under the accessibility panel. All right. Now, that brings us to the end of our session today. Thank you so much for joining me. This concludes today's session on "Pieces of an Accessibility Audit - What's in an Accessible Name" by myself, Wes Estes, accessible engineer at TPGi. I again remind you. For more technical information on manipulating accessible names and crafting good accessible names, please look at some of the articles by my colleagues. We have "Good Intentions, Poor Context" by Doug Abrams and "Context is king: long live the king" by Ian Lloyd. I think we still have time for some questions. Is there any questions that we have?

- [Kari] Yeah, we've got about six questions right now in here. So the first question we have. "For PDFs that will be both printed and published on the web, what is the best practice to use for the accessible name?" There's an example with a page link in the Q&A as well.

- So the quick answer is I'm not a hundred percent sure on this one 'cause I'm not a hundred percent sure what you're asking. But why don't we follow up with you with email on this one and go on to the next one.

- [Kari] All right. Next question we have here. "I'm wondering whether a list can have an accessible name. Example, social links are grouped in a list, but without any nav or any other landmark role. Just a list."

- That's true. So lists can have an accessible name. But they don't necessarily need to have an accessible name. This is another one of those kind of gray areas. So you can go through and you can apply an aria-label, for instance, to the ul. And that'll be exposed to the accessibility tree. But you don't necessarily have to because a lot of times, the list is prefaced by other context.

- [Kari] Yeah, next question we have here. "In example nine, does the screen reader need a required indicator?"

- Yes. I said that I simplified a lot of these code examples. And that's true in this case as well. So the required indicator visually is not necessarily required for screen reader users. Depends how you've set up your site. If, for instance, you have a description saying that asterisk denote required fields at the beginning, then you may wanna still have that exposed. But most of the time, screen reader users rely on one of the other attributes that gets applied. And that's the ARIA required attribute, which I omitted in this example for the purpose of brevity. But you're correct that they need to have some way of being told that that thing they're on is a required thing.

- [Kari] All right, next question we have here. "Are the steps shared in the examples specific to websites or can they be applied to PDF remediation as well?"

- Okay, another good question. I'm not as familiar with PDF remediations. So this is another one of those where I'd like to kind of pull my colleague and get back to you via email on that one, if that's okay.

- [Kari] "Is it allowed to use aria-label with a dynamic logic like in the example 12?"

- Let's go up to example 12. Yes. Yes, it is. So one thing I didn't point out in this one is that the contents of that button that is being referenced by its own call. We also use some visually hidden text to add the about for clarifying things. You could have also applied to this an aria-label of, let's just say read more about, and an aria-labelledby call, again, to itself and to that heading. And it would come out the same way. You could do it that way as well.

- [Kari] All right. Next question we have here. "For a frontend dev who has not used, used with a screen reader, is it safe to say that looking at the accessible name in DevTools is enough to predict how a screen reader would announce it in interactive control?"

- All right, so this is a little bit tricky. With enough experience in using a screen reader, you can learn to predict how that accessibility panel will be announced by a screen reader. So if you have enough experience to understand how that's being announced, then yes. A lot of times, for your gut check, it's good enough to look at the accessibility panel, see how you think this is gonna be announced, and continue to put your thing together. But you should always do a final check with an actual screen reader to hear how it really gets announced.

- [Kari] All right, next question we have. "What's the use case for using aria-describedby rather than aria-labelledby?"

- This is a great question. So I intentionally avoided this and focused on purely the label. So aria-describedby provides a further description of the element with the accessible name. So, for example, if you had, I don't know, a form field, enter date, and then you had additional, enter birthday. And then you had additional instructions with format equals DD/DD/YY, or MM/DD/YY, things like that. You may not wanna include those specifics in the accessible name, but you still want them to be available. And you could do that programmatically using aria-describedby. The difference is that aria-describedby is a feature that can be turned on or off by the screen reader user based on their preferences and is announced differently based on how people are navigating with a screen reader. So if you're navigating with a virtual cursor, you may not hear the aria-describedby announcement. But if you're navigating by tab, you might if you have those settings enabled. What that translates to is if it's important information necessary for contextually understanding what the element that it is you're interacting with is for, it's better to include that in the accessible name so that it's available all the time. Additionally, when a screen reader goes to read that, so let's use that enter date of birth example again, it's going to read the accessible name, enter date of birth, text field editable, and then there'll be a pause, and then it'll announce the accessible description, if there is one, and if it's enabled. And that "Context is king: long live the king" article, it actually goes into this into some more detail. So if you want a more tech heavy answer on that, I'd recommend you give that a quick read.

- [Kari] All right, next question we have here. "Do we have sub-navs contains accessible names?"

- I'm sorry. I don't understand the question.

- [Kari] Yeah. We'll reach out and ask for more clarification on that if needed.

- [Wes] Yeah.

- [Kari] Next question I have, it says, "I'm a bit confused about the term accessibility API. Could you elaborate a bit on that?"

- Sure, okay. So I know we kind of covered this a little bit in the beginning. But this is that first key concept that I said that, you know, not everybody quite understands yet. So there's your, let's just use a webpage as an example. There's other types of content. Let's use a webpage. Your webpage looks a certain way. But how it's coded ultimately gets translated on the backend into the accessibility API. And various assistive technology tools can interface with that accessibility API to get the information that is represented by the webpage. One of those is the name property. So I keep calling it the accessible name, which I note in the example is it just listed as a name. That was me trying to give you context. That's coming from the accessibility API's name versus some other random name. The accessibility API is gonna contain all of those relevant attributes, not just the accessible name. So it's gonna contain things like, hey, what is the role of this element? You know, what is the current state of this element? Does it have a value? Is there an aria-describedby? What's the aria-label on it? Where do these things all end up? It's gonna map all that information so it's available to assistive technology.

- [Kari] All right, next question we have here. "If a link does some action, example copy URL, how could we inform a screen reader user about this action? Titles?"

- The link does some action. So I think what you mean here is like, does a button do some action like copy a URL? 'Cause a link would probably take you to a different URL or something like that. And in those situations, we would notify the screen reader that the action had taken place with, it could be a few different ways. But let's just say you had a button that, you know, copied that link. Okay, but when you activated that button, you need to notify assistive technology users that some action has occurred. That could be a dialog opening that says success, you know, or content copied. Things like that. It could also use an area live region, although that's less preferable to announce the status of copied. Things along those lines.

- [Kari] All right. Next question we have here. "In example seven, you indicated that a person using speech command would be able to activate the read more button, which had screen reader only text connected to the accessible name. If the page had multiple read more buttons all coded with unique accessible names, will the speech command need to be repeated to get to the third read button, read more button since the full name is not visible to the user?"

- This is a good question. And you're correct that since the user is going to be saying only part of what could be multiple names, when they do so, depending on which speech input program they're using, it may try to help them. So for instance, if they said, "Click read more," it might add numbers on the numbers of, you know, say 20 read more buttons on the page. And then they could say, "Number two," and it would activate that one. Additionally, they may start to understand how this is formed. And so they might say more than just read more. So they might say, "Click read more about your," and then it would know, find this one. Speech users also have other ways of of navigating. So they could instead say, "You know what? I'm confused. Show me all the labels." And it would go ahead and it would show them on the screen what the accessible names are of those various controls so that they could speak them out loud and control them. Good question. Thank you for that one.

- [Kari] All right, next question here. "If an element is intentionally hidden from screen readers, does it still need to have an accessible name so that the voice, so that voice input users can access it? If not, it fails WCAG 2.5.3, label and name, correct?"

- Let's see. So if... This one's not showing up. Sorry, I was trying to read it. But... So I think you said, "If an element is hidden from assistive technology, does it still need to have an accessible name for speech input users?"

- [Kari] Yes, correct.

- And the answer in that case is yes.

- [Kari] All right. Let's see. And then we have, "Will the accessible name be ordered according to how elements are listed in the aria-labelledby attribute or does the order depend on something else?"

- Ah, so I think what you're asking here is about that last example where I was referencing multiple IDs to concatenate. And yes. The way they're ordered does matter. So if we had flipped the IDs referenced from the control1, heading1 to heading1, control1, it would've announced those things reversed. It would say, "Your accessibility partner read more about."

- [Kari] All right. And last question we'll get to here. "As a beginner to accessibility, can you kindly share how much ATML training one may need to locate and correct the accessible names?"

- Hmm. Okay. This is gonna depend on each individual person and how tech savvy they are, how much code experience they have, stuff like that. But if you're a beginner and you're just trying to kind of understand what various things in HTML do, the first thing I would do is I would actually take a course on basic HTML, And then I would probably take a course on basic CSS and JavaScript, just to kind of get your feet wet and get an understanding. But if you're used to code and you're used to looking at things like this, then in that DevTools window, what you can do is you can actually modify the code live. So you can see what the accessibility tree, accessibility panel is showing in the computed properties. And then you can start adding attributes at various places and see how that affects the resultant accessible name or other attributes that you're trying to understand how they're tied together. This is actually one of the ways that I actually started off in accessibility as well. It was I started off by just trying to understand how these elements interact with each other and investigating and researching and reading great articles. So that's where I would start.

- [Kari] All right. We'll go to, we had one more question pop up in the chat here and then we will wrap up. "To ensure that both screen reader users and speech input users can access an interactive element, the visually accessible names should always be shorter than the computed accessible name. Vice versa, it may create problems for speech input users. Is that correct?"

- If I'm understanding your question correctly, the answer is, it kind of depends. So kind of like I alluded to earlier, if you have an accessible name and it's nice and short and succinct, it's also easy for a speech input user to say. But they only have to be able to say part of that for the the API to essentially find the resource that they're trying to pinpoint. So they don't necessarily have to say, you know, click on 50 word phrase. They can just say part of that. But similarly, you know, if you have really, really long accessible names, then they may be too verbose and you may need to think about kind of simplifying your interface and making this more usable. I hope that answers your question.

- [Kari] All right. Again, Wes, thanks so much for your time. Everyone, thanks so much for attending the session. If we did not get to answer your question, we will reach out to you via email. I will also send the answers to any unanswered questions. Make sure those go out with the recording as well so that those of you who attended that would like to hear the answers will have copies of those answers as well. If you have any additional questions come up after, feel free to reach out to Ida at ida@tpgi.com. And we'll make sure your questions get routed to the right person to get you any additional information. Again, thanks everybody for attending. Wes, thanks so much for your time today. We've got another webinar coming up next week. So check out our website. See what we've got going on next. We look forward to seeing you guys again soon.

- Absolutely. My pleasure. Thank you all again for joining today. Have a good day.