 Welcome to Designing in the Browser. As we continue our mini-series on accessible interfaces, today we'll be navigating navigation. Ba-dum! So that your users can access your website and navigate through it, whether they're using touch, a mouse, or the keyboard. After all, the ways people are accessing information is constantly changing. And what's the point of serving your content if people can't get to it? To help with navigation and keyboard accessibility specifically, semantics and aria roles play a big part. We talked about semantics in the first episode of this mini-series, so check that out for more information. And today we're going to be taking a look at document structure and how to navigate that structure, whether it be through landmark roles, tab index, and stylized states using focus and the newer focus within styling. Regions are the first way in which we enable easy navigation for keyboard users. Regions mark up our headers, footers, nav, articles, aside, and more. Many of these regions have corresponding HTML elements, so aria roles are usually not necessary. Even something as elemental as a heading helps navigation for screen readers immensely and properly marked up documents help indicate where sections begin and end. So it's really important to have semantic headings and other types of semantic elements in your page. According to research done for the 2019 web Almanac, 38.6% of pages skip heading levels and H2s are found on more sites than H1s, meaning some folks are just skipping H1s entirely in lieu of H2s, and that's heading 1s and heading 2s. These are different heading levels that should be placed in order. Many popular screen readers enable navigating by quickly jumping through links, lists, headers, list items, iframes, and form fields like edit fields, buttons, and list boxes. So keep in mind that structure is always key to maintaining accessible navigation. You can always style stuff later. Let's take a look at what the browser sees when navigating through a page. This is the accessibility tree, and there are new DevTools in Chrome that help us to see the underlying structure in regards to accessibility. If I open up DevTools, if I hit inspect, you can see this little icon here, which is the inspector, and if I click on that, I can now hover over elements within this page, and you can see there's this accessibility section that shows contrast, name, role, and if this element is keyboard-focussable. So if I look over at these link items, you can see that they have a roll of link and they're keyboard-focussable. You can see the contrast. There's a lot of information here that this panel provides. Here we see a roll of search box for the search area. We can see that there's different regions here. So as I start scrolling through this page, there's a main section at the bottom here. There's a footer section as well. So you can really clearly see this is sort of denoted as a main roll, and this is really going to help people who use screen readers navigate their your site. So if you are curious about any of the elements on your page, you can always use the inspect tool and these new accessibility DevTools to see how it's working in terms of roles, regions, and other semantic components. As I mentioned in the semantics episode, many screen readers rely on document structure to navigate. Here's a quick overview of navigation for the draws screen reader. You can see that these quick keys enable for jumping between headlines and other sections really quickly. It's also important to know that some CSS properties can actually change the visual order of your content and throw off the accessibility tree. If I use Flexbox or Grid and the order property within those, I could theoretically reorder elements. So visually, they look one way on the page, but look at how the accessibility tree doesn't change. So I'm going to inspect the elements here, and here you see we have this header section that has these breadcrumbs, this headline, the subhead, this publish date, and then some author info. Let me just zoom in here on the DevTools for you there. And if I wanted to, I could with Flexbox change this order around. So if I just did a display of Flex on the parent, now this is completely sort of out of whack. So we want to make the flex direction column so it looks normal again as we expect. And here I could just change, maybe I want the header to be order two. So now this header is going to appear after the subhead and after the published authors. Even though in the DOM, we see the article header coming first. So this becomes confusing to screen readers because screen readers will read this first while the page is showing it coming after the rest of the content with that order. And this is why it's pretty tricky sometimes when you are using Flexbox and some of these techniques for accessibility, you likely don't want to be changing order around. It's using the document structure to read and parse information. So using these reordering properties could really break accessibility and confuse your users. Definitely something to watch out for. We can also adjust how a user can navigate with a keyboard using tab index. I wouldn't recommend using this often since you can throw off the natural flow of the document and accessibility in that sense, but knowing how to use this properly can be really useful, especially when creating custom components. The default tab index is zero. This implies that the element is within a natural tabbing order. You'll want to add this to be able to tab into anything that is not typically a tabbable component. And what I mean by that is it could be a div tool tip or a span element within an inline element that you want to be able to tab into anything that you want to create a focus state inside of. Any tab index higher than zero, such as tab index equals one, will give this element tab priority over other elements. It will be tabbed into first. This is generally a bad idea because not everyone navigates the tab key and it can make the navigation experience confusing for some people who wouldn't navigate to that element first. So you're making a lot of assumptions here and it's probably better just not to do this. Tend to stick with zero or negative one for your tab index attributes to be safe. A tab index of negative one removes the element from the default navigation flow but allows it to receive programmatic focus, meaning that focus can be set through scripting and JavaScript or links. A good example here would be a dialogue window that should become focusable only after a specific user action. We can then set this tab index of negative one through scripting so that it becomes visible to the user. Another important styling note when it comes to accessibility is to always include a focus state where you have a hover state. I like to say where there is hover, there is focus. You can differentiate between what these two look like. For example, you can have a global focus state with hover overrides or vice versa but making sure you're giving every element the ability to have both interactions is important. This is necessary for styling consistency but it's especially important when it comes to data-rich applications that might have content accessed by an interaction like a tooltip. Speaking of tooltips, it's probably best to have your tooltips actionable by click and focus instead of only on hover but if you are certain having a hover interaction, make sure that an equal interaction can be reached by a focus in both your CSS and JavaScript. You can use the focus pseudo class in CSS and now the focus within pseudo class to help greatly for those tooltip styling as well. It depends on what you're trying to achieve but the issue with focus is that it only styles elements on which you are actively focusing. With a tooltip or menu, if you're focusing on the parent, that's great. We'll see the child elements or next sibling element as we would expect if you're using CSS to style them but if we then tab into those children or that sibling, the focus is no longer on the parent and we might lose that visual feedback. The children could disappear. We want that tooltip to stay open when we're focusing on a child within it. So that's when we want to apply focus within alongside focus. Here we see an example of a navigation bar with three links and some sublinks inside of that second link and so I'm using unordered lists and then an additional unordered list within this list item to make these appear. So they appear via hover or via focus via tabbing. If I'm tabbing through this, they all appear and that is the expected experience and the reason why this is working is because I'm using focus within here to apply these stylings to this list item within that unordered list and then I'm making sure that the unordered list within it when this list item is focused also becomes visible and has opacity and has display. So if I did not have this line if I deleted it, now if I hover I'm still seeing these items but when I'm applying focus I am no longer seeing them I'm no longer able to tab inside of it and this is because what I'm stating here is that when I want this parent to be focused inside these elements should also be appearing they should also get the same style as though I'm hovering over the parent itself. So this is really useful it's useful for tooltips as I mentioned earlier and definitely useful for dropdowns. You can even style the focus ring with focus visible. The focus visible pseudo class enables us to change that default blue focus ring and now you can use this in some browsers as a default pseudo class or you can style this with a polyfill for other browsers. We'll have that linked in the show notes so you can play around with this capability and this polyfill, this is what it looks like. If I wanted to style the focus ring a bit I could then use the focus visible pseudo class and here I'm just styling this on all of the links so let's give it a border left and let's say border left maybe three pixels of width and say I want this to be dash and the color to be white. So now when I'm tabbing through here you can see that left border and it kind of pushes the text a little bit I think it's kind of nice to see this effect here so it's kind of cool that you can create some sort of indicator that you are focusing without having the default indicator that the browser provides to you. People who are differently abled aren't the only ones who benefit from good accessibility practices on the web. We all do. The developer benefits from better SEO as robots can more easily parse the page, non-screen reader users benefits from more navigable and well thought through content flow and with assistive technologies people now have more options. I hope that you enjoyed today's show and learned something new. Remember proper markup and structure are at the core of accessible websites and your users are not just people who are similar to yourself. So make sure everyone has a good experience on your product. Thanks again for joining and I'll see you in the next episode.