Ted Drake & Sarbbottam - Accessibility + yui

Andrew Wooldridge: Alright, we are ready for our next talk on the second day of YUIConf 2013. I'm proud to announce Sarbbottam and Ted Drake coming to talk to us about accessibility and YUI. Let's give them a big hand. [applause] Ted Drake: Hi everybody. It was sort of a walk down memory trail when Dav was up here earlier. I joined Yahoo around 2005 so I remember YUI when it was like dot 001 trying to implement it on one of our projects. When I joined Yahoo I helped found the Yahoo Accessibility Stakeholders Group, which was sort of like a bunch of engineers that got together and said how can we make Yahoo more accessible. That eventually evolved into the Yahoo Accessibility Lab where I was able to work for two years full time doing nothing but helping accessibility. I'm now in charge of accessibility at Intuit. TurboTax, Quicken, QuickBooks, that kind of stuff. One day I was over at Yahoo recently meeting with Yahoo's accessibility team, Mike Shebanek from Yahoo and Gary Moulton from Microsoft. They introduced me to Sarbbottam who is working on the user sign up for Yahoo, when you want to become a new Yahoo user. He was trying to figure out the phone number, you know you're dropping down and you want to choose a new phone number, and it just so happened I was working at Intuit we were trying to solve the exact same problem with our international banking product. I'd hit a wall, and I was like how am I going to solve this thing, and then when I met Sarbbottam he had it solved. He made it open source and we actually integrated his work into the international banking product we were working on at Intuit. When this YUIConf came up I told Jenny, I said I'd love to do an accessibility thing but I've been out of YUI for a while. However I think if I introduce it a little bit and give Sarbbottam the microphone I think you guys will learn a lot from him. What we're going to be talking about today is how can you use YUI, how can you build a really dynamic visually engaging form that is just a form, it can be doing anything that you're doing, but also make it accessible. Not just the code, but also the strategy behind it. This talk is about Bruce Lee, it's kind of like the theme. There will be a few Easter eggs where there are some very wrong things about this, so some of you might chuckle when you realize something that's completely wrong. It was intentional. Bruce Lee said once mistakes are always forgivable if one has the courage to admit them. I think that this is really true about accessibility. I don't think the inaccessible stuff out there was done because people wanted to make them not accessible. I don't think they intentionally said let's purposely refuse access to our site or our app because we don't want them to use it. It's more like I didn't realize I was doing it wrong. But when you realize you're doing something wrong it's your obligation to fix those things and actually make your stuff accessible. That's why we're up here is to show you how easy it can be, what are the steps you can do. We have a standard, it's the WCAG 2.0 standard. This is part of the W3C and it's basically saying if you want your stuff to be accessible it has to do these things. They can be summarized into POUR. Perceivable, Operable, Understandable, Robust. Essentially if someone comes to your app or to your site they need to know what's on the screen. They need to be able to focus on interactive elements. They need to be able to interact with those interactive elements. They need to be able to hit the control key or the escape key, they need to be able to hit the enter key, they need to be able to hit the mouse key. They need to be able to click in any instance. It has to be understandable. When they land on something they need to know what's the context, what is this thing actually doing, and what is the text. Just using background images is great for visual people but if there's no text in that span or in that link then you don't give the user anything to understand what that link is about. And finally it needs to be robust, and that's what progressive enhancement is all about. It needs to be able to work on IE. It needs to be able to work with a Braille reader. It needs to be able to work with Android 2.0. Robust means thinking about your users no matter what kind of technology they use. We're going to be talking about a few parts of ARIA today. ARIA is Accessible Rich Internet Applications. It's a standard that allows us to say I'm no longer building a document, I'm building an application and this application is going to behave like let's say Microsoft Word. Yahoo Mail, Microsoft Word, there are some core relations here. Microsoft Outlook I mean. Let's give the user some expectation. When I click on this link it's not just a link, it's actually going to pop up a menu. When I come into this list of elements it's actually a menu, or it's actually a tab set. These are the things that ARIA allows us to do. Sarbbottam's going to show how he used live regions, which is when the content on the page changes, it's automatically announced. He's going to be talking about how he strategically used labels and descriptions and how you can define the role of an object. Now one of the key things about ARIA is if you can use native HTML, use native HTML. Don't use a div and then retrofit it with ARIA to make it work unless there's a very good reason to use that div instead of the native element. He's going to show us some examples today where because of the visual designs he wasn't able to use the native element. What he did was he used a non-native element and used ARIA to fix them. But one of the cool things I saw about his work, you turn off JavaScript and it works. The native element, the underlying HTML is perfect. But he's then saying if you have JavaScript enabled then let's go ahead and make the interface fancier and let's make it accessible. Let's see a little bit of this in action. What we're going to be looking at is a form. This form is available on GitHub and he has a test page so you'll be able to get the code to look through it. When we go through this form, every bit on the form will be announced. I'm using the tab keys, so the keyboard allows me to go back and forth throughout the elements. I can use the up down arrow keys to go through the menu items. What you'll want to look at is just understand when the screen reader goes through this, everything is understandable and everything can be accessed. We're going to go through the different elements so you don't have to memorize everything on here. You'll understand them afterwards. Screen Reader: First name. First name required edit text. BRUCE. Bruce. Last name. Last name required edit text. LEE. Lee. Username. Username required edit. Suggestions available. Press shift + down or up arrow to navigate between suggestions and press enter to select or type the desired username. brucelee. brucelee76. bruce.lee. bruce.ninja.lee. bruce.ninjamaster.lee. End of suggestions. bruce.ninjamaster.lee. End of suggestions. Unmask password unchecked check box. Password must contain eight characters. MyKarate. Weak password, easy to crack. MyKarate. B3. Not bad, but you can make it better. [laughter] TT. MyKarateB3tt. ER. MykarateB3tter. Super. You are a password ninja. [laughter] United States +1 Country Code for mandatory mobile number pop up button. Mandatory mobile number. Mandatory mobile number required edit text. 41 ) 415 ) 55 ľ 555 ľ 1212. 1212. Male radio button, one of two. Female selected radio button, two of two. Male selected radio button, one of two. Afghanistan Country, pop up button. Japan menu item. Japan Country pop up button. India +91 Country Code for optional recovery phone number pop up button. Jamaica +. Japan +81 menu item. Optional recovery phone number edit text. 555 555 1212. 555 1212. Submit button. Ted: So you've gotten an idea as to what that form looks like and sounds like. Now Sarbbottam's going to walk you through three of the key elements, and if we have time there's a fourth key element. I'll pass this on over to Sarbbottam. Sarbbottam: Good morning once again, and thanks Ted for the great introduction. How many of you really have worked with web forms? Can I just see a few hands? So how do you feel? You can style them in every way, or the way your visual designer mocks really present it, and you can do everything with the forms, or you really need to tweak here and there. Or let's cut the crap and make it simple. Is working with form and the visual mock which your designer comes up, is it really an easy task? So you just have seen the country code drop down menu out there. In the ideal case, it would have been just a select an option drop down, but I could never find an option in which you can style the options. There is no way that you can put a country flag or anything of those sort in a select option. So the only way I could have done it... Okay, let's mimic it, let's try it with some div and menu items. I mean the unordered list out there. But then how do you make it keyboard accessible? Okay, let's give the functionality to do it the up and arrow navigation keys, but how do you also mimic the feature of in a select drop down you can just easily type it and it will automatically select. For example if it's a country list out there which is coming, you can easily type IND and it will select India automatically. Or maybe PAK and it will select Pakistan. How do you give this kind of functionality to your custom element? How do you read out how many items are there? These are the many things which I had to take care of, and we'll drill down to each of them one after the other. If you see that's a button. When you see a select option out there, it's a button, it's a select button. We click out there. But looking at the text, and the text only reads the +81 which is the country code. Visually that makes sense. You are seeing the country flag out there, you see the drop down arrow there and you see +81out there. It gives you an impression that you can click over there and a popup menu will come up. But how does a user who cannot see it really understand what it does? If you see those highlighted text, it's already a HREF which is out there and I haven't added anything extra. You already must be having this span out there for the flag, you must be having the span out there for the drop down arrow or something like that. But the things which I have added out there, role equal to button, and it does a button. Aria-haspopup equal to true, so it tells you that it has a popup. We'll go through the video once again. And you have an aria-label. That's a label for the button. It speaks out completely that the Japan +81 country code for optional recovery number. Let's see the video once again. Screen Reader: United State +1 Country Code for optional recovery phone number pop up button. Japan +81 menu item. Optional recovery phone number. Optional recovery phone number edit text. Japan +81 Country Code for optional recovery phone number pop up button. Sarbbottam: So that label is every time changing whenever you're making a selection out there. The voiceover, the assisted technology knows, okay, this is a new label and I'll read it out. I think this is the most simplest example and this is the most simplest workaround that you can do to make it accessible. You have a password meter in your form, you're updating the meter as well as you're updating the text out there. But that text is not readable. I mean the text is not visually presented to the user who's focus is on the password field. I think I am making a mistake out here. The text is not read out to the user because the focus is on the password field so you are typing something out there and the text is dynamically changing, and also the meter is changing out there. Visually you can see it, but what for the user who cannot see it? The VoiceOver or the NVDA or the JAWS, they are reading out what you are typing in the password box or the text field. But what about the message which is coming up? Ted: Whenever you're changing anything on the page, you've got JavaScript that's putting new information into that password thing, and that's all visual. We just want to make sure that that's also announced to the screen reader user. Sarbbottam: So you just add aria-live, aria-atomic and aria-relevant, and that's all. You can use polite or assertive out there but it's always better to go with the polite. If you use assertive the moment it changes it will speak out. It's better to go with the polite. But if you really have something which needs the immediately attention, for example a model comes over something, you better go for assertive. But it is always better to stick to polite. Aria-atomic false tells you is the change atomic or the change complete. The relevant tells you what are the relevant things. If you are really not sure about what are the relevant things, go with all. Or if you really know about it, go with relevant equal to text or something like that. Ted: Just as a quick note, atomic equals false and relevant equals all is the default, so if you don't put those on there it's okay. Sarbbottam: You see in this example that I haven't done anything, just by adding three attributes, three state attributes, you're making it completely accessible. That is a text which actually gets changed. The text should get changed with the innerHTML feature. That's how the live region gets triggered, that you already must be doing in a form validation. But if you just add those three state attributes you just make it completely accessible. So that's the text which is getting changed out there. Ted: We'll watch the form again. Screen Reader: Password must contain 8 characters. MyKarate. Weak password, easy to crack. MyKarate. B3. Not bad, but you can make it better. TT. MyKarateB3tt. ER. MyKarateB3tter. Super. You are a password ninja. Sarbbottam: This was more challenging when I had to really implement it, but as our second slide suggested we learned from our mistakes. This is not yet accessible in the Yahoo registration page, which we'll do it maybe within a few weeks. The code is there, it hasn't been pushed yet. The problem is that these additions will be coming from the server side, so there is a latency. There is a latency of at least a second or 500 milliseconds. It dynamically gets injected into the page. So again, for a visual user you know that some visual layout got changed, so something got developed out here. But how do you, once again, tell it to the user who cannot see it? The best strategy is just to use aria-live which we have seen in the password example and dynamically change that text out there. But you really need to make sure that the autocomplete is off out here, otherwise your layout and the browser's cached autocomplete will override with each other. We'll not go through each and every attribute in this one, but when you talk about the form validation we'll go through what is aria-required, aria-describedby, and why I have chosen aria-labelledby, that's the static decision I have taken. Instead of mapping it from label to... Instead of using labelfor I'm using aria-labelledby. I'll come to that discussion and I'll go through the form validation. Ted: This is the container. Sarbbottam: It has the same thing which we have seen in the password, but the only way I change it dynamically. This is the JavaScript snippet which actually updates the text out there. You get suggestions HTML out there, you take it out from there. You also see whether the end of the suggestion has reached or not, and you update the text accordingly and insert it into that container. That's the suggestions readout container text which is getting updated each and every time you're hovering through each and every suggestion. And the hovering is... If you see there your actual focus is in the username box, so it's a pseudo-focus I'm trying to show you when you're pressing your up and down arrow keys. And also one more thing we really need to be careful out there, since we don't want our focus to be... Since we don't want our user name field to lose the focus, so when you're doing the mouse interaction it's always better to do the mouse down even instead of going for a click, and also prevent the default, so that the focus will never lose from that field. Ted: Just to clarify, I had some confusion on this. We were actually talking about this. Why did you go with this concept of having an external paragraph that gets updated? That was really interesting the way he solved this, is that the focus is still on the input but you're using your mouse, you're using your arrow keys, which are basically going through the options, and you're not changing the focus. The focus is still on the input. So while you've got a pseudo-focus, you could say, and you're moving through the options, because the focus is still on the input we've got to place that information somewhere that it can be announced. By taking it out of that option, sticking it in this extra container, we're able to announce in that extra container. That's why we're able to do that. It seems a little bit odd but it's because we're not going with the standard HTML options. Here's the video of it. Screen Reader: User name. User name required edit. Suggestions available. Press shift + down or up arrow to navigate between suggestions and press enter to select or type the desired username. bruce lee. brucelee76. bruce.lee. bruce.ninja.lee. bruce.ninjamaster.lee. End of suggestions. bruce.ninjamaster.lee. End of suggestions. Sarbbottan: So that was the main reason behind having an extra container to read out those things. Ted: We've taken 20 minutes. We do have another element that we can show. Is there anybody, raise your hands, do you want us to show one other element? Or do we want to take questions? Okay. Sarbbottan: We are coming to the form validation. I'll try to speak a little bit faster because the slides will be pretty much self-explanatory out there. You have many fields out there, but you used to see in the older times you used to have an asterisk out there which used to mark the fields that are mandatory for the visual indication. But you want to do the same thing for the assistive technology, just use the attribute aria-required equal to true, or just use the HTML5 required attribute. But just make sure if you're using the HTML5 required attribute, and if you don't want the form to be validated and give some native validation messages out there, like this is mandatory, that's what Chrome will be giving and Safari will be giving. If you don't want that just put an attribute no validate in your form. Ted: One of the quick things that we showed off in this one is that the input has already describedby equals name-message, and then there's this paragraph which is actually going to hold our alert message. The aria-describedby points to that paragraph, so when we update this and you put an error message in that paragraph, it'll be announced immediately because of the live region. But we've also validated that input that it's now invalid, so by putting aria-invalid equals true onto that input, the user now knows that it's invalid. If they were to tab off that input and then go back into it, it would announce this being an invalid input. And because we've got the aria-describedby pointing to that message it would also announce that alert. So we have the instant aria-live announcement and then when the user goes back to it it'll also announce the error message. Let's see that one. Screen Reader: First name. First name required edit text. Enter name. Last name. Last name required edit text. First name. First name required invalid data edit text. You are currently on a text field inside of HTML content. To enter text in this field, type. The help tag is enter name. Ted: VoiceOver treats that like a title attribute and it takes a little long. That's why we had to wait. If using it in NVDA or Jaws it's pretty quick. Did you have anything else? Sarbbottan: That's for the field level validation. Another thing which is more a strategy decision that we have taken at the time of implementing this sign up page, many times I have seen the submit button or the call to action button stays invisible unless and until it passes through all the validations. A better approach I think would be, which we have implemented, like keep your submit button always available. Let your user click over there irrespective, or they can press enter which would be the shortcut. Or let them click the submit button, then do your complete form validation, apply your visual indications, find out whichever is the first invalid element, and set the focus out there. So the voiceover will also read out, okay, you have made this action, the form was submitted, the submit action has taken place. But there are invalid fields and you have been navigated to that field once again. That's all I had from my side to show. I think we have six minutes. If you have questions we'll try to answer them, or I'll just show the actual... So far you have been seeing the videos. If we still have time, I mean if there are no questions I'll show the live thing. Ted: One thing I do want to mention real quick is we've shown how you can create custom elements, the YUI has done an amazing job of making all of the widgets accessible. It's really great. Whenever I see a site using YUI I get happy because I know that it's going to work generally. If you're building stuff for the gallery, please make sure your stuff in the gallery is accessible also. But you can use the YUI AutoComplete and you can know that it's going to work out of the box. Sarbbottam: Just one more. There is a very nice widget developed in YUI, YUI MenuNav. If you are really creating your menus henceforth, try to use that YUI MenuNav which is completely accessible and it comes out of the box. Audience member: My question isn't necessarily about forms, but I've noticed that when you download a file on a browser it pops up in the bottom window but is not visible for a blind user. I love how with aria-live you can automatically announce that something is there. Do you have any tips for us notifying the user that this file has been downloaded and it's now available here? Ted: If the downloading is part of the browser's action then there's not much you should do. You should allow the browser to do that. If you're doing something in your page that's showing that it's done and that's your code, there's the aria-role equals alert, and role equals alert basically includes aria-live. Let's say I have a div, I have aria-role equals alert. Whenever anything in that div changes it will be announced, and it will not remove focus. It's like an alert that doesn't need focus. So it would be announced your file has downloaded. The only caveat on that is that Safari doesn't deal very well with, or VoiceOver doesn't do aria-alert very well. But it works great on Windows machines. Audience member: It doesn't do it well in that it won't alert you at all? Ted: Yeah, unfortunately. VoiceOver doesn't deal with role equals alert very well and some of its live region support is iffy. But it's the standard way of doing it, and it works on phones, it's just on Safari on desktop it's kind of iffy. Audience member: But the end of the story is if you want to have a file downloaded you're at the mercy of the browser? Ted: Yeah, and the browser should handle that. If you turn on Safari and VoiceOver and you download it, the browser should notify the user that the file is downloaded. Audience member: Okay, thanks. Audience member: From the usability aspect or perspective of non-sighted users, is error reporting on a per field basis preferable or a submit after all of the inputs are filled in and then the entire form is validated? It seems like you would want to link the inputs to a single live region in the latter case versus maintaining a variety of live regions for each of the individual fields as the live validation was happening. Ted: I wouldn't program specifically for the blind user. I would program for the visual design so that you're just doing it once and it affects everybody. If your visual design has multiple error messages, each one of those can have a live region, and they're only going to be announced when that content changes, either via display block or inner HTML. You don't have to do a separate one just for non-visual users. Audience member: Sure. I'm thinking about the impact of full form validation where you have six errors on the page and that's an awful lot that gets read out all at once. Ted: Yeah, if it's a page refresh then the inputs should all have aria-invalid equals true and you should point to those error messages. Audience member: Well even without the page refresh. Ted: If it's not a page refresh it's going to be... You can have a single one, and that one would say... And I've seen this many times. You have a dialog and it says you have the following inputs are invalid. That would work fine. What I would do is an unordered list or something like that, and it would read everything out. But then as you go from one input to another maybe it's pointing to one element. Maybe it's a span with an ID that has this error message. You go to the next input and it's pointing to this span. So that when the page refreshes, the aria-live announces all of them. But when the user is tabbing through the inputs it's once again just going to the one that's invalid for that particular one. Does that make sense? One of the reasons why I've seen this done is like a password where you have the check marks. Audience member: Yeah, I'm thinking about the case where the live region gets updated with a long list of fields that are invalid. The user's then going to change focus to... Or maybe the focus gets dropped on the first invalid field. Now they've had that read out to them once and they've already forgotten by the time they're at the second field. They're going to end up tabbing through all the fields waiting for the ARIA notification that this particular input is invalid. Maybe that's fine, maybe that's just sort of the status quo, but I don't know if there's a way to improve that or if it's best just to avoid it. Ted: The way to improve it would be making sure that each input connected to its error message using aria-describedby. That way when they're in that input they still have the message with them. Audience member: Oh sure, sure, sure. Ted: Whether or not you announce them all, that's a different question. Audience member: I see, so the live region div for example would contain a number of paragraphs and each of those paragraphs hits an ID, and then as you're tapping to it... Gotcha. Sarbbottam: Just to add on to these answers, live region will read out the last one which has been updated, that is its preference, because whenever there is any... I'm not sure whether this user actionů Can I just get the slides up? The screen ones? I'm not sure, I'm just trying to show it. It might address your concerns out here. Pressing the enter button out here will invoke the submit action, or you can even click over there. Screen Reader: First name. Required invalid data edit text. Mobile number required. Sarbbottam: It's in the last one which was updated with the aria-live part was the mobile number one. But it has read out only that one. The focus has moved to the first number out there if you see. First since I have used the ariaů The mode is polite out there, so first context went to the first name, it has read out that okay this is the first invalid field and whatever went into that one. Then it has gone to the last of the live region that was updated. The first name required user name required, password contains, and everything was part of the live region, but the last one which got updated was mobile number required, so that one was read out. It's not reading out each and everything as you have speculated. Andrew: Alright, I think we've reached the end of our QA session.