 Hi, everyone. My name is Laura Palmero. I'm the program manager for the Chrome team for accessibility specifically. And I'm Alice Boxell, and I'm a software engineer on the Chrome team, also working on accessibility. We're really excited to be here with you all today and talk about Polymer accessibility. So first of all, when we say accessibility, what do we actually mean? So accessibility refers to the design of products, devices, services, and environments for people with disabilities. And to give you a sense, one in six people have some form of disability. That's over a billion people in the world. And that's a really significant population size, obviously, and a very powerful statistic. But when we think about disability, it really impacts us each on a very personal level. To give you a little bit of my personal story, when I was 14 years old, I essentially went from having 20-20 vision to being legally blind within one week. I was diagnosed with a super rare visual disorder, which impacts my central vision. So while everything peripherally is still intact for me, anything that I look directly at is this mixture of distortion and darkness and little flashing lights that kind of pulse around. And I've been told that it takes a lot of drugs to simulate that effect, so I've got that going for me. But when all this first happened, I was quite a transition. So I was just about to enter high school, big new school, and all of a sudden, I could no longer read a book or see a blackboard or distinguish my friends' faces in the hallway. So this was a really big change for me and my family. And quite honestly, those first few years were a struggle. So I'd come home from school, and my father would teach me my math classes, because they couldn't quite figure out what to do with a student who couldn't visually see the blackboard. My mom and my brother would read to me. When it came to taking the SAT exam, I sat in the room with a wonderful woman who read it out loud to me. It took nine and a half hours, and that was not a fun day. I can promise you that. So thinking back to this time, it was a struggle. And it was honestly, I'm so thankful for all the support that I received. My family was just incredible. I don't know where I'd be without them today. But when I think back, this was really the definition of disability and dependence to me. And I hated it. So over those couple of years, my vision shifted a little bit, and I did happen to regain a tiny central field in my left eye, which is about the size of three letters or so. So if you can imagine, tunnel vision. And then I was able to kind of aggregate the right sort of assistive technology to really regain a lot of my independence back. So to give you a little glimpse into my world and what I see, first I, three weeks ago, adopted a really lovable black lab named Bow. So if I wanted to go ahead and figure out what sort of dog park to take Bow to in San Francisco, I could bring up Google Image Search and type in a search result. And once the images are there, I can go ahead and really easily zoom in to get it to the right level of magnification for me so that I could use my peripheral vision, as well as that little central field and piece together the image the best way that I can see possible. So the important thing to know is that when we all in this room on the livestream, when we're all looking at these images, we might not all be seeing the same thing. But the really crucial part is that this UI is flexible enough so that I can customize it and use the vision that I have and see it the best way that I can. And success, we made it to Lafayette Park and this is Bow soaking up the sun. All right, next, this is how I interact with Gmail just to give you an example. So as you can tell, I've got the white text on black background instead of the typical reverse. This really helps to reduce eye strain. And I'll go ahead and show you an example of how I use magnification and text to speech. So I can go ahead and zoom in just by pressing Command plus or Control plus. See an email from Alice. Hey, are you bringing your dog to work today? I can't wait to meet him. Then I can craft a response and highlight it and press a keystroke. Yes, we're on our way with treats and tennis balls. And then it's read back to me. So this technology has literally transformed my life. So when I think back to my college days, we used to buy physical textbooks and strip their bindings off of them and then run all the pages through a high-speed scanner, then use OCR software to convert to text, and then I could use this mixture of magnification, contrast, and text to speech to go ahead and access those materials finally. So it was not a pretty process, but it completely changed my life. And it was at this point that I realized the amazing impact that technology can have on individuals. And it's really just inspired me ever since and fueled my passion to progress accessibility. So I'm just one example of a low-vision user who greatly benefits from assistive technology. But when we're all designing UI, which is often quite visual in nature, we need to be really conscious and aware of the many different ways that users might be interacting with the UI. So we need to think about people, for instance, who are fully blind, who might be using a screen reader or a Braille display. We need to think about people who are hearing impaired, who are using captions or even an example in this room of using live captioning of speaking of exactly what I'm saying right now. We need to be considered of people who might have a motor impairment or a dexterity impairment and might not be able to use a mouse and might rely fully on using the keyboard to interact. Or maybe typing is actually really difficult and instead voice control would be better or switch access with a switch controller device or even a head tracking system or eye tracker. We also need to be considered of people who might be neurologically diverse with autism or dyslexia, et cetera, who may benefit from, instead of typing, they might really benefit from dictating or using spell check more heavily or the auto suggestion of words. We also wanna think about the aging population who as we all get older, we're gonna potentially experience a bit of slow deterioration, a vision and hearing. And lastly, we wanna think about temporary or situational impairments. So essentially, what if I break my arm? What do I do then? Or even just the instance of, hey, if you're in a loud bar and you're trying to watch a football game and you can't hear what's going on, you're gonna rely on those captions to hear what the commentator is saying. So disability is a really broad spectrum and by no means are we saying that when you're out and designing that you need to test your UI with every single different type of visitive technology that exists in the world. But we are saying that there are a set of design principles that we can all use that'll help us to really create products that are usable by the greatest number of people. All right, so that's a lot to take in, obviously. What can we do as developers to actually make sure that we're not at least breaking accessibility? And obviously the first thing we can do is to take advantage of any built-in accessibility where we can. So HTML5 comes with a lot of built-in accessibility that's been designed into the platform sort of over the years and built into browsers. And anytime we can use a native HTML element to express semantics, that's absolutely what we should do if we can. If we need to move beyond the standard HTML vocabulary for whatever reason, then that's where custom elements can come into the picture and help out. So Polymer obviously provides a suite of custom elements that are also gonna make certain guarantees about accessibility. Now we're gonna talk a bit about what guarantees Polymer makes about accessibility and I wanna stress that this is software and it's never gonna be done, it's never gonna be perfect. So we can say certain things at the moment and obviously it's always gonna improve with time. So we've got the paper elements, Google Web Components and gold elements that have had a lot of work done already on accessibility that you can drop right into your pages today. If you're rolling your own custom elements or need something a little more bare bones, they also have the iron elements which are gonna provide extra functionality or UI patterns that you can build on top of and build your own UI and your own look. Great, so as we were leading up to the 1.0 launch, we really wanted to be able to stand behind the accessibility of each of these elements in the library. So to do so, we built and executed a really firm strategy which had four prongs. So first, upskilling the team. We really focused on educating the entire team about accessibility. So instead of just appointing one expert, we wanted to educate all of the front-end engineers so that they could actually resolve the issues that were currently existing and then also incorporate accessibility into the forward-looking design. Second, we wrote and ran automated tests to be able to catch low-hanging fruit as well as regressions. And while the automated tests are fantastic, we can't ever really expect them to catch every single usability glitch or issue. So in this strategy, manual testing was a really critical component. And the only true stamp of accessibility is that the product or service or site works for every user. But drawing from experience, we can tell that we can actually capture quite a bit of the potential issues by using a standardized checklist for testing. And to create this checklist, we leveraged the gold standard web component checklist and pulled out all the accessibility related pieces and crafted our own accessibility-specific checklist and then used that to run across each individual element in the Polymer Library. Great. And the testing checklist falls into three buckets. So first, focus and keyboard, since keyboard interaction is absolutely fundamental to accessibility. Second is semantics, and third is working on flexible UI. And we're gonna dive into all of these later in the presentation. All right, the fourth part of our strategy was prioritization. So as you can imagine, leading up to the 1.0 launch, there were a lot of different moving pieces, and we had to figure out how to work accessibility into the broader scope of work. So we aggregated all of the testing results of what sort of issues existed, what else we wanted to improve, and then we figured out how to prioritize on two axes. So first, how critical was the user issue? And second, how high traffic did we imagine that element would be? And here's just a really quick example of our progress snapshot leading up to the 1.0 launch. So to walk you through the process that we took to test and identify issues and then resolve the issues, we're gonna walk everybody through a case study of the paper checkbox element. So let's start with the keyboard. So if I was a user who was going to use the mouse pointer in a traditional fashion, I could go ahead and hover with the mouse pointer. I could click to check or uncheck the boxes. I get a nice little visual animation but this whole process works really smoothly, right? But what if I can't actually use the mouse? What if I have to rely on the keyboard only? So let's see in this early demo what the experience is like with just the keyboard. All right, so you might hear that there are some little dings in the background. That's me tabbing around, trying to see where focus is, trying to actually use this with just the keyboard. Doesn't work at all, major fail. So what actually went wrong here? So first, we're not able to focus anything. Therefore, if we can't focus anything, there's no visual indication of focus. And third, we can't actually interact with this at all using just the keyboard. So let's address those one at a time. So we probably all have some notion of what focus means, although we may not have actually interacted with it. But if anyone has ever filled out a web form using the keyboard, I do this all the time because I really hate using the mouse if I don't have to. You probably encountered a situation like this. When you get to the end, you've got these two checkboxes. It's like, yeah, I've totally read and agreed to those 10 pages of terms and conditions. Absolutely. So, OK, yep, checked that. And I can hit Tab, get to the next checkbox, which says, your ideas are intriguing to me, or I wish to subscribe to you. I can use that all the words, so that effect. Basically, spam me forever, please. No, I do not want that. I'm going to hit Spacebar, uncheck that, hit Tab again, get to the Submit button, submit the form. Wonderful. Takes maybe three seconds if I'm really slow that day. So that's really great. So that form is you're all using native HTML elements, which have the focus ability, have that focus styling, and have keyboard interaction all built in. The way that we can actually add focus ability to any kind of custom UI, including custom elements, is using the TabIndex attribute. Which, again, probably most of us have come across. So I'm just going to quickly run through. It can take three classes of values. If the TabIndex is zero, it's going to put it in a natural tab order based on the DOM order. So this is exactly what you would get using a native element. If that TabIndex is negative, which you can apply on any element, including native elements, the element is going to be programmatically focusable, but not in that tab order. So I could move focus to it. Say, for example, I'm moving it onto the screen, or it's part of a menu that I want to actually have finer grain control. Or maybe I need to shift focus based on a user interaction. Then I can use that a negative TabIndex to actually control when focus moves to that element. Greater than zero TabIndex puts the element in a manual tab order. Obviously, on a custom element, this makes no sense whatsoever as a default value. It can make sense in certain situations, but in general, it's usually you want to avoid that. So Laura mentioned that we need to make focus visible. So this is what it looks like if focus is not visible. So I got to the end of the form, and my focus is on one of these elements. And I have no idea which one it is. So it might be unchecking the terms and conditions checkbox. That's not so bad. I can fix that. It might be unchecking the spam me forever checkbox, which is good, which is what I want, but it also might be submitting a form, which is going to do me to another six years of spam from this airline until I finally figure out the right sequence of links and whatnot to actually unsubscribe. I like to call this focus roulette, and it is really not a nice thing to do to your users. So if we are in a position where a designer has said, no, you really have to kill that native focus ring, we need to make sure that we're actually styling focus. And it's pretty straightforward. We just need to use that focus so you don't select us. So in this case, we're matching focus on the host, because we're going to make sure that that host is focusable using that tab index attribute. In this case, we're actually using the Polymer host attribute object to set that tab index attribute on the element once it's rendered in the page. And then we can just set a nice background color to say, OK, make this element have this particular background color when it's focused. Finally, we need to actually make good on the promise that we're making by making it L1 focusable and showing that it's focusable. Unfortunately, this is one of the rougher areas of programming for the web. I can't lie to you. So many good libraries exist to paper over this, so to speak. Iron accessibility keys is one that I highly, highly recommend. It's really great if you're using Polymer and can use this library. It puts a nice thick layer of spackle over all of those giant fishes in the web platform. It provides a mixing behavior for keyboard handling, and it abstracts away the nasty cross-browser differences, and provides a really simple usable syntax for defining those key combinations that you want to listen for, and the listeners that should be fired. So a quick example of that. We need to import that iron accessibility keys behavior, add iron accessibility keys behavior to the behavior array, and then we can provide this key bindings object, which uses some readable syntax for what keys to listen for and what to do when those key events happen. All right, so let's take a look at the fixed experience. So here we can tab around or press Shift tab to go in reverse. We get a very clear visual focus indication, and we can use the keyboard to actually check or uncheck those checkboxes, which is just a much, much smoother experience for keyboard-only users. It wasn't that hard, right? All right, next part of our testing strategy was to test with screen readers, which are software that essentially allow visually impaired or blind individuals to navigate the UI using audio spoken feedback. So just for a moment, I'd invite you all to close your eyes. And let's take a look at what the experience is like with the paper checkbox using a screen reader. Carbon unchecked checkbox. Hydrogen checked checkbox. Nitrogen checked checkbox. All right, you can open your eyes or keep them closed. I know it's been a long day. So essentially, this is the smooth experience. You're able to navigate through. You hear what the specific checkboxes are for. We know that they are checkboxes, just to start. We can hear the state of whether or not they're checked or unchecked. And then from there, we can infer that we could also use the keyboard to change that state. So this is a really smooth experience. Just to give you a sense, there are a lot of free screen readers out there that are most of or many of which are actually built into your operating systems. This is just a few of them. There are also additional screen readers that are available for purchase or for download. We on the Polymer team do our testing across a wide variety of screen readers, operating systems, and browsers, just to get really comprehensive testing results. All right, so let's take a look at an experience that's not quite as smooth. Group, group, group, group, group, group. Awesome. That's so awesome. Fail. All right, so what went wrong here? So first of all, we have no declared semantics. And second, we don't have any sort of labels. We have no idea what this UI is for. All right, so taking a look at semantics, what's actually involved here? So the browser creates this thing called the Accessibility Tree, which provides an interface which assistive technology can actually use to interact with the page. So this Accessibility Tree is this very beautiful diagram, indicates it's sort of a simplified version of the DOM. So it takes out most of the presentational information, sort of any unnecessary sort of elements, sort of a bunch, yeah, a bunch of the extra detail just doesn't need to be there. The assistive technology can then use that to provide a different type of output to the user, potentially. So for example, in the case of a screen reader, it's going to provide speech output. In the case of a Braille reader, it's going to provide Braille output. The user can then interact with the page via the assistive technology. So for example, in the case of a screen reader, it's often based on keyboard shortcuts that can simulate a mouse click and so on. In the case of a speech control device, it's not going to provide any actual output because the user can often see the page, but it might allow the user to provide verbal commands. The assistive technology then routes that action back to the accessibility tree where it takes action in the page. So how do we translate the DOM tree into that assistive technology tree? So when we create an element in the page, typically, we'll get this really nice visual rendering, giving a visual indication of what role that element's playing. So in the case of a checkbox, we get this little rounded box. We get a check mark telling us what this is something that we can check and uncheck like a ballot box. We get a DOM object that we can interact with programmatically. And we also get this accessibility node. So a node in that accessibility tree, which is used by screen readers and other assistive technology. The semantics that we can actually provide on an element include its role. So is it a checkbox? Is it a radio button? Is it a text box and so on? Its value, its state. So something like, is it checked, disabled? Does it help pop up and so on? And a bunch of other properties, things like a minimum value for a text, sorry, a numeric range and so on. For custom elements, we actually need to provide those semantics ourselves. And this is what happens if we don't. So we still get that visual rendering, because obviously that's what we spent all of that time doing. We get that DOM object, and we can still interact with it programmatically, which is, again, really great. It's what we need. But we don't get that accessibility node. Instead, we get a completely generic node, because the browser has no concept of what role this element is supposed to be playing. It's effectively just a div. The way that we actually provide those semantics in the case of custom elements or any other type of custom UI is by using aria, which stands for accessible rich internet applications, which allows us to specify those role, state, value, and properties, semantics via HTML attributes. So in the case of the paper checkbox, we actually need the element to write out its own aria attributes. And it's going to give itself a role of checkbox and an aria checked value of true. So again, we get that visual rendering. Nothing's changed there. Nothing's changed in the DOM object, except that it's got these extra attributes. But now we actually have that accessibility node, which is comprehensible and usable by the screen reader and other assistive technology. The way that we do this in the paper checkbox is, again, using this host attributes object. So that allows us to say, OK, write this attribute out to the DOM once the element is rendered. But it also respects any author-provided attributes. So for example, if I wanted to inherit from the paper checkbox for some reason and say, OK, I know you're saying you're a paper checkbox, but I'm getting you to add a radio button. I can give that a role of radio button. Then we need to make sure we keep those semantics in sync with the element state. So in this case, we want to make sure that that aria checked value keeps in sync with the checked property. OK, so we've declared some semantics. Let's see what the experience is like now. Uncheck checkbox. Check checkbox. Check checkbox. OK, so this is a slight step up. We know that these are checkboxes, and we understand whether or not they're checked or unchecked. But what are they for? All right, so I'm going to give you a quick whirlwind tour of all of the options we have for explaining what things are. So when we have native, labelable elements, like a checkbox, we can use the label element. You can use a wrapped or you can use an ID. Another great side effect this has is that I can actually now click on that text and uncheck the checkbox. So anyone out there who is not using this, you get my look of disapproval. Because that drives me crazy. All right, we have the alt attribute for native images. So in this case, we have a lovely image of Boo, and then if that image doesn't load, we get a little bit of text saying Boo showing off his new red leash. This is also useful for screen readers, obviously, because we can provide a completely useful text alternative to the image. Quick note, alt and title or any other tooltip or caption are not the same thing. So alt is intended to provide an alternative to the image. A title or a caption is some kind of augmented information to the image. So in this case, we've got a title saying this is Boo, because you can't tell that from the image. You can tell from the image that he has a new red leash. All right, another option we have is element content, which is going to work on most things. We also have some options from Aria. So we have an Aria label attribute, which we can use to provide a string, which is used for an assistive technology-only label. So in this case, we have something, a bold toolbar button. As someone who can see that button, I can say, yes, I've seen that icon before. I know what that does. Screen reader user has no way of telling what icon that it has. So they get a little bit of extra information. And in this case, it actually provides information about the keyboard shortcut, so that they don't need to actually find the button again. We also have Aria-Labeled By, which allows us to specify an ID of an element in the page, even including an element which is not rendered and used that element as the text alternative for the element. So in this case, we've got a comic image which has a lengthy transcript. We can use Aria-Labeled By to tie that transcript to the image. Finally, I just want to point out that all of these labeling options compose. So for example, if we have a button which contains an image, the alt text for that image will be used as a label for the button. OK, so let's take a look at the smooth experience one more time. Carbon, unchecked, checkbox. Hydrogen, check, checkbox. Nitrogen, checked, checkbox. So this is a vastly more accessible version for non-visual users. The Polymer team also do regression testing on these things. So when we find a bug like a label is missing or it needs to have a particular role, they will actually write a regression test like this to assert that those attributes and properties are provided. All right, so the third bucket within our manual testing checklist is ensuring flexible UI. And that has three main components that we want to talk about today. So first, ensuring redundant color, second, magnification, and third, contrast. So let's start with redundant color. So 1 in 12 males are colorblind and 1 in 200 women. So this is a very large population of people. So the main concept that we want to take away is that we never want to use color as the only way to indicate any sort of information. So here we have an example with the gold email input element. And we have essentially the indication that this second email is incorrect just through the red text. So to somebody who's colorblind or to someone like me who has trouble perceiving color as a whole, we can't actually tell that anything is wrong here, which means it's just a frustrating experience. And just a quick note that we're using a Chrome extension here called NoCoffee, which allows you to visually simulate different visual conditions. So the next step up that the Polymer team provided was to use this thicker red line to underline the mistake. But again, if you can't see that that's red, it might just look like a stylistic change, and that's still not giving you the right context. So the best way to approach this is to use what the Polymer team has provided and use the custom error messaging. So this is great for people who can't perceive color. It's also really great because that custom messaging can then be pulled in and used as the label for the screen reader. So this is definitely the most accessible version. Great. So next, we've got magnification. And we want to ensure that the magnification is working smoothly if you zoom in using Control plus or Command plus. So as I zoom in on the paper checkbox element example, you can tell the labels all stay in the same place. All the formatting is still intact. I can still use the keyboard and get that clear visual focus ring. It's a really smooth experience, which is great. All right, and third, we want to ensure sufficient contrast. So the WCAG accessibility standards specify that the minimum contrast ratio of texts in its background color should be 4.5 to 1, unless you're dealing with large text size 18 font or larger. And then the minimum is 3 to 1. And contrast is something that's really important. So not only for low vision users like myself, but it's 25% of all adults have vision that is in the range between 2020 and 2040, meaning that the 3.1 ratio is actually going to be really hard to see. But 4.5 makes it so much clearer. So this is a really, really key concept to include in all of your sites and apps. And I'll give you a real life example. So last week, I was about to make brownies for a friend's birthday. And this is what the box looked like, unfortunately. So the ratios on this box are actually only 2.2 to 1 and 2.6 to 1, clearly well below the 4.5 to 1 minimum ratio. So I had to go as far as to look up the recipe online and use my screen reader to actually listen to it and access it, which was honestly just unnecessary and a little bit silly. So if we boost this up so that we're meeting the WCAG guidelines of 4.5 to 1 minimum, this is what the box now looks like, which is honestly a really great improvement. But it's still a little bit tough for me to see that. So the best approach is to use what the WCAG guidelines specify as AAA, 7 to 1 ratio. And you can see this is just so much clearer for everybody to be able to see. All right. Just quickly, another tool that you can use to actually test for accessibility. Sort of along the lines of a lint, obviously, it's not going to find all of your bugs, but it'll catch some low-hanging fruit issues, including color contrast, is the accessibility to developer tools extension. So it'll run and audit in your page, but also gives you some context-sensitive information in the elements pane as well. So in this case, we've got the website for this particular company. And we can see that the context ratio of the text on the page is a little better. It's 3.98. But we can apply some suggested colors here. So for the 4.5 or the 7.0 ratio. And the same rules that that extension uses for its accessibility audit are also used by the Polymer team in all of their automated testing. So they're going to run that same lint on each test case for their elements just to make sure that they're catching any low-hanging fruit before it gets to manual testing. All right. So that's where we've been. Where to next? So we on the Polymer team really want to be leading the charge when it comes to accessibility. So we have it woven into our entire forward-looking roadmap. So we have continuous automated testing and regression testing that runs. We have regular manual testing schedules in place. And we're also working on making a more sophisticated release process so that we can actually add accessibility as a blocker to any sort of stable releases of elements. And with that, we'll be able to have more transparency around what sort of testing was done for each element version. So to wrap up, we often like to say that hope is not a strategy. So we all have a really important role to play in up-leveling and standardizing accessibility on the web as well as beyond. So the World Health Organization made a statement that really resonated true with us. It said that disability is really the unsuccessful interaction between an individual with a health condition and their environmental factors. So this is when barriers are really put in place. I think back to my early days in math classes, where I was just sitting there in that classroom really frustrated because there was just no other way to get that information if I couldn't visually see the blackboard. So the amazing thing is that with all of these technological advances and the more that information shifts into electronic formats, many of these barriers just no longer need to exist. So I can customize my own setup. I can access a site, assuming that it's built in an accessible way. I can do whatever I need to do, albeit slightly differently. So this is just extremely powerful. We really hope that you found this talk informative and that you all will incorporate accessibility into your design and development and help to make for a more accessible world. Thank you.