 All right, that is my cue. Thank you all for coming out this morning. I want to wish you, first of all, a happy Global Accessibility Awareness Day. It just so happens that May 19th is the official Global Accessibility Awareness Day. So very cool of y'all to be here for that. So yeah, if you're tweeting during the talk or whatever, use the GAAD hashtag. That would be very awesome. Also, before I get into things, I do want to point out because I know this is being recorded on YouTube, and sometimes folks don't always make it to the end of a long video. That everything that we're talking about today is also going to be part of a Udacity course. So you can go check this out as well. So all the topics I'm covering today in brief will be covered in that course over sort of like a multi-week period, doing a very deep dive on a lot of these things, giving a lot more practical advice on building accessibility into your applications. So definitely go check that out. Now I want to start off by just sort of telling a story. So about a month ago, it was April, and like many of you, I was doing my taxes, and it was awesome, right? Didn't you guys love it? It was great, right? No, it actually sucked. So doing your taxes is like a really, in the US at least, it's a really frustrating, horrible experience because you have these like amazing tax forms. I don't know how many of you have ever actually filled out an actual tax form? Have you ever had to deal with that? Yeah, it's like you kind of go off-road with your tax software and suddenly you end up having to fill out a real form. And these tax forms, they're horrible because there's no real hierarchy, right? There's no like, I don't know if I'm going off-road or if I'm in some place I shouldn't be or if I'm messing up or anything like that. And I kind of think of the tax form as like my interface to the IRS, right? Okay, and so my goal is very simple, right? I just want to pay my taxes, but their interface is like totally blocking me. And eventually if you've gone through this process, you reach this point where you're just like, oh my God, I just want to give you my money. Like I don't want to, you know? And I want you to think about that feeling, okay? Because it sounds like many of you have felt that feeling before. It doesn't necessarily have to be taxes, but it could be trying to book a hotel room or something, the website's just not doing it for you, something like that, but really hold on to that feeling of frustration that you have felt before, okay? Now for many of us that's just an occasional thing, right? It just occurs during tax time or something like that. But for a lot of our users, especially anybody with a disability or impairment, this can be a recurring theme as they're trying to interact with websites that just haven't been programmed with accessibility in mind. So for that reason, I personally really like working on accessibility because I like feeling like I'm sort of actively removing some of that anxiety and frustration from the universe and from people's lives. To me, that is super, super motivating. But there are a bunch of other reasons why I think accessibility is extremely important and everyone should be prioritizing it in their applications. Now, of course, there are obvious legal reasons and potential missed sales opportunities. Those are very important, but I don't think that that is what motivates a lot of developers. So instead, I think there are these three other things which to me I think are super exciting when I think about accessibility work. The first is just that this is sort of a big green field space. And what I mean by that is that accessibility is sort of underserved in the platform, meaning there's a lot of room for developers to come in and build cool new tools and cool new libraries to write blog posts and to kind of get their name out there as thought leaders in this space. So if you like working on sort of like interesting technical problems, accessibility is one of those areas where you can really sink your teeth into it and do some really awesome work. Another is just that accessibility work really benefits everyone. The chances are very good that pretty much all of us in this room are gonna experience some form of disability in our lifetimes. If not right now, then as we age, as our ISRI site degrades, our hearing degrades, our motor impairment degrades, all of these things. So all of us are gonna wanna use our computers and our phones when that happens. And we're gonna be happy that accessibility work has been done on those platforms when we reach that point. Also, disability can be situational. It can be temporary, right? I'm sure many of you were outside the other day, perhaps trying to use your phone in very bright sunlight and it can be very difficult to read. Maybe you needed a little additional contrast on the screen or something like that. So, you know, disability can affect us in temporary ways as well. Finally, and for me, this is what sort of is most important and gets back to that earlier point. When my users are using my application, I want them to feel certain and confident in the actions that they are taking. So filing your taxes, booking a plane ticket, booking a hotel room, these are not things that you wanna get wrong, right? And so fundamentally, I just think that good accessibility equals good user experience. Working on accessibility is going to expose things in your application that you have overlooked because it's gonna force you to step outside of yourself and work with your app from a different perspective. And when you do that, you're just gonna end up with a better, more polished product that is ultimately, you know, usable for more users. And so when I tell this to a lot of developers, they're like, yeah, dude, totally, I 100% agree, right? But they find working on accessibility to be difficult. You know, as web developers, I think many of us have kind of like, we know bits and pieces of how accessibility works, right? But in general, we sort of have this like Swiss cheese understanding of the platform as a whole and how it all kind of like fits together. So as web developers, we need a more solid foundation in our understanding of accessibility. And once you sort of remove that mystery, then working on accessibility becomes much more fun, much more exciting, because you don't feel like you're guessing or you're just kind of like making stuff up, you actually know that you're headed in the right direction. So that's what I wanna talk about today. I wanna talk about how we set a good foundation for ourselves as web developers with accessibility. And I also wanna cover some practical advice, some stuff that you can use every day in your applications right now to start improving the accessibility of them. So I'm gonna split this talk into kind of three sections. The first is just like looking at the diversity of users that are out there, kind of looking at the accessibility topics that affect them. And then I wanna move on to the two big areas that I see many web developers struggling with, which is focus and proper semantics. But I wanna start just by understanding kind of who our users are and the range of accessibility topics that affect them. Now I'm going to focus on people with permanent disabilities in this section, but again, I wanna reiterate that accessibility really does affect all of us. If you are trying to use your phone one-handed while you are holding like a screaming baby, then you are sort of temporarily or situationally impaired. And it really makes no difference if you're holding something in one arm and trying to use your phone one-handed or if you have like a motor impairment and are paralyzed on one side of your body. Again, it sort of nets out to the same thing. So I just wanna get some stats out there because I feel like these are pretty interesting. According to the World Health Organization, about 15% of the world's population lives with some form of disability. And to put that into perspective, we're talking about around 1 billion people across the globe, right? So not insignificant size. And we can roughly split this into about four categories. There's disabilities and impairments affecting visual senses, those affecting motor and dexterity, auditory senses and cognitive senses. I wanna go through each of these individually, starting with visual impairment. So visual impairment kind of spans a broad range. You could have users who are completely blind to those who have limited or low vision. Users who have no vision may be using a screen reader device to access the page. So this is a talk back on Android, or they might be using a similar Braille reading device to access the content of the page. Users with limited or low vision may be using screen magnification, though they might also choose to use a screen reader, or they might use high contrast mode in the browser to sort of switch the background color and increase the legibility of the text on screen. Users with motor impairment, this could span a group of folks who maybe have even just like a wrist injury, a broken arm, repetitive stress injury, something like carpal tunnel, right? And they prefer not to use a mouse. All the way to folks who might have physical paralysis or sort of limited range of motion with some part of their body. So these users, they may use head or eye tracking to navigate the page. This is an example of a program called Dasher, which combines with a head tracking camera to allow someone to type. These users may also use their keyboard. Primarily to navigate, they may use a discrete switch device as you're seeing here, or they may also use voice control to navigate the page. For auditory impairment, this group ranges from those who are completely deaf to those who are hard of hearing. So I'm personally in the hard of hearing camp. I'm about 90% deaf on my left hand side. And so for this group of users, it's important to make sure that we're not relying solely on sound to convey information in our applications. So we've got captioning, we've got transcripts. If we're playing sound in the background that we're providing some sort of visual indicator to let the person know that that is happening. And finally, for cognitive impairment, this is a really broad range, encompassing everything from ADHD, dyslexia, autism, just to name like a few items. And for these users, the accommodations are obviously extremely diverse, but we do find some overlap with things like zoom functionality and making it easier to read the page and minimizing distraction. So this is an example of a Chrome extension for someone with dyslexia. And what it does is it applies color gradients to the page to aid in the reading order and make sure that they can read in a linear fashion. So these are kind of like the four major categories that we need to keep in mind when we are thinking about accessibility in our applications. But because accessibility is so broad and the usership is just like so diverse, it's really helpful to have a guide to sort of lead us on our journey here. And we find that in the form of the Web Content Accessibility Guidelines 2.0 or WCAG 2.0. So this is a set of best practices which have been put together by accessibility experts to really try and define what it means for something to be accessible. And the WCAG is extremely comprehensive, but it can also be overwhelming. So it's a very large sort of spec document. And for a lot of developers, they open that up and they're just like, uh, and they're like face melts and they're like, no, no, don't want it, right? So to help mitigate this, the Web AIM group has actually distilled the WCAG down into this really easy to follow checklist called the Web AIM checklist for WCAG 2.0. So the nice thing about this is it is specifically geared towards Web Content. And now if you were watching that previous section, you were sort of wondering like, wow, how am I going to cater to that diverse range of users and all those different assistive technologies? I think a really, really great starting point is to just nail this checklist. And what I think is sort of a good personal strategy is figure out what the primary user journeys are in your application. If creating a new account is like a really, really important journey that you want every user to be able to complete, then go through all of the steps of that process and make sure that you can check off the relevant checklist items so you can ensure that that user has an accessible journey that they can complete. And then do that over and over again for the primary actions in your application. And you want to incorporate this work into, you know, not just the development phase, but also obviously the design phase, make sure that all of your stakeholders are bought into this. So with that checklist in hand, we're now ready to actually start exploring some of the nuts and bolts functionality that we're going to need to add to our application to make sure we can build those experiences. And I want to start off by looking at focus and really like what does it mean for something to have focus? What is it, when we talk about focus in the platform, really what are we getting at there? And focus is kind of one of these like underlying bedrock key things in accessibility. And in a nutshell, what we're talking about is focus just sort of helps determine where keyboard events go on the page, okay? That is sort of the main takeaway here. Focus determines where your keyboard events go on the page. So if I go over and I click on this text field, I get this indicator to let me know that it's focused. And now as I'm typing keys on my keyboard, right, all those key events are directed right at that field and then it knows to display the keys that I've typed. Now some users drive their computers entirely with the keyboard or with some other sort of discrete input device like a switch control like I showed earlier. And so for these users, it's sort of their primary means of reaching everything on screen. And it's absolutely critical that we have a good experience with focus and tab order in our application. And to move focus around the screen, if you're using a keyboard, you can use either tab or shift tab. And the ordering that the items in your application get focused is known as creatively enough, the tab order. And the tab order is based on your elements position in the DOM, right? So how you write your HTML. And this is great because it means you don't have to go in and explicitly tell the platform, okay, focus this thing and then focus this thing and then focus this thing, right? You don't have to like programmatically do that. It just does it for you. It's just inferred based on the order that you wrote your HTML. But right away, we get to a potential gotcha. Because the DOM order is so important, it's possible though that we could reposition our elements on screen using something like CSS without changing the DOM order. And then that can lead to all sorts of kind of weirdness for our users. So I'll show you an example. Here, I've got a little bit of HTML, just a few buttons. And then you can see the output over there on the right-hand side, okay? So I'm gonna just tab through this really quickly. So I hit tab, right? Focus is my first button. Hit tab again, focus is second. Tab again, focus is the last, right? So far so good, no surprises. So now I'm gonna add a little bit of CSS. I'm gonna change that first button so it has a little inline style so it's floated to the right. Now visually, I have updated sort of the layout and appearance of those buttons on screen now, but I have not at all affected their position in the DOM. So let's look at what happens when I tab through this now. Okay, well, we start at the end, and then we go back to the beginning, and we go to the middle, right? That's kind of weird. Here's an example on a site that I built, and you can sort of see this in a more real-world use case. So I start tabbing through. It starts way over there. Now we're going backwards through the navigation kind of. It's gonna jump to the bottom of the page because I have something absolutely positioned. It's gonna jump back up to the page, right? So you're kind of like bouncing around the page like a pinball, and I see this on websites all the time. Like go to a website today and just try and tab through it, and you'll see that focus jumps around. Sometimes it just disappears for a while, and it's like, I don't know where it went, and then it comes back, right? So the main thing here is just, you know, make sure if you're changing the visual position of something, then you're also updating its position in the DOM. Don't fight the platform here. It's trying to help you out, actually. It's trying to infer your tab order for you so you don't have to write a bunch of code to tell it what order you want things to focus in. But that means that you've got to play along with that. And if you want to move something visually later in the document, move it later in the DOM as well. And it's the best practice. Make sure that you're just tabbing through your site occasionally. If you haven't done it, if you work on a big site and you haven't tabbed through it recently or ever, maybe sit down and do that. It can be a feeling, hurting experience, but it is an important and useful thing that everyone does. Okay, so we talked a little bit about what can be focused. I want to move on now to just talking about really like, or we talked about what focus means. I want to talk about what can be focused and really like what should be focused. So many of the native elements that you're familiar with are all sort of implicitly focusable, meaning any sort of control that a user could interact with or provide some input to. So like button, input, select. These are all implicitly focusable, meaning they get naturally inserted in the tab order. So I don't have to do any work. The user can just press the tab key and it'll focus them, which is great. But not all elements are focusable. So for instance, this header, this paragraph of text, this image of this cat, these are not focusable. These are not implicitly inserted in the tab order or anything like that. And because there's no need to focus something if a user cannot interact with it in any way. So if now this, something that comes up a lot of people get worried that a user with a visual impairment might miss like an important heading or an important piece of text or something like that. So they make it focusable. But really, again, there's no need to do that. Those users have tools like screen readers and the screen reader's sole job is to read headings, it's to read text and to make sure that the user gets all that content. So again, you don't need to make something focusable if it's not interactive. And this now presents another sort of interesting gotcha that I see a lot. Because generic elements are not focusable by default, then we can end up in this weird situation where here I've got some more buttons and I'm gonna replace that center button with this very fancy looking button that I've created using a div. But again, this is sort of a generic element, right? There's nothing implicitly focusable about it. And so as the user is tabbing through the page, right? It focuses the first item, tab again and we just like jumped right past that button. So if that button was your, you know, give me money button or sign up for a new account button, then a user who's using a keyboard or a switch device, they're effectively cut off from that because that item is not inserted in the tab order. So an easy way to fix this, just use the proper element, right? Use a button tag here, we're gonna get implicitly inserted in the tab order. You can style button elements very easily. And now as the user is tabbing through this experience, right? They'll just land on that button and we don't have to do a bunch of extra work. An interesting bonus of using the button element is if you give a button element an on click handler and a user lands on it and presses either enter or space bar, it will run the on click handler. If however, you have a div that you've, you know, made focusable and I'll explain how to do that a little bit later, but if you have a div and you give it an on click handler and the user focuses it and they press enter a space, nothing's gonna happen. Because there's a little bit of browser magic that actually makes sure that the on click gets run with your button. So that means you're gonna have to add an additional key down handler to your div button. It means you're gonna have to check which key was pressed when they hit the button. There's no real upside to it. So again, don't fight the platform here. The platform is trying to give you some accessibility for free. That's why these elements exist. That's why they're implicitly inserted in the tab order. So use the native elements whenever you can. But I realize there are times when there's just not the native analog to what you're trying to build or maybe the native element is just too difficult and frustrating to style. So there will be times when you need to go off-road and build your own sort of custom components. And when you're doing that, it's important to make sure that you're adding back in that keyboard support for those users who rely on it. Now to do this, we can use the tab index attribute. And the tab index attribute basically just helps us kind of figure the focus ability of our elements and it takes kind of a range of values. So tab index of zero means that the element will be inserted into the natural tab order. And it also means that the element will be programmatically focusable if we call it's focus method. So here's another one of these fancy buttons that no one can interact with just yet. So I give it a tab index of zero, now the user can very easily just press the tab key and focus it, okay? So far so good. Tab index of negative one means that the element will not be in the natural tab order. So the user can't tab or shift tab to it. But we can still programmatically focus it by calling it's focus method. And this can be useful if you need to sort of temporarily disable an interactive control or for a technique called roving focus or roving tab index. So if you're building a very complex component, this technique can be super useful. So let's say I have this list here and maybe I have like a hundred items in this list. And I wouldn't want my user to have to tab through every single one of those items just to like move past the list. So I wanna treat the entire list as one big tab stop. So you can land on it. They can use their up and down arrow keys if they wanna interact with it. But they should be able to tab out of it if they need to. And so to do this, I'm gonna set tab index to negative one on all the elements except for the one that I think is sort of like currently active or currently selected. And then when the user does focus this item, right, they're gonna land right on the one that's active. And if they press the down arrow key, I can listen for that and say, all right, now I'm gonna move my tab index down. So I'll set the next item to tab index zero, the previous one to tab index negative one and I'll call it's focus method. So this way, if the user tabs out of the control, they tab back in, they're gonna land right on that last item that they interacted with. But if they need to, again, they can just quickly tab out and they don't have to tab through every single item in our huge list. So this is a really, really, really useful technique if you're building sort of complex components. Lastly, you can have a tab index value of greater than zero. You can have a tab index value of like five, 10, whatever. And this is gonna take that element and actually jump it in front of everything else that's in the natural tab order. So in general, this is considered kind of an anti-pattern because it's very easy to tie yourself in knots with this and end up with like, again, sort of crazy focus jumping around all around the page. It's also a little strange for someone who's using a screen reader. A screen reader users tend to navigate the dawn in kind of a linear fashion and you've got these elements that sort of don't comply with that at all and are trying to exist in different tab orders. So I wanted to put this here for completeness so that you know the tab index greater than zero is a thing. But in general, it's an anti-pattern you probably never, ever wanna do it. Okay, so I showed that sort of complex control a second ago, that list thing and one of the questions that comes up a lot is like, okay, so I'm building this complex control but what are all of the things that I need to add to it to add proper keyboard support, right? What happens when the user presses escape or up or down? What's the expectation? What do users want from me here? And so to help with this, there's this amazing document called the ARIA authoring best practices guide. And I'm gonna talk about ARIA more later on in the session but this is such a useful document. I wanted to put it in here early and what it does is basically list patterns like UI patterns on one side. So combo box, button, check box, whatever. And you can click on those and then it will take you to a section which just tells you all of the keyboard support that that kind of control needs to have. This is what users expect when they interact with a dialogue or something like that. So this is a super useful guide to just answer and clear up any of those questions that you might have when you're trying to figure out what support do I need to add. Now, you might look at this and be like, okay, well that's like a non-trivial amount of work, right? And again, as I said before, good accessibility equals good UX. And so that means that the controls that we build need to have really robust, polished keyboard support, right? So it is, it can be a lot of work at times. And if I'm doing all this work, then I wanna think to myself, how do I get the maximum amount of mileage out of this? And what I think is kind of a good approach is once you've done all this work with your component that you're building, consider sort of extending the platform and then turning that widget into a web component. And the nice thing here is you've now encoded all these useful keyboard patterns into a reusable component that you should be able to use sort of in any context, in any sort of framework or library or anything that can just work normally with the DOM. So this is a nice place to just extend things and get something that you can take with you onto future projects. This is an area where in particular the Polymer team has spent a lot of time over the past year making sure that the components that they build comply with those ARIA design patterns. So a good example of that is the modal window. So the modal window in accessibility is like the boss battle that you reach at the end of accessibility because they're super, super hard to program in an accessible fashion. I'll kind of walk you through a scenario here. So let's say you have a modal window, right? You just made like a little div thing and you don't want the user to be able to click on the background, so a lot of developers will put a little overlay behind it, right? Cool, right? Problem solved. Well, let's look at what it looks like when someone goes through this using a keyboard. So they press the Tab key, they focus the first item, Tab key, and they focus the next item, and they press Tab again, uh-oh. It just went like, right behind the overlay. Just focus the next focusable element in my document because it doesn't care that there's an overlay there. That does not affect the Tab order at all. And so what you need is kind of like a temporary focus trap inside of that modal, right? And this is, you know, not always a trivial amount of code to write. So this is the code that I wrote recently for my modal focus trap thing, right? And I don't want to write that over and over and over again in all of my projects, okay? So this is a place where I would love if there was a pre-existing web component that I could just take off the shelf that did all those good behaviors for me. So the Polymer team spent a lot of time working on this when they created their paper dialogue element. So this element, if you give it just this modal attribute, just that one thing there is a signal to say, hey, when the modal is open, trap the keyboard focus, okay? So I don't have to deal with any of that code anymore, which is awesome. Also, when the modal is open, move focus into the modal so that my user knows, like, hey, a modal window just opened because if I'm using a screen reader and a modal window pops on screen, I need some indicator. I need something to tell me that that thing exists now. So move focus into it. That's what the autofocus attribute will do. There are attributes for, you know, confirming or dismissing the modal, which are very handy. And then I love this attribute right here, which is when the modal gets closed, it's gonna restore focus to whatever was the previously focused item in the document. So now the user has that sort of continued continuity with their experience. So this is a great example of taking all those accessibility best practices and putting them together into a web component. You can see that in action here. So I'm just gonna open this paper dialogue and as I'm like hitting my tab key, right? It's trapping focus now, so I'm not escaping to the back of the page. I can just hit enter or space on those buttons and just close it and restore it back to the document. It's awesome. Okay, so we talked a lot about focus. I gotta shift gears now and talk about semantics. So when I think about semantics, there's like two questions that come to mind. And the first is like, what does it mean when we talk about good semantics? And the second is, how do good semantics benefit our users? And to answer these questions, it helps to think about this idea of affordances. So affordances offer or afford a person an opportunity to perform some action. A teapot is a really good example. So a teapot just based on its physical design has all sorts of affordances built into it, right? It has a handle and because I've seen other things with handles before, I know that I can pick that thing up and sort of probably operate it and tilt it based on that handle. So the handle, the little lid on the top, the spout, these are all visual affordances that basically tell me how this thing's gonna work. I don't need someone to explain to me how a teapot works, right? Now when it comes to a graphical user interface, we still have affordances, but now they're kind of more metaphorical. So a button is a good example. You might take a button and you might try and make it look like a real world button, something that someone might actually click on. So you give it a drop shadow and like a border and you make it look kind of 3D, right? So these are all visual affordances that you're like adding back in so the user can infer how to use the UI. But for a user who can't see the screen, they're gonna miss out on all of these visual affordances, right? So we need to make sure that the information that we're trying to express with these elements is expressed in a way that's flexible enough that assistive technology can pick up on it and create an alternative interface for our users. And so we refer to this as expressing the semantics of the element. So to give you an example, here I've got a select element with a label and this is gonna produce a visual UI, right? Which is full of its own affordances. But because I've used semantically rich elements, it's also able to produce an audio UI for someone who's using a screen reader. And generally speaking, for mostly elements in your application, you could expect the four sort of crucial pieces of semantic information to be there. The element should have a role. So our select element has a role of pop-up button if you're using the screen reader voiceover on a Mac. It has a name and when I say that, I mean sort of like the label. If you wanna think of it like that way, like what is sort of, if a screen reader were to land on this thing, how would it sort of like say its name or its label? So I'm not talking about the HTML name attribute, but really just like the associated text with the control. It could optionally have a state. Not everything has a state, but some things do. And it could optionally have a value. So what's happening here is when we write HTML, two things get produced, right? We get the DOM and then from that we get a GUI and we get an accessibility tree, which is sort of a collection of all those semantics. That accessibility tree then gets handed off to assistive technology. So something like a screen reader, which is then able to produce a secondary interface for our user, so it can announce, hey, this is the element that you're interacting with. So under the hood, this is what's happening and this is why it's really important to make sure we have those good rich semantics in our applications. So just like we saw with focus, native elements have implicit semantics. So if you are using an input with a type equals password and you focus it using the screen reader voiceover on a Mac, then it's just gonna go ahead and announce that it's secure edit text, right? So I didn't have to add anything there. These are just all built into the native controls. And just like we saw with focus, when we try to bolt functionality onto non-semantic elements like a div, then we're gonna end up missing out on all of these goodies that the browser is trying to give us for free. So here is another one of these fancy div buttons and I've added tab index, right? So it's focusable, but to a screen reader, a div is just a generic container, right? It's not, there's nothing about it that says that it's interactive. So when the user lands on it, if they're using a voiceover, it's just gonna say group, group of what? I don't know. Like, I don't know what to do with this thing. So again, this is another place where we wanna make sure we're not fighting the platform. Whenever possible, we wanna use native elements because we're gonna get these sort of freebie semantics. And by the way, just to send a side, I hope at this point, none of you are ever again gonna write a div button. If anyone writes a div button after this talk, I have clearly failed. Yes, there's no upside to it, but I get it, there are times when you have to build something that, like again, there's no native analog for it, right? You gotta go off road and you've gotta make your own component, right? And when you're doing that, just like we saw with Keyboard Focus, we wanna make sure that we're adding back in those proper semantics. So we can do this using the web accessibility initiatives, accessible rich internet application spec, or ARIA, there's a lot of acronyms in accessibility. So what ARIA does is it lets you do surgery on the accessibility tree, right? It lets you add attributes to elements, and those elements then modify, or say those attributes, then modify the semantics of those elements. Now an important thing to remember here is that semantics is the only thing that ARIA changes. ARIA does not and cannot affect the behavior of your element. So for me, this was one of those Swiss cheese moments that I referred to earlier, kind of like a hole in my understanding of the platform. So I used to think, if I just added like a roll of button and like spam some ARIA attributes on a thing, like it would just become keyboard-focussable. It would just like magically like work with a keyboard, right? That is not the case. All it does is update semantics, which is a really important thing to understand. So that means if you are adding ARIA, you still need to go do your tab index work and you still need to make sure you're adding this keyboard support things as well. Okay, so I'm gonna walk through an example here. This is a custom element that I was working on. It was a checkbox. And you can see what it renders over there. And in this little box down here, I'm gonna put what the screen reader announces when I interact with this thing. Now right now, this thing is so semantically uninteresting that if I were to land on that checkbox element, then voiceover on a Mac would literally just say nothing. It'd be like, this is a nothing to me. I care not about this tag. Okay, so I gotta figure out like, how do I add the right semantics to this? And you could go look at the ARIA spec, which comes with this very helpful diagram. Or what I would recommend is to go back to that ARIA design pattern stock that I was showing earlier. Find the control that you're building. And then this will actually take you to, so since we're building a checkbox, we can get to section 2.7. And it'll actually show you here, there's a whole column if we scroll down, dedicated to these are the right roles and states and things that you need to add to your element. And here's when you need to add them. So this tells me I need a role of checkbox. I need to provide an accessible label. I need to set ARIA checked to true or false, depending on our state, right? Right, up there. Okay, so that's what we're gonna do. So I'm gonna go back to my checkbox. And the first thing I'll do is I'll give it a role of checkbox. And I can see in my little, my box down there, now my screen reader is just gonna say, ah, this is a checkbox and it's unchecked. It's actually inferred that it's unchecked based on the role. And in the world of ARIA, the role is like the most important attribute, okay? Everything sort of falls out of the role. There are many ARIA attributes which don't even work if they are not paired with the correct role. So the first thing I'm gonna do is nail that role. Make sure you got the right one up there. Now, if you're looking at the checkbox, you can see that, well, it actually is checked. So I need to tell this thing that we're currently in that state. So an ARIA checked attribute of true. Now here we see kind of an interesting quirk of ARIA. Some HTML attributes or many HTML attributes are Boolean attributes, meaning that just putting the attribute on the element will imply that it is true, okay? With ARIA, you always have to pass a text value of true or false as a string. I think it's one of the, it's one of the only places where you have to do this. So this is just sort of an interesting quirk of ARIA. So you always have to give it a literal string of true or false. Now the next thing the doc told us to do was give it a label. And labeling is super important in the world of accessibility. And there's kind of two main ways that we can go about it. There's the ARIA label attribute. And this is just a string that we can kind of just apply right to the label itself. So a good example of when we would use this is on something like a hamburger button on your responsive website, right? Like you might not have, you might not have any text around that button. So there's no sort of label to associate with it. But if a user lands on this button in voiceover, it's just gonna say button, okay? Button for what? Like send my social security number? Like what is this button, right? So I need to give it some kind of label. And I can use ARIA label to do that. So now I can say main menu, button, right? Very easy, very nice technique. It's important to note too that ARIA label will override any other label or text that you have associated with an element. So if you've got a button and you've got some text inside of there and you give it an ARIA label, the only thing that will be announced will be that ARIA label. Similarly, we have another thing called ARIA label by. And this lets us actually associate sort of another element as our label. So it's similar to using the native label tag that many of you are familiar with, except for the label element only really works with a few things, a few inputs and other controls, whereas ARIA labeled by can be applied to pretty much any HTML element. And the cool thing about it is it composes. So we can have multiple things that we're referencing that we can use to sort of build up a complex label for our element. So in this case, I've got a shop now button. And when the user lands on it, it just says shop now button. Well, shop now for what? Like shop now for hats, shop now for sunglasses. I want to associate it with that piece of text right up above it. So I can actually put two IDs into my ARIA label by field. I can put that labels ID in there, as well as the buttons ID itself. It can like self reference. And now we've composed together a bigger label of men's outerwear shop now button. So this is what I want to use for my check box. So I've got this little associated span down here. And I'm just going to use ARIA labeled by and refer to that span by its ID. And now we can see that our final outcome is sign up check box, which is awesome. Now there's a few ways to verify that the work that we've done here is correct. You can either learn a screen reader, which I would absolutely recommend everyone do. It takes about 20 minutes. You've got a free one on the Mac in the form of voiceover. And if you go to your system preferences, there's even a tutorial that will just walk you through voiceover, which is awesome. And on Windows, you have NVDA, which is also free. So pick one of those up, check the work that you're doing. But if you're on a big application, it can be a little frustrating to have to tab through or navigate through the entire page with a screen reader every time you want to verify your work. So I'd also recommend that you check out the Chrome Accessibility DevTools extension. So this is available on the Chrome Store. This was created by my teammate, Alice Boxhall. And it's an extension is going to let you inspect your element's accessibility properties the same way that you would inspect like CSS or anything else associated with an element. So I'll give you a little example. So here's our sign up button. And I'm going to open my elements panel, and I can actually find it in the DOM. And then I can go look where normally there's like styles and other things. I have this accessibility properties tab that I can open up. And now I can see the role, the element that is providing my labeled by value. I can see down there where it says text, I can see sort of the computed name or label that will be announced for this thing. So you get all this information for free. And this way I can just very easily go through and inspect my app and make sure that I'm doing the correct work. Now just like we saw with Focus, this can become sort of like a non-trivial amount of effort, getting all these attributes right. And so again, this is another area where you might consider turning this work into web components. And so the Polymer team has actually been looking at that ARIA authoring guide and they build loads of controls. And as well as having good keyboard support, these controls also all apply the correct ARIA roles and correct ARIA states and values when they should at the correct time. And sort of a good example of this is the site that the team has been working on called Shop. So I really like this because I think it's sort of in, it shows that you can use kind of like bleeding edge technology like web components without having to sacrifice on good semantics or anything like that. So you can actually see my screen reader running down here in the corner. I'm gonna navigate through the Shop site and you'll see that it's announcing all this semantically rich information to the user, selling them the control that they're on and how to work with it. It's pop-up button, they can pick their sizes. But you're also seeing good sort of like keyboard focus management. So as I click Add to Cart, now I moved up into that dialogue that just opened up so the user didn't have to furiously search for it. So this is like, again, I really like this project. It's up on GitHub today at Polymer slash Shop on GitHub. Go check this out. Please, if you find accessibility issues, file them because we wanna make this like a sort of a model showpiece of using web components and accessibility to produce a really great final product. Okay, wrap up. We covered three sort of major areas today. The first is make sure that you really understand that diverse range of users that are out there. Learn the WCAG, familiarize yourself with the WebAIM checklists. You know, figure out what your primary user journeys are in your application and make sure that you can really check off the relevant checklist items that relate to those. You also wanna make sure that all of your interactive controls can be reached with the keyboard. So use native elements whenever possible because they're gonna get implicitly inserted in the tab order. But if you need to go off-road, you need to create your own controls. Make sure you add that keyboard support back in using Tabindex. And similarly, we wanna make sure that we're offering good affordances. So use native elements when you can because you get rich semantics for screen readers. And if you need to go off-road, take a look at the ARIA design pattern stock and make sure that you're applying the correct ARIA attributes. The main takeaway that I would like all of you to leave with is sort of one like mantra that you can have in your head is that good accessibility is good UX, okay? Take this back to your team. You know, scream this in your meetings. When you work on accessibility, right? Through every step of your process, what you're doing is you're making sure that the final product that you produce is significantly more polished and that more users can access and enjoy your experience. Okay, I'd also ask you go check out this course. If you've been interested in the things we've been talking about today, this is a multi-week course. It goes way deeper on all the things that I've been showing this afternoon. Also, there are a few more accessibility sessions here at I.O. So this evening at 5 p.m. in Hercules, there will be one. There's one tomorrow at 11 a.m. in Ursa Minor. Also, go check out the sandbox, the access and empathy sandbox. They always have the coolest stuff every I.O. because they're showing off all the cool new future assistive technology. It is always my favorite sandbox. So be sure to go find them and check that out. Lastly, thank you so much for joining me this morning and I hope you enjoy the rest of I.O.