Well this is Improving Accessibility in Web Applications. My name is James Craig, I am an engineer in the OS X server team on collaboration tools project. To begin with I want to talk about what we're going to learn today. So the first half of the presentation will be about universal design, what it is, and how you can use universal design techniques to improve the accessibility and usability of all of your products, whether they are physical products or software products. And also by doing so you'll gain a lot of other benefits including search engine optimization, so you can drive more traffic to your web applications. And then we'll finish with a demo of some specific keyboard techniques for keyboard accessibility in web applications.

And then the second half of the presentation is going to be more about accessibility - certain disabilities of people that may use your website, assistive technologies that they use as well, some common sense principles that you can think about when you're developing your websites and web applications... and some specific techniques for making those web applications accessible, especially new techniques using some new emerging specifications from the W3C.

But to begin with I want to talk about what I mean by the word accessibility. Just by a show of hands, how many people here have what they think is an understanding of the word accessibility? Most of you. So it's one of those terms like design where it means something slightly different to everyone that hears it.

So for the purposes of this presentation, I'm going to be using it to talk about accessibility for people with disabilities... web accessibility or software accessibility for people with disabilities. So that might include someone with a dexterity impairment, so they may have a hand tremor and not be able to use a mouse in the same way as a non-disabled user, may have a hearing impairment, may have a vision impairment and use some assistive technology such as the screen reader; which speaks the contents of the screen to them so they can understand it. We'll talk about that a little bit more, but for now I want to talk about the broader topic of universal design.

What I mean by this is design that's so thoughtful of that it works for everyone from the start, as opposed to something that needs to be patched for the disabled as an afterthought. So you guys have all seen examples of this. Probably the most quintessential one is a curb cut, like a wheelchair ramp on a sidewalk. They're required by law within the U. S.

at least, by the Americans With Disabilities Act, for people using wheelchairs. But if you think about it... people pushing baby strollers, people riding bikes, delivery personnel pulling packages, you probably use them on the way to the airport. In fact in the U.K. they don't call these curb cuts or wheelchair ramps, they actually call them 'pram' ramps. Pram is like U. K. slang for a baby carriage. So they've kind of completely removed this from their minds from the concept of a disability, and it's just these are baby carriage ramps but wheelchair users use them too.

So it's a good design that works for everyone. Also caption broadcast content you're probably familiar with, again required by law for people with hearing impairments, but think about who uses these. You've probably used it last time either at the gym or maybe the airport on your way here to the conference. And you're starting to see some product design, or physical products that take universal design into consideration.

So this is the new iPod Shuffle that's the first, or one of the first iPods that had a spoken interface, first one that had a completely spoken interface, and it can now be used... you click a button on the headphone and it speaks the track that's playing to you, or you click and hold to listen to the playlist. And it can be completely used by someone who is completely blind, and it's probably the first iPod that could do that until the new release of the iPhone VoiceOver this week, which I'm real excited about.

You're also going to see some universal design trends in graphic design, especially as it applies to web design. So this is the Flickr homepage, very well known site. A good example of the kind of web "2.0 trends". One of the graphic design trends that came about around the time that the site launched was these large text and big buttons stuff that's easy to see for everyone, and whether or not they may have low vision or vision impairment.

Also these larger clickable areas, for example the upload and organize section. It's a large target area so you can move your mouse to it quickly and click on it before you really even think about it, also works better for somebody that may have a hand tremor and has trouble getting to a small spot on the screen.

So that's some graphic design techniques for some product design stuff. Let's talk about some specific techniques for you and your website; stuff that you can implement... today for that matter. In this section I'll be talking about semantic markup, progressive enhancement, captions and transcriptions, and full keyboard access. Semantic markups - so by a show of hands, how many of you consider yourselves web developers? A few. And how many of you are Cocoa developers that have some web development experience? OK, so mostly web developers, that's good. So this is going to be very, very familiar to you, a good base for universal design is this semantic markup.

They've been talking about it on the standard Eastern blogs for almost a decade now I guess. So first of all I want to show you... that you really can't see the difference between semantic markup and non-semantic markup from a visual perspective. In other words which is which here, you can't really tell because one could be using table based layout, one could be using CSS, one could be using all inline styles, one could be... using only DIVs versus headings. So that the point of this is just to show you that semantic markup doesn't get you anything visually, but you're going to get a lot of other benefits when you start to use semantic markup.

So here we've got a page... and the heading up at the top says All About Widgets. And so other users in the room, myself included, can see that All About Widgets is bold and it's larger text than the surrounding text, and so we can infer from the visual style that that is the main heading on the page.

And the web developer has decided to use a DIV to describe it, DIV is just a generic tag and actually puts the style right in there; which is fine but it doesn't go as, it's not as useful as it could be. Instead they should just call it what it is - describe it by the self describing semantic markup. So in this case the first level heading on the page, so we're going to use a heading level one tag, which is an H1.

And you're going to start to see a lot of benefits, so from the developer's standpoint it minimizes your markup, it makes it easier to maintain when you can style this H1 in CSS, and it gives you better selectors, more specific selectors. You get a lot of search engine benefits too.

All search engine algorithms are different, but it's widely known that text within heading tags actually gets a higher priority in search engine optimization algorithms. And the reason is because if this page is, really is actually all about widgets, then the widgets is a search term being in that heading, it's at a higher probability that the rest of the page content is going to be about that as well. Sometimes spammers will try to fake that, but we do a good job of weeding them out.

In addition to the development benefits and the search engine benefits, this is going to provide some nice user interface for people that can't necessarily see the screen. So I mentioned a blind user might be using a screen reader before, so instead of having... instead of just hearing the text all about widgets, now because you've used semantic markup they can hear something a little bit more appropriate such as heading level 1, All About Widgets.

I also want to talk about progressive enhancement. The idea behind progressive enhancement is that you make something work for everyone, and you make it work even better, or you may it work best for people using the latest technology or modern technology. So a good example of progressive enhancement is CSS. If we start with our baseline technique of using semantic markup, then all web users can actually see that content, even users that are using a command line browser like Links on Unix; almost nobody has used in 15 years.

And so then we style it with CSS and people using modern browsers can actually see your presentation style that you've set up for them. Another technology that's more commonly associated with progressive enhancement is JavaScript, and we could probably spend a whole session talking about that, but I just want to give you one example of progressive enhancement. So this is the Google homepage... I'm sure you're all very familiar with this one.

It's visually at least; it's been relatively unchanged for the past decade or so. It still has the Google logo in it, still has the search box, and the search button. So you type your search term in and you hit enter, or you type your search term in, click the button.

You go to another page to present with a list of results for that search term. A couple of years ago they added a little bit of JavaScript that goes off, and kind of in the background as you're searching, does that search for you and brings you back a list of potential search terms, common search terms that you might be searching for. And so this is a good way of still providing that baseline functionality. It still works like it always has, but now it works a little bit better for users that have JavaScript, which at this point is almost all web surfers.

Now captions and transcriptions are really a topic we could spend an entire session on. I'm going to talk about these just briefly, but captions if you're not familiar, they're just like broadcast captions, or at least with web content they're just like broadcast captions with synced text that goes along with a video file. Transcriptions are usually a plain text document that goes along with an audio file such as a plain text transcription of a speech. This is a screenshot of some caption content on the Apple.com site - one of the iPod marketing videos... commercial, excuse me.

And you get a lot of benefits from captions and transcriptions as well. The main one that you guys are probably going to notice quickly is the... is that now if you actually have that text data associated with these multimedia files, search engines recently have started indexing all of that content.

So if you have an audio file and you've got a plain text copy of it, then the search engine can find that plain text webpage, which links to the audio file. You can find what it is you're looking for. Same thing with captions in video, in fact a lot of caption, or a lot of video services now have actually started letting you link to a particular spot in the video. So the search engines can index that content and then you can link directly to the spot in the video where that search term appears.

Kevin earlier said that CNET TV had captions with videos, and its Google traffic went up 30 percent. That's a huge number, I mean if you think about it CNET TV had... almost all of their content was videos online. So now that they've captioned it, they get this huge boost in traffic from users doing search terms and clicking on a link in Google that brings them to their CNET TV site. So this is something that can translate into more traffic, more users, and potentially more money for you guys as well. Now I wanted to talk a little bit more in depth about full keyboard access.

It's a topic that... seems pretty straightforward, but a lot of people make very common mistakes, including well known websites, well known quality developers, who either don't think about stuff or it kind of gets pushed to the back of the project. And so there's some common mistakes that we'll talk about, and how to avoid them.

I want to talk a little bit about tab order in browsers, what it is and how you can control it to make your websites more usable to the keyboard, and then we'll have a demonstration. So this is the new WhiteHouse.gov site, great website, love the fact that they are video blogging and providing lots of transparent information public.

When you tab into this page, the developers made one mistake though, when you tab into the page, and by tab I mean you hit the tab key on your keyboard and it moves the keyboard focus into the page so you can get around without using the mouse. When you tab in you're first focused on this email field up in the top right.

You hit tab again, moves to the Zip field. You hit tab again, it moves to the Get Updates button. That's pretty logical, it's a type in your information here and you can receive updates. And if you hit tab again, it kind of disappears and you can't really tell where you are.

Maybe you could figure out, OK you're probably over here on this set of links. Hit tab again and you can't see where you are. Hit tab again, you can't see where you are. You're still navigating throughout the page, but a sighted user using the keyboard can't determine where they are so they can't use the webpage effectively.

In fact when it gets down to these plain text links here, the default keyboard focus is hidden, so you can't really see where you are. So we're going to show you how to hide the default keyboard focus, but actually style it to where you can still see where you are in different method.

The Bank of America website, not a great website, very secure, very useful. But when you first get to the website your keyboard jumps to this online ID field, this username field that's over in the... top left, and that appears to me that they're trying to make the form more usable because that's probably what most people use. That's probably what most people do when they come to the Bank of America website, is immediately login. Hit tab again, it goes to the sign in button.

That's still pretty useful. Hit tab again, you're still in that form. That's a fairly logical order, even though it's slightly out of order. And then you click around some more and just kind of watch the focus here. It still is in that section, moves back up to the links up above it, the links down here. And then at this point it kind of jumps out of that whole section. It jumps down here to the Go button as you tab again.

It becomes an illogical tab order here, and then it goes back up to the top, the main navigation over to the sidebar, and finally to some of these other form elements that are nothing. Now from an outside perspective, it appears to me that they were trying to do the right thing and make that login form more useful. But as part of that ended up... not necessarily paying attention to how that change affected the rest of the navigation on the page. And so we're going to talk about a technique for changing that default navigation, and how to do it a new way.

So again, tab order in browsers is when you hit the tab key and you move the keyboard focus through the page. Now the default tab order is source code order, so the first interactive element that appears in the HTML is the first thing that gets focus, and the next interactive element that appears in the HTML is the next thing that gets focus, and you move through it in general source code order.

You can override that with an HTML attribute called tab index. It's been around in HTML for a long time. Originally it only applied to links and formulas; that is... elements in the browser that were interactive by default. So you can move your keyboard focus to a link and click on it and activate that link, or you can move your keyboard focus to a form element and type in some information, or press the button or what not.

It also allowed change of the default tab order, so you can say this link, you tab to this link before you tab to anything in the normal source code order; which can be useful, but can be misused as well. So recently, and I mean it's in the past year or 2, there have been some extensions to tab index. Now it applies to any DOM element, anything that can be rendered in the browser can receive keyboard focus. So that includes generic elements like DIVs and SPANs.

It also includes stuff like list items and paragraphs, and it doesn't make sense at first why you would want to make those things keyboard focusable, but as you see the demo it'll make a little bit more sense. And you can still override the default order where you could put stuff in order before the source code order, but now you can also add elements to the default tab order, or remove them from the default tab order.

So if you use tab index equals 0, which is a new extension, it just puts it in source code order - suddenly it makes this other element focusable in addition to all those native focusable elements. And to give you a demo of how to maintain visible keyboard focus and use the new tab index techniques, I'm going to bring Chris Plazak up to the stage.

Chris?

Thanks James. So today I want to talk about using keyboard access to improve the usability and accessibility of your websites, not just for users with disabilities, but for everyone. So the web page I'm going to use for this demo is here, and we have some content at the top, we have a list in the middle, and then some content at the bottom. And we want to make this into something more like a desktop app like Mail for example, where you have a list of messages, you can tab into them, tab out of them, move around with the keyboard.

So the first thing we do, if we just try to tab through this right now, I'll press the tab key. We get to this link at the top, we skip over all the elements, and we get to the link at the bottom. So the first thing we want to do is to bring these elements in the list back into the tab order. So let's go to the code, and to do that... it's not hard, I'll just start setting the tab index for all of these.

And here that says item 1 so maybe I'll say, that should tab index 1, tab index 2, 3, and so on. I'm going to copy and paste the rest of these for the sake of gravity. So we have up to 10. So let's see that and see what happens.

So I'll press tab for the first time, I get to item 1. As I go through this list, get to item 10, press it again now I'm back at the top. Press it again, where will I go? All the way to the bottom. So I've brought these elements into the tab order, but that's not really correct. I've tabbed first to the items in the list, and then I jump around a lot which isn't real ideal.

So instead of explicitly setting these elements to numbers, which you can imagine if this list grew large would become a real pain to manage. Instead we can just set them to 0, and what 0 does is explicitly tell Safari in this case, to just put the items in the order that they come in, in the source code. So where will they appear in your DOM? That's where it will be in the tab order.

So if we try this again... first tab brings me to the link, next tab brings me to item 1, so on through the list until I get to the end. So that looks pretty good so far. We can tab through all the items now, we're enhancing the usability of our website, but this list doesn't really look that great.

It doesn't look like a Mail app or something that you see on the desktop, that we really want to mirror in this web application. So instead of relying on the default tab order, default style of the tab, we can change that style to make it look more like a selection. So I'm going to paste in something that will change the color, the font color, of the items in the list; and change the background color of the items in the list when they become active.

So let's take a look at how that looks. Tab in, and now as I'm tabbing around I've a pretty nice looking focus in the background; starting to look more like a list. If you look closely, we still have that tiny keyboard focus ring border around that slight blue hazy object, and that doesn't look that great in this case. So we can remove that with just another line. We can set the outline to 0, which will remove any visual indication that keyboard focus is there.

So now when we tab through it... all we have is just this nice selection in the background, which looks pretty good but notice I didn't do that until I had added another visual indication that said where is keyboard focus at the time. You don't want to remove the outline and then leave your users in the dark as to where the keyboard focus actually is.

So we're doing pretty good. I can tab through all these items, but say my web application starts to grow and I have 1,000 items in this list. I don't want to make users tab through every single item in the list, just to get to the bottom. What I'd really like is to be able to tab into the list, tab out of the list, and move on just like Mail and other applications where the lists do. So to do that, we're going to use this JavaScript function.

And in this function which changes focus, it's not completely filled out yet, what we're going to do is check if the event coming in is a key code of 40. And now obviously everyone here knows what key code of 40 is, I don't have to say what it is. It's the down arrow key, so this says when a down arrow key comes in, I'm going to do something. And what that is I'm going to leave that as a mystery until we get to that part.

So to make sure that this function is called, we need to install the JavaScript handler, and I'm going to do that by copying some code ... and then install some JavaScript handlers on each one of these list items. Alright, so each one of these list items now says on key down, so when someone presses the key down, when the keyboard focus is on this item, call this JavaScript method. And this JavaScript method will call this thing here.

Now notice I only have tab index of 0 on the first element. The other ones do not have tab index of 0. So what that means is that these other elements in the list will not be in the tab order. So I'll tab to the first thing, when I press tab again I'll leave the other items and skip right over them.

So that'll be important because we don't want to tab through all of them. So now we need to make this JavaScript handler do something, and what we want it to do... is to change focus. So using some JavaScript frameworks to just simplify, what shouldn't be too hard, is that we get the next element from the current element, which just pulls out the next element in DOM order. Obviously it'll be the next list item here.

We set the tab index to 0 here, which is important, because that brings this element into the tab order that Safari has in its internal mechanisms. So we bring it into the tab order by setting tab index to 0, and then we call focus on it. Alright, so that should be enough. Let's see how this works. We'll reload it, I tab to the first item, alright tab to item 1. If I press tab again right now, I'll leave the list, that works.

So if I go back to item 1 and I press the down key, which I'll do now, I start to move through these items in the list. Alright, that's pretty good. So I can tab out of this list, I can go back to it, and if I start tabbing back I'm now using the tab key to move forward and back. Notice all of the sudden my items are all in the tab order again.

So the only one that isn't there is an item 10 because I have an arrow down to that, once I arrow down to that now this is in the list as well. So what happened here? We were maintaining keyboard focus only on the first element, and trying to use the arrow keys to set focus on the other ones, but we forgot one important part and that was removing the previous element from the tab order. So with this method here, we added all of these elements into this tab order, but we forgot to remove the previous one.

So in that case all of them were there. So how do we remove it from the tab order? We're going to use something, we're going to use an extension tab index by setting it to -1. Setting it to -1 tells Safari to remove this item from your list of things in the tab order; so just takes it out.

So now if we try this, reload, we'll tab in, we can tab down a few items, I can tab out. If I tab back in, and I can tab immediately back out of it. So now as I tab through these, I'm just on the item that I last left. So with just a few tags, few extra attributes and JavaScript handlers, not too much code, we've made our website a lot more usable and not just for people who have problems using the mouse or so on, but for everyone.

So we can bring this to this natural conclusion, and I have an even more enhanced version where we maintain a disabled state for the list when it doesn't have focus. We can arrow up and down through the list... and I can also click on items in the list, because universal design is not just about addressing people with disabilities, but everyone's needs for how they can interact with the computer.

Alright, James?

So so far within the keyboard access section, we've learned some common mistakes and how to avoid them; such as maintaining a visible keyboard at focus, and maintaining logical tab order. We also learned some new extensions to the tab index attribute, some of which is going to make a lot more useful. And Chris showed us a demo of maintaining that visible keyboard focus.

I noticed he only removed that focus ring once he had already set up another style. And talked about a technique that's known as roaming tab index, and roaming tab index is a search term that you can use to find out more about that particular technique online. But I want to shift here from talking about universal design, so that is from techniques that you can use to benefit all users including those with disabilities; some more specific techniques and information about users with disabilities, so people that might need special considerations.

So again, some of the disabilities we've talked about... I mentioned the wheelchair ramp, the curb cut, at the beginning. Typically wheelchair users don't have much problem accessing the internet because most of them have full range of their hands, full range motion of their hands, and usually sight and hearing. But quadriplegic users, rather dexterity impaired users may have trouble actually pressing keys on the keyboard. Hearing impaired users may have trouble accessing multimedia content, which is why we need captions and transcriptions.

And finally we're going to talk mostly today about vision impaired users. That includes people that are completely blind. It also includes... people that are called low vision, or legally blind; that is they have, they can see somewhat but they've got very, very bad vision. And this also includes the aging population, other people that kind of just lose some of their vision as they get older, which will include all of us I'm sure.

So we're going to talk about assistive technologies. Has anybody, by a show of hands, who here knows what assistive technology is? Not too many. OK, we're going to talk about some accessibility principles that come from the web content accessibility guidelines, and then we're going to talk a lot about web application accessibility, and then more specific techniques.

So assistive technology is a broad term that refers to both hardware and software tools that people with disabilities use to access the computer, to help them access resources and other... other things in the same way that... with the same degree of... access that other people have. So one example of assistive technology, so this is hardware so the screen shot is actually what's called a refreshable Braille display.

Most of them work with OS X, some of them work with other computers as well. What it is, is it's a row of pens that raise up and down, and display the text that's rendered on the screen in a way that a blind or a deaf blind user can see it. There's also alternate pointing devices.

Some people will use eye trackers that they could actually look at a particular spot on the screen, it'll move a pointing cursor like a mouse cursor, to that spot, interact with it. Some people use alternate keyboard devices, so I mentioned some paraplegic users will use what's called a sip and puff tube.

It's just a little tube, they have very limited range of motion, but they can either suck in or blow out on this tube and it gives them a few keystrokes that they can emulate a keyboard. There's also one called a Head Wand, so some people have limited range of motion and it's essentially like a long stick on their head that they can use to press a key on the keyboard in front of them. So that's some of the hardware assistive technologies.

There's a lot of software assistive technologies as well, and several of these are built in right into your Mac OS X desktop. They've been around for a long time. Speech output, I'm sure you've all heard, also known as text to speech. And there's also speech command software, so that includes both the speakable items that are built in to where you can say... phone number for John Doe, and your computer will speak the phone number back to you. Or also third party dictation software such as Dragon or Mac Speech.

There's some utilities that you can find in the system preferences. This includes sticky keys, so some people who have a limited range of motion might have trouble pressing 2 keyboard keys at the same time. So if we hit command S to save, somebody might have trouble hitting those both at the same time, so they could hit the command key and then the S key. And Mouse Keys are a way to use the arrow keys, or the... 9 key track pad to move the mouse cursor around the screen. And there's also screen readers, and Chris is going to demo the built in screen reader Voice Over for you in a minute.

But screen readers are usually an audio only interface that allow mostly blind and low vision users to get a mental model, or a picture, of what's on the screen. So as they're moving their keyboard focus around the screen, it not only tells them the text that's rendered on the screen, but it tells them other information about that. So in the previous example we heard... or the previous semantic markup example, not only would they hear the text all about widgets, but they might hear some semantic information about that; some other meta data such as the fact that that's a heading level 1.

So accessibility principles. Is anybody here familiar with the Web Content Accessibility Guidelines? One person, OK, a few people. Good. So there's a new specification, or rather a recommendation, now from the W3C, came out in December. The Web Content Accessibility Guidelines 2.0, and it's a big document but at its highest level it's very simple.

It's these common sense principles that you can use, and these are easy to remember, write them down and just think about them as you go through your development cycle. One is the content must be perceivable. So in the broadcast caption example earlier, there was somebody on the screen and one of the girls was actually speaking.

So in order to make that perceivable to somebody with a hearing impairment, you had to render the text on the screen. So that's an example of perceivability. Another thing is like if there's an image on the screen and a blind person can't see it, so there's got to be some alternative text that they can hear that describes that image.

Also make content operable. So if we have something that looks like a button and it acts like a button, when you click on it with your mouse you should also be able to move the keyboard focus to it, and click on it as you could with the keyboard by hitting probably the Enter button or Space button.

All content must be understandable. So this is a little bit more abstract, but a good example of that is the heading example previously, to where the text all about widgets was perceivable but it wasn't completely understandable to all users until you use the semantic markup to associate that heading role with that text; so now everyone that can see the screen can tell it's a heading based on the visual style, but everyone that can't hear the screen can hear additional markups, or additional meta data spoken such as heading level 1 all about widgets.

And the fourth one, all content must be robust, is the most abstract of these but it basically... a good way of thinking about this is that to provide your content in a variety of ways. So not everybody's going to be able to access all content in the same way, even if you make it completely accessible. So for example, if somebody, you may have a web blog and on the blog listing page there's a list of entries.

Well that particular page may not be accessible to all users, but that user that it's not accessible to may have an RSS reader that they can use. And so by providing that content in another way, you've made it more robust and they can download the RSS feed and access the same content in a different way that's more appropriate for them.

And finally I want to talk about web application accessibility. Some new problems that have arisen due to the fact that up until a couple of years ago most of the web accessibility... tools and techniques were all focused from document accessibility, not web application accessibility. So there's new problems now that a lot of big sites are using web applications, or applications on the web. We're going to talk a little bit about WAI-ARIA, it's short for the Web Accessibility Initiative Accessible Rich Internet Applications. In fact it's a new emerging technology from the W3C, it's got a lot of support from all major browsers, vendors, and operating systems.

We're going to have a demonstration of those technologies as well as a screen reader demonstration. So what I mean by new problems... now when the web was originally developed in the late '80s early '90s, it was mainly scientists that wanted to share research papers with each other. So the first browser, the first HTML documents and browsers, were all focused around document semantics; like you'd have headings, and paragraphs, and lists, and tables, and then some interactive elements too like links and basic form elements.

But if you think about... how we've been using the web over the past 5 years or so, a lot of the websites that you keep going back to on a day in day out basis are full blown web applications that just masquerade as a web page, or they're actually acting as a web application within a web page. So this is an example of a web application.

This is Mobile Me web mail, and there's a lot of new semantics that come along with web application user interface helmets that just don't exist in HTML, don't exist in semantic markup. And so one example that I want to point out here, is up on the top left side we've got a list of tabs - inbox, drafts, sent, trash, and junk email - and we can tell by looking at that first one, or sighted users can tell by looking at that first one, that it's selected and by being selected it's mutually exclusive. The other 4 are not selected. And also since that one is selected, all the rest of the content on the right portion of the page is sublevel content within the inbox.

And if we were to click one of the other tabs, then the inbox content will go away and we'll see some other content. There's no tab element in HTML, there's no semantic equivalent of that. And there's no semantic equivalent of marking something selected, short of maybe some form element.

But nothing to make a tab selected, and no way to indicate that to an assistive technology such as a screen reader. There's also, that was a full blown web application. There's also some hybrid web applications that are on web pages, so this is a content page from the app about Com Site.

It's a document about the iPod Nano, but when you watch the video it pops open this dialogue, so the dialogue kind of, actually this player application, you've got some new things too on there like a play button, a progress indicator. There's no semantic HTML markup for a progress indicator to show you where you are within the movie. There's also no way to indicate that a particular DIV, or no standard that would indicate that particular DIV is a dialogue if it can be closed by clicking out of this Close button.

And so... as a solution to those new problems, a bunch of companies working together within the W3C on a standard called WAI-ARIA, Accessible Rich Internet Applications from the Web Accessibility Initiative. And in short what it allows you to do is to take web pages, or portions of web pages, and declare them as applications and have those web pages send other states and properties and role information about the application to... an accessibility API through way of the browser, so that the assistive technology like a screen reader can convey that information to a user.

So the way you use this is first of all, what we learned in the last demo, manage keyboard focus on complex UI widgets, because if you have applications that are in web pages on the web you want them to kind of behave like desktop applications do. So in the first example we showed you how, within a list, a complex UI... like a large selectable list. You don't want to tab through every item in that list, it becomes tedious, especially if it's something like a mail list might have several hundred or several thousand messages in the table.

And then you want to assign semantic roles. Now in addition to the universal design aspect of keyboard focus, we need to tell assistive technology users what something is. So we need to make something understandable. We also need to make all of the rest of the information perceivable, and we'll do that via states and properties.

So this is a screen shot of the desktop application iTunes. But say we were to masquerade or... take an interface like this and put it on the web... to where we've got a couple of lists in the middle here and your web application may look something like this - a few lists and a search box, and some other buttons at the bottom.

So say the user was focused on that search field up on the top right, and they wanted to get down to these buttons over there that are on the bottom left. If you were to make everything focusable it would be very tedious, because they'd have to tab through all the items in this list, all the items in that list.

So instead what they do is they hit tab once, moves over to this section. They can use the arrow keys up and down, tab again, moves over to the main content table. They can hit the arrow key up and down, and then finally over to the buttons that they're trying to get to. And so that's a way of managing keyboard focus, and Chris talked about that in his previous demo.

Another thing we're going to do is assign those semantic roles, so we're going to take interface elements and make them understandable. Keep in mind those accessibility principles - perceivable, operable, understandable, and robust. So in order to make those understandable, how do we make this particular element understandable? Sighted users in the room can infer from the visual style that it's a volume slider.

It's got some icons around it... it may be labeled volume, but what is a slider in a web page? There's no semantic markup equivalent for that. So in order to do this we need to take whatever element we're using and assign it a role, say this is a role slider so that somebody that's used to desktop applications that have sliders can understand that.

Same thing with this control. In Cocoa this is called a segmented control, but we've got something like this in HTML. It's kind of like a set of radio buttons, and if you press one of these, they're all mutually exclusive, right? You press the one on the right side and the other 2 pop out. So it's kind of like radio buttons, but you web developers in the audience I'm sure know have tried to style radio buttons in semantic HTML before. You can do it but it takes a lot of hacks.

You either take that native form element and you make it almost completely transparent, or you position it off screen and put a representation of it onscreen. So instead of using those hacks, we can take another element instead of that semantic input, and actually just give it the semantics that that input would have, so we're going to say this is the role of radio even though it may be used in a spam tag or an LI tag.

And finally, we're going to make these controls perceivable by giving other states and properties to the user. So on the case of the slider, what else might they need to know about besides the fact that it's a slider? Well they need to know what the volume is at that particular time. So in this case we can perceive that it's about 45 percent or so volume. Also and the set of radio buttons, we need to know which one is checked or pressed.

So in order to do that I'm going to bring Chris back up to the stage. He's going to introduce the screen reader VoiceOver, and I encourage you guys to learn it as much as you can, and then talk about how to use some WAI-ARIA states, properties, and roles.

Thanks James. So before we get into how to modify our web pages to make them more accessible, I just want to talk a little bit about VoiceOver. So as James mentioned, VoiceOver is a screen reader that ships with every single Macintosh.

It's on over 30 million Macs worldwide, and it's been around for 5 years. So the easiest way to turn on VoiceOver is to go to system preferences. Inside of system preferences it's in the universal access tab, and I'll find that most easily by typing turn VoiceOver on. It's down in the corner. Once I click that, there's a seeing tab and VoiceOver's here.

So when I click the on button the first thing that will happen to VoiceOver in Snow Leopard, is that it will display and speak whether you want to go on a tutorial journey through VoiceOver. And if you have an hour or so before your flight back today, or wherever you're going, it may be worth going through this tutorial to learn about how to use VoiceOver. You need to use the keyboard, there's some other commands that you can use to get around the screen.

So I'm going to turn VoiceOver on now.

[ Computer: ] Welcome to VoiceOver. VoiceOver speaks descriptions of items on the screen, and can be used to control the computer using only your keyboard. If you already know how to use VoiceOver, press the V key now. VoiceOver on.

Alright, I already know how to use VoiceOver so I'm going to start it right away.

You can of course press the learn more and go through that. I'm sure you'll be enlightened. So the first thing you might notice when VoiceOver starts, is that there's 2 visual indications on the screen. There is a caption panel on the bottom, which displays everything that is spoken, and there's a black border around an item. And this indicates what is in the VoiceOver cursor.

This means what is the VoiceOver user selecting at this time? So I can move around the screen with just VoiceOver and the keyboard, and get to every element.

[ Computer: ] When using this computer, I would like assistance with seeing, securing tab... keyboard tab, 3 or 4, mouse tab...

So by just listening to audio cues and synthesized speech, I can completely control my computing environment, using just the keyboard in this case.

[ Computer: ] VoiceOver off.

Alright, so let's go to the web and see how we can change our web page to make it more accessible to VoiceOver users.

So what we have here is something that looks like a toolbar. We have some buttons over here, and we have something that looks like a radio button or a segmented control on this side. The question is, you've done all this work to make it look nice and pretty and look like a web app, what does it look like to a VoiceOver user? So I'm going to turn on VoiceOver.

[ Computer: ] VoiceOver on.

Blank... before the application... list 3 items.

Alright, so before we take a look at how these things sound, I'd like everybody to close their eyes. And you're going to listen to what VoiceOver says, and see if you can notice anything wrong.

[ Computer: ] Blank... get new mail. Blank, compose new message. Blank, delete. End of list. List 3 items.

List small icons, large icons.

Alright everybody open your eyes now. So what did we notice?

[ Computer: ] VoiceOver off.

When we were going through these items? Well the first thing it said that this was a get new mail link, compose link, and so on. Those things aren't really links, those are buttons. So we'd like to describe them as buttons.

The other part was over here. First it didn't tell us that this was a radio button or segmented control, or anything that would give us an indication of how this thing actually works. In fact it didn't give us any type information at all, it just said list, small icon and large icon.

So to a VoiceOver user, as you just were for a few moments, you might realize that this might be a little bit confusing when you're navigating through the web page. So we're going to use ARIA to modify this web page, and see if we can make it a little bit better.

So here this line, I have the code that has the get new mail, compose new mail buttons. And what we're going to do here is just say role equals button. And that is an ARIA attribute that defines what kind of type this element is. So I'll paste them for all 3, let's go back to Safari, turn on VoiceOver quickly, and get some guidance.

[ Computer: ] VoiceOver on. Get new mail button.

Compose new message button. Delete button. VoiceOver off.

Great, so now these things just said they're buttons instead of links. So already with just 1 extra attribute, that didn't change the visual indication, it didn't make you reorganize your web page or do anything extra. You've made this more understandable. Now our other problem was these radio buttons. So as you can imagine, there's also an area role for these radio buttons and we can assign those by saying, role equals radio.

So I'm going to do that for these 3 items. We can save that.

[ Computer: ] VoiceOver on. Safari.

And now let's see what it says when we move over these items.

[ Computer: ] End of list. List 3 items. List.

I'll reload the page first.

[ Computer: ] Safari.

Stop. Get new... delete... end of list. List 3 items. List view radio button. Small icon view radio button. Large icon view radio button.

Nice. Now it says radio button. So we only have 1 more issue to resolve, and that is what about this thing here? It says, it looks like it's selected right? You can imagine if you press the other ones they would also appear selected, but it didn't say it was selected.

[ Computer: ] List view radio button. VoiceOver off.

So we want to use another ARIA attribute to make sure that this first one, which is here, which has the active class on it, reports that it is the selected radio button.

So we're going to add another area attribute called ARIA checked equals true. Reload the page, turn on VoiceOver.

[ Computer: ] VoiceOver on.

Let's get to the same item.

[ Computer: ] Delete... end of... list 3... list view... selected radio button.

Good, so now it says it's the selected radio button.

So all the information is there for the VoiceOver user to interact with your web app.

[ Computer: ] HTML content.

If we put all the pieces together that we've learned, with the keyboard focus, ARIA, we can get a very compelling web app, not just for sighted users, but also for users with disabilities. So let's go through this with VoiceOver.

[ Computer: ] Blank. Focusable content. Before the application widgets. List 3 items. Get new mail button. Compose new message button. Delete button. End of list. List 3 items. List view selected radio button. Small icon view radio button. Press small icon view radio button. Large icon view radio button.

Small icon view selected radio button.

So notice the selection changed to the one I just chose.

[ Computer: ] Item 1 group.

I can press the tab key, I'm just pressing the tab key now.

[ Computer: ] Focusable content. Item 1 group.

Notice that VoiceOver moves with me because I've managed the keyboard focus. I can use the arrow keys in this case.

[ Computer: ] Item 2 group. Item 8 group.

So VoiceOver also follows and announces what's going on, so you don't even need to use the VoiceOver special commands to get around. If you've made it universally usable for everyone, it affects everyone.

[ Computer: ] VoiceOver off.

So by adding accessibility to your web app, it's not difficult. It expands your user base. It will help you avoid any legal complications with any government regulations, and it's the right thing to do.

So James, back to you.

Thank you Chris. So what did we learn so far? Again at the beginning we were talking about universal design, how you can use these principles and techniques to increase the usability and accessibility of your websites and web applications for all users.

And we learned some specific techniques about keyboard focus management, the roaming tab index technique. We also learned about web accessibility, a variety of disabilities, and assistive technologies that users with those disabilities sometimes use to access web content. And we learned about some accessibility principles from the Web Content Accessibility Guidelines.

And those are that content, again, must be perceivable, operable, understandable, and robust. And again, I encourage you to think about these 4 principles as you're developing your websites and web applications. And Chris just showed us a little bit about VoiceOver and some specific techniques of using ARIA to enhance the accessibility of your web applications.

But if there's just a few things that I want you to take away today, it's first of accessibility is the right thing to do, and not just because some users have special considerations that need to be accounted for, also there are... but also because it's the law. There are regulations... some of you have probably heard of section 508, or the Americans With Disabilities Act; both of which now are applying to electronic resources.

You may have heard some litigation about Target and Ramada and Priceline, were fighting some litigation a few years back But not just because it's the right thing to do, but also because it affects everyone, and I don't mean just the standard user that you could consider disabled, but all of us as we get older, we're going to have limited range of motion, maybe limited range of sight. In fact, I heard a statistic that 12 percent of all males are color blind in some sort.

Now a lot of them don't even realize it, but that's probably about... 5 or 10 people in this room have some form of color blindness. A lot of times they won't tell you, or sometimes they don't even know about it. And so this includes everyone including the people that could typically be considered disabled as well as everyone who's getting older.

And also that accessibility helps you. Remember we talked about some of these universal design techniques, and accessibility techniques are going to build up search engine rankings, and search engine optimization. And by doing so, you're going to be able to drive more traffic to your website, which in turn can be... can turn into more money for you, more sites on your... more eyes on your products.

And also if you make it more usable using these universal design techniques and accessibility techniques, you make it more usable to your users so they end up getting happier and they come back as repeat users, which also means a higher user base and potentially more money for you guys. I'm going to show this slide again, then we're going to have some Q and A panels, but Vicky Murley is the Safari technologies evangelist. I encourage you to email her with your questions. There's more information on the Apple Accessibility website and Safari Dev Center.

The new specification, the emerging technology we talked about was called WAI-ARIA from the W3C site, and you can find that online as well as a new O'Reilly book that came out this spring called Universal Design For Web Applications. That covers a lot of the same topics that we talked about today.