 Welcome back to Designing in the Browser. Today we're starting a special series right here at home on accessibility and design. It's super important to pick accessibility and from the start, since good structure or a bad structure for that matter scales to your entire product. So I'm really excited to create this series of short episodes on how you can give all of your users a better experience as you build and design. Disco is excited too, right buddy? So we've been talking and decided that the best place to get started would be right with where the content lives in the markup and jump into semantics. So let's get started. First of all, why is this even important? Why can't we just use divs and call it a day? Well, I'm glad you asked. To understand this better, I wanna illustrate how the browser would parse your webpage. In the new Canary Experimental Dev Tools, you can actually see a little accessibility tab on hover over your elements. Here's what that looks like. So I can open up DevTools here. I like to do so through the Inspect panel. And there is a little inspection toggle here. You can also hit Command-Shift-C to open that up. And when I'm toggling over these elements, you'll see not only the color font and padding that you would in normal inspection, but with the new DevTools that are coming to Chrome, you see this accessibility bar here with some accessibility information. So under here, you could see the role of this is the button. And if I start to go through this page, you could see the role of banner here for this web.dev live banner. As I continue here, you see a role of heading. Then you see a role of paragraph under that heading. And I can just continue here, this role is time. And here we have a link, a couple of other links. In addition to the role, you see the contrast, the name of this element, and if it's keyboard-focussable or not. So this is a pretty cool tool here that can show you how users could navigate the page and what the various roles are for these various elements on your page. Let's scroll all the way down at the bottom. You can see that we have a whole navigation role here. That's the macro element. And then as I go in here, there's links. And these are all various links. Here we have a combo box that you can click to drop down and get more content there to choose from. So this is a language selector. So you can clearly see here how all of these roles and all of these various elements make up the page and really help users in how they can access it. You can see that a lot of these elements, like the headers and paragraphs, specify a type of element in the DOM, the document object model. The browser itself gives you a lot of built-in accessibility so you should leverage that when you can. Where you can use a semantic element like a main tag or article or header or footer, you should. Did you know there are semantic elements for keyboard characters, addresses, details, dialogue, maps and abbreviations? These are always a much better choice than your average do. Another important distinction is between links and buttons. Links specify a change in location, whereas buttons specify an action. Now I know sometimes the design calls for an element which looks like a button but acts as a link into another page such as a learn more call to action in a card. But this learn more call to action would actually link into another page. This is a case where you should semantically be using a link in your markup, but with CSS, you can style that link to look like a button. Let's take a look at what that looks like. On this page, we see this list of services and each of these cards has a call to action here to get started. And this looks like a button, but if we hit inspect, you can see that this is actually a link. So what we're doing here is we're using a semantic link, but then we're applying the styling that gives it a boxy looking background that gives it this letter spacing, this text transform uppercase, all of that fun stuff. We're giving it this hover state. So what we're doing is semantically keeping things as they are by making sure that a link is something that opens into another page, not using a button, which signifies an action, and using CSS to style this to have it look however we want. Native input and semantic elements give you automatic free and effective keyboard navigation. You can use tab to go forward through a website, shift tab to go backwards, and the spacebar, arrow keys, or enter keys to manipulate these elements. Here I'm in a great demo by Rob Dotson, which is linked to a wonderful blog post that I will have in the show notes for this video. And here what he's doing is showcasing all of the various HTML elements that are native that aid in this keyboard navigation. So I'm just going to go through and tab through every one of these elements or navigate through the Museumine keyboard. So you can see that this is a multi-line content editor. This one's content editable, so I could just delete the existing content and then update it to say whatever I want to put in there. Here you have select, so here I could hit shift and then enter and select a different item with the multiple select. As you're tabbing this list, you can also use that shift to have multiple items selected or use command and then have this enter for the next item that you want to use. Then tab will tab you into that next element. Here's a link. If I hit enter, it'll open into a new window. The next element here that is a native element is this range slider. So you can use the left and right arrow keys to go through the different items values in this range slider. This is the date picker. So I could go numerically through this and update the month, date and year. And here we have time. So again, you could change the hours, minutes and AM or PM individually using both the tab key and the arrow keys. And this is a number input type. So the number you could manually enter using the keyboard or you can use the arrow keys to go up or down, changing that number input. Here we have a color input type. So if I hit returns, going to open a color picker and I can use the arrow keys to navigate this brightness, this light versus dark meter with the saturation, this sort of the dark to light and saturation level of this color. But if you want to adjust the hue, what you could do is hit tab and now you are changing the hue on this color wheel. So that's how you can sort of access all these colors. You can go through and enter any of these RGB values. And then if you hit tab here and use the arrow keys, you can adjust the type of color. So that can be hex, RGB or HSL. Always you should be able to hit escape to get out of these experiences and then tab to enter into the next experience. So here, this is a file input type. If I hit enter, I could then select a file and have that be chosen for this input. If you don't use native elements and build your own, say you're building a component to handle the color picker instead of a need of color input, you have a lot of catching up to do regarding accessibility and making the functionality of that component work in an accessible way. There's just a lot of room for error. So I prefer using what the browser gives us. However, if a component you're building doesn't neatly tie with some semantic markdown or you need some more complex interactions, you can add ARIA roles. ARIA stands for Accessible Rich Internet Applications. It's a specification from the W3C and was created to improve accessibility of applications by providing extra information to assistive technologies such as screen readers via attributes which could be added to HTML. ARIA provides a long list of possible role options to help describe your content to the browser. Let's go over a few of the different types of roles and then look at an example of a more complex interaction. First, there are landmark roles. Landmark roles identify large content areas and are used by screen readers for navigation. Many of these roles have corresponding HTML elements such as main, header, and footer. Ideally, you should place all of your macro content into a landmark. However, don't overdo it. Having too many nav or aside elements can make a web page harder to use, so make sure that you're using them appropriately. Section role equals content info as an example of a landmark role that can be used to describe a section within the footer that contains the document's meta content information such as the copyright information. You can combine landmark roles with other area properties too. For example, nav aria label equals primary can help you identify primary versus secondary navigation or just aid in giving more context to the type of navigation you're providing. The next type is document structure roles. As with landmark elements, there are many equivalents in HTML to these document structure roles. Role equals form or role equals nav is unnecessary when you use the form or nav elements respectively. Headings are another example of semantic document structure. Using the proper headings h1 through h6 in the correct order makes a big impact in helping users navigate your documents. In a 2016 screen reader study by Hayden Pickering, many respondents that use screen readers noted that they use headings and regions as a primary means of navigation. However, you can use other structure roles when there's no existing equivalent. There are also widget roles. Widget roles describe common interactive patterns that currently lack semantic equivalents in HTML such as tab panel or combo box. Window roles consist of alert dialogue and dialogue. These roles are meant to be used when creating a sub window to the primary document. You can think of this like a pop up or tool tip. And finally, we have live region roles which can be set to either the assertive, polite or off states. These are used within applications that use JavaScript to change parts of a page without a full reload. And the developer wants to send a small alert or some other type of message to the user. These are great when used in moderation but can become quite distracting for users when overused. The search bar on the web.dev site is one example of where our roles are used heavily to ensure an accessible experience for everyone. In fact, we have Rob Dodson here to walk us through it. Hi, Rob. So here on web.dev, we have a search field up at the top and it allows the user to start typing a query. And importantly, we keep the focus inside of this text box so that they can continue typing their query but they can also use the up and down arrow keys to look for other options. So how do we make something like this accessible? Well, anytime I'm building a really custom component, something where there's no counterpart in vanilla HTML, I'll start by looking at the ARIA authoring practices guide. So this is a really wonderful doc that lists a number of UI patterns and explains how to build them in accessible fashion. In this case, what we're building is a combo box. So a combo box is a widget made up of a combination of two distinct elements, a single line text box and an associated pop-up element that helps the user set the value of the text box. That sounds like a pretty good fit. So scroll down and I'll check out the examples. Here is an example right here. We can play around with these, seems to match the pattern that we want. And importantly, if we scroll down a little bit further, it'll tell us what is the expected keyboard behavior for both the text box and the list box pop-up. And it'll also tell us the required ARIA roles, properties and states. So in this case, we know we're gonna need an outer element with a roll of combo box. There are a number of additional ARIA properties that we're gonna set on that element. Inside of that, we're gonna use a text box. A regular input type equals text will work in this case. And lastly, we're gonna need a list box element. And this is going to have a list box role and this is what's gonna contain all of our results. So that's what we've built over here. We've got a combo box element right here. That's sort of the wrapper inside of that. We've got this input element and I've added a roll of search box to it. So it'll additionally announce that it's meant for searching. And then finally down here, we have our element. It's not visible right now, but it's got a roll of list box and this is what's gonna contain all of our search results. So let's try this with a screen reader. So we'll navigate over to our search field. Vis-vis-vis-visited all articles, search text field, search. You can see that it announced all articles. That's because we have an ARIA label that specifies that this search is going to search all of the articles across the site. And then it also announced that it's using a search role. We can start typing. C-S. And then when the user presses the down arrow key, visit link. 10 modern layouts in one line of CSS, one of 10. It tells them how many results are available on the page. Lastly, because we're building a single page application when they select an option, we're going to call focus on the first header in the new page that we've loaded in. This way the user knows that something has changed on the page. Again, you only really need to do this if you're building a single page web app. But let's see what the experience is like using voiceover. All are heading level one. 10 modern layouts in one line of CSS, main. Thank you, Rob, for that excellent run-through. And thank you for joining us today in this semantic accessibility discussion. Basically, use semantic HTML as much as you can, and substitute with ARIA roles where you can't. That's how we can make sure that users who navigate your website, using a keyboard or screen reader, will also have a great experience. Until next time.