The Web is Inherently Accessible

Speaker 1: Hello, my name is Rachel DeTullio. Thank you for joining me for my talk, The Web is Inherently Accessible So let me just tell you a little bit about me before we get started. I 've been a web developer for two decades. I got my first job as a web developer back in 2000. Um for several years I worked as as a front-end developer for a software company before deciding to go back to grad school and study information science. I got my master's degree with a uh Area of specialization in user experience design, and that's what I focused on for the next few years. until uh I really became interested in accessibility.

Speaker 1: Um between nineteen twenty nineteen and twenty twenty, I got a couple of certifications from the International Association of Accessibility Professionals. And now I am a certified web accessibility professional. And with those credentials and my front-end knowledge, earlier this year I became an accessibility engineer. And what an accessibility engineer does on a day-to-day basis is review uh designs they can be um pre-production or things that are already in production. Um and you we're looking at designs and code, whether it's uh websites, mobile apps, uh kiosks. And testing that software for how usable it is for people with disabilities

Speaker 1: So what are we going to go over today? So this talk is called The Web is Inherently Accessible. And we'll we'll talk a little bit about what that means before we really get into it. And then we'll talk a bit about what web accessibility is. before actually diving into several code examples around uh using the proper semantics for certain elements on the page that um can easily be done with um aria or some other code and may break the semantics. So we'll talk about using native elements whenever we can So the w web accessibility provides an inclusive experience. And what we mean by that is

Speaker 1: That by default the web is accessible if we're using standard native HTML elements , even ARIA. We can create an a very inclusive experience if we are intentional about it. If we're not intentional about using accessibility best practices uh we can very easily introduce several accessibility issues into our code. So to kind of demonstrate this, I came up with um with a site called Accessible Web. And it's it's both a tool that will strip out the CSS and JS from a page so you can just see the HTML elements.

Speaker 1: But it also includes this about page, which I'm showing here on the screen. It says Accessible Web. Please disable CSS to view this web page. So let's go ahead and take a look at this page and see what it's about. So I got the idea for this page from a colleague who trying to make a point changed his website to require the user to disable JavaScript in order to view it. The point was to demonstrate to developers how easily we exclude folks from our websites by requiring JavaScript, for example, rather than working through progressive enhancement techniques. And I decided to do the same thing, but using CSS

Speaker 1: to demonstrate how easy it is to inadvertently um just exclude a huge number of people um if you're not paying attention to what you're doing. So if we look at this page um You can see I'm gonna hit control A. I'm highlighting all the content. There's no there's no hidden content like just cup, you know, the same The text is the same color as the background or anything like that. It's programmatically hidden. And what I want to do now is start up a screen reader. Uh Jaws is the screen reader I'll be using. And we'll see, we can listen to that screen reader and we can we can tell that there's content on this page that for someone who uses assistive technology like a screen reader, this page is fully accessible

Speaker 1: But if you're someone who relies on site, the page is not accessible. And that was that was strictly a design choice. So let me start up Jaws here.

Speaker 2: Jaws.

Speaker 1: And I will just have it read some of the page so that you can get an idea of what JAWS sounds like and also get an understanding of how Text can be hidden, but accessible.

Speaker 2: Accessible web vertical bar about dash Google Chrome banner region visited same page link skip the content. Visited Heading Level 1 Link Accessible Web. Main region. Heading level 2 The web is inherently accessible. Block quote. Quote your weekly reminder that the web is accessible by default and it's our design decisions that stop it being accessible number A11YQM Lingitkov Marmal Underline CT on December 7 2020. Block quote end. Why did you have to disable CSS to view this website no reason other than a design choice that excludes sighted people? Did you notice how many visitors quote view quote web pages already colon? List of five items.

Speaker 2: Bullet search engines. Bullet dots. Bullet site crawlers. Bullet analytics. Bullet blind people. List end. This website is fully accessible to people with Link screen readers. And Braille displays but many websites are not do the poor design choices that exclude some people.

Speaker 1: Okay, so let me turn off the screen reader now. So we could hear it saying a lot of things, and I actually have and we'll we'll be looking at the contents of this page in a little bit, but it's just to It's just a kind of a demonstrate the issues that we can introduce with accessibility and hopefully make you feel a little bit of of the discomfort that that folks who encounter dis disabling websites everyday feel and how it's it's frustrating. It's frustrating. We want when we go to a website we expect to be able to use it and when we can't um that causes um frustration. So let me go back to the presentation

Speaker 1: Alright. So let's talk a little bit about what web accessibility is So web accessibility is the extent to which a website or web application can be used by disabled people. That's my definition. You'll see variations on this, um but essentially it's important to think of just it can be useful to think of disability And accessibility as a spectrum. So I'm showing on the page here a horizontal continuum from less to more, and there's a a marker towards the more end of the spectrum and it says web accessibility. And this is just to show that websites are

Speaker 1: neither accessible or inaccessible. Every page, every element, every component has accessibility factors to it and the culmination of these and the full experience of using the site determines how accessible it is or not. So we're always striving to make our site more accessible. But even if we check all the checkboxes and pass all the criteria, there are those human subjective things that that still may need to be done and can be discovered through testing that would make your site more accessible. So accessibility is defined by the W three C using the web

Speaker 1: content accessibility guidelines, which are a set of guidelines that dictate what you should be striving to do to make your site more accessible. It it's and also realize that that is a floor of requirements. It's not the ceiling. It's the base basic minimum that you should be doing and if you discover other issues in your code through testing or things that are usability issues you should address those as well So the Web Content Excel Accessibility Guidelines, or WUCAG, as you can see in the middle of the chart on the screen. It is made up of four guiding principles, and those are the contents perceivable, operable, understandable, and robust.

Speaker 1: Now, the web content accessibility guidelines have gone through several versions over the years. In fact, we're we're very close to version 2. 2. But right now, um The the version that most people test against is WCAG 2. 1 and within each version There are success criteria, the the discrete things that we're trying to accomplish on our website to make it accessible. And those success criteria are divided into three levels, A, AA, and AAA. Most folks, and this is largely due to because uh laws often point to WCAG 2. 1 level 2A, this is this is the version and level that uh most most of our clients are are testing against and

Speaker 1: striving for. That doesn't mean that you can't also do their success criteria under like the triple A level, but those are often seen as going above and beyond um the the bare minimum. So again if you're trying to make the most accessible site that you can look at those level triple A requirements. But um In general, sites are tested against 2. 1 level 2A. And level and that that combination results in 50 success criteria, which may sound like a lot, but it it's very rare for every for any one web page to be subjected to all fifty of those success criteria.

Speaker 1: For example, if you do not have a video on your web page, that's about five success criteria that you can just say are are not applicable from from the get-go. Because you don't need to worry about captions or audio descriptions, that kind of thing, if you don't have a video on a web page. So that being said, did you know? The WCAG guidelines were first published way back in 1999 , before I even had my first web developer job. So No matter what framework you're using, technology stack, anything, these guidelines have been out before that. They were around when we had HTML.

Speaker 1: And that's a lot of what guides how accessible a site is, is whether we're using the semantic elements in order to um Enable people who are using assistive technology like the screen reader that I demonstrate to understand the interface in a programmatic way because they can't necessarily see the color of an element, the shape, the position. Um they need that programmatically identifiable information to understand controls on the page. Semantics. So That being said, every semantic HTML mistake introduces accessibility issues into your code. You are not properly labeling an element if you're not using the right input.

Speaker 1: Um, all of these things have programmatic information that are relayed back to assistive technology users when they're using something like a screen reader or a ba braille display. And when we don't programmatically use HTML correctly, we get these accessibility issues from semantic mistakes. So my goal And I really hope to convince you as much as you can to use semantic elements to make sure that your interface is as understandable as possible for people who can't necessarily see it or use it in the way that you might imagine um the average user would use your product. So, like I said, um we're gonna look at at some code examples, and you can

Speaker 1: I put uh an uh uh uh some code from that accessible web. about page into a code pen. So you can go to tinyurl. com slash html three three t to open up the code example. Again, that's tinyurl. com slash html three three t So I'm going to switch back over to the web browser here and open up that code pen. And you can already see here on the left in the HTML panel, you can see a lot of this HTML that is in there and that can be read by a screen reader, but is not available

Speaker 1: to a sighted person who uh has CSS enabled on their browser. So the first thing that we should do um in order to um See this a little bit better is I want to disable the CSS so that you can see what's on the page as intended. Okay, so now we can see just the rendered HTML and it's using the browser's default user agent style sheet. So this is Chrome. Um every browser has has a user agent style sheet that that does some basic uh formatting of of elements. So headings.

Speaker 1: H1 to H6 look increasingly smaller and bold. Um links are blue and underlined, um unordered lists have bullet points and so forth. So uh this is just to let you know what is actually on that page and then we're gonna look at some examples further down in the code to talk about the specific semantics. So let me go back to the presentation real quick. Alright, so the first semantic element we're going to talk about are headings. Like I just mentioned. Those are the H1 to H6 elements. Headings break up content into meaningful sections, and screen readers can also navigate by headings, which is why they're really, really useful.

Speaker 1: So I've got some I've got example heading tags here on the right in HTML, so we've got an H1 Accessible Web, which is the name of our web page. Then we have an H2 semantics, and then under that we have our topics we're going to cover, H3, heading, H3 form label, H3 buttons and links, H3 table, H3 images. And then within images we've got three subcategories, so we're down to H4. So alt text h4, SVG H4, and charts and maps h4. And that gives us a way to break up content into logical chunks and makes it easier for folks who can see, they can easily scan the page and and headings will jump out at you. And if you're using a screener, like I said, you can also navigate by headings and I'll demonstrate that when we go back to the code.

Speaker 1: So let's take a look at our example code and we can look over here so here's our heading H1 accessible web Here's our H2, the web is inherently accessible, and so forth. And we can see here on the content side, this is bigger than this, these are H2s, then this is an H3, and you can see how the user agent style sheet cascades those down. When someone is using assistive technology like a screen reader, those heading levels get announced. So let's let's fire up the screen reader again and see how that sounds

Speaker 2: Jaws. The web is an errandly exquote your weekly reminder that Link Kevin marred 7 December to block. Seven link heaven maquet your weekly reminder block quote, heading level, main region, heading level to the web is inherently accessible.

Speaker 1: So you can hear the web is inherently accessible, heading level website

Speaker 2: 1, heading level 1 accessible web.

Speaker 1: Heading level 1 accessible web.

Speaker 2: Main heading block quote link 1 bar 7 block wide detail list of five items bullet bullet bullet bullet bullet list and display link screen braille display. Heading level when the page is the W3Cs when the page is accessible it was developed with the Intent Web Content Accessibility Guidelines Left Parent WCAG right parent heading level 3

Speaker 1: Okay, sorry, that was a little verbose, but now what I'm going to do is I'm going to hit the H key on my keyboard while the screen reader is running, while Jaws is running, and that will show you how the screen reader can switch between Headings down a page just like we can scan with our eyes.

Speaker 2: Semantics heading level 2, headings heading level 3, form labels heading level 3. Buttons and links heading level 3 tables heading level 3 images heading level 3 Alt Text Matters Heading Level 4 SVG heading level 4.

Speaker 1: Okay, so I'm gonna disable JAWS again.

Speaker 2: Unloading JAWS

Speaker 1: So, you can see how headings really break up content and and also allow navigation to be easier for folks who are using assistive technology. And that's the main reason to use headings because anything that visually looks like a heading should programmat programmatically be marked up as a heading and the way you do that are with the H1 through H6 elements. Best practice is to have one H1 on the page just So that that's the you know the overall main heading topic on the page. Um HTML5 doesn't require that. Again, it's just a best practice to have um your single H1 that says what the main topic of the page is.

Speaker 1: Alright, so that's headings. Now let's go back to our presentation. And let's talk a little bit about forms. So form labels, labels provide visible and accessible names to form inputs when they are programmatically linked So a lot of people know about the label element, which you can see here in our HTML example. Label for equals email, and then we have the visible label is email and end label. And then in the input that follows it, we have an ID equals email. And that's what the four in the label is referring to. Um it it's referencing the ID of the input.

Speaker 1: And that is how we programmatically link an input with a label. If we don't have the four, or if the label does not surround the input, which is typically what you do with like a radio button or a checkbox, then that semantic link is broken And what does that do? Well, when a user using a screen reader gets to an input, the The screen reader may not announce the name of the label. It'll just say text box editing. And this is because the four and ID attributes are not aligned. This makes it harder for people who use screen readers to fill out forms or understand what controls mean when they don't have clear, accessible labels.

Speaker 1: The other thing that we should note, two other things that we can note on the input here. So we have type equals email. So there are different types. So the default type is type equals text. for something like entering your name. But there are special types which you can look up, and email is one of them that programmatically indicate the kind of information that this field is looking for. And that's another accessibility requirement. It makes it easier for folks to to fill out forms. It can trigger a different kind of keyboard in a mobile context. You may have noticed that before, that looks different than the regular just typing keyboard. And then the other element attribute that I want to draw your attention to is the autocomplete attribute.

Speaker 1: This is another accessibility requirement. So anytime you are asking for personal information that uh could be stored in the browser something that um the site the site could autocomplete because that information has been filled out in the browser before. Um we can trigger that by saying autocomplete equals email. So any other fields where they 've been named email and there's a value that's been entered, then the browser can remember that and help folks autocomplete future forms with that autocomplete equals email. And there's a whole list of those autocomplete attributes that you should look up for anytime again that you're asking for personal information. So

Speaker 1: name email address and so forth. Alright, so let's go ahead and look back at our code again. So I'm scroll down the page here a little bit till we get to the form labels section. And I'll scroll down in our HTML. Okay, headings. Form labels. So here we are, form labels. So uh a couple of things that when these are are programmatically linked correctly, uh some things that you can do. You can click on the label to actually toggle the control. So and that's a really big help because these

Speaker 1: Hit areas are usually pretty small on radio buttons and checkboxes. But if you can click on the label as well, that makes it a lot easier for folks. So And if you're creating your own custom components, and I'll talk about this um a couple of times during this presentation, if you're If you've got these as a custom component for some reason you don't want to use a default checkbox, there are several things that you have to do to make that checkbox work. So it has to work on mouse click, it has to work with the enter or space key on your keyboard. It has to be focusable. And these are all things that are natively done when you use out-of-the-box input elements.

Speaker 1: If I use my keyboard here, you can see there's a focus indicator when I tab through these with my keyboard. So you have to make sure there's a focus indicator if again if you're doing anything custom. um or you're you're messing around with focus indicators. I'm using my space key here to select and unselect that. So that's an example of form labels. Um let's look at look at m uh input type equals text. So here we've got And I'm going to scroll down so that we can see the HTML as well. So yeah, I I want to I want to mention when you have a group of controls like

Speaker 1: a list of radio buttons with several options, check boxes with several options. Another semantic uh Some semantic elements that you want to use are the field set and legend, which you can see over here. And a field set and legend programmatically groups form controls in a way that assistive technologies c users can understand that These checkboxes are related in some way and not just a series of checkbox inputs with with um no commonality. So the the legend for our field set here is cat 's colors, and then we see that each of the options is a color. So that's an important thing to do is group, programmatically group form elements when you can

Speaker 1: Now if we look at some typical uh just text-based uh input type equals text where we can just type in Something like Kat 's name. Again, we can see there's a focus indicator around our field. There's a cursor that tells us we're on that field. If I click on Kat 's name, it's putting Focus into the field. Just like it toggled on and off our checkboxes. Um you have that same hit area when you've got it programmatically um associated that lets you also tap on this and not necessarily have to um tap on the f on the form field. Just a quick thing that I want to mention, um, you always want to make sure that these fields are programmatically

Speaker 1: determined to be required or not. So we've got a little asterisk which visible or I'm sorry uh sighted users can see and know that a field might be required, but assistive technology doesn't necessarily So we've done two things here. One, we've used aria -hidden equals true to hide that star, that asterisk, from screen readers so they don't hear it. Because it's it's it's really just for cited users. But on the input, we've done two things. We have a dash required equals true, which will programmatically um announce that a uh field is true. And we also have the HTML required attribute, which will allow some moderate um

Speaker 1: in page uh field uh form validation, but don't rely on it. It it's not always announced correctly by screen readers. You still want to have your own um field validation on submit and display error messages and such, but this can help uh users fill out the form. more quickly. Um let me start up the screen reader and we can listen to what that required field sounds like

Speaker 2: Jaws.

Speaker 1: As well as let's let's listen to these checkboxes too.

Speaker 2: The web is an air groupstart black checkbox not checked group start cat's colors. So

Speaker 1: group start cat's colors.

Speaker 2: Black checkbox not checked.

Speaker 1: Black checkbox not checked.

Speaker 2: White checkbox not checked. The web is inherently orange tabby checkbox not checked. Torby checkbox not check Great checkbox not checked, the check press spacebar.

Speaker 1: Okay, now I'm gonna tab over to the cat 's name required field and let's hear what that sounds like.

Speaker 2: Cat's name edit required invalid entry has pop-up type and text

Speaker 1: So you could hear that it said invalid entry required and that lets a screen reader user know that they have to put some kind of information in this field. Let's listen to the email one.

Speaker 2: Email edit required invalid entry as pop-up type and text.

Speaker 1: So again, this one's required. It just doesn't have the visible asterisk, but it programmatically it's Still being announced as required because we have aria dash required equals true. Let me turn off Jaws. So yeah, something important to note is A lot of a lot of people have heard of ARIA, which stands for Accessible Rich Internet Applications. It's basically a set of attributes that make that extends HTML's semantic capabilities for more advanced um functionality things like um drop down uh a a menu that that has a a pop-up

Speaker 1: um various kinds of of button um Tasks that that happen when you that you when you need a button like a date picker or logging out, that kind of thing. So yeah, so let's um so that's form labels. These are important. Next, let's look at another part of forms, which let's go back to the presentation. All right. Um quickly let's look at tables. A lot of folks think that They should not use tables.

Speaker 1: That tables are completely off-limits. This is, for those of you who are too young to remember, we used to use tables to lay out our designs in HTML. And that has semantic problems. If something is a table, it should contain tabular data and nothing else. So there are a lot of valid reasons to have uh tables and tabular data, we just have to make sure that they're marked up correctly. So we can see here in the HTML we've got a table The table has a caption. The caption, it can be visible or hidden, but it's important for assistive technology users so they understand what the purpose of the table is.

Speaker 1: So that will be announced at the beginning of the table. Then we have our first row in our table. And that first row generally are contains our column headers. And that is a special uh element called the TH element. So it really does matter if you use a TH instead of a T D for your column headers because for assistive technology users These column headers will be announced periodically, depending on the screen reader, to help orient as they're moving through different rows and columns of the table with the arrow keys or tab. And it will identify something as a column header

Speaker 1: and then tell you what the name of the element in that row is. So we can take a look at uh have a listen to what that sounds like. Um let me go back to our web page. Scroll down here. To tables. Alright, so we can see here I'll scroll down this. So here's our HTML here, table, caption, TR, TH, and so forth. And this is what it renders as. So caption is at the top of the table, then we've got our two table headers, which the user agent style sheet bolds. to make them look different. Um and then we've got our table rows with with our data.

Speaker 1: So let's see what that sounds like.

Speaker 2: Jaws The web head mail and the cat and the cat isn't re as head to for builds while it the one thing about accessibility most people know is that it hadn't taken black briad hashtag black still torble. Luna, Kat 's K Cat's name. About table with about my cats. Table with two columns and five rows. About my cats.

Speaker 1: Okay, table with two columns and five rows about my cats. Then we're gonna go to row one.

Speaker 2: Cat's name. Cats colors. Luna. Torby Stellan Black and White Shadow Tabby, Brienne, Black and White, Table End

Speaker 1: Yep, so as I use the virtual cursor to go through the table, you could hear how it actually announces all of the table data cells in the table as I navigate with my arrow keys. There are other ways to navigate tables that's not just sequentially um or tabbing through. Um but we won't get into that for for this talk. But it's important to understand that there are definitely times that you need to use tables and HTML tables. A lot of folks We'll try to mark up a table using ARIA grid, roll equals grid. This is only the role equals grid is only for interactive tables. If it's literally something like a spreadsheet. that you're trying to replicate in HTML. Otherwise you want to just use

Speaker 1: native table layout and it is the most semantic semantically sound thing and it allows um users to navigate through the data in ways that they understand how to do with their assistive technology. Alright. So let's go back to

Speaker 2: The Web is inherently a PowerPoint spandicum. The web growth jaws, the web, the web powerpoint slideshow dash the web heading level 1 code pen example. The web has has notes presenter slide 12 dash buttons and links.

Speaker 1: Oops, let me turn off

Speaker 2: unloading JAWS.

Speaker 1: Alright, so buttons and links, let's talk about those real quick. So A lot of people think these are inter interchangeable, that a button can be used as a link, a link can be used as a button. But again, there there's a strong semantic element here and these two things do different things and should be used for their speci specified purpose only. So a link moves focus to a new URL. Whether that's um jumping somewhere place in page with an anchor like when we use a skip link or actually taking you to another another HTML page, another web page. When that URL changes in the address bar,

Speaker 1: You should be using a link. Um unless this button unless what you're doing is performing an action. So for example, you might have a You have a form. We all know about buttons on forms. A button can submit a form. But buttons should also be used for anything that's interactive. Say opening the menu on the uh mobile viewport of your site, um the hamburger menu, uh a date picker, a disclosure widget, any number of things where if you're if you're Clicking an element or focusing and using the keyboard on an element to make it do some kind of action within your application, that should be a button.

Speaker 1: And one of the important um aria attributes that you want to use on a button if you are doing something like having a menu pop out, You want to use aria dash expanded equals false when the menu is collapsed. But as soon as that menu is expanded you change that attribute to true. And again, this is this is a semantic way to express to screen readers the state of the UI. So the screen reader will say button expanded or button collapsed based based on that particular attribute. And that's really useful for folks who can't see the interface but want but need to know what is happening and what it's doing.

Speaker 1: So let's go ahead and look at our code example and we'll look at some buttons and links So um I mean everyone knows what a link is. They just get misused sometimes. Uh especially like folks will will have we'll use an A Href. element but then they will say roll equals button. You don't want to do stuff like that. If you need a button, use a button as much as you can. Now I realize there are some framework limitations. But as much as possible you should be using that native native button element. And what does that do? Well, when you have a native button, it's already can get keyboard focus for folks who are not using a mouse.

Speaker 1: It can be activated with both the space and enter keys. It's activated on key down. It's activated on mouse click. And you can give it an accessible name and you have these um helper classes in Aria like the Aria dash expanded to help identify for for folks who can't see the screen what's going on with the application. But if you say take a div or some other unsemantic element and you add that role equals button Uh you have to you have to programmatically make sure all of all of those things are true. It has to be focusable with the keyboard, it has to work with space and enter keys and so forth And you save yourself all of all of the time of of

Speaker 1: and hassle of doing that if you just use the native button to to begin with. All right. Lastly, let's look at the semantics around images. For every image or graphical object, you want to provide an accurate text equivalent This includes things like icons, SVG, charts, maps, other graphics, anything that's conveying information to the user. And that is somewhat subjective. But if you are looking at an image and it's doing anything other than just providing decoration, you should have an appropriate text equivalent. So let's look at our two code examples here. The first is the standard

Speaker 1: HTML image element and if anything if people know anything about accessibility it's generally that that images need alt text and so this is what that looks like. The image element has an alt attribute Our example is two cats on an easy chair under a blanket, and we'll look at that in the code example. But what if you have like an inline SVG? that does not support the alt attribute. So if you were if you were loading an s an SVG with the image tag an svg file, so say cats. svg, that would still support the alt uh attribute. However, if it's inline SVG in the page uh where you're doing some kind of dynamic

Speaker 1: code switching, we have to label it a little bit differently. There is a title element that goes in the SVG element that holds the name of your label and in this case it's purple hexagon. What we do is we give a unique ID to that title element. Here it is ID equals SVG dash title. Then we go up to our svg element and we can say aria -labeled by equals svg-title and the screen reader will announce that it's a graphic and the name of that graphic, whatever we've given it in title. So let's go ahead and go over to our code example and see what that's like. So

Speaker 1: here's our Image example we can see here and there's two cats under a blanket Then we've got the purple hexagon, we can see our inline SVG here with our polygon and fill, and then a more complex image down below. So I'm going to go ahead and start JAWS. And then we will hear what these sound like.

Speaker 2: Jaws The web is anherrantly accessible dash Google Chrome frame wrapping to top to get Ms. Two Cats on an easy chair under a blanket graphic. Purple hexagon graphic. A cat lying on the bed that is divided up into areas graphic

Speaker 1: So for all those we could hear essentially a text equivalent that describes them in some way. Our third example, the more complex example of a cat on a bed that's divided up into areas Below that we have some text, and and this can be visible or hidden. Best practice is to make it visible to everybody, but it's it's a longer description that further describes a complex image. If this were some kind of chart or graph, you might have a data table that that lists out the specific data points within the graph and some kind of summary explaining what the data is showing.

Speaker 1: For this one, what we have, if we go over and look at the HTML here on the left, The image is marked up in a figure element, and the longer descrip description is marked up as a fig caption element with a unique ID. The The image element can then use the aria -described by attribute to reference cat map and what that allows to happen is both the alt tag both the alt attribute value is announced by the screen reader as well as the longer description from the ARIA dash described by.

Speaker 1: So let's go ahead and listen to that real quick.

Speaker 2: The web is an errantly access rapping tattoo purple a cat lying on the bed that is divided up into areas graphic. Rapping tattoo purp rapping tattoo purple a cat lying on the bed that is divided up into areas graphic cat bed never used pillows show weight for food here and pouring zone. Other areas on the bed are listed as pruning salon, sleeping area, launch pad too.

Speaker 1: And so forth. So you get the idea. So I'm gonna go ahead and shut the Okay. So let's go back to the presentation. And that's all I have for today. So please feel free to reach out to me with any questions or comments. I'm on Twitter at Rachel DeTullio. You can go to my website, racheldetulio. com, or email me at work, rdetullio at tpgi. com. Thank you very much.