 Thanks so much, Rob. Hi everybody. My name is Laura Palmero. I'm the program manager for accessibility on the Chrome team And I'm Alice Vauxhall. I'm a software engineer on accessibility on Chrome Great. We're really excited to be here today to talk with you all about Palmer 1.0 accessibility First off when we say accessibility, what do we actually mean? So accessibility refers to the design of products services devices and environments for people with disabilities So one in six individuals has a disability. This is 15% of the global population About a billion users. So this is a really substantial amount of people a significant statistic But disability really impacts us on a very personal level To give you a little bit of insight into my personal story and my experience with disability I'm what's considered to be a low vision user or a legally blind person I have a really rare visual condition called Croidal Astiomas Essentially that means that centrally my vision is very impacted. So if you can imagine everything peripherally is quite clear I'm able to navigate around and walk without assistance But everything that I look directly at Sorry, excuse me for one moment Thank you But everything that I look directly at is really impacted So it's a mixture of blur distortion almost if you imagine like a fun house mirror effect and then little flashing lights that kind of pulse all around and This happened really unexpectedly when I was 14 years old with in one week I actually went from being you know having 20-20 vision to being legally blind And this was a big shock to me. It was a huge period of transition for myself as well as my family And quite honestly when I first started I was you know, I was just about to enter high school And all of a sudden I was entering school again not being able to read a blackboard or to read a book or honestly to even distinguish face Walking down the hallway This was this was big this was a big shock and I would come home from school at night and My parents and brother would literally read to me because my materials weren't available in other accessible formats at the time My dad taught me all of my math classes after school because the teachers couldn't quite figure out what to do with the student Who couldn't visually see the blackboard? In my opinion, this was the definition of disability and dependence and I quite honestly hated it So it was just a 14 year old girl I'm just trying to fit in and be normal and this really stopped me and I'm so overly thankful for that amazing amount of support from my family I don't know where I'd be without them today But that wasn't going to sustain for me and that wasn't going to be how I can move forward on my path So over the next few years my vision kind of continued to shift a little bit And I did recover a tiny little field of vision in my left eye that remains centrally I can see about three letters at a time or so to give you a sense So actually to give you a glimpse into my world and what I see and I Heavily rely on using a mixture of all of my different senses of vision Whether central with that tiny little field or the peripheral vision to kind of piece together every image in every environment So if I wanted to take a look at the beautiful canals in Amsterdam for example I'm gonna go ahead and pull this up on Google image search And my typical method here would be to zoom in on the page Really expand the content and use that flexible UI to be able to then use that little tiny field of central vision that I have as well as the peripheral vision to put together the image the best way that I can so you know we can all be looking at this picture and Not all of us are gonna see it the exact same way But the really important thing is that the UI is flexible enough to allow me to customize it so that I can then See it the best way that I can Also to give you another little glimpse. This is how I use Gmail actually so I use a mixture of Screenwriting support so text-to-speech software Contrast adjustments as well as magnification, so I'm gonna go ahead and zoom on in to the level of Magnification that works best for me And then I see an email here from Alice So I'm gonna go ahead and open that and then I'm gonna highlight the text. Hey, let's meet up tomorrow and practice our talk I'll bring the stroke levels if you bring the coffee Then I can go ahead and respond Sounds great and now I can dream about coffee So this this solution and this assistive technology has literally transformed my life Thinking back to when we first kind of discovered all of this when I was entering college We would literally take Physical books and textbooks and strip their bindings off We would high-speed scan the pages then convert them using OCR software Put them into an electronic format and then I could use this text-to-speech and magnification To make it work for me. So by no means was this process pretty but it completely changed my life And it gave me that independence back And it was at this point that I realized the tremendous impact that technology can have on people's lives And it has driven my passion into accessibility ever since So let's talk about some of the users who might be needing assistive technology or requiring accessibility and design So we could be talking about users like myself who are low vision Or perhaps people who are fully blind who rely on full-screen reading software or Braille We could be talking about people with hearing impairments or who may be profoundly deaf who rely on screen captioning or sign language We could be talking about people with motor impairments or dexterity impairments Maybe it's hard for them to use a physical mouse or to use a keyboard They may rely on speech recognition software or even a virtual keyboard or switch controller Or we could be considering people who are neurologically diverse So perhaps somebody who has dyslexia or autism and maybe they need to have a little bit more support on their screen of Keeping focus or maybe even using text-to-speech software We could even consider people in situational impairments. So for example somebody who just you know broke her arm Can't type for the next three months. What do you do then? And lastly it definitely urged everybody to think about the aging population As technology is more and more heavily used in everyone's day-to-day lives as people get older They may experience some slight deterioration of vision or hearing and they're gonna expect their devices are gonna be there to support them Throughout their life and throughout the phases very seamlessly So this is a lot of different Different use cases and disability is a really broad spectrum So when you're designing by no means are we saying that you have to individually test for each and every single use case But we want to kind of expand what we're talking about here today and think about how we can actually design for the most group the highest amount of people at once So from the from now on in this talk We're actually gonna focus our efforts on talking about guidelines that can help us through accessible design And we'll also talk through the process that we followed for enhancing polymer 1.0 accessibility So for a problem on 1.0 the polymer team really wanted to create a set of a Set of elements that they could stand behind in terms of their accessibility and their usability by a really broad range of users So we created a checklist that would allow us to sort of capture a bunch of best practices That we could run over each each element and sort of give it a Sort of okay, this is our best effort. I'm making this accessible and This checklist is based on the web components gold standard, which is available publicly on github The gold standard actually includes accessibility just generally throughout the checklist as it Makes the position that accessibility is just part of any complete custom element But we've just here pulled out the accessibility related items and group them into a few categories that we sort of like Keep in mind as we're going through and sort of like make sense to kind of bundle together Great and to give you a sense of our process that we took leading up to the Palmer 1.0 launch We created this the spreadsheet tracker and this is just a small snapshot of it And we used these guidelines that Alice just mentioned to test each element individually And as you can imagine leading up to the 1.0 launch There was a lot going on a lot of moving pieces and we had to figure out how to prioritize Accessibility within this broader scope of work, so we helped to prioritize on two axes So first how critical was the user issue in seconds? Basically how high traffic did we expect that that element would be comparatively Great so to walk you through our process that we took to test for accessibility Identify issues and then resolve the issues. We're going to take you through a quick case study of the paper checkbox element Great, so let's start with the keyboard So here Good here. We've got the traditional experience with the mouse pointer So I can go ahead and use the mouse pointer To hover over these checkboxes to go ahead and click to check or uncheck them and I get a nice little animation It's very smooth But now let's take a look at the keyboard experience. What if this user can't really use a mouse? They need to use the keyboard only So in this early demo, I'm tabbing through But getting no no sort of visual feedback So I really don't know where I am on the screen. You may have heard some little dings in there That was me trying to press enter to activate one of the checkboxes. Nothing was working. So major fail. This is not gonna work So what actually went wrong here, so we're missing focus So we're also missing focus visibility and it's not keyboard interactive So I can't actually use or activate the checkboxes with just the keyboard only So breaking those items down one by one taking a look at flexibility So by comparison, we have just a native checkbox here a couple of native checkboxes This is sort of trying to recreate the experience where you filled in a credit card form. Maybe a flight booking If you're me, you're gonna go through with the keyboard fill it out really quickly not even touch the mouse Because I just yeah, I know my credit card details and whatnot get to the end and I'm gonna check the yes I read and agree to the terms and conditions checkbox because I've totally done that And then I really need to make sure that I unchecked this. Please spam me every day checkbox so I can move focus there and Uncheck it so very very simple something we're probably all familiar with but to break down those concepts we have Those checkboxes are focusable I can move the keyboard focus there and I feel like I'm sort of circularly defining focus here But the focus and the focus ring that you see there I kind of a promise that you can do something with this element using the keyboard so In the case of like the credit card field I could cut time at credit card details into it once the focus moves down to these Checkboxes, I can check and uncheck them with the keyboard The way that we make custom elements focusable is by using the tab index attribute So tab index can take one of three sort of ranges of values If tab index is zero that's going to put it in the natural tab order So following the DOM traversal order So this is just exactly the same as you would get with a native checkbox if tab index is negative one It's going to be programmatically focus focusable, but you're not going to be able to get to it using the tab key So this might be a piece of motor UI or something like a menu item Where you want to actually have control over when focus gets to it rather than just having the user stumble across it in the Tab order if tab index is greater than zero. It's going to be in a manual tab order So you get to specify any sort of index in there All of those elements are going to come before everything else in the tab order This obviously makes very little sense on the outside of a custom element because you don't know where your element's going to fall in the page by definition It is scoped within shadow DOM, but if you don't know whether or not you're going to be in shadow DOM again It really makes no sense to use it. This is kind of something that you really want to mostly avoid In the case of paper checkbox actually making it focusable is really straightforward because we have this host attributes object So host attributes is going to be applied just after the element is created But it's also going to respect any value that the author the web page author has provided for that value So in this case we could take a paper checkbox and I could say no I really need this paper checkbox to be right up front in the page give it a tab index of one It's going to appear before the yellow elements in tab order. So that's working as expected So once you've made something focusable, it's absolutely critical to make sure that you can tell when it's focused So I've actually seen Developers do all the right things and add all of their custom keyboard event handling and make things focusable and they have designers come in and say we're not a fan of that focus ring turn it off and What this looks like to a keyboard user is that they have just thrown them under a bus because they can't tell what's going on They can't even tell that focus is getting to the element that you know that they may be able to do something So it's absolutely mandatory to make focus visible in some way So if you are forced to turn off that focus ring You can obviously match the focus style and in a custom element You would probably want to match that on the host or wherever you put the tab index So in case of a complex custom element which might have multiple focusable things inside of it You would obviously match those in this case. I've just created like this silly toy element with a star And I'm going to say okay make the background color for that star span this nice polymer blue and Yeah, then I'm done with that For paper checkbox It's actually done a whole end round around the CSS focus styling system and actually uses its own Custom paper in key focus behavior, which gives it that nice ripple. It makes it a really consistent experience with using a pointer So it's going to look just the same whether using a pointer or focus. It's gonna. Yeah, you're really nice experience Once we've addressed the focus ability and the visible focus then obviously we need to fulfill that promise that we've made by making it Actually do something when you use the keyboard keyboard event handling in HTML is not great But luckily polymer team have provided iron accessibility keys behavior, which you can mix in so this is going to abstract away all those gnarly cross browser differences and legacy and spec mismatches and whatnot and give you just a simple syntax for defining key combinations and their listeners So again with my wonderful little star element. We've got a Import for the iron accessibility keys behavior behavior We're adding it into the behaviors list and Then I'm going to add this key bindings object, which is going to define which keys I'm listening for and what happens when those keys get fired So in this case, I've left it up to your imagination. What's going to happen when you press space or enter All right, so let's take a look at the fixed experience now So now we're able to tab through Either using tab to go forward or shift tab to go in reverse You get a really nice clear visual focus, which is that gray circle And I can use the inner key to actually check or uncheck the checkboxes. See that wasn't that hard, right? All right, so next we did extensive testing with screen readers and screen readers are used by people with visual impairments to navigate the UI Purely using audio and for the next moment. I'd like to invite you all to just briefly close your eyes All right, so let's take a look at the paper checkbox now carbon uncheck checkbox hydrogen check checkbox nitrogen check checkbox Great, you can open them if you choose So that was the smooth experience of what what a user should be able to navigate So basically this this user I'm able to navigate using the keyboard Hearing the audio of what the checkboxes actually are for What state they're in and I can then infer that I could use the inner key or the space key to then change them to either check or Uncheck them. This is great Just to give you all a sense of some of the free screen readers that are available out there So voiceover is available on OS X and iOS for free. It's built in The NVDA screen reader is free and open source Available on Windows We've got the Chrome Vox screen reader on Chrome OS and we've got talk back on Android There are plenty of others out there available for purchase. You may have heard of zoom text or Jaws or others We did our testing for the Polymer 1.0 launch and beyond Across a multitude of screen readers as well as browser and OS combinations because we wanted to make sure to be as Comprehensive as possible. So now let's take a look at an experience that isn't so great group group group group Super helpful, right? So if you're non-visual, what are you getting from this? Nothing I'd be really confused and honestly just angry and I'd walk away So what went wrong here? So we have no semantics that are properly declared and we have no labels We have no clue what's going on or what we can do with this UI. So taking a look at those items from buy one for stop semantics So again comparing and contrasting with a native HTML checkbox We're going to yeah, just add a checkbox in the page and That gives us this nice visual rendering which to anyone who can see it gives you some semantic cues So we know for example that this is going to be something which takes a bullion type value. It's on or it's off It's probably going to be choosing one in a list of options or it's going to be answering a question like yes Please spam me for the rest of my life We also get this dumb object that allows us to programmatically interact with that with the the element on the page What you probably may not have seen before is that it's also going to translate into a node in the accessibility tree the accessibility tree is what screen readers like Boy server, which we were demoing just before or many other screen readers or assistive technologies Actually interact with rather than the visual UI which is painted painted on the screen So in this case we have an accessibility node with a role of checkbox and a value of one meaning checked And some other attributes. It's got a role description. It's which is going to be localized. It's got Invalid value saying it's not invalid. It's not it's not disabled So that gives us like a bit of an overview of what semantics we can actually express We can we can give an element of role So this is obviously really critical for any interactive element We need to know what type of interactions we're going to be able to do with it. It can take a value So is a numeric value or a text value. It can take a state So checked or not checked but also things like disabled has pop-up and Any other type of properties so things like for a slider you might have a minimum maximum value Which is not really a current value, but it's just a property So going back to our paper checkbox example We've got we've just as we did with the native checkbox We've entered the paper checkbox on the page and can make sure that it's checked Just so with the native checkbox. We'd not get this nice visual rendering which gives us some visual cues as to its meaning and semantics And just as with the native checkbox We get this great DOM object that we can manipulate programmatically because polymer provides this really nice API for us but the accessibility node that is created by default from this element is Basically non semantic it has no meaning the browser is just going to say group So this is this is why in the demo a moment ago is just saying group group. That's the browser saying I don't know what this is Which is really not great for accessibility The way that we can address this in custom elements is by using WAI aria Which stands for accessible rich internet application which allows us to specify those roles states values and properties By a plain html attributes So the way this might look if we didn't build this into the paper checkbox is that As an author I could come along and give this custom element a role of checkbox and aria check value of true So it's still going to look exactly the same It's still going to be have exactly the same API But now to a screen reader or assistive technology It's going to look identical to that native checkbox because it's going to have the same role and the same value in the same state Which is exactly what we want and again, this is very straightforward to do in a polymer element. So In the paper checkbox, we just add it into the host attributes Object again, and again, this means that as a web page author I can come along and say, okay I know you say you're a checkbox, but I'm going to pretend you're a radio button into a screen reader It would say, okay. Yes, great. That's a radio button and we're also going to give it a default aria check value and then keep that aria check value in Sync with the actual live element state Great. So now we've declared some semantics. Let's take a look at the experience now uncheck checkbox check checkbox check checkbox Okay, so it's a little bit better I know if the checkboxes are checked or unchecked and you know that they are checkboxes But what am I checking? Maybe I really want that spammy newsletter. Who knows? All right, so what do we do from here? So this is why labels are so important We have a bunch of options in native html for providing labels and wherever possible We should try and use those because they'll always provide sort of extra benefits So we've got the label element for anything which is labelable according to the html spec we've got alt attributes for images and Most things can actually use their textual content as and as a label as well aria also gives us some options for labels So aria label will allow us to specify a non-visible label For something like an icon button where the the actual meaning comes from the icon for a sighted user Then you don't need to provide an actual text label but you can provide an aria label to replicate the experience of the icon and aria labeled by allows you to take a visible piece of UI which may not be part of your descendant content and say Okay, this is acting as my label So for paper checkbox, we're actually using the aria label option Great, so let's take a look at the positive experience one more time Carbon uncheck checkbox hydrogen check checkbox nitrogen check checkbox As you all can tell this is a vastly more accessible experience for a non-visual user All right, the third bucket of the guidelines that we're going through today is making your UI more flexible So three things that we wanted to cover and are ensuring, you know redundant color and sufficient contrast and magnification So first redundant color and did you all know that there are? 315 million people out there who are colorblind. That's roughly the same amount of people who speak English as their native language This is a really large amount of people. We need to be considering them in our design So the main purpose here is that we never want to use colors a soul way to actually identify key information so we're going to take a look at the the golds email input Element for a quick a quick review of this so right now. We've got an email entered below Which is basically an incorrect email and right now in the early stage of the demo The only way that this is signified is by the red color in text and the underline So if I were a colorblind user or for me being someone who just has difficulty detecting color This actually looks just completely normal to me So I might be going through and filling out a form and just continuing to hit this error hitting submit and getting really frustrated Because it's just not letting me know So the polymer team then gave one step up which is Basically allowing you to enhance the thickness of the line just to say hey like there's something wrong here But again, if you can't say that that thicker line is also red It might just look like a styling change or a formatting change. So it's still not overly clear to the user The best option is to utilize what the polymer team is provided in custom error messaging So this way you can actually show whatever whatever wording you need to show about oh, there's something wrong here This is really clear to all users whether or not they can perceive color or cannot and it can be used as the label For the screen reader to then tell a non-visual user of exactly what's going on So we can just flash up the fully accessible version So showing color, but also the thicker line and the actual wording So next up we've got contrast and it's really important to ensure that you've got sufficient contrast between the text or an icon And it's background color So the WCAG accessibility standards basically say that the absolute minimum contrast ratio that we want to consider is 4.5 to 1 the only time when this doesn't really apply is if you're using large text So it's 18 font or larger and this you're the minimum is actually 3 to 1 So definitely want to consider these standards across all of your design I'll give you all a real-life example on my flight over from San Francisco to Amsterdam This was the screen that I experienced on the plane. So when I was choosing movies and for me This was really difficult. I couldn't actually read any of the texts so I wound up just fumbling with my remote control and I came across pitch perfect randomly wound up watching it a few times. Don't get me wrong pitch perfect is fine It's cute, but that was really unnecessary and some of you we experienced out in the overflow room with bean bags We noticed that the the big beautiful windows They're letting in a lot of light and it's actually making that screen a little bit harder to tell So some of you may not even be able to see the text Which is you know a real-life example of illustrating the point that Here we've got a contrast ratio of 2.9 to 1 which is far below the 4.5 to 1 recommendation and in guideline So in case you're not able to calculate contrast ratios in your head by looking at color pairs The accessibility developer tools extension which Chris mentioned in his talk earlier As well as allowing you to audit for contrast ratio of text actually provides a debugging tool as well so if you can see it there is a Extra sidebar pane in the elements panel here, and I'm just inspecting some text on just a regular HTML Google results website, and I found some blue contrast text and the extension is going to tell me it's current contrast Issues 3.95 which is low and give me some suggestions for darker shades of gray that I could use and Chris also mentioned that the same audit rules that are in the accessibility to develop tools extension are built into the Polymer testing library, so I've got an example here of some accessibility testing for the paper checkbox No paper radio button element So they've written some custom accessibility tests, but all of the accessibility audit results there are coming straight from the audit And it's all of those passes mean that this check was relevant to this element and it passed so that's really great Great and lastly we want to make sure that magnification is working smoothly So if I need to zoom in on the page, I want to make sure that all of the content actually still renders correctly So here we can see the paper checkbox again And I'm utilizing just the command plus on Mac or if you're on Windows or Chrome OS Control plus to zoom all the way in And I can see that you know the the formatting still stays really well intact I'm still able to use the tab key the focus still remains. It's in the right place. It's a really smooth experience So we definitely encourage you all to quickly check how how your elements and how your sites and apps are rendering when magnified or zoomed in So that's about where we are where to from here If you're using the polymer elements, obviously you have the option to use the paper elements Which is going to give you the full material design experience and also The up-to-date accessibility experience so the accessibility is sort of sort of like perpetual work in progress But it's just going to keep improving its time goes on the iron elements give you the more basic behaviors So you can use the reusable mixing behaviors So things like the checkable behavior or even the the accessibility keys behavior But also bare bones elements that you can build on top of like there's sort of a bare bones list element that you could use and if you're wanting to start completely from scratch the polymer library obviously gives you some accessibility support as well with the Keyboard mix in the host attributes object and the automated testing built into the polymer testing Great and here are a few additional resources that we recommend that you all check out So first the gold standard accessibility checklist that we mentioned available on github The material design usability guidelines are really helpful and also some of the automated testing tools So for instance the accessibility developer tools audit that Alice mentioned which was available as a Chrome extension So if you just do a quick search for any of these terms and you'll be able to get more information and learn more So to wrap up the world's health organization made a statement that really resonated with us So they said that disability is really the interaction between individuals with health conditions And then their personal and environmental factors So this is when real barriers are set in place So if somebody's in a wheelchair in this building and really needs to get to the second floor But the elevators are broken or thinking back to my early days in my math classes Where I was sitting in class and just couldn't get the actual context because there was no other way of receiving that information Aside from visually reading the blackboard So the incredible thing about technology and all of the advancements that have been made over the last years is that these barriers simply Don't need to exist. I think about how now I can customize my entire experience Really to my needs and assuming that the site or the app is actually built in an accessible way My visual impairment doesn't have to hinder my experience at all and I can do whatever I need to do I'll be it slightly differently So we hope that you've all found this talk informative and that you now include accessibility in your design and development and help to Make a more accessible world. Thank you