[MUSIC] 0:00 [APPLAUSE] >> Thank you very much and good morning. 0:09 And thank you everybody for coming to this talk. 0:15 I really don't need to introduce myself after 0:18 that comprehensive introduction from Ian. 0:21 One thing I will say though is that sometimes asking questions at conferences 0:24 like this can be a little bit scary, so my Twitter details are up on pretty 0:27 much every slide so if you don't feel like asking a question through the talk or 0:31 at the end, please come up and say hello afterwards or ping me a Tweet and 0:36 it'll be good to catch up and carry on the conversation. 0:40 So a conversation about what? 0:43 Well, making interfaces accessible so that people really want to use them. 0:46 Accessibility to my way of thinking has a bit of a brand problem. 0:52 It makes people think of legislation and conformance and guidelines and 0:57 being sued and all kinds of nasty bits and pieces. 1:02 But actually, for me, it's something much more fundamental than that. 1:05 It's just about designing like we give a damn. 1:08 Like we give a damn about the things we put our hearts and 1:11 souls into developing and creating, but 1:13 mostly like we give a damn about the people that are gonna be using them. 1:16 What I'd like to talk about today is my take on designing like we give a damn and 1:20 accessibility to offer some ideas about how we can make it happen in 1:24 a really practical sense and to look at the experiences of someone like me 1:29 who uses a screen reader to access computers and the Internet. 1:34 And to do that, I am gonna share four principals that I've used before that 1:39 explain my theory of designing like we give a damn. 1:44 >> Slide two: Design like Banksy [INAUDIBLE]. 1:49 [INAUDIBLE] >> Oops. 1:51 What I should explain is that's my screen reader you're listening to there at about 1:53 the speed I tend to listen to it. 1:56 So don't try and follow along. 1:57 It'll probably drive you a bit nuts. 1:59 But trust me, it makes sense to me. 2:00 Or at least as much as anything ever does in this life. 2:01 So the first principle of designing like you give a damn is to design like Banksy, 2:04 which is to say read the rule book, understand it but don't ever be afraid 2:10 to challenge the accepted wisdom, rip it up and start again. 2:14 There's a lot of information out there about accessibility. 2:18 That maybe once was true, but certainly is no longer true, or is downright incorrect. 2:22 And I just wanna share some of those myths with you so 2:28 we can perhaps start to put them to rest for once and for all. 2:30 >> Slide three: Accessibility. 2:33 Accessibility. 2:35 >> Accessibility stifles innovation. 2:35 This is something I hear a lot, all of the time. 2:37 When you think about accessibility, people get a bit like, oh my goodness, 2:40 now we're going to have to put everything in black and white, and 2:43 it's all going to have to be just non-interactive and 2:45 there's going to be no shiny, that's really not what it's about at all. 2:47 If you get an idea for a product or a web application or 2:50 an app, whatever it is you want to build, don't let the thought of having to make it 2:53 accessible put you off innovating in the technology in itself. 2:57 All you need to do is just make accessibility one of the many 3:01 things that you think about when you're innovating. 3:04 You can innovate within accessibility as much as you can within any 3:06 other area of technology. 3:09 So don't let it stifle your imagination when it comes to building stuff. 3:11 Just think about the people that are gonna be using that product and 3:15 make the accessibility part of the innovation. 3:18 >> Accessibility kills creativity. 3:22 >> Accessibility kills creativity is something we hear quite often. 3:23 On screen, there's just a cast of my business card website. 3:27 You'll probably gather from the slides that I've got a bit of a thing for 3:31 the film noir kind of thing going on. 3:34 It's the same on my blog. 3:35 And a friend designed my business card website with a bit of CS animation just to 3:37 give it a bit of interest. 3:41 This is perfectly accessible. 3:43 It's all good semantic HTML. 3:44 You can turn off the animation if it's too distracting for you. 3:46 But, hopefully, it gives you an idea that accessibility can be something creative 3:49 and, like innovation, think about accessibility when you do the creation. 3:54 Don't let it slow you down. 3:59 >> Accessibility is difficult [INAUDIBLE]. 4:01 >> This is something we hear a lot. 4:03 Accessibility isn't difficult. 4:06 What it is, actually, is unfamiliar for a lot of people. 4:07 What you guys do everyday is the difficult part. 4:11 You've learned JavaScript, HTML, CSS, 4:14 you've got those things most of the time to work in most browsers, and frankly, 4:16 if you can do that, everything else is pretty much a cinch. 4:20 The unfamiliarity is what slows people down with accessibility. 4:24 It's easy to know what it feels like when someone uses a tablet or 4:28 a desk top or a Netbook or a Macbook or whatever it may be. 4:31 But the chances are, you might not know what' it's like to use a screen reader. 4:35 That translates content into synthetic speech. 4:39 Or, to use speech recognition where you control your computer entirely 4:41 through voice commands. 4:45 But all of those things are pretty achievable. 4:46 We've got a MAC, hit command F5 and you'll get a screen reader. 4:48 Play around with it a little bit. 4:53 Know that it's command F5 will turn it off again so 4:54 otherwise you'll get stuck forever. 4:56 Most technologies on Windows you can download a free screen reader called NVDA. 4:59 From nvaccess.org. 5:04 Download it, grab it, play around with it. 5:06 You can get your hands on pretty much any kind of assistive technology, so 5:08 just take those first steps, and 5:13 experiment to remove that kind of level of unfamiliarity. 5:14 >> Slide six: Accessibility is irrelevant. 5:18 How families in an automated car driving along the highway next to a futuristic. 5:19 >> Accessibility is irrelevant. 5:22 A lot of people will say, well, you know, it's just for people with disabilities and 5:23 there's really not many of them out there in the world so, yeah, you know what. 5:27 The simple fact is that if you think about accessibility now you're gonna be making 5:31 things a hell of a lot better for yourself in 25 or 30 years time. 5:34 It's a sad but true fact is, as humans we tend to get a bit slower, 5:38 a bit less capable as we get older. 5:43 But the interesting thing about us now is that if you think about your older self, 5:45 your future self. 5:49 Are you really gonna have the patience and the tolerance to put up with a web 5:51 that won't let you go out and do the things that you do? 5:55 My hunch is, pretty much not. 5:57 If you've been used to using the internet to do whatever it is you want through your 5:59 younger life and then suddenly because your eyesight starts to deteriorate or 6:02 your hearing goes a little bit as you get older and 6:06 suddenly you discover you can't use something. 6:08 That's not gonna be an acceptable state of affairs for any of us. 6:10 So it's very much thinking about our future as 6:13 well as people in the current time when it comes to accessibility. 6:16 >> Slide seven: Design like Da Vinci. 6:19 >> So the next principle is to design like Da Vinci. 6:24 And never stop being curious about how we can make things better and 6:27 that's really important with all kinds of technology cuz very much that's 6:32 what we want to do with technology a lot of the time. 6:35 >> Slide eight: Perfect is the enemy of good. 6:38 Each carrot is a different shape, none of them conforming to the perfect shape. 6:40 Backslash. >> So enemy. 6:43 >> I'm having real trouble with this. 6:45 Perfection is the enemy of good. 6:47 You've got a bunch of lumpy carrots on the screen, I think. 6:49 It's dreadful trying to find a picture for this. 6:51 When you think about accessibility, there's a temptation to think that it's 6:53 gotta be perfect, and this comes back to this idea of complying with the law. 6:56 Needing to conform with some set of guidelines. 7:00 That's actually a really dangerous way to think about anything but 7:03 especially accessibility. 7:06 Because if you start to think about it having to be perfect, 7:07 you just quail at the whole idea. 7:10 It seems unachievable, insurmountable. 7:12 And then, quite often, you don't wanna take the first steps. 7:15 The truth is, is that with accessibility, 7:19 even if you do just a couple of little things, 7:21 you're going to be making a difference to somebody somewhere out there. 7:23 So don't worry about the big picture, just keep doing little things every day to 7:26 make a difference, and there's quite a few things we can do to make that difference. 7:31 >> Slide ten: Interaction. 7:35 >> Interaction. 7:38 If your an interaction designer think about talking to people. 7:39 And I think I just skipped a slide actually. 7:43 Which is to say we don't want to just keep throwing things over the wall. 7:45 Shout out if you've ever been working on a project where the interaction designers 7:49 and the prototypers have put together a fantastic set of interaction designs. 7:53 Handed it over to the design guys who've made it look beautiful and 7:58 absolutely fantastic. 8:00 Handed it over to the developers who've taken one look at it and 8:02 gone, we can't build that on the platform we're working on. 8:04 [INAUDIBLE] >> [LAUGH] Right? 8:06 We've all been there. 8:08 Trying to talk to each other all the way through this, 8:09 agile does help with this a lot, is a really kind of important thing. 8:12 And it's very much the same with accessibility. 8:15 So with interaction, when you're thinking about interaction, 8:18 think about the fact that people are using lots of different ways. 8:21 To consume the content. 8:25 >> Interaction. 8:27 >> So if we take something like a search. 8:28 It used to be back in the day that 8:30 most people used a mouse to interact with content. 8:33 Except for people with disabilities who, more or less, used a keyboard or 8:36 some device that mimicked the behavior of a keyboard. 8:39 That's really not the case anymore. 8:42 We all use touch, we use speech, we use mice, 8:44 we use keyboards to interact with content and you can't really now tell 8:47 which people using which of those things has a disability and which doesn't. 8:52 So when you're thinking about interaction, keep things really simple. 8:56 We've got a search field up on the screen now. 9:00 Is there an obvious way to execute that search? 9:02 Is there a button that says Search, or do something? 9:05 That's good usability for everybody, but if you're talking about somebody who's 9:08 perhaps on the autistic spectrum, where clear instructions are really, 9:11 really critical, having that button with the clear instruction to search or do or 9:14 whatever is very, very important. 9:19 If you're not sure that that's gonna be feasible, 9:22 talk to the designers to make sure it can be built in so it's obviously a button. 9:24 Talk to the developers to make sure the space and 9:27 capability to put that button there. 9:30 Similarly, make sure it's clear that this is a search. 9:32 There'll be visual labels but you need to make sure that there are labels for 9:35 screen reader users. 9:40 People like myself who can't see what's going on. 9:41 Something like a search. 9:44 There isn't always real estate to put that, kind of, search text label in. 9:44 But, again, go talk to the developers to find out if there's ways in the code to 9:47 make those labels available to screen reader users. 9:52 Trust me, there will be. 9:54 But, if you just make assumptions at this point, you could be building, 9:56 Corners that the developers and the designers really can't get out of. 9:59 >> Slide 11. 10:03 Design. 10:04 >> When it comes to design, and I'm gonna come back to buttons. 10:04 >> Design. 10:07 >> Buttons just always come in for grief in these talks. 10:08 Make sure that, when you've got an element or 10:12 a control, that the visual affordances are really, really obvious. 10:14 If it's gonna be a button, make sure it looks like a button. 10:18 Now the reason I'm picking up on this is because quite often, what we find 10:20 is that something that looks like a button under the hood when it comes to the code, 10:24 is in fact a link. 10:27 If you happen to use a screen reader or another assistive technology like 10:29 speech recognition, those two things are fundamentally different. 10:32 If you've got a speech recognition tool and you're looking 10:35 at something that appears to be a button, and you say click on that button, but it's 10:38 actually a link under the hood in the HTML code, those speech commands won't work. 10:41 It's the same with a screen reader. 10:45 If you click on a shortcut to move to the next button on the page, but the button 10:46 actually turns out to be a link, everything pretty much stops working. 10:50 So when you think about the design, not only is it really good to make sure that 10:53 something actually looks like what it is, but again, talk to the dev guys and 10:57 make sure that it's actually gonna be what it appears to be under the hood. 11:01 >> Slide 12. Choice. 11:05 >> Give people choices. 11:06 >> Choice. 11:08 >> This was all from my blog, and here I've just got a dark and 11:09 light color theme switcher. 11:12 That's just one example of how to give people choices when you're thinking 11:14 about a website. 11:17 It doesn't have to be color. 11:18 It could be some other form of personalization. 11:19 Could just be making sure that there's a capacity for the content to be zoomed 11:21 using the browser's function without kind of losing legibility or readability. 11:25 But these are all just kind of tiny little things that you can do. 11:30 None of them are really earth-shattering, but by talking and thinking about how 11:32 people interact with stuff, you can start to make a really big difference. 11:36 >> Slide 13. 11:40 Communicate. 11:40 >> And all through this is just the necessity to communicate. 11:41 Keep talking to each other. 11:45 That more than anything is the most vital thing because between you, you have all 11:46 the information that you kind of need, but if you keep working in isolation, well 11:50 we've all been there and done that, it's just gonna make life a lot more difficult. 11:53 >> [INAUDIBLE] >> So, design. 11:57 Design like Chanel and you might of heard of this if you keeping up with this, 12:02 strive for beauty and elegance in the things that you build, but 12:06 understand that those things are pretty much different for 12:08 everybody who's going to be using your content. 12:11 So what I'm going to do now, 12:13 is just going to give you some incites into what it's like using a screen reader. 12:15 >> Slide once more from the top. 12:20 >> So back in the day, what used to happen when you accessed a web page with a screen 12:22 reader is that it would be like reading a text document. 12:26 There was no semantic structure, no information at all. 12:28 You'd just start at the top of the page and 12:31 pretty much read your way down a bit like this. 12:33 >> [NOISE] Chapters and 12:35 those [INAUDIBLE] can be used 12:39 to insert content into page. 12:45 In some situations, this technique is a useful thing to do, but 12:51 how to browsers and screen readers handle the generated content? 12:54 Using Schema.org with Microdata posted and code things on February 25th, 12:57 2015 search engines have ways of extracting meaning from content. 13:02 But they are prone to error because information on the web can be presented in 13:05 so many different ways. 13:09 Marking up information so it's easier for 13:10 search engines to index is a good thing to do. 13:12 And thanks to the vocabularies available from Schema.org, 13:14 it's also very accessible. 13:17 Time out notifications 13:18 [INAUDIBLE]. 13:28 >> You still with me out there? 13:33 >> [LAUGH] >> So this is kind of why it gave rise to 13:34 the idea that if you use an assistive technology like a screen-reader, 13:37 it took you a hell of a lot longer to do anything than your sighted counterparts. 13:40 It really isn't surprising because it really was that painful. 13:43 Things have kind of moved on in recent years, though. 13:47 >> Slide 16, [INAUDIBLE]. 13:49 >> What we've got now is browsers that 13:50 make a lot more information available to assistive technologies. 13:54 This has led to the ability to navigate by different kinds of elements, like this. 13:57 >> [NOISE] Heading level one accessibility support for 14:02 CSS rated content heading level two length visited. 14:05 Using Schema.org with micro data adding level two length visited. 14:08 Accessible time out notifications adding level two length visited. 14:12 >> So that's just using a quick navigation short key. 14:16 In this case, the H key jumps you from one heading on the page to the next. 14:18 In most screen readers now, there are shortcut keys for jumping between tables, 14:22 images, links, headings, paragraphs, div's. 14:26 Pretty much any HTML element you can think of. 14:28 So it's no loner necessary to just start from the top and hope for the best. 14:31 You can actually move around within a page, but all this is very, 14:35 very dependent on the HTML being present and correct underneath, of course. 14:38 >> Slide 17, [INAUDIBLE]. 14:42 >> With HTML5, something even more interesting happened, and 14:44 that was the introduction of the sectioning elements like Main, Article, 14:47 Header, Footer, Aside, and Nav. 14:51 They add even more semantic information to the page that screen readers can 14:54 make use of. 14:57 >> [SOUND] Main region. 14:58 Accessibility support for CSS generated content article. 15:01 Using Schema.org with Microdata article. 15:05 Accessible timeout notifications article. 15:09 Navigation region. 15:11 Complimentary information. 15:12 Search region. 15:15 Navigation region. 15:16 Contend information. 15:19 >> So with those just HTML five elements, just pure HTML, 15:21 there's nothing exciting under the hood there at all. 15:24 The screen reader is able to use another shortcut key 15:27 to make navigation between each of those elements possible. 15:29 But it could also tell you now which part of the page you're looking at. 15:32 Whether it's related to search or navigation, complementary, 15:35 which is what maps to the aside element, or other bits of page. 15:39 So suddenly, a screen reader user has gone from having to read from top to bottom, 15:42 to now actually being able to get a pretty good overview 15:46 of the page as a whole to kind of holistic idea of all the chunks on the page, 15:49 which until HTML 5 came along, was pretty much impossible. 15:53 So things are definitely kind of improving as technology moves on. 15:57 >> Slide 18, Modus Operandi. 16:01 >> One thing thing to be aware of is if you're using all these shortcut keys as 16:03 a screen reader, like H to move from heading, P to paragraph, 16:06 or whatever they might be in each screen reader, there are times when you're going 16:09 to actually need to use those letters for the things that they're intended to do. 16:12 >> Tab. Search edit. 16:16 S-O-M-E-T-H-I-N-G. 16:18 Tab. Search button. 16:21 >> So that popping noise just indicates that, in this case, 16:22 the screen reader, it's Jule if you're curious, has switch modes. 16:25 So instead of intercepting the keystrokes and using them for quick navigation around 16:28 the page, it's actually passing the keystroke back through to the browser so 16:32 they can just type into the form field, 16:36 as you'd pretty much expect them to under any normal circumstances. 16:38 >> Slide 19, accessibility mechanics. 16:42 >> So how does all of this work? 16:44 Well there's quite a lot of mechanics that goes on in the hood of the browser. 16:45 Something that you'll almost certainly know is that when you load content 16:48 into the browser, the browser will create a document object model. 16:52 Dom Tree, it's a hierarchical representation of the content that 16:55 contains a whole bunch of information that you can interact with, 16:59 manipulate, do all sorts of things to. 17:02 >> Slide 20. 17:04 >> What you might not know is that the browser also creates 17:05 an accessibility tree. 17:08 It takes a whole bunch of information from the DOM, and 17:09 creates an alternate hierarchical model. 17:12 And this model, 17:14 this tree contains information that's used specifically by assistive technologies. 17:15 And there's all kinds of information in there. 17:20 >> [INAUDIBLE] Role, role. 17:22 >> There's information about the role of each element on the page. 17:23 All HTML elements have implicit roles. 17:26 So onscreen, we've just got a check box, and input with a type="checkbox". 17:29 >> Bullet label equals. 17:33 >> And that type="checkbox" tells the browser that this is 17:35 an input with type checkbox. 17:39 That information is picked up in the accessibility tree and 17:40 used by assistive technologies, so 17:44 a screen reader encountering the control created with this code would tell the user 17:45 that this was a checkbox, and that's the role of it and its purpose if you like. 17:50 >> Slide 23, 23. >> You also get information about 17:55 the state, in this case we've got checked attribute on input. 17:57 And again, that state information is picked up by the accessibility tree, and 18:02 made available to assistive technologies. 18:05 So the screen reader would not only know that this was a check box, but 18:07 it would also know that it was in the checked state. 18:10 >> Slide 24 >> Lastly, 18:12 the information in the accessibility tree contains a whole bunch 18:15 of accessibility properties about an element. 18:17 The most common of them is the accessible name for an element. 18:19 Which is basically the way that you tell, 18:23 in this case one check box on the page from the next. 18:26 >> [INAUDIBLE]. 18:29 >> [NOISE] We've done it in this case by just using the label element and 18:30 hooking it up to the input using the foreign ID attribute pairing. 18:33 Really, really basic 101 HTML. 18:36 But now, a screen reader coming to this page will know that the name of this check 18:39 box is Tequila, as opposed to any other that might be on the page. 18:43 Speech recognition user for now could say, uncheck the tequilla check box. 18:47 Just identifying it by name, in a way that you identify a person by a name. 18:52 >> Slide 25, Accessibility APIS. 18:56 >> So all these works thru Accessibility APIS. 18:58 Form has one. 19:01 Windows, Linux, OSX, IOS, Android. 19:02 They all work at the operating system level. 19:06 So the idea is that if an assisted technology wants to know 19:08 something about an interface, it gets the same information back whether it's asking 19:11 something at the operating system level, something within an application interface, 19:15 or something within the rendered content within a browser. 19:19 >> Slide 26, Design like Brunel. 19:23 >> So, how does all this work in practice? 19:25 We're going to take a bit of dive into some code now and pull some of this 19:27 together to give you a working example of how the accessibility API is, 19:30 the accessibility tree all come together to makes things more accessible for 19:34 screen readers, in this case. 19:38 >> Slide 27, Skeleton HTML. 19:39 HTML. >> So 19:40 we're gonna start by building a custom disclosure widget. 19:41 Yes, it's always better to use a native HTML element because you get a lot 19:44 of accessibility goodness built in, but, with the advent of JS frameworks, 19:48 where unfortunately the output code is not always created by people who understand 19:52 good quality semantic HTML, because we get stuck where we need to remediate legacy 19:57 code that was built in goodness knows when We're just gonna take a worst case 20:01 scenario, and that's starting with a span that we're gonna use as the control for 20:05 disclosure element or widget, and 20:10 a div that's gonna contain the content to be disclosed. 20:12 >> Slide 28. 20:16 Using a mouse. >> If we imagine we just throw a bit of 20:16 CSS and scripting at it, this is how it would pretty much work for a mouse user. 20:18 >> Using a mouse. 20:23 So, all well and good. 20:32 Things open, they shut. 20:33 Content appears. 20:34 It's all pretty good. 20:35 Slide 29. 20:37 Using a keyboard. >> If you looked at it on a keyboard, 20:37 this is what would happen. 20:39 That's it. 20:43 Nothing. 20:43 Absolutely nada. 20:44 A span is not an interactive element, so you can't focus on it with a keyboard. 20:45 You can't use the tab key to get to that control. 20:49 So, for a keyboard only user, that's it. 20:51 Game over. 20:53 Bother shouting. 20:54 If you throw a screen reader into the mix, it is actually possible to focus on 20:55 that control because there are ways to do that without using the tab key, 20:59 but this is the net effect. 21:02 >> That's it. 21:04 Just the one word. 21:06 There's no indication that this is actually a button, or 21:07 anything more exciting or interactive than a piece of text. 21:09 And that's because div and span, or 21:13 span specifically, isn't semantically neutral element. 21:15 So, in the accessibility tree, it's really just treated as a piece of plain text. 21:18 So, we need to start adding some more information into the browser's 21:22 accessibility tree to give screen readers something a bit more concrete 21:25 to deal with. 21:28 >> Slide 30. 21:29 Add role. 21:30 >> And we're going to do that using some Aria attributes. 21:31 Accessible rich internet applications. 21:34 Version one is the current version with respect from the W3C. 21:36 So sets of attributes that you can apply to HTML markup and, increasingly, 21:39 to SVG, as well, that lets you manipulate, or 21:44 change the information that's available in the browser's accessibility tree. 21:47 Aria doesn't change functionality, 21:51 doesn't add behavior, it just changes the semantics of what we're dealing with. 21:53 So, the first thing we're going to do is use the Aria role attribute 21:57 with a value of button. 22:00 And that gets applied to the spam and will basically, in the accessibility tree, 22:02 tell assisted technologies, quit treating this like a spam, treat it like a button. 22:06 It's really important to stress though, this doesn't change anything in the Dom. 22:10 It's only in the accessibility tree that stuff changes. 22:13 Slide 31, add to index, full printer. 22:16 >> We're gonna add tab index with a value of zero. 22:18 >> Bullets bullet. 22:20 >> And we're gonna do that on the span as well. 22:20 That's gonna make it keyboard focusable. 22:22 Tab index with a value of zero will place this into the tab order of the page 22:24 based on the elements location in the dom so it keeps it really natural. 22:28 It'll just slot it into the natural keyboard order of the page so 22:32 it's a good way to do it. 22:35 >> Slide 32, add focus impulse, play button. 22:36 >> We're then going to add some focus visuals. 22:38 So now you can focus on it with a keyboard. 22:40 It's really important to know that you focused on it with a keyboard. 22:41 So we're just gonna duplicate the hover styles that were in place already and 22:44 just make those work so that when you tab onto that control you get that same 22:48 visual change in appearance that lets you know exactly where your focus lies. 22:52 >> Slide 33. Add event listeners. 22:57 Listeners. 22:58 >> We're gonna add in some event listeners, so 22:59 there's a good chance already that the event listener for click is in place, but 23:00 we also need to listen out for keyboard events. 23:05 We're gonna listen for the key down event as opposed to key press or 23:08 any other because the expected interaction for a keyboard user and 23:11 a button is that you can use either the space key or the enter key to activate it. 23:15 If you're using the button element, the native button element, 23:19 that's what you get built-in by the browser automatically. 23:22 So we're gonna listen for the key down because we need to capture the key code, 23:25 so we can identify which key's been pressed and add in some functionality. 23:28 And all we're doing here is just listening out for those keys. 23:33 If any other key is pressed, we're just letting them get on to do their thing. 23:35 But if either of the key codes, 32 or 13, 23:39 are identified, then we're just gonna make sure that the rest of the function 23:42 that we need to execute is carried out based on those key commands. 23:46 Slide 35. Add Aria-Expanded Expanded. 23:50 >> We're gonna come back to some Aria now and add in the Aria-Expanded attribute. 23:52 Again, that goes on the span. 23:57 [SOUND] >> Bullets bullet. 23:58 >> And what this does is indicate the state of the disclosure widget. 24:00 So we'll set it to false initially on the assumption that the disclosure widget 24:03 is closed. 24:07 But as the widget is activated, the script will toggle it to be true and that'll just 24:08 inform the screen reader whether the thing is open or closed in its current state. 24:13 Slide 36. Add state visuals. 24:17 Visuals. >> Then we're going to map some visuals to 24:19 that as well because if we're going to make custom faces accessible to everybody. 24:21 It's not just about us screen reader users, 24:25 we need to think about you sighted guys too. 24:27 So, we're going to add in an icon that just flips over depending on the state and 24:29 we're gonna bind that to the current value of the area expanded attribute. 24:33 Using attribute select is a really neat way to keep things neat and tidy. 24:39 Stops you having to clutter up stuff with class names in your HTML. 24:43 Actually, I have to thank Hayden Pickering, one of the other speakers here 24:47 this week for that particular tip, which I've become extremely fond of. 24:50 >> Slide 37. Add Aria-Controls. 24:54 Bullets equals quotes. 24:55 >> We're gonna add in some more Aria, the Aria-Controls property, and we're gonna 24:55 use this to create a relationship between the control button and the content. 24:59 Bullet id Mismatch >> When you look at this and 25:04 you activate the widget, you're gonna know that something has appeared. 25:07 It's gonna be really obvious. 25:10 But if you're using a screen reader and 25:11 you hit the button, it's not gonna be obvious that some content has appeared. 25:12 What the Aria-Controls attribute does is create a relationship that will tell 25:16 the screen reader to inform the user that they can move, take a shortcut, 25:20 to the content that's being controlled by the button. 25:24 So, it just sets up that relationship and enables a navigation mechanism for 25:27 moving to it. 25:31 >> Slide thirty-eight. 25:31 Add Aria hidden. Bullets list. 25:32 >> We're going to add in Aria-hidden and 25:34 we're going to do that in a couple of places. 25:35 We're going to add into the span where the icon is shown and 25:38 also to the div where the content is. 25:41 [SOUND] >> Bullet divides bullet. 25:44 >> What Aria-Hidden does is remove content completely from the accessibility tree. 25:45 So as far as the browser's accessibility tree and 25:50 any assistive technology is concerned this content won't exist. 25:52 So we'll set hidden to true on the icon span because there's no real need for 25:56 a screen-reader user ever to need to know about that icon. 26:00 We'll also set it on the div. 26:04 We'll set it to true initially because the content will be hidden. 26:05 And then as the widget is activated, we'll toggle it backwards and 26:09 forwards between true and false. 26:12 Slide 39. 26:14 Add more state visuals. 26:14 Bulletin=quote. 26:15 >> We're then going to add some more visuals in there and 26:16 that's just making sure that the content is shown in high based on the CSS. 26:19 You might be asking why user are hidden and something like display none. 26:24 It's really belt and braces techniques. 26:29 If we don't need the content to be rendered in the accessibility tree. 26:31 There's really no point in making it be there. 26:34 So, Aria hidden just kind of takes that out of the equation. 26:36 There's also kind of an edge case where someone might not have CSS enabled. 26:39 It's fairly slim edge case these days, but 26:43 the RA hidden would still just make sure that the content was 26:46 tucked away from assistive technology users, even if that was the case. 26:49 Slide 40. Add functionality. 26:52 Function title disclosure. 26:53 >> Lastly, we're just going to add in some functionality, so 26:54 we're going to make sure that the whole thing works. 26:56 So if someone activates the button and the script is executed, 26:58 we're just going to toggle the states of all those Aria attributes, 27:01 the Aria hidden and the Aria expanded. 27:04 And in doing so kind of kick off the cascade that ties in the CSS to create 27:07 the the right visuals, and hopefully bring the whole thing together. 27:10 >> Slide 41. Using the screen reader. 27:13 >> So, [LAUGH] after all that little lot, 27:14 this is the difference that it makes to someone using a screen reader. 27:16 >> Using the screen. 27:20 To feel the button collapsed. 27:21 To feel the button expanded use Jaws 27:22 key/g+Alt+M to move the controlled element. 27:25 Move the controlled element. 27:28 Makes me happy... 27:29 [LAUGH] Trust me. 27:30 Tequila does make me happy. 27:33 But [LAUGH] what should hopefully make us even more happy 27:34 is that we've still got the disclosure widget that, on the face of it, looks and 27:37 behaves and appears exactly as we originally intended it to but 27:41 now has a whole bunch of accessibility built in under the hood 27:46 to make the experience more inclusive for many more different people. 27:49 And that sort of really comes back to this whole idea about designing 27:53 like we give a damn. 27:56 Go out there, build the thing you want to build, create the thing you want to 27:57 create, be as inavertative and outlandish and mad and crazy as you can possibly be. 28:00 But know that there are ways that you can make things accessible. 28:06 If you're not sure where to go from here, as they say, come and shout me afterwards. 28:10 Questions now, or ping me on Twitter, but myself and 28:13 plenty of other people out there in the accessibility world are really happy 28:15 to help answer you and point you in the right direction. 28:18 Slide 42. [INAUDIBLE] 28:21 >> Thank you. 28:22 >> [APPLAUSE] [MUSIC] 28:27