- [Mike] Thank you for joining us today. We'll begin momentarily. Thank you for joining us today. We'll begin momentarily. All right, good morning, good afternoon, everyone. My name is Mike Mooney, the Director of Marketing at TPGi. Really excited to have everyone join us today for "The web is Inherently Accessible." Now, before we get started, I just wanna go through a few housekeeping items. First off, this session is being recorded and we will email everyone the recording after the event. We have captions available, feel free to use those as needed. And lastly, if there's time for Q&A at the end of the session, please use the Q&A box provided by Zoom, and we'll get through as many questions as we can at the end of the presentation. And with that, I will let Rachele get started. Go ahead, Rachele. - Thanks, Mike. Hi, my name is Rachele DiTullio. I'm a Senior Accessibility Engineer with TPGi. And welcome to the talk: "The Web is Inherently Accessible." To start with, I just wanna give you a little bit of my background, so you know where I'm coming from. I've typically tailored this talk towards developers, but this time I hope to make it a little bit more expansive for other folks as well. So I got my first job as a web developer back in 2000. That's my background, a front-end web developer. After working for several years at a software company, I went back to graduate school and I got a master of science degree with a specialization in user experience design. That's where my interest laid with usability and information architecture, and that naturally led into accessibility. And so after doing some UX accessibility work for another software company, I decided to get the IAPs certifications for web accessibility specialist in the CPAC. So I'm a certified professional in web accessibility now. Last year I transitioned from being an internal accessibility person to working at TPGi as an accessibility engineer. So doing accessibility full-time. And this past March, I got a promotion to senior engineer and I'm actually leading a team now. So that's an interesting experience. But let's go over the agenda of what we'll be talking about today. So first we'll go over a little bit about what is web accessibility? What do we mean by web accessibility? Make sure we understand what terms we're talking about and that we're defining the same things. And then we're gonna dive into some semantic markup, particularly around headings, buttons and links, images, tables and forms, to get an understanding of sort of that natural inherent accessibility that the browser and HTML gives us when we're creating web pages. All right, so what is web accessibility? This is my definition, but web accessibility is the extent to which a website or web application can be used by disabled people. And when I say disabled people, I mean, people who are unable to use our websites or web applications due to some kind of design issue that we've implemented. Something that prevents someone from using the site when they probably could, if we had the right semantics and everything coded in there. But it's also important to note that web accessibility is not an all or nothing thing. So we have guidelines that we follow. You know, if we think about web accessibility as a spectrum from less to more, all our sites fall somewhere on there. There's always something more we could do. We could always introduce a lot of problems and make it less accessible as well. But if we think about it as an ongoing process and a spectrum where we're trying to incrementally improve over time, I think that makes the problem of an inaccessible site a little more manageable, and gives you kind of an idea of what we're approaching when we talk about these guidelines and then that there are additional things that we could do that are outside the guidelines. For example, dark mode has gotten a big comeback recently. You know, there's nothing in our guidelines about providing dark mode, but that is a more accessible experience for some people, if we added in there, so that would allow us to be more accessible. And like I said, your site is always changing, your content is always changing, so it's difficult to think of accessibility as an absolute boolean; it's there, it's not. There are a lot of layers to it and a lot of different aspects that we can approach accessibility from. And so we'll go over a bit of that today. But as I mentioned, there are guidelines, the web content accessibility guidelines. These are the main criteria that we look at to determine whether a webpage conforms to these web content accessibility guidelines, and therefore we can say is more or less accessible. The guidelines are broken up into four. Well, there are four different guidelines that break up the success criteria for the web content accessibility guidelines. And these are perceivable, operable, understandable and robust. And so you will see success criteria, they all start with a number, so anything that's a number one is perceivable, anything that starts with a two is operable, anything that starts with a three is understandable and anything that's four falls under robust. And I won't go deep into that. I assume some folk folks have some rudimentary understanding of accessibility. But when we're testing, it's important to understand we're testing version 2.1 of the web content accessibility guidelines. And we're usually looking at a compliance level of level 2A which includes all level A items and all level 2A items. And this brings us to a list of 50 discrete success criteria that we can test any content or component against and figure out how accessible is it according to these guidelines. But like I said, there's always more that you can do. These guidelines are really the floor of the building. There's always more that we can do to improve it, make it more functional, more useful to certain sets of people. So don't let this limit you and limit your thinking that you only need to follow these things. This is the bare minimum, and that's how we should look at them. And we should always look for additional ways to improve as we get feedback from our users. So given that, did you know that the web content accessibility guidelines were first published in 1999? So this web accessibility is older than any framework that you're using to develop with today. It's not a new concept, but a lot of people are just now really kind of understanding what it means and taking it into consideration. But these guidelines have been around for more than 20 years and they've changed and improved over time, but the goal is the same of making accessible content using semantic markup. So let's talk about semantic markup. That's really the crux of the talk today. And when I talk about semantic markup, it involves a couple of things. The first is native HTML elements. That's where we always wanna start when we're creating any component, any piece of content, we want to make sure that it semantically makes sense. And by semantics what I mean is when we use different elements for containing our content, we are conveying to assistive technology, and to some extent, visual users, what the purpose of that content is. So it's not just a bunch of text on a page that just looks a certain way. I mean, we can certainly design our text to look bigger and try to imply that it's a heading, but if it's a heading, it really should be marked up as a heading and not just look like one so that people who are using assistive technology get access to that programmatic information that we kind of take for granted as visual users on a site when we're able to scan a page. So for example, here I have the label element, which is used for form labels, just something simple, like your name. After that, I have a link, an href element that links to a homepage. And then I have an opening and closing table element. And we'll actually look at a full table later on in the talk. But that's what I'm talking about when we're talking about native HTML elements. There are lots of elements that give semantic meaning to content if they're used correctly. But in case we need to build something extensible, something that's more robust than what is provided with those native HTML elements, we also have ARIA, Accessible Rich Internet Applications. And these are a set of elements, or not elements, but attributes that we can add to HTML elements to change them and give them more programmatic meaning than they have just natively from the HTML element. So let's look at a couple examples here of ARIA. So the first example is an unordered list element and I've added role equals listbox. So the first thing that we can add with ARIA are roles. So it's always role equals, and we're equaling some predetermined component names. So you can't just put anything you want in here. There are ARIA guidelines and authoring practices that you can reference, and that will tell you the types of roles that you can add to an element to change it semantics. So there's roles. And then there are also what we call ARIA attributes. So it'll be aria dash something and then a value. So we have on the screen, a button element with an aria-expanded equals false. So we're programmatically giving a button that has an expand, collapse feature, a programmatic name for assistive technologies to understand whether that button is expanded or collapsed. And that's what the aria-expanded equals false means, it's collapsed. Aria-expanded equals true means that it is expanded. And so those are kind of the two main ways that you can apply ARIA to your content. And we'll look at some more specific examples and context. But I would be remiss if I did not tell you what the first rule of ARIA is. And the first rule of ARIA is do not use ARIA. Bad ARIA, ARIA that's added without understanding its complexity and its purpose is worse than no ARIA at all. You can really change the semantics, and the understanding and the meaning of a page if you start sprinkling an ARIA and you don't exactly know what it's doing or how to test for it. And the way that we test for it is typically using a screen reader. So I encourage everyone to, if you've never used a screen reader, we're gonna use one during this talk, and you'll get some exposure to how that sounds and how a screen reader user might navigate semantic content and some of the issues that they could run into. So let's look at an example of ARIA. It's the example that I call the less good example, because it's creating a custom button using a div. Now, what we have on the screen, we have a div element with a role equals button, and then we've added tabindex equals 0. The button text is search. And basically, you know, if we do this and we create a custom button like this, there's a couple of things that we have to do, and the reason that we have these ARIA attributes on it. First, the control has to have the correct role. So if it's something that acts like a button, you'll have to give it the role of button. Even if you programmed all the functionality with a mouse and keyboard, it still needs to identify itself with the correct role. So you have to have that role equals button. Then we have to make it keyboard focusable, which is what that tabindex equals 0 does. It makes that div focusable to someone using a keyboard. And then we also have to program this custom control to work with the enter and space keys for keyboard. So even if it's focusable, it has to be programmed to actually respond to the enter and space keys. Or you could use that native HTML button element and get all that functionality built in. So that's why I call it a less good example. There's nothing technically wrong with doing a button this way, but you're putting a lot of extra work on yourself by having to program all of the things to make the button work. If you used a native button element, you would get all of that functionality built in, and it would just work. So something to consider there. Now, I wanna talk to you a little bit about a site that I created. So web accessibility provides an inclusive experience, is the title of the slide. And I have a screenshot, oh, I have a screenshot from a website called Accessible Web. And there's some text on a black background that says, "Please disable CSS to view this webpage." So what I'm gonna do is actually next show you a video example of a screen reader using this webpage and actually announcing all the content and functionality that's there. But it's just a design decision that I made to hide this content from sighted users. And that's the same thing we do to users of assistive technology when we don't use semantic HTML and we don't use ARIA attributes correctly, we end up with a page that is basically we've disabled the user by preventing them from accessing our content. It's not that they couldn't, if everything were constructed with semantic HTML, it's that we've made a design decision to exclude people. So if you don't know how to disable CSS, you wouldn't be able to access the content on this page. You could view source, of course, but you wouldn't be able to view it in the browser. So let's listen to an example of using this webpage with a screen reader and give you an example of some of that content that's actually there, but is not visible. - [Screen Reader] Accessible Web vertical bar about -Google Chrome Banner region visited same page link skip to content. Visited heading level one link Accessible Web. Main region, adding level 2, the web is an inherently accessible. Block quote: "Your weekly reminder that the web was accessible by default and it's our design decisions that stop it being accessible. number a11y-. Link at KevMarvel_CT on December 7th, 2020." Block end. Why did you have the disabled CSS to view this website? No reason other than the design choice that exclude sighted people. Did you know? This is how many visitors, quote, "view" webpages already, colon. List of five items: Bullet, search engines, bullet, bots, 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 due to poor design choices that exclude some people. - Okay. So I'm gonna quickly show you what this page looks like with the CSS disabled. So this is all the text that was just announced by the screen reader, in case the captions weren't clear to you. But we can see there's some headings, there's a block quote, there's a list. And all of those semantic features were announced by the screen reader, like the heading level, the fact that the list has five items, things like that. So using semantic markup really gives assistive technology users a lot of those visual cues that we take for granted, like the number of items in a list. We have to do programmatic things to make sure that those get announced to assistive technology users. So if you are, let me switch back to my presentation. If you would like to look at this HTML example code, you can go to accessibleweb.net/github, and that will redirect you to this code on GitHub. So that's accessibleweb.net/github to look at any of the code examples that we're gonna go through on our sample page. So I'm gonna use that page that we were just listening to with the screen reader to demonstrate different aspects of semantic HTML, as we outlined in the agenda. And then I will go through those elements using the screen reader so we can get a sense of how someone using assisted technology would experience that content. All right, so let's start with headings. Headings breakup content into meaningful sections. You know, if you're just scanning a webpage, you can usually tell what headings are on the page, because that text tends to be larger, bolder, different in some way. There are visual cues that tell us what are headings on the page. But if we're using assistive technology, we need that to be semantically encoded using the proper HTML elements to create headings separate from the text of the page. And then something to note, which is really important is that screen readers can actually navigate by headings. And we we'll look at that, which can be really useful since they can't visually scan down the page. They can jump from heading to heading and get a sense of the hierarchy of the page. And that is really important. That's one of the top ways that people who use assistive technology tend to browse a webpage. So let's look at what that look like in the HTML. You've probably all seen heading tags or elements rather, but this is kind of what it looks like for this talk, for our sample webpage. We have our overall main topic of the page: Accessible Web. That's our h1. So whatever the main heading is on your page, and usually that should reflect what's in the page title for reinforcement, that's gonna be what your h1 is. And it's best practice to have a h1 on every page so that it's clear what the main topic of the page is. And then any content that you have beneath that can be in successively lower hierarchy heading. So next is h2, that would be for your subheadings, then h3 would be any headings under an h2 and so on and so forth. We can see on the page here, we have one h1, then we have one h2, and then we have five h3s. And then under one of the h3s we have three h4s. Sorry, I know that's a lot of numbers, but that's kind of the hierarchy of the page and the way that it is marked up. So let's go ahead and go to, oops, let me go back to my webpage here. And I'm gonna turn on the JAWS screen readers. That's the one that I was using in the video, and that's what I'll use now. And I'll show you how headings sound to a screen reader and also how we can navigate by heading. So let's start up JAWS here. Takes just a minute. - [Screen Reader] JAWS. - Okay. So I'm in the content of my webpage here, and the hot key for navigating by headings is the letter H, so. - [Screen Reader] H. - First I need to get focus on the page. - [Screen Reader] accessibleweb/Googlechrome left . What is web accessibility? Heading level two. - All right, so I'm gonna go back to- - [Screen Reader] The web accessing some wrapping to bottom and some wrapping the top. Accessible Web heading level one. - So Accessible Web heading level one. And I'll hit H again. - [Screen Reader] The web is inherently accessible, heading level two. - The web is inherently accessible, heading level two. Let's see what the next heading is. - [Screen Reader] What is web accessibility? Heading level two. Web content accessibility guidelines, left parenthesis, WCAG, right parenthesis. Heading level three. - So we got a heading level two, then a heading level three. Now, let me show you what that looks like for screen reader users who can bring up a menu of the list of links. - Heading list dialogue. - The list of headings. Sorry, I'll make it stop here. But we can see in this dialogue here, it says heading list, and it shows us all the headings on the page, starting with Accessible Web, which it says is having heading level one. Then the web is inherently accessible, heading level two and so on and so forth. And so very quickly from this menu even, a user of assistive technology can get a sense of what all the main sections of content are on this page. So that's really useful. There are also controls to sort the headings alphabetically, or to just display all heading level one, all heading level two, et cetera. So if you just wanna see one hierarchy level, you can do that as well. So I'm gonna shut off JAWS now. - [Screen Reader] Unloading JAWS. - Go back to our presentation. Okay. So that's the gist of headings. They're really important for breaking up content, and they're really important for navigating for people with assistive technology. So let's look at the next category, which is, oh, my presentation is not responding. Just a second. There we go. Okay. Buttons and links. Okay. So a lot of people think buttons and links are kind of interchangeable and can just perform any URL action on the page. And while there that's technically true that there are ways you can create code in JavaScript and make a button act like a link or a link act like a button, it's semantically confusing even for visual users. Not under not having a good idea of what is a button versus a link can lead to confusion. It can lead to anxiety of like what's gonna happen when I access this control. So a button, a button pretty much performs an action on a page. So submitting a form for example, is probably the most common use of button, But they can also be used to expand list of menu items or open a modal dialogue. That kind of thing. But they perform an action on the page. They're not taking you to new content. So the understanding for an assistive technology user is that they're staying on the same page. They're just interacting with some kind of custom control. A link on the other hand does take a user to a new place, either on the website or external to the website, but it is designed specifically for linking you to a new page, so that's why it's called a link. And it's important not to use these interchangeably because there is an expectation from users of assisted technology and even sighted users. You know, when we're designing things, when we design a link that looks like a button, that can cause some confusion. It's good to test with your users and see if a link that takes you to a new website looks the same as a submit button. Is that causing some kind of confusion or uncertainty for your users, so. It's good practice to make sure that buttons look like buttons and links look like links as much as people can agree on that. I know there's no agreement, but there are some general guidelines like underlining links, typically, anything that's underlined is understood to be a link. And so that's a really good reinforcing behavior. Whereas buttons tend to have some kind of container for the button text and look like a button. So just keep that in mind when you're designing one to look like the other. It may be confusing for your users. That said, let's look at some of the ARIA that we can use on buttons in order to make them extensible and give them additional functionality if they're doing something other than just submitting a form. All right, so we have two attributes we were gonna look at, aria-expanded and aria-pressed. So first, I have a button that shows it's just the button element, and the button text is play. So if we're just, you know, playing, turning something on and off a button with no state is probably sufficient. But maybe we have a, when our site is in mobile version, we have a menu button that expands the navigation in those smaller view ports. So our next example is a button element that has aria-expanded equals false. And the text for that button is menu. So a user of assistive technology would understand that there's a button here, and when that button is activated, it will show additional content. So they understand that it will announce that it is collapsed because it's aria-expanded false. And then it will announce that it's expanded when re expanded changes to true when that button is activated. And that's something that we have to do with our code, with our JavaScript. We have to put in a listener there and say, when this control is expanded, we switch out that false for true. And then the other state is the pressed state. So here I have a button element with aria-pressed equals true, and the text of that button is light mode. So the implication here is that when this button announces itself as pressed, we know that light mode is enabled on the site. Similarly, if it announced that it was not pressed, we would know light mode was not enabled on the site. And you may have a complimentary control that said dark mode that again, when you press that you know dark mode is enabled or not. So that's some examples of ways that you can extend buttons using ARIA. Really, using aria-expanded is probably the most frequent application of aria on a button that we see. And there's many more examples. This is just to give you an idea of what we're looking at when we talk about adding ARIA to these controls. So let's look at something similar for links. So links have the href attribute. And I have examples of links here. So yeah, what makes a link a link? It's that href attribute. If an a element does not have an href attribute, it will not function as a link, it will not get focus and it will not take the user anywhere. So that can be confusing if you use the a element for something other than a link. I've seen it happen . But it's also why you want to make sure that you're using links as links, and they always have that href attribute. So if we look at our examples here, the first one is an a with an a with an href, that goes to another place on the page. It says, #headings and their link text is headings. And that would basically jump you to a different part on the page; it's called a page anchor. And again, if people understand that something's a link, then they know that there's skipping to different content on the page rather than opening a control. The next example we have is just a regular all fully qualified link. We have a href, and it says accessibleweb.net, and our text is accessibleweb. This is just your typical everyday URL with a fully qualified path. And then there's also, we can have links to either telephone numbers or email addresses. On the screen here, we have an a href for an email address. And that value you have to have mailto:, and then your email address, so info@eff.org. If this were a telephone number, your href would be tel, T-E-L, colon, and then your telephone number. And in certain contexts, there are applications that would support dialing out a telephone number if you created a hyperlink out of that telephone number. So that's some additional things that you can do with links. All right. So let's move on to our next heading of images. So the most important thing that we need to do for images is to provide accurate text equivalents for all graphical objects. And this includes what we're gonna look at, just regular images, a photograph on a webpage, also charts and graphs often created using SVG. And then meaningful icons or emoji. Things like that that sometimes actually need to be hidden from assistive technology because it's decorative. So we're gonna look at those three examples. So let's start with a regular old image element. An image element needs to have an alt attribute. So that's what's on this slide. We've got a photograph of two cats on an easy chair, under a blanket, and that is the alt text for our image element here; two cats on an easy chair, under a blanket. I've got that text highlighted. And that just allows when a screen reader or other assistive technology encounters this image element on a page, it will provide that text equivalent so that there's an understanding of what that graphical object actually represents to the user. There's a lot of artistry that goes into good alt text, and you'll get better as you do it over time. But it's really important to keep in mind that you're describing the purpose of the image and not just literally translating what's there. And I'll give you an example. You know, a lot of sites like to use a check mark icon to indicate that something is completed or finished, but then they'll give that check mark icon, an alt attribute of check mark. But check mark doesn't really convey the meaning of that visual icon. The meaning is completed or finished, and that would be a better alt attribute for a check mark icon. So finished. step one. And that gives someone who is not sighted an understanding of the purpose of the icon rather than just literally what it is. So that's a really important thing to keep in mind, is the purpose of your alt text when you're writing that especially for icons. Now, let's look at an example of a chart that is... Originally, this was rendered with SVG. On a webpage, it would be SVG. And this is a chart of US consumers, by percentage, the number of consumers that use streaming video services. So we've got the years 2016 to 2021 in a bar chart. And each of those years shows a percentage from 52% in 2016 to 78% and 2021. So let's look at what the SVG for this chart looks like so we can have an understanding of how we convey what sighted users can see by looking at the chart as a text alternative. So we've got two things going on, the first thing is we want to identify that SVG as an image, so we need to add one of those role attributes that we were talking about. So in our SVG element, we will now change the semantics of this SVG to image. We'll give it role equals image, and it will be announced then by assistive technology as an image. And since it's an image, it needs a text alternative. The easiest way to do that with SVG is to use the aria-label attribute, which is another really common ARIA attribute that gets used on a lot of custom controls. So what we've got here using aria-label is a synopsis of what's in that chart. We're not putting everything that is demonstrated in the chart, all of the data points. We're not doing that in this short description. We're gonna talk about that in a minute. But what we do want to indicate is what the image is, and basically what it's showing. So we've got an aria-label here of bar chart showing the years 2016 to 2021, as the percentage of us consumers with a streaming video service increased from 52% to 78%. So that gives us a synopsis of what's in the chart. And what we also need to do is we have to make all of those data points in the chart every year and every percentage. We do need to make those accessible as well. But we're gonna look at that in our table example, so just hold that for now. But remember that adding role equals image to an SVG and giving it an aria-label if it's a chart or graph with a short description of what's going on is where we need to start for any kind of graphical chart element. Now, let's look briefly at custom icons, whether it's a font icon or an emoji, something like that. A lot of times those elements are decorative. And so I have got an example on the screen here of a link. It has a href and then a telephone number. And the link text is a little icon of an old fashioned telephone and then a phone number. The problem with this is that, oh my goodness, hold on, I'll get back to that in a second, sorry. The problem with this is that telephone icon will get announced in some way. And it varies from assistive technology and browser to browser. These icons are not announced in a consistent way. So the best thing we can do in this instance, since it's gonna tell us it's a link and it goes to a telephone number, is we can use another attribute called aria-hidden to actually hide that icon from assistive technology. So what I've got now is the same link, but we've got a span tag with aria-hidden equals true around that telephone icon. And this will prevent that icon from being announced to assistive technology. So I'm gonna switch over to our sample site and we'll go over a couple of these things. Just a second. All right. Oh! Lost it. Okay. So first let me scroll down the page here. We talked about headings. Let's listen, I neglected to op open the screen reader for listening to how these buttons sound with our aria on them. So let me do that real quickly. I'm gonna start up JAWS, and we're gonna look at some of the things that we just talked about as it works with the JAWS screen reader. - [Screen Reader] Jaws. Accessibleweb-googlechrome, left parent, and right parent. Main region, list with four items. Menu button collapsed. To activate press enter. - So it said main region list with four items. We've got four items here: collapsed, expanded, not pressed and pressed. And then for each one of those, we've got an example button. So the first one said, menu collapsed. I'll move focus off of it and move it back so you can hear it again. - [Screen Reader] Menu button collapsed. To activate press press enter. - Menu button collapse. To activate press enter. And that to activate press enter is part of the assistive technology, how it interprets a button by the browser. That's not text that we had to add in, it's innately provided. Let's listen to what a control sounds like when it's expanded. So we've got a search button next. - [Screen Reader] Search button expanded, To activate press enter. - So same thing, it's just announcing that role aria-expanded equals true, 'till it comes out to a search button expanded. Now, let's listen to pressed and not pressed. - [Screen Reader] Dark mode toggle button. To toggle the state, press spacebar. - So dark mode toggle button. To toggle the state press spacebar. So that means that it is not currently pressed. Now, let's listen to a control that is pressed for light mode. - [Screen Reader] Light mode toggle button pressed. To toggle the state, press spacebar. - So light mode button toggle pressed. So now we know that that one is pressed. And you can see- and what's interesting- - With four items, light mode. - What's interesting is all of these buttons visually look the same. We haven't done anything to make it clear that one is pressed, one is not pressed, or expanded or collapsed. All of that is visual cues for sighted users. What we're concerned about is whether those same visual cues get communicated using assistive technology so we can hear how those buttons convey their state. And that's really important. Now let's listen to the images that we were just working on. The shortcut for getting to an image using a screen reader is- - [Screen Reader] The Accessible Web. - The G key for graphic. - [Screen Reader] Two cats on the easy chair, under a blanket graphic. - Okay, so the screen reader jumped to our two cats on an easy chair, under a blanket graphic and shows kind of a highlight around it. And it announced that it was a graphic. Let's look at our chart now. - [Screen Reader] Bar chart showing the year 2016 to 2021, that's percentages of US consumers with a streaming video service increased from 52% to 78%. Graphic. - So again, our SVG is announced as a graphic 'cause we added that role equals image, and the aria-label that we provided provides a short description of the contents of that chart. Now, let's listen to the two instances of our telephone number with the phone icon and see how those sound differently. And since those are not technically graphics, I have to navigate there a little bit differently. - [Screen Reader] Three hollow link hollow link, one list end list end list end, link one list and list end. Heading level three tail list end. List end nesting level one. Link 1-800-700 hollow round bullet link, black telephone 1-800-799-SAFE. - Okay, sorry. That was a little verbose, but it said black telephone, is how JAWS in Chrome announced the exposed telephone icon next to our phone number. So I'm gonna move focus off and move it back, so you can hear that again. - [Screen Reader] Hollow link black telephone, 1-800-799- SAFE. - So it said link black telephone. Now, in the next example, visually looks the same. We can see the telephone icon, but I've hidden it using aria-hidden, and we'll notice how it does not say black telephone. - [Screen reader] Hallow link 1-800-799-SAFE Hallow link 1-800-799-SAFE. - So that one just announces link and then the telephone number. So that's the power of aria-hidden. It will literally hide anything from- - [Screen Reader] Text switching to move to an item. - Let me just turn off JAWS. - [Screen Reader] Unloading JAWS. - It will literally hide anything from assistive technology, which makes it really dangerous, but also, it's useful, but you can easily apply it to the wrong thing, and then suddenly everything is hidden from a screen reader or other assistive technology. So you have to be real careful using his aria-hidden attribute. And use it sparingly and only to hide, you know, decorative information or information that should not be on the screen at the current time, perhaps it's a collapsed menu or something like that. But just be careful with that. All right, let's look at tables now quickly. And our table example is going to be referring to that chart. So tables format tabular data into a grid that assistive technology can navigate. So what's really important is, you know, you can visually mark something up to look like a table, but if it doesn't have the table semantics, then people using assistive technology cannot navigate that table with the hot keys and keystrokes that are provided by their assistive technology that allow them to navigate and scroll around in that table content in ways that we don't need to, if we're just visually looking at it. But it's ways to scan columns and rows and skip around content that is very useful especially if you have a lot of data. So that gives assistive technology users a tool to access that data by actually marking it up as semantic HTML. So let's look at an example of how the table for our SVG chart would look. So we've got a caption for our table that says US consumers with streaming video subscription. And then we have a table with two columns and seven rows. The first row looks a little bit different, and it looks different because it is different. The first row has a column header of Year, and then a second column header of US Consumers. Notice I said column header. These are functionally different than our cells of data. So it's an element called the th element, and we'll look at this in a second. But the names of your columns, that first row in your table, those semantically different content than the actual data within our table, which if we look down the table, we have 2016 as the year, 52% as the consumer and so forth all the way to 2021 and 78%. So this is a way that we can provide all of those individual data points within our graph in an accessible way to users of assistive technology. And you could have this table collapsed in a disclosure widget or something like that, or just have it always visible for everyone, because it's not just users of assistive technology that benefit from seeing data in multiple formats. There are a lot of other folks whether they have cognitive disabilities, or just prefer to look at tables of data, would find this more useful than trying to interpret the graphical bar chart. So let's look at what this would look like in HTML. So we've got a table element that encapsulates everything. And then the first element in our table is a caption element. And the caption is a way to give a title to a table. This is particularly important if you have multiple tables on a page. If you have just one table on a page, you don't necessarily need to have a title, but it it's good practice. Then your first row in the table, as we discussed, we have a table row. And then we ha use the th elements or the table header elements, column header element, to provide those column names. So we've got year as one of them and then consumers as the other. And then we have our rows of data. So our first row of data, we have the year 2016 and the percent of consumers is 52%. And so that's just the easy semantic way to lay out data points using a table. Now, I'll switch over to our sample site real quick, and we can listen to what it's like to navigate this table using assistive technology. So I'm gonna start up JAWS. - [Screen Reader] JAWS T. Accessible Web, there are table with two columns and seven rows. US consumers with a streaming video subscription, column one, row one. Year. - So we heard it announced that it was a table. We heard it announced how many rows and columns it had. We heard it announced the caption of the table, and then it stopped at the first table header, year. And we can navigate using arrow keys from there. - [Screen Reader] E, Year, less than 64%, 2018, 69%, 2019, 74%, 2020, 78%, 2020, 78%. - So, and then there are other short keys, hot hot keys that users of assistive technology can use to jump around through this content in different ways, you know, go back up to the beginning of the table, that kind of thing, that I won't get into right now because it's complicated. But that's a tool that assistive technology users rely on when they're trying to consume this kind of data. - Text switching to move to an item, press the arrow key. unloading JAWS. - We unload JAWS again. We're gonna switch back to our presentation here and talk about the last element, which is forms, where we see a lot of semantic issues. So when you have a form field, you have a label and an input. So labels provide the visible and accessible name to form inputs when they're linked programmatically, and inputs determine the type of data. So let's look an example of a label and an input that are semantically linked. So here we've got a form with a label. And the label has an attribute called the for attribute. And that four attribute is linked to the input's id attribute. And that's how we get a programmatic semantic link between a form label and an input. And when we do this, it allows the name of the control to be announced when a user's assistive technology puts focus in that form field. So they're using the tab key going form field to form field. If this is semantically linked, then the name of the control will be announced automatically. Additionally, for sighted users, we can actually click with the mouse on the label to get focus in the form field. This is particularly useful for like radio buttons and checkboxes where the hit area for the actual input is quite small. We can also actually click on the label if we have the semantic link in place. So that's really important. And let's look quickly at some input types. So there are various input types. Most of the time you'll have a text input type, but there are other ones like email, radio for radio button, checkbox for checkbox as we discussed. And there are also some other types like search, URL and tel. And you can look up the whole list of these HTML five input types if you just search for that HTML five input types, and it'll give you an idea of some semantic things that you can do to just make entering form data a little bit easier. Now, if we have a group of similar fields, like a group of radio buttons or a group of checkboxes, we need to make sure that those are semantically grouped as well, so people understand what the overall question is as well as the labels to each of the responses. So the way we do that is with a fieldset, which groups our related fields. And then there's a legend element within the fieldset, kind of like the caption on the table that provides a label for the group of controls. So let's look at checkboxes as an example. So here I've got a fieldset element and then I've got a legend element. And the legend says cat's colors. And now what you would see in the HTML is a list of checkboxes with different colors like orange, white, black and so forth. I've got on the screen, I've marked up the checkbox for the color black. And what we've got is we have a label for that checkbox, which is black, the color black. And then in our input, we have input type equals checkbox, and we've semantically linked our label for with our id again, as we we mentioned in the previous slide. And that allows us to click on the color black to actually check or uncheck that checkbox. But when this is read by assistive technology, they'll understand that this control that's just labeled black, it will announce that it's for cats colors. It will give it some context rather than just suddenly the user encounters a big list of checkboxes with colors and doesn't understand what those colors are for. The fieldset and legend will group those semantically for assistive technology users. Okay. So just to summarize real quick, as I said, web accessibility is an ongoing process. You're not gonna solve it overnight, and it's not a one and done thing. It's something that needs to be maintained and updated as necessary with user testing. When we talk about semantic markup, we're talking about those native HTML elements plus any correctly used ARIA. So use semantic markup as much as you can. We looked at headings. Headings help people navigate pages. They are the most used browse feature for users of assistive technology to understand what's on a page, and to orient themselves. We learned that buttons and links do different things. Buttons perform actions, links take you to a new webpage. We found out that images need text equivalents. And this includes things like charts and graphs in addition to photographic images or artwork. And then we learned that some images, if they're decorative, we can actually hide those from assistive technology because they're not useful. We learned that we can use tables for data. You know, some people don't think you can use tables, but you can. And the perfect reason is tabular data. And the example we used was data points to supplement a bar chart. And then lastly, I just wanna encourage you to structure your forms in accessible ways. We've just barely touched on the topic of forms, but if you can start with making sure that your inputs and labels are semantically linked, that that's a really good place to begin. So with that, I'd like to say, thank you. If you wanna reach out to me, you can, on Twitter @Rachelditullio, and I'll spell my name, 'cause it's spelled a little differently. R-A-C-H-E-L-E D-I-T-U-L-L-I-O. You can also reach me at my work email, which is rditullio@tpgi.com. Or you can reach me on my website at racheleditullio.com. And with that, Mike, do we have any questions? - [Mike] Yeah. Great talk, Rachel. We have a few questions. We'll try to get through as many as we can. And the first one is "How do you get a certificate in," I guess it's how do you get a certification in web accessibility? - Sure, so the International Association of Accessibility Professionals is sort of a member... You can join the IAAP, if you want. It's sort of an organization for accessibility folks to get information, to talk to each other. And one of the things they do is this certification program. So you can go to IAA, I think it's accessibilityprofessionals.org. I can't remember exactly. It's not iaap.org, but just look for the International Association of Accessibility Professionals and you can see what kind of certifications they have. And if you study for an exam and you sit in exam. That's basically it. - [Mike] I'll find the link too and share it with everyone as well as the recording after this session. - Okay. Thank you. - [Mike] Our next question, "The JAWS focus box, in parenthesis, red box, doesn't seem to be aligned with the content on the screen as you're going through it. That's something we have struggled with on our side. Is there a way to properly align the two?" - Nope, that's just the... In fact, I don't think that red box was always there. That's really just to help sighted users kind of understand where the virtual focus is. You'll notice that keyboard focus is, you know, assuming that you have properly coded focus indicators that keyboard focus with the tab key should generally line up all the time. But that virtual focus box, the red box, it just kind of depends where the content is on the screen when the box gets drawn. And if something moves, it's not gonna line up. But I don't think there's any way to fix that. It's actually trying to be helpful and give sighted users a way to approximate where the screen reader is at. - [Mike] Okay. "How do web accessibility guidelines, in particular around HTML markup, translate when creating accessible native apps?" - Oh, that's a good question. So when we test native apps, we look at the web content accessibility guidelines and we try to apply them in whatever way makes sense. There are some things like you won't have a page title for pages on a native mobile app, so you probably won't test for that. But things like whether your app is responsive, does it change orientation, color contrast, focus, working with a keyboard. Most of the web content accessibility guidelines apply to native mobile content and apps as well. You'll just have to, you know, there just be some things that you will not test for. And there really isn't anything extra per se, but it's perfectly valid to use the web content accessibility guidelines to lead you through an accessibility exercise with the native mobile app. You'll find that most of them are applicable. - [Mike] Awesome. All right, so there's a few long ones. We'll try to get through again, as many as we can. But so "I need to make accessible and old website when the href always the same, but the content changed. I don't know if I should use buttons or links for the elements that trigger a complete change of the page, but the URL doesn't change. I would use links with HR equals the hashtag symbol and a on click function to change the page. I know that in this way, the open link in new window won't work, and for sighted users, the URL is not meaningful, but at least the screen reader users could differentiate between navigation links/buttons and generic buttons. Do you think that is okay to do so?" - So it sounds like a single page application is what you're dealing with, and best practice for that is to change the URL programmatically. Obviously you're not clicking a link and going to a new page, but you can update the URL. You can update the page title when that functionality is invoked and changes the screen. If the page fully updates, even if it's a single page application, for assistive technology users, they need those cues, like a different page title, like a different URL to understand that content has updated. And also you need to control focus. If something small on the page updates, you need to move focus to the content that updated or provide a status message that's automatically announced to let the users understand that something has changed. So I would encourage you to test that with a native screen reader user and get some feedback on how they think it's working. - [Mike] Awesome. Next question. "If you have a table with a lot of blank cells, is there a way with the screen readers to skip the blank cells and navigate only to the meaningful ones?" - That's a good question. I do not know the answer to that. But an assistive technology user would understand that a cell is blank or not. So I guess, I don't know, skipping a cell might be confusing because it's illogical. There's an expectation that they're at a certain place on the table and they don't go there when they do a keystroke. So I'm not sure I would recommend even doing that, but I would have to ask a native screen reader user what their experience is. - [Mike] Okay. And this will be the last one. I'm gonna kind of summarize this question. It's around alt texts. And the essence is basically like if you had a statement or phrase that use quotes, which you would include the quotes in that phrase for a screen reader user? Would that cause confusion? - You can do that. I don't believe, I mean, there are some screen readers that you can set the screen reader to different settings as far as what punctuation they enunciate. So there's possible that a screen reader user, they want to hear quotation marks and in that case it would absolutely be useful. You can also use single quotes if you're worried about mixing double quotes. But it's really not a problem. Again, it would just be a... If there was some semantic meaning to those quotes that was really important for a screen reader user to understand the content, then, yeah, I would definitely include them. - [Mike] Okay. And actually, Rick in the chat actually mentioned that "As a screen reader user, I cannot skip blank cells. So typically one should avoid blank cells in tables, if possible. - Good. Yeah. Yeah. That's good advice. - [Mike] Yep. Awesome. Well, again appreciate everyone for joining us today. Thank you, Rachele, for the awesome presentation. And in a few days, once everything is processed, we'll email out the recording and any relevant links that were mentioned today to everyone. So if anyone has any questions, feel free to follow up with us. If not, you'll hear from us in a few days. So thanks again. Thanks, Rachele. And we'll talk to y'all soon. - Thanks. Bye. - [Mike] All right, bye.