 Good afternoon. Welcome to my presentation. My name is Sarah Police. I go on to the Twitter handle SarahTK. And if anyone's tweeting today, you might like to add the hashtag for accessibility, which is A11Y. Everyone takes it for 2Ls, but what they've actually done is they've taken 11 letters out between the A and the Y, and that's how we get A11Y or ALI as we refer to it verbally. Today, I'd like to talk to you about creating dynamic and accessible web content in Drupal 7 using a W3C standard called WayArea. So, a little bit about me. I'm currently the Web Accessibility Evangelist queue for AccessIQ. In essence, I just get out there and I talk about accessibility. Back in 2002, I can still remember what my I guess the blinding moment for me, understanding accessibility was when I was at the Australian Accessibility Conference, the Aussie Way conference, and someone brought up an image map in a browser, turned off images, and there was absolutely no way for someone who was, for instance, blind or visually impaired to actually navigate past the home page because all of that information was inaccessible. I still remember today the feeling of sitting there. It was the aha moment for me. Throughout 2002 to 2010, I've done a variety of things. I've got a techie background, but I'm not a dev and I'm not a Drupal developer. I am a Drupal user. AccessIQ that I mentioned I worked for runs on a Drupal 7 site and is accessible as does Media Access Australia, which is our parent company, and we've got a few other Drupal sites hanging around. So, I'm fairly good at using Drupal, but I've never had to actually do any coding in Drupal. So, I've done a range of things. I've got the techie background, I've got a marketing background, and in 2010 I came to work for Media Access Australia, and then when they set up AccessIQ which is a social enterprise aimed at actually helping government, non-government, devs, anyone who wants to make accessible content, we're there to assist through training and services and content, and I became full-time for AccessIQ and go around talking about accessibility and doing training and generally being a jack of all trades pretty much. So, I wanted to ask how many people have heard any of the following statements? People who use screen readers, and just in case anyone in the audience doesn't know what a screen reader is for someone who is blind or vision impaired and has trouble seeing the screen, there's a piece of assistive technology called a screen reader, and essentially a screen reader uses text-to-speech technology to actually read out what's on the screen. Usually that's delivered in an audible fashion through your speakers, sound, so on and so forth, but it can also be converted into braille, and so for people who are braille users, they have what's called a refreshable braille display, and it has a whole lot of pins, which the braille language is actually made of little sets of six pins, and depending on the orientation they're in is what letter it is, so that information can also be communicated through a braille device. Today you'll see a number of examples of screen readers, one live one, because I promised myself I wasn't doing live demonstrations, and then they showed the Australian War website and I thought, oh, that would be cool to demonstrate, and here I am doing live demonstrations again, but there's also going to be, there's four videos today that I'm going to play. Unfortunately this projector is 800x600, really not up to the task, the videos are quite grainy. I will explain what's happening, and by and large it is a screen reader reading out information, so you will definitely hear it, but all of the videos are up on YouTube as are my slides on slideshare, so all of the links and that are all in slideshare, so don't worry about jotting them down or anything like that. So back to what I was asking, who's heard the myth that people who use screen readers just turn off JavaScript, so you can't use JavaScript if you're building an accessible website. A few people, maybe about five or six, that's really good usually, maybe because you're all here and you're all interested in accessibility you're a little bit smarter than that, but that's one of the myths that's often sort of passed around. The second one is that you can't have dynamic content on an accessible website, which has anyone heard that one? Heard it but wouldn't believe it, lovely. And the last one accessible websites are boring. I've got a good audience, this is really good. Well these are the three myths that often we hear and often we have to debunk, and today talking about ARIA I guess addresses these three myths. First off that people are not turning JavaScript off anymore because there are ways to actually make JavaScript or Ajax content accessible and by that there's also ways to make dynamic content accessible and so we're getting away from that whole concept of an accessible website has to be boring, I can't do all of those neat funky things that I want to do. So I mentioned way ARIA so ARIA stands for accessible rich internet applications and it's a standard that's published by the W3C Web Accessibility Initiative. The Web Accessibility Initiative are the guys who also publish a lot of the other accessibility standards WCAG2 or the Web Content Accessibility Guidelines which I'll probably talk and touch on today is often the main one we look at. If anyone here is working on government websites you probably would have found that they're asking for accessible websites that conform with WCAG2 and this is because in June of 2010 the Agamo the Australian Government Information Management Organization released the National Transition Strategy otherwise known as the NTS and the NTS essentially outlined that all government, all federal, state and territory websites needed to be level A compliant which is the first level accessibility by the end of 2010 so we've been and gone past that deadline and they must be double A compliant by the end of 2014 so this has done a huge amount for accessibility, it's brought accessibility back on the radar and obviously the demand for people who can create accessible websites and web content has definitely gone up. So the problem we really grapple with with dynamic content comes down to the information that is communicated from the user agents so the web browser through to the assistive technology in essence when you've got static content that doesn't be driven by a scripting language there's a contract between these two items and so elements like roles and states actually are communicated through to the assistive technology so for instance if a screen reader hits a link it looks at that link, it knows it has an AHRF reference and so it actually says to the user that this is a link and then it will actually announce the link text and all of that information that the fact that it is a link or that it is a button is communicated from the UI or user agent through to the assistive technology but when we've got javascript actually driving that UI component and actually changing elements within the DOM on the fly what happens is if we don't use a technology like ARIA that information the changes in roles states and actions, values, changes in relations doesn't actually translate through to the assistive technology so a good example is some, let's say you've got a news site and in the corner you've got a little area that is actually dynamically updating so every minute that someone's on a website it actually asks for the latest headline and it updates automatically now for a screen reader user what I should say is they recognize that something has changed but for a screen reader user they don't actually know that something has changed on that website so they either don't know that that change has happened or if they happen to actually be reading that out at the time using their screen reader suddenly it changes from reading about yesterday's heatwave to an example, I've forgotten an example, what's a nice news headline to floods happening now so that's why we actually need to communicate this information to the screen reader so ARIA actually is all about HTML attributes is essentially an extension to HTML and the attributes actually are divided into two main groups the first group is we have way ARIA roles and within those roles we have four broad categories we have abstract roles so they're actually not used when we're creating a website but we do have widget roles we have document structure roles and we also have landmark roles the other elements we have are states and properties so these are to actually indicate to a screen reader when something actually changes so this includes widgets that are updating content or actually changing states due to a user interaction live regions so updating content that's just refreshing on a screen things like drag and drop elements, tree elements and also relationship attributes so these can be used certainly in all of your websites but they're definitely important for web applications where we're trying to simulate a lot of those things that we're used to in a desktop environment which currently are quite accessible when you say running under Windows or Mac but now we're moving into a web environment and we need to make sure that all of those interactive elements are also accessible so what we'll look at today first we'll look at page structure and in particular landmark roles we're then going to look at ARIA live regions for updating content using ARIA on forms and lastly using ARIA for widgets and at the end touching on Drupal and what you can find what ARIA elements you can find in Drupal currently I've tended to focus in this presentation more on the ARIA side of things rather than the Drupal side of things first off I'm not a Drupal expert but secondly you guys know how to patch modules and that kind of thing so it's more about communicating what ARIA can do so that you know and you can take that back into your workplace so you're probably familiar with skip links there's a success criteria it's probably the only success criteria I'm going to quote which is 2.1.4 and it's all about bypassing blocks of content and essentially it's that we have repeating blocks of content on a website you know our banner, our navigation elements now as we get familiar with the website we might not want to hear all of the information and the banner and all the information in the navigation for a screen reader they actually read information out linearly through the page from the top to the bottom and so they're forced to listen to all that information before they arrive at the actual main content area which is often the area that they're interested in and so because there was no way to actually mark up a page with semantic information we used skip links which is essentially just anchor links that usually are put at the top of a page and in this case on the NAB site they've got a skip to content link that when activated takes you down to the introducing the new way to trade so it was really a work around because there wasn't anything better in place what ARIA gives us, it actually gives us nine landmark roles that we can use to mark up our page structure. You'll see that some of them actually do overlap with HTML5 for instance we've got a role equals navigation and there's the nav item in HTML5. Currently screen readers support ARIA much more than they actually actually support HTML5 elements so if you are coding websites in HTML5 I'd still recommend you use the ARIA roles even if you are using the HTML5 nav element or so on and so forth. So to briefly go through the nine roles we've got an ARIA role which is Banner which is essentially the information that you've got on the top that usually consists of your logo and so on generally roles are assigned to divs and they can actually be nested there's the role equals search to actually mark out your search box. This is particularly important for people using screen readers because often they will use and rely on the search function even more than we do because it's an easy way for them to find if there's some information on the website or even the webpage so it's important to mark up that area we've got role equals navigation. Now this role can be used multiple times. The roles that only should be used once according to the spec are Banner, main and content info. So we can have multiple navigation items. Role equals main which is essentially your main content area and you can also have role equals form and role equals application having said that application is not very well supported by any assistive technology so I wouldn't actually recommend using it right now. There's also an area role equals complimentary which is for complimentary information so often you've got your right hand side elements that might be promotional elements or something like that. They could be assigned a role of complimentary having said that complimentary can be nested within main and we'll see an example in a minute of where that occurs. And our last one is content info and that essentially is the elements usually found in the footer. One thing to note is for the roles that can actually use multiple times within a web page it's really good to use another area element called attribute I should say called area label. So the example here is we've got two navigation areas. One which has an area label of main menu and another one which has an area label of sub menu. When a screen reader is actually skipping from landmark to landmark that area label will actually be read out so if there's three navigation areas on the page it will actually not only identify them as navigation it will also identify them by their label so that a user can actually differentiate whether they've hit the main menu navigation or sub menu navigation. So I'm going to go to the Government of Canada website. Later on in the presentation I've got two Drupal distributions that actually have been created to be accessible out of the box and one is the WET, the website experience toolkit and it actually has been designed by the Government of Canada and the Government of Canada website is based on this particular module. There with me I've got a few things open. So this is the first video as I said apologies for it being grainy. What I'm showing you here is that screen reader users can actually navigate landmark roles in two ways. One way is that they can actually bring up a dialogue box which is what we'll see here and it will actually allow them to navigate the landmark roles in a tree type structure. So you can see we've got some nested elements there we've got search which is nested under banner and we've got complementary and content info which is nested under main. Landmarks radio button checked out deep. Tree view navigation one of five. Banner expanded to of five. Level one search one of one. Level zero navigation three of five. Main expanded four of five. Level one complementary one of two. Content info of two of two level one. Level zero content info expanded five of five. Level one navigation one of two. Navigation to a two level one. File sub nine one of four. No go away you're too early. So that's just giving you an example of how a screen reader user may actually look at the overall navigation structure of a page using landmark roles. The next video which I'll queue up now is exactly the same page but instead I've actually gone through this page using a shortcut key. So the shortcut key D actually jumps from landmark to landmark. I should say that all of these demos are done using a screen reader called NVDA. It's free and open source so it fits in very well with this conference. You can download it and it's homegrown. It's actually developed by two blind developers up in Queensland. So if you're looking for a free screen reader to test on windows that's your guy. And if I can encourage you these guys are they lift off grants and or actually project funding to do this. So if you are using it and you can spare some money to give them a donation you can do that through their website I really would encourage it because it's the only free solution out there. By comparison you've got commercial solutions like JAWS which is the key solution for the windows environment. It costs about $1,500 to buy and then the upgrades are also close to $1,000. So I really want to support these guys and allow them to keep on doing what they're doing because they're just doing an amazing job. And they're the guys that are often doing things first. Navigation. Landmark. Government of Canada. Navigation bar. Heading. Level 2. Banner. Landmark. Government of Canada. Visited. Link. Search. Landmark. Search. Heading. Level 2. Navigation. Landmark. Site navigation bar. Where it says navigation landmark site navigation bar that's our ARIA label tag coming in and actually being read out and communicated via the screen reader. I mean landmark home heading. Level 1. Complimentary landmark supplemental content heading. Level 2. So that just gives you an idea of what a screen reader hears for landmarks and also how beneficial it is. I would still encourage you to include skip links within your template. The reason is that although screen readers are actually reading out landmark roles, you can't actually use and get to landmark roles using your web browser. And it is useful for people say who have screen magnifier users who actually magnify the screen rather than having it read out to them. They might find those skip links useful and at the moment because the web browsers don't actually support landmark roles and have shortcut keys to use them, I think it's still good to implement both solutions. So there's quite good support for landmark roles within assistive technologies. JAWS 11, 12 and 13 has complete support. Chrome Box which is a screen reader that works specifically with Chrome has complete support as well. VoiceOver which is the Mac screen reader which works on Mac OS X and also on iOS devices supports all landmarks except for forms and NVDA supports all landmarks except for applications and forms. Window Eyes doesn't support ARIA landmarks but thankfully there's only a small case of users still using Window Eyes. So the second topic is actually using ARIA Informs. As I said, I think ARIA landmarks and ARIA, the ARIA Elements Informs are two of the most easy things to be doing right now with very minimal effort and just working it into your coding practice. So there's a few attributes that can help. The first is ARIA Required. So this attribute actually is added to your input element and essentially means that the input element is a required form field. So this will be communicated again through the screen reader so that when a user tabs into a form field it will actually read out the label such as first name and it will also identify the form field as being required. Again, if you're using HTML5, do use both the HTML5 required and also the ARIA required. Another nice element is ARIA described by. So often there's information in this example. It's where it's got extra information about the characteristics of a password or what you need to, things you need to meet in order for your password to be valid. There's different ways that you can do that in Forms without ARIA. Usually at a minimum we suggest that it's at the very, very top of the form field. So as a person navigates nearly through a form they hear all of the information about restrictions up the top and then they navigate through the form field. But an even better way to do it with ARIA described by is actually to be able to associate the input field with that piece of text. So when the user again tabs into that input field it will actually read out not just the form label but it will also read out the information that is identified by ARIA described by. So in this case we've got a paragraph with an ID of password required that says your password must be eight characters in length and include one number and that's linked to the input field using ARIA described by with the value of password required. Another nice one, ARIA invalid. So this can be used in form validation. If there is a field that is invalid you can actually inject an ARIA invalid equals true into that form and so as a user moves through that form again when they hit that form field it will communicate that that form field is invalid. You could also use the ARIA described by also 2.2 an error message as well that informs the user of the error and also gives suggestions on how they might fix it. And the last two elements are ARIA label and ARIA labeled by. So the purpose of these elements are the same but you use ARIA labeled by if the label text is visible on the screen. If the label text isn't visible on the screen then you use ARIA label. Nice example of how this is used is this comes from a web aimed presentation. It's a little form that says self destruct this page in form field five seconds and they've used ARIA label sorry ARIA labeled by to actually associate with three elements. They're associated with the label element the time element and the seconds element. So it will actually read our self destruct this page in five seconds all as one block. Just checking the time because I have a horrible thing of going over time. ARIA live region so I mentioned ARIA live regions are fantastic for dynamic content like stock tickers or news items that are dynamically updating. What you can do is you can actually mark a particular region within a web page with an ARIA live attribute and there's three values that the ARIA live attribute can take. The first one is off and this just means that the updates are not announced to the user. The second one is polite and that means that when something updates those updates will only be announced to the user if the user is idle. So if they're not actually reading out anything on the screen and suddenly they stop accessing the page it will actually then read out that information. The last one is ARIA live equals assertive. So that's where for really important updates the updates are announced as soon as possible but they don't actually interrupt the user. So often users when they're reading a web page they'll use the arrow down key and it will read sort of chunks of text maybe about 10 to 15 words. So for instance if a user was using that method of reading a page when they got to the end of that particular chunk of text it would actually jump in and alert them to the fact that there was a change. There are also other attributes for live regions that actually communicate relevance. So there's an ARIA busy attribute which takes the values true or false and the assistive technology such as screen readers will only announce changes once ARIA busy equals false. So this actually allows you some control about when you actually communicate something to the user. There's ARIA atomic which also takes the values of true or false and it only reads out actual changes or the entire live region. So if you've marked up a live region but there's only certain text within that live region that's updating then you can actually ask it just to read out those updates or to read out the whole a lot of text again. The last one is ARIA relevant so the values are additions, removals or text so you can it actually reads out the changes to the live region depending on what your value is. So for the next demonstration we're actually going to go to the Yahoo 7 website. So unfortunately this is probably one of the ones that's going to be really hard to look at. This video is broken up into two pieces. The first piece is I've got Firebug open here down the bottom and we've got the Yahoo search on the top and I'll give you some context because it's really hard to look at but what I'm going to start to do is type in Drupal into Yahoo 7 and if you can see what would actually be happening is this text down here which reads live class and it's aria live equals polite role equals status and then it's got some text which at the moment is no suggestions and as I start to type letters in what you'll see is that that no suggestions actually will be dynamically updating with the number of suggestions in the drop down list that are there. The second part of the video is then what you hear with the screen reader so it will essentially be mimicking what you'd see in Firefox but you can have a look at it on YouTube a little bit later as well. So we're still at 10 suggestions and now we've hit 5 suggestions 2 suggestions and 1 suggestion Search Query combo box collapsed has auto complete editable blank. D expanded R 10 suggestions U 10 suggestions P 10 suggestions A 10 suggestions space T C 5 suggestions O 2 suggestions M 1 suggestions Drupal commerce Drupal commerce Yahoo 7. So that's actually using a combination of aria live regions and also some other aria attributes to insert that so that the user actually knows that there are suggestions coming up underneath that text box and I find this particularly important. I remember going to the Woolworth site and on the Woolworth form it asked me and I was actually testing this for accessibility. It asked me to sign up but it actually has to verify your address against a central database and it had the suggestions popping up in that same way as suggestions underneath and that was not communicated to the screen reader at all and so unless you actually typed in your address exactly right there was no way to know that if you just pressed the down arrow you would actually get a number of options and you'd be able to select that option which was being sourced by the database which would then have a much better chance of actually being correct so this is I find really important for forms such as that as well. So the last topic is aria for widgets now aria for widgets is a huge area that you could come across and at the end of this presentation I've got a number of references including this code from accessible jQuery UI components demonstration which is on github which I do encourage you to go and have a look at because it's got some really nice examples of what you can do with code examples and if I actually no I haven't got it open. I'll just click through because it's a really nice library so it actually has examples for sliders, progress bars, menu bars buttons, dialogs, checkboxes, accordions, trees, carousels, tabs, tooltips, auto, complete and date picker and if you become familiar with a screen reader you can run the screen reader over the examples which come under here and actually see what's happening and actually have a look at the code. So in my usual way as I said I wasn't going to do live demonstrations and then they this morning we talked about the Australian law reform commission and I thought look at that menu I wonder whether that menu is accessible or not so I'd like to run the screen reader over it. It is accessible but I would actually like you to think when you see how NVDA runs over it is it actually usable for our user who's navigating through a menu. Just ignore me while I get to the bit I'm looking for. Okay so we're just about to tab into the main menu. At this point I think if you weren't interested in anything to do with about and you could have determined that from hitting about the first time you've spent a whole lot of time listening to 13 extra items that you didn't really need to. Now look I'm all for practical solutions and I'm all for things being as accessible as they can but the next demonstration will actually show how you can use ARIA to actually be able to navigate and expand menu items and not have to make it into that very very long list type structure where essentially a screen reader has to listen to all of the list items and all of the sub menu items before they actually get through to the end. The menu bar from the GitHub example I just showed you the screen reader is going to be navigating through the menu which is file, edit, view and more options. View sub menu 3 or 4. More options sub menu 4 or 4. File sub menu 1 or 4. So there's instructions up the top but all I was doing there is actually using the cross arrow to navigate through each of those menu items. I could also use the tab key at least to get from those items. And once I hit file I can use the down arrow to actually expand out that sub menu. Open 1 of 6. Save 2 of 6. Save has 3 of 6. Recent documents sub menu 4 of 6. Close 5 of 6. Quit 6 of 6. Copy 1 of 4. Full screen 1 of 3. So because I'm in the sub menu I can actually just move across into the next sub menu as well which is what I'm doing there. File sub menu 1 of 4. Open 1 of 6. File sub menu 1 of 4. Edit sub menu 2 of 4. So again that's another way of interacting with the menu where I went into file, I got into the sub menu. The beep you heard was me pressing escape which brought me back up to the level 1 menu item and then I could navigate across. A completely keyboard operable menu item by someone so it's not... We tend to focus with ARIA on people who are blind and vision impaired using screen readers because obviously it's the communication with the screen reader. But in this case this is also for people with a physical impairment where they might only be able to use the keyboard or even to use what's called a switch device where they have one or two or three main switches that actually replace the more complex keyboard because they don't have the fine motor control that actually allows them to use the keyboard. So I'm not going to go into all of the code, you can have a look at that on the jQuery website. So lastly looking at Drupal with way ARIA. So I'll be completely upfront and say that this might not cover everything that's in Drupal 7 and also coming in Drupal 8. However I do know there are a number of Drupal 7 themes with way ARIA. Boron, Genesis, Panels, 9, 60 GF they all have ARIA landmarks already as part of them. Some ways that you can also get more information or become involved with the Drupal accessibility community. So there's the accessibility Drupal group which is spearheaded by Mike Gifford. He does fantastic work. He has contacted a lot of us actually just in the last week or so to say hey guys look if you've made any updates to Drupal core from Drupal 7 please let us know because we want to incorporate that into Drupal 8. So the Drupal 8 becomes even more accessible out of the box. So if any of you are working on accessible websites and haven't submitted any of those patches back up I would suggest that you do so. He's also put together a list of Drupal sites in the disability sector and I guess being in the disability sector they tend to be accessible. So if you are looking at Drupal sites that have been built and more than likely accessible then I'd suggest having a look at that list. As I mentioned before there's actually two Drupal distributions that have focused on accessibility. The first one is the Web I think it actually should be Web WET. Anyway WET which as I said was done by the government of Canada up and can be downloaded. The other one which was recently released at the end of last year by previous next was AGov. So AGov has been packaged so that it is accessible out of the box. It has Drupal core plus a number of modules that government may need to install their websites. It's also got accessible themes that fit the branding. Previous next actually worked with Agamo on the branding so I think from memory there are six themes to go with AGov and again that can be downloaded and set up as well. So a few things with ARIA validation. ARIA attributes don't validate in HTML4 so if you're using any of the standard validators it's going to spit up errors. It doesn't actually mean that it isn't conformant and you sort of have to ignore the, there's a success criteria about conformance in the Web Content Accessibility Guidelines so you kind of just ignore that one with an understanding that you've done rigorous testing to test that your ARIA attributes are actually working as expected. You can use the HTML5 dock type with ARIA markup and then you can validate it using the W3CNU markup validation service. Last time I checked they didn't sort of say it was completely stable but at least it won't actually throw up all of the errors if you are using ARIA attributes. So a few takeaways. Dynamic content no longer has to be inaccessible to assistive technologies and it's really nice to see an audience who I seem to be preaching to the choir in the sense that you already know and believe that. You can start using ARIA now if you're not already and there are easy wins like the landmark roles and the forms that you can form attributes that you can use now that are really easy to do. And the one thing I always think is it's kind of fun. We live for a challenge development is all about challenges. It's all about finding solutions to things and accessibility is no different. It is as much of a challenge and as creative as a lot of the other endeavours you do when you're solving an issue. It's just a different type of issue. The obligatory slide of don't forget to fill out the session evaluations. So my session creating dynamic and accessible content in Drupal 7 using way ARIA. I've got a bitly link there which is actually you can have a look at it at slide share. I'm not going to read that out. And just a reminder. So the slides are on slide share with all of the links through to the elements that I've referenced today. The videos are on YouTube and when you visit the slide share you'll get the pages of the ARIA documents. So they're the specs. Some ARIA resources that I think are useful particularly if you're getting started. And even more ARIA resources. These are more library based ones. So the accessible jQuery UI that we saw demonstrated before. Accessibility code library. Yahoo has a fantastic accessibility blog. They expose all of the things that they're doing. They shove all of their code into the code library that you can go and have a look at. So it's a great resource to go and look at what you can do with ARIA and learn from what they've done. And also the Mozilla developer network ARIA. It's great and it also has quite a lot of links out to other content. Great blog where someone rounded up a lot of the screen captures of people using ARIA in different situations and so on and so forth. So all of those are available on the slides. And I'm done. And I'm on time I think. Questions. And please feel free. They don't necessarily have to be ARIA related if they're more broader web accessibility. Happy to take questions about that. Yes. So the technical spec is the one you want to have a look at. The authoring practices is also a good one. The technical spec is the normative document. The authoring practices sort of look at how you put that into practice and what have you. The prime is a good introduction. Sort of an overview of the issues and what way ARIA does and so on. So they form the suite of documents. The menus were accessible. Yes sort of. I guess yes I wouldn't be surprised if it's an AGUV website. I didn't know this morning and I think it's using SuperFish from I can't remember how I've looked at that but I thought oh I think it's using SuperFish. I guess it comes down to accessibility versus usability. Often we get quite caught up in is it WCAG 2 compliant. Does it meet the success criteria. And that menu definitely meets the success criteria. It's keyboard accessible. It's reading out all of the labels for the menu items and that which is why I say yes it's successful. And it even had shortcut keys which you could hear the screen reader announcing so that if you were revisiting the site you could use the shortcut keys to get the menu. By comparison though I guess with a menu of 13 items and thankfully that one that was the longest menu in the set. The others weren't nearly as long or didn't have any sub menus. But from a usability perspective if you're going through we visually sort of look at the top level and say oh what information am I looking for that's the element I want. Let me expand that and look at that. The way this is put together that doesn't give the user that option because it's actually listing them as a nested list. So it does come back to I think what I call user experience in getting away from the checklist mentality of it is WCAG 2 compliant. It is compliant out of the box. Yeah that's right. And look there's always arguments also for backwards compatibility and graceful to get... Thank you. I knew someone would help me out. From an assistive technology perspective. So I don't have all of the stats but you probably would need to look at which of the ARIA attributes were supported in assistive technologies. You get into this bind because it's not a problem for NVDA because NVDA is free and every time someone pushes out an update you get it. Same with voiceover and even orca on Linux. You get those updates just in part and parcel. But for your users and in the commercial as a commercial product it is the... it has a huge base. It's often cost prohibitive for people to be upgrading their technology. So it's always a little bit of a juggling act about when do you make it accessible using newer technologies and when don't you. And I don't have a good answer. It's like do you support IE6 or not. It's sort of that question. Any further questions? Wonderful. Well thank you all very much for coming. Please feel free to grab me if you had a question you didn't want to ask me. I look forward to meeting you again. Thank you.