All right, so I guess I will start. My name is Everett Zufelt. Oh, hello. All right, my name is Everett Zufelt. I'm a Drupal core accessibility maintainer. I'm an invited expert to the HTML working group at the W3C and I'm also an accessibility lead and tech lead at my planet digital in Toronto. We're going on the slides. Great. Wonderful, thanks. So what do those three things mean? I guess is where I want to start. As the accessibility maintainer for Drupal core, I monitor the issue queue for issues, the Drupal core issue queue, not so much contributed projects, for issues that are tagged either accessibility, meaning that the issue is related directly to accessibility or needs accessibility review, meaning maybe somebody's thinking about changing the UI or introducing a new UI component and they'd like a little bit of help understanding of the changes that they're making are going to be accessible or create any accessibility regressions in the product. I haven't done much work with the HTML working group recently, but when I was more active in the working group, what I was doing is reviewing the HTML5 specification. This is the W3C version, not the WG version, to make sure that there's nothing in the specification that would cause problems with accessibility and to make sure that the specification has everything that we need to ensure a richly accessible experience for the new web. And then at my planet digital, I give some organizational oversight to accessibility as long as some technical guidance or assistance on one of the Scrum development teams. I don't have the elevator pitch for my planet digital memorized. It's a user experience company that builds websites primarily using Drupal, but also using a number of other technologies depending on client's needs. So what I want to talk about today, I've done some accessibility presentations in the past at different Drupal related events and normally it's introduction to accessibility or sometimes advanced accessibility, how to look at the guidelines to understand guidelines, some of the automated tools that you can use to assess your site. That's not what we're going to talk about today. Though if somebody's interested in having that discussion, we can set up a BOF maybe tomorrow and we can have that discussion as a group. What we're going to talk about today is how to ensure that custom user interface components are accessible to people with disabilities. And so this is kind of the subtitle of my presentation, I think, is a span is not a slider and a div is not a button. And that's kind of from the technical perspective. There's a human perspective about user interface accessibility in the same way that there's a user perspective about usability and we'll touch on those concepts as well. But really looking at the why ARIA recommendation from the W3C and how it can help web authors design components and design user interfaces that work for the broadest possible range of users. And then why ARIA, just to break that down, that stands for the Web Accessibility Initiative, that's the Y part, that's an initiative of the W3C. ARIA stands for Accessible Rich Internet Applications. So we have lots of reas out there in the world, Google Docs, Yahoo Mail, all sorts of rich internet applications. We want to make sure that they are accessible to all users. I just want to touch base. Morton did a presentation on theming earlier, which was excellent. I wanted to touch base because this came up in my mind while he was talking. He was talking that there are developers who build stuff and there's designers who create stuff and in the middle there are themers that have to try to marry those two things together. A lot of talk about accessibility, and this is all semantics, but I guess that's what the web is, comes down to really the paradigm of an accessibility enhancement. How can we make this broken thing accessible? And when we're talking about enhancing a UI, it oftentimes falls to the theme layer to bring those enhancements to the user. We need to stop doing that in Drupal, and what we need to do is talk about having real semantics on the back end coupled with the data that can represent what that data is on the theme layer. If it's a list, if it's a toolbar, if it's a slider, we need the semantics on the back end that represents that, and then we can allow the themers to marry the design with those semantics to give the visual presentation and the interaction that design informs.  That was kind of my initial blurb and I've got more slides and lots of content and some fresh content that I came up with today because I did a really, really fast inaccurate review of some of the Spark stuff that was being presented and discussed throughout the day yesterday. But I want this to be an interactive session. Please interrupt me.  That's not going to work. For anybody who's not aware, I always forget this part. I'm completely blind, so the putting up your hand part, that doesn't work at all. If you yell out and interrupt me, if there's something that you'd like me to clarify or stop, I know all of this information and you don't. If I skip over a point and you're like, I still don't get that, interrupt me, and we'll spend a little bit more time making sure that everybody is up to speed and that everybody understands what I'm talking about. What is a user interface component? The user interface component is a piece, kind of an encapsulated piece of user interface. These are the building blocks. These are the things that you would maybe find in a toolkit like YUI, JQuery, Dojo. These are the pieces that you can put together to build a user interface. We're talking buttons, spinners, sliders, progress bars. These are user interface components. Most, well, we won't say most. There is really a single common markup language for the web and that's HTML. There's HTML4 or XHTML and then there's HTML5. There is not a lot of semantic good components in HTML4. There's a button and a select box and a check box, radio button. You could probably name them on less than two hands. There are not a lot of components in HTML4. What we've done as web developers, when we get a design handed to us or when we get a user flow handed to us that has a progress bar and a slider and a tabbed interface and a tree grid and all these things, is we fake it. We fake it with some meaningless divs and spans that have no semantics. We fake it with CSS to make it look the way it's supposed to look and JavaScript to bring the behavior in behind the scenes. But those things that we're building and integrating into our applications, those user interface components, they don't actually exist. They really don't. We're pretending that they exist by building them the way that we do. What common components aren't available? I discussed some of them. In HTML5 that changes and now browser support may vary, but in HTML5 that changes. We now have some new rich semantic elements. I'm not going to go through them all, but we have things like a menu now. We have things, well, we have menu items. We have toolbars. We have more semantic elements. We actually have in HTML5 in the spec, though I suspect there's been zero implementation of this at all. We actually have a dialogue element now in the spec, which allows content authors, really web application designers, to use a dialogue, a modal dialogue, some of those light boxes that pops up over the screen and trust that user agents are going to perform some of the heavy lifting, some of the functionality, and probably some light default theming for that. Now, that being said, a lot of these exciting new pieces don't work yet. They haven't been implemented. Some of the ones that haven't been implemented or that have inconsistent implementation do have some polyfill support by different libraries, but we're really talking about the future. We're not talking about all of these things or not things that we can achieve today with native semantics from the markup language that we're using. So that's a background. That's an understanding of what we have. We have some components that existed in HTML4 that work everywhere. We have some components that exist in HTML5 that work a little bit in some places and not at all in others. And then for the rest of the things that we need to do, which is most of what we need to do daily, we fake it by building these non-semantic JS, CSS user experiences that don't actually map to any native semantics. So why is that a problem?  We need to understand how assistive technology and for the purposes of this discussion, we're really going to focus on three personas, but there are many, many more, but in order to keep it simple, we're going to focus on the person who has no apparent disability. Somebody who can see the screen, use a keyboard, use a mouse, they're fine. Then there's going to be the keyboard-only user. This is somebody who has really no limitation except they can't really use a pointing device, or they choose not to, or they're on a device that doesn't have a pointing device, and so they have to interact with your content, with your site, using only the keyboard. Then we're going to talk about a third group of users which are screen reader users, like myself. These are users who use the keyboard, don't generally use a pointing device, though most screen readers have a horrible, clunky system of faking using a pointing device when you absolutely need to, and screen-reduced users who... There is a technological barrier between a screen reader user and your content, and that barrier is the screen reader. So when I'm on a web page, if I start typing, if I start pressing keys, those keystrokes are not going to the browser. They're not going to Chrome, and they're not going to Firefox, they're not going to Internet Explorer. First, they're going to my screen reader. My screen reader is going to make a decision about what to do with that keystroke. Is it going to process it? Is it going to capture it and do nothing with it? Or is it going to let that keystroke pass straight through to the browser so that your JavaScript or the browser Chrome can do something with the keystroke? So we're talking about some of these more rich user interface components. We're talking about components where you are defining some behavior and a lot of the time that behavior is based on keyboard behavior. What we need to understand is that if you're saying, hey, if somebody hits the letter H, pop up this help dialog, a screen reader user, when I hit the letter H, I'm going to jump to the next heading on your web page, and I pressed the letter H at all. So I think most people here are familiar with markup. That's HTML. That's the stuff that gets downloaded by the browser from your server. So we won't go into that. Probably most people, if not everybody here, is familiar with the DOM. This is what happens once the document is downloaded by the browser and gets parsed, and it goes into kind of a, well, the document object model, it gets parsed into a tree that the browser now knows how to interact with and how to render and how to attach behaviors to. The part that most of us probably haven't had experience with is what's called an accessibility API. And boy, would my life, would all of our lives be easier if there was an accessibility API? There is not. There is Microsoft that has two. Firefox has one. OSX has its own. So there's MSAA and UI2 or UA2, something. That's the Microsoft version. The Firefox platform has iAccessible2 or iA2, and then OSX has its own kind of native accessibility API. And what is an accessibility API? An accessibility API is really very similar to the DOM. It's this tree. It's got parent-child relationships and, I mean, if you're really familiar with kind of comm programming, this is just a relationship of components. It's really an accessibility component object model. It's saying the roles, state, and properties of given elements or given objects that are on the page. And screen readers particularly interact with the accessibility API. They interact with it to be able to communicate back to the user what information is available to them. Are there any buttons on this page? Are there any headings on this page? Are there any text fields on this page, radio buttons? All of those roles are communicated back to the screen reader through an accessibility API. So if you can imagine me being on your website and thinking, oh, I know that on this website there is I want to search. Almost every website has search. Most home pages, unless you maybe have like a user login or a mailing list subscription, the only search, the only edit field, there's really three edit fields that are on maybe four on a home page. There's a search, username, password, and email address for maybe a mailing list subscription. There are, you know, very few home pages that have any other than those four edit fields. Now if your home page has 5,000 words on it, 2,000 words on it, 1,000 words on it, and if what I really want to do is search your website, as a screen reader user, I can start at the very top of your page and read down that page until I get to the part where your search box is and now I can actually interact with that and enter my search terms and get to your search results page. I quit if that's the way it has to be. Or I can somehow find a way to navigate directly to that search box. And by having the accessibility API expose the fact that there are editable text nodes within your DOM or in your document, I can use some keyboard commands to navigate through your page quickly and jump from one text field to the next. If the semantic wasn't there, if there was no way for a screen reader to distinguish a text field from a div, that wouldn't be available to me and your document, your website or your web application would be far, far less navigable. So that's the world that we live in with native components. Native components, if it's input type equals text or input type equals radio those types map to the accessibility API. But like we've been saying, not not every thing, not every element that you're putting on your page, not every component has a type that will have its own explicit or even implicit semantics. Before I get into the why aria part, this is the problem. This is the problem that we're facing. I want to put a slider on a web page and there's nothing in HTML that's going to let me do that. Does anybody have any questions at this point about the problem before we start to talk about the solution? Excellent. So what is why aria? Why aria is an these are their words. It's an ontology of roles, states and properties that can be used with markup languages in order to communicate semantics to well I say assistive technology, but just period, end of sentence. In order to communicate semantics that are not in the native markup language that you're using. It can be used with any markup language. So it can be used with HTML4 or XHTML 1.0. If you go to validate using the W3C validator and you're using it with XHTML 1.0 your document will not validate because the why aria attributes are not part of that specification. If you're using the experimental HTML5 validator, your document unless it's broken at the time will validate because HTML5 is part of HTML5 and validates as part of HTML5. There's a few different things, there's a few different types of categories, there's roles there's states, there's properties roles are really the thing that says this is what I am I am a button, I am a region I am a slider. There are states which is really saying you know what I have currently so I can be selected or unselected I can be pressed or I can be not pressed and then there's properties and properties are much like states but they're more persistent so a property could be I have a pop-up that might pop up at some point or I have ownership of another component on the page like we might have with the relationship between a tab button so one of the most common places to get started and really one of the places that we got started with moving some aria support into Drupal 8 is with regions and regions are a roles are kind of broken into a few different categories this what am I the actual rich semantic part of it and region is one of the categories or landmarks is one of the categories so regions are roles that are meant to be navigational aids and what they do how they can be implemented and are in a lot of screen readers is if you're using regions to mark up the different chunks of your document a screen reader is going to allow a user to jump through your document from one region to the next so I can jump from the navigation region to the search region to the main content region to the footer region instead of having to read up and down the page line after line after line if I know I want to get to the main content it's the semi-colon key JAWS is the screen reader I primarily use in Windows if I had the semi-colon key a few times I hear main content region now I know that if you've marked up your document properly I know that I'm at the top of the main content and I can start reading here I don't have to read all the way through the site navigation or any sidebar content I can just start reading the article that I clicked through from Google to get to your site to read live regions are a special type of region a live region indicates to assistive technology that there's a section of your page a section of the DOM that is going to have changes dynamically and that you want the screen reader to announce those changes as they happen now don't please go out and add live regions to your website everywhere you have content that changes if you have a website that shows a stock ticker going along the bottom of every single page and if every two seconds a new stock appears in that region I can't read the article on your web page if every two seconds I hear a new stock symbol and a new price so we need to apply these things, these tools that we have to make the web more accessible and a better experience for people with disabilities we need to apply them carefully we need to think about the human being that we're trying to help with this tool to ask is this tool going to actually help somebody or is it going to make their life miserable a place that a live region would be useful is if you have a web chat like a live person style of a web chat where every once in a while a new node is added to that section of the DOM and it's a node that you know the user is interested in because they're on a page where they're chatting with one of your representatives that's an excellent place to use a live region in Drupal we didn't put any accessibility no, we didn't put any aria into Drupal 7 except for in a couple tiny little places which are where we put some live regions in there's three places that we use live regions in Drupal 7 the first is on the progress bar or widget which I don't know if we use it anywhere in core other than on the installation page but this is the thing where it's like installing node module 17 of 28 73% complete and as that progress bar updates my screen reader will read those updates to me I don't have to keep navigating around on the page to find the update the screen reader will read those updates and it will read them because the container is a live region the other two places that we're using it are the password strength indicator so as you start to type in your password and it says weak, medium, strong that container there with that change is being read out loud as the password typed in and the third place that we're using it is on the autocomplete widget so that and it's not the world's best implementation but it was fast to get in at the end of the development cycle which is as you navigate up and down the list using the keyboard there's this hidden live region off of the page that populates the selected item into the live region so that a screen reader user can hear what element is currently selected as we go up and down that list there's some other ways to implement autocomplete this is the one that we chose in Drupal 7 subsequently it's the method that pretty closely matches what jQuery UI has implemented in 1.9 and so that's one road block removed from getting something like jQuery UI autocomplete into Drupal 8 core instead of using our own custom autocomplete JavaScript so regions are really things that you're going to use to help people navigate your page or they're informational more than being interactive really this next section that we're moving into is more of the interactive components on a page this kind of goes back to the subtitle of the presentation a div is not a button so if you have a div and you have a JavaScript behavior attached to that div even if you have an anchor and you have JavaScript it's nice when I see when I look at markup or when I look at the DOM and I see an anchor with a class that says button-green that's you just it says button right there whoa it says button right there it's a button but it's an anchor now when I hit that page when I go to read that page with a screen reader it's going to say to me it's a link because that's what the semantic is when you look at it it looks like a button because that's what the visual affordance is and now in a case of button versus link it's probably not that big of a deal though there's people that would perhaps argue that one way or the other it's not likely that big of a deal I know that either a button or a link if I click on it it does a thing I don't know what it does but I know that's going to do something when I click on it but if we think about using an anchor an unnamed anchor as kind of the action item for a slider all I hear a lot of the times on a slider is link number sign and there's no way for me to know if clicking on that or trying to put focus on it and using error I have no idea what a link number slider does or sorry what a link number sign does I have no idea what that does so it's important to make sure that the semantics that we're presenting to users match the behavior or the interaction pattern that we're trying to elicit so how can we how can we achieve semantics when we're using when we're either trying to build components that don't exist in the markup language or for some other reason like with the anchor button example we find it beneficial it's either themeers or developers to use an anchor instead of a button we can do it by explicitly setting the role of those components by using the why are you role property there are a set of roles there's an ontology of roles you can't make up your own role because there's a contract there's an agreement between assistive technology or really between accessibility APIs assistive technology and content authors, application designers that says here are the roles that we understand to exist so if you want to take your anchor and make it a button you can put your button class on it and then it gets styled like a button and then you can put the attribute role equals button and now what happens is when the DOM is being rendered over to the accessibility API in the DOM you have an anchor with an attribute that says role equals button in the accessibility API you're going to have a node of type or of role button and the accessibility API is going to know nothing about the anchor that exists in the DOM all it knows is that a button exists as a node in the accessibility API again that's not as important as if you have a div in your DOM with role equals slider or role equals tab or role equals button when it gets passed over to the accessibility API it knows nothing about a div what it knows is that that div from the DOM maps to a button role in the accessibility API and now that semantic can be communicated to assistive technology users so application mode this is another quirky part let me say that a lot of people again we need to apply these tools that we have at our disposal carefully to make sure that they actually help users instead of hinder them if you're not building a web application you probably don't need to use application mode so I'm only going to touch on it lightly so having a tab strip is probably not a web application having an email client with a list of inboxes and a message viewer area that's maybe a application the lines blurry on the web what role equals application does a screen reader takes the accessibility API most screen readers render the accessibility API into a virtual document or a virtual buffer so that it's easier to navigate instead of navigating a tree list of parents and children nodes we navigate a document that's been rendered out but if we're navigating that document that's where we're using things like h to jump to the next heading or f to jump to the next form field or semicolon to jump to the next region or landmark with role equals application applied to a section of a page or to the body element of a page a screen reader stops using that virtual document and passes almost all keyboard interaction through to the browser so now if I if I hit the up and down arrow keys I would normally hit up and down arrow keys and read through your document line by line and I might come across the heading or a button but I'd read through the document line by line when application role is applied to a section of a DOM I can't do that anymore arrow keys don't move me up and down a virtual document because it no longer exists if there is behavior specified in your web application that requires the arrow keys if you're catching those and doing something with it on the node that currently has focus then behavior will happen and this is exactly what we want in a web application for all users screen reader users keyboard only users users we talked about who interact with the web like the standard 90% of users do we want the behavior to be consistent across all of those user groups again we use this in one spot in Drupal core and I don't really like how we use it because this really interferes with the interaction pattern that people screen reader users have come accustomed to on the web we are accustomed to 99% of the content we reach on the web being in that virtual document so you can imagine that if we tab into a widget of yours and it breaks our ability to hit the up and down arrow keys to read down through the rest of the page we're going to feel lost disoriented and likely hit the back button and just go to find another link on google that will get us the same information that we were trying to get from your site that's why we need to be really careful about where this is applied right now in Drupal core it's applied around the autocomplete widget it's applied there so it can trap the up and down arrow keys so that we can actually navigate the user up and down through the list there are some pros and cons there are alternative ways to achieve this without using the application mode for consistency of at least the performance or behavior of that widget we've used it there though it does break or does interfere with the interaction pattern that screen reader users are accustomed to using on the site and I know that because it even confuses me sometimes and I built the widget so I can imagine that it's an even more demanding experience for other users who were not involved with it they're just expecting to type something in a box I'm going to skip over the next section about why overlay isn't a dialogue other than to say during the summer of 2010 before Drupal 7 was released yeah we tried and we tried and we tried and we tried and not a few but probably dozens of core contributors tried to find a way to make the overlay dialogue with the dialogue that pops up administration pages as part of the overlay we tried to find a way to make this work properly to work as a dialogue, to use application mode to use presentation mode on the stuff in behind people tried they coded up prototypes I tested so many things at the end of which we kind of came to a position where we decided that we decided that I decided that from being the user who was doing the primary testing to come up with a solution that for users of the latest and greatest technology would probably be a pretty good solution but for users of older technology and remembering that commercial screen readers some of them can cost a thousand dollars or twelve hundred dollars for users of older technology this was going to be a really, really bad user experience so what we did is we didn't add any of these extra semantics to the overlay and what we did instead is provided an ability on a user account edit page per user basis for them to choose to disable the overlay that really sums up what I wanted to cover about ARIA about how it's used, why it's used and how we have to be careful about using it there's a little bit there's fifteen minutes left and I'm happy to answer questions I've also yesterday because I spent a lot of the time with the Spark team for Spark Drupal for anybody who's not familiar is authoring improvements for Drupal 7 and Drupal 8 I did the really quick analysis accessibility more from a user experience perspective than a deep, deep analysis I'm happy to speak to some of those findings which I posted in an article on my website which is just zoofelt.ca so I can answer questions I can go through some of the points particularly the practical implementation we did the what's wrong what's the solution and this would be a real practical implementation showing how to apply some of these concepts to that work in progress it's in alpha this is not a criticism, this is helping to make it better so maybe we can do some questions I can talk to some of that Spark information if we have time at the end of the Spark the highlights of Spark let's define the test I went to the Spark demo site I logged in and on a given node, node 1 I switched from the view mode to the inline edit mode and I attempted to edit the body content field that was the use case that was the test plan login, no problem switch to edit mode try to edit the content inline as opposed to going to the advanced edit mode and editing it on the regular node edit page and I ran into some I guess one major problem and a few little minor things one of the and so if you can take a look or maybe we could put the article up because it's got a screenshot to give some of this more context it also has some of my notes about it one spot I think the first node I look at is this idea that there are two anchors after you switch into edit mode I think there are two anchors a save and a close maybe save and close they're both anchors their class clearly says button I'm not sure about visually if there's a visual buttony affordance about those I'm going to guess since the class says button they probably have some buttoniness associated with them the one it's a link it says save that's fine probably should be a button that says save because it's an action but that doesn't really matter as much the other one is a link that says number sign link number is what my screen reader reads to me and that's because there's actually no text inside that anchor and so not only do we now have a component that doesn't have a meaningful role we have a component that doesn't have a name at all associated with it that was one of the observations so when we're looking at making sure the information in our application or in the document maps well to an accessibility API having a role is not enough having the role of anchor or the role of button that's not actually sufficient there has to be a name to go along with that because you can imagine button button button button is not very useful if they have CSS sprite images indicating save, load email to a friend and if all I hear is button button button then that I can't interact with your application that was one of the things and again that's easy easy fix for the team I mean they spent I think somebody said all day long on Monday preparing their demo so that's not a big deal there's a toolbar and the toolbar is tabbed so once you click on the edit once you click to edit the body node the WYSIWYG toolbar is tabbed and that's nice from a user experience perspective because it saves space you can select which set of buttons you want to be able to use to operate on the content at a given time those things that are tabs in which I haven't asked anybody I'm certain that the visual appearance is as tabs where we know that one and only one of those items can be selected at any given time to me I hear link link so link format link insert I don't know that they are tabs and that's maybe less important it doesn't really matter all that much whether or not I know that they are tabs or not tabs it matters that I know that one and only one of these items can be selected at a given time and that I know which one of these items is currently selected and that semantic is not being presented through this user interface it's on my website so if you just go to zoofelt.ca yeah if you go to zoofelt.ca there can be the first article there that's on the homepage and you can click on it there's node 75 if you want the fast way zoofelt.ca and so again so we have these tabs but I don't know that there are tabs I don't know which tab is selected currently and once again these are links probably in a list if I remember correctly from the markup and so it's easy there are why aria roles there's a tab list role that's for the container so you put that on your unordered list there's a why aria probably tab button I don't remember the names of them all but tab or tab button role that's when you put on your anchor so that this is now a tab there's an aria selected state so that you can indicate is this tab selected so again you put role equals tab aria dash selected equals I think true and now that indicates hey look we have an unordered list well now the accessibility API thinks that's a tab list so it's going to tell me that it's a tab list we have an anchor but the role is now set to tab so now the accessibility API it's not going to say link format it's going to say tab format and we have this aria dash selected state which if we apply it to one of those tabs now the accessibility API is not going to say tab format tab insert it's going to say tab format selected tab insert because that's the one where we don't apply the aria selected state and so that takes this user interface this component this tab list component where right now I have it works there's two links if I hit enter on one of those links it switches the tool bar back and forth but it takes it and makes it more usable the reason that you don't just cross the top and made a tab list across the top is they were trying to make the application easier for people to use and by providing the correct semantics and states using my aria we make it easier for even more people to use and then there's a few other comments there maybe one of the one of the more relevant ones and then I'll see if there's any other questions one of the more relevant ones is in Drupal 7 we have the idea of tabs tasks if you go to a node if you're logged in and have permission to edit that node you're going to have a view tab and an edit tab they're not really applicationy because all they really are are links but it's the same concept the same paradigm that we have a context the node and that node can be in one of two states it can be in the view state or the edit state in Drupal 7 we put a header for lack of anything better to do we put a header in front of those tabs primary tabs and for the selected tab hidden in parentheses we put the text selected tab or active tab there's no semantics about that at all there's nothing that indicates to me other than the text the reading it in the hopeful proper translation there's nothing that's not good but we did with what we had at the time because we didn't want to break the validity of our XHTML theme so what we have interestingly with this spark is when we go to the selector widget near the top where we can choose between view and edit for that inline edit those have been themed with those primary tab theming but what happens in for starters we probably could update that to just use the YARIA roles and states that accurately reflect the state of those tabs with good semantics and not the text that we've been using in the rest of Drupal 7 so when I click on edit that selected tab hidden text doesn't pop over to the edit link it stays with the view link also when I select these tabs whether it's those ones or the ones for the toolbars nothing indicates to me that something happened now if there's tab semantics you know and I know that if you select a tab something's going to happen you know that there's going to be something on the page that once was something else and is now going to be changed and the semantic is of a link you have absolutely no way of predicting what's about to happen next that's another reason to have the real semantics that matches what the visual patterns that we use tabs because everybody knows how they work and we visually present them so we need to semantically present them about which about the regions the question was if I could say something more about regions yeah so regions there's this generic regiony thing and I'm not going to get into that because it's a little complicated but essentially you can create your own labeled named regions for your document you probably want to stay away from that unless you have a really specific use case for doing that and even then you probably want to consult with somebody who does this sort of work frequently to see if that's a good idea if there's a better solution but landmark regions these are a way of marking up large chunks sections of your document and saying what they are the utility is it assists somebody with navigating through your document and understanding what the different sections of the document are and there are some specifically named landmark roles like form like search main content navigation others content info I have no idea who came up with that name but it means footer a side which is kind of if you have 14 users are online kind of block in the side of your website and a side is saying this is information that's relevant but completely unrelated to the main content there's different regions with different roles and they're all described if you look at the spec pretty well there's a document that specifically goes through every role and explains why you would use one instead of the other and it's broken down so there's a section of that document specifically about the landmark roles what it does for me is it helps me navigate through your page and I can skip past the navigation and I can skip past those aside blocks and the search block and the user login form and I can get to the main content quickly instead of having to read through all that information or kind of hit the down arrow key and hold it for a few seconds and hope that I land at the spot that I want to be at well you probably need to keep using skip leaks because the reason is that I have a piece of technology that recognizes what these landmarks are and allows me to navigate through them a keyboard only user who doesn't use a screen reader likely doesn't have a piece of technology that allows them to do that now you can say and I can say they should absolutely they should but they don't and when IE6 was a huge part of the market we catered towards those users and some of us said you should have a better browser we said but you don't so we might not go a long way out of our way but we're going to make sure that the experience works for you if you can imagine being a keyboard only user who starts at the top of a DOM or a document and wants to get to a link in your main content and there are 75 links between the top of that document and the link they want to get through that is a lot of pressing the tab key so it's nice to have that skip to main content link at the top now we leave them in ideally we leave them in and we make them visible to everybody but I know that's not going to happen so we leave them in we make them invisible we make them show up on focus so as the keyboard only user when I hit tab for the first time it pops up it hit tab again it disappears now that's the second best way to do it for everybody so everybody knows it's there that will help depending on how your page is laid out on a mobile device it could help a mobile device user as well if they see the icon at the top so what do I say about browser compatibility use new it's a hard question so some of the why are you stuff has been implemented in browsers and assistive technology for a long time some of it has yet to be implemented it's really kind of like a css3 scenario you really just need to become familiar with what the limitations of the different parts of the spec are across different browsers and if you're building a web application for a bank where you know the browser that everybody's going to be using that's a lot easier and you can maybe take a little bit more you can use more stuff because you know exactly what environment is being coded against if you're building it for a website where you may have any number of browser combinations then you maybe need to be a little more conservative about the types of widgets you try to implement so that question was essentially advertisement how do we get advertisement onto the page in a way that it is I won't even say discoverable but right in your face but easily dismissible and this is what happens and so I would say don't do it I don't want to see your advertisement and so that's easy for me to say but this is what we're doing to all users right we're saying boom here's a light box right in front of you you have to dismiss this before you're actually able to get to the content that you want to have or here's an ad that's sliding in from the left side of the page and you know you have to it's in your face and you can choose to dismiss it I'm going to say we pretty much do it the same way probably you're going to do it with the dialogue you don't necessarily have to use dialogue you could make it modal or you could make it modeless so you could trap people inside of that region of the DOM or not but you're probably going to do it the same way you're going to stick it at the very top of the DOM so a screen reader navigates the page in DOM order and though it respects CSS to the extent of if you have display none it will omit it it doesn't respect CSS that if you have things floated left and floated right that makes any difference to it at all so you're going to want to put it at the top of the DOM because that's where the user expects to be and you're going to probably want to have the first thing be a heading that says blah blah blah buy my sports car and the next thing something that says you know dismiss this ad and then after that could be the ad content and that's the experience that other users are getting right their eyes are drawn to the headline pop over to the dismiss button but might skip over that dismiss button and read the next couple lines first knowing that they can quickly go back to that dismiss button to make it disappear for a keyboard only user you're going to want to make sure that I don't want to say you're going to want really you're going to want to make sure that the focus when the page loads and that advertisement slides in is on the dismiss button because that way they know how to dismiss it they don't have to try to tab a million times to get that thing to disappear you could also have it the escape key that's not going to work for screen reader user because the escape key gets stolen by the screen reader for a keyboard only user the escape key you could have it dismiss the ad I think we might be running out of time I am happy to do a bof tomorrow sometime during the day if people either want to talk more about this if they want me to take a quick look at a site or an application that they're developing or have developed to get some ideas and some feedback or if you just are I'm completely lost about accessibility and I just want to understand where the resources are where the tools are to be able to learn more we can talk about that too whatever people want to talk about I'm happy to do that sometime tomorrow I would ask that somebody else organize it huh I'm not going to organize it and have nobody show up but if somebody else wants to organize it or if a group of people want to organize it and then just reach out to me and we'll make sure that it fits into my day tomorrow