EASI

March 3, 2011

MARISOL MIRANDA:  Hello everyone, I'm Marisol Miranda from EASI. And I want to welcome you all to the webinar on accessibility on HTML 5. Our today's presenter is Derek Featherstone. Hi, Derek. And now I'm going to turn the mike over to Norm Coombs. Hi Norm.

NORM COOMBS:  Hi Marisol. Thanks for being here. Thanks for everyone else. We're pushing 50 or more at the moment. But I'm sure we'll get some more coming in. What I may not have made clear to our participants when I was taking an international count, Derek is also Canadian. And I was born in Canada. So we get a nice little sprinkling of internationals here. Let me give you a couple of heads up on the webinar that's coming up next week. On Thursday, I believe it is, the tenth. Web aim has had for several years a great accessibility checker called wave. And Karen Smith from web aim is going to talk to us about wave, how it works and illustrates a little bit how you can use it to actually repair web pages. They're having an upgrade to wave coming soon and Derek may say something about that as well.

So I guess that's all we'll say today. I'll send who is on the mailing list a link for the archive which should be up tomorrow or Saturday. And I want to thank Derek Featherstone for being our presenter today. And I'll turn it over to you, Derek.

DEREK FEATHERSTONE:  Norman, thank you. Thank you, Marisol, for having me here. I'm really kind of excited. I enjoy speaking even over the Internet these days. I do enjoy interacting with people. And the only thing that I could say right now is that it's night and cold here in Ottawa and Marisol I wish I was down there presenting with you in Mexico, I think. This virtual seminar is about HTML 5 accessibility and what you need to know to get started in terms of understanding what the accessibility issues are with HTML 5. What HTML 5 is from the get go and what things you need to watch out for at present. There are some limitations that we're currently facing with HTML 5. Part of that is because it's essentially a standard that is being still at the age of being defined. We don't have a final specification for it yet and therefore, we don't have a final specification or final implementations and certainly don't have final best practices. So one of the things that keep in mind as we go through this today is that while this may be the case right now, the things that we present in terms of what HTML 5 is and where it sits, that may change over time. Implementation is going to change. Browser support is going to change. There will be things that continue to evolve. So definitely keep that in mind as we go through today.

So let's get right into this. Before we go too far I just want to let everybody know who I am. As you know, my name is Derek Featherstone and I'm an accessibility specialist. I'm very fortunate to have been invited all over the world to speak about the work that we do in accessibility. So we have a company here in Ottawa, Canada called further ahead. And we do a lot of accessibility consulting and quite a bit of training as well. I used to be a high school teacher and when I got into the web world and left teaching full time, it was very natural for me to continue to speak and to teach folks such as yourselves who are passionate about accessibility like us and want to learn more. And that's something that we're, you know, very proud of and want to continue to do. We do a lot of accessibility assessments to help people figure out where they stand in terms of accessibility and work with them on their remediation strategy and their moving forward strategy so that we're not continuing to see the same accessibility problems that they've seen before. And we help them with training and accessible design as well. We have our staff that are designers and developers. So with that, that gives you a bit of a background on where I come from. I actually was a web developer as well. But I spend a little bit less time now in the hands on code area of things.

So I had a little delay there in the slide but hopefully that comes through. So HTML 5 is the latest iteration of HTML and I have a little aterrific there because believe it or not, this is actually still being debated. This statement continues to baffle people. But essentially the development of HTML 5 has a long history and essentially what has happened is people are saying that HTML 5 is the latest iteration. And other people are saying well actually it's not the latest iteration. HTML is no longer going to be something where we iterate and take these snapshots. It's just going to be an evolving language forever. There's different groups that believe different things. And I believe in being a true Canadian and not taking sides on it at all. I'm going to let them figure it out and I will continue to teach people about HTML and HTML 5 and whatever it is that they need to learn about. Just be aware that when you're out there you may hear people talk about HTML5 in different ways.

So a while ago in the world of the web, we got to a point where we knew HTML needed to evolve. And one of the principles before people set out to look at HTML5 and start defining what HTML5 was this simple design principle to pave the cow pass. And essentially what happened was some people got together and they looked through millions and millions and millions of pages looking for patterns that would evolve. Looking at the code level. Looking at what developers were doing to try and accomplish certain tasks. What code standards weren't ever explicit standards but what were some of the standards that were developing or emerging as de facto standards. So Google has a huge farm in terms of their servers and their server capacities. So they were already spidering all these millions of pages anyway. They actually started analyzing the data and started looking for patterns. What they found was that there were a lot of commonalities in the HTML that developers were writing. What ended up happening is that we would come up with our own little conventions for marking up certain things. So we might have a div in a page that has a class of side bar. Or we would have a div with a class of header. Or a div with a class of footer. And these were things that emerged as patterns when they started analyzing the data. There were lots of designers and developers and coders that were using these practices on a fairly consistent basis.

So one of the things that we see quite often in the web and even in the real world is that when we don't have a tool that works exactly the way we want it to, we modify things. Take a look at this next slide, you'll see an example of this. This is a hack. Essentially what this gentleman has done is he has taken his Nintendo 64 game controller. He's a disabled gamer and he doesn't have full use of his hands. So what he has actually done here is modified his Nintendo 64 game controller to operate with the use of vacuum switches. And those vacuum switches, you can see here, so there's the red Nintendo 64 controller and then almost, you can sort of see how they're attached to the back, series of 4‑gray switches. So those gray switches that are plugged into the back and have been wired in are the vacuum switches.

So what he's able to do, and you can see on the gray, on the two far gray switches, you can see these little black straw type tubes. So what he's able to do with this is actually manipulate the video game controls by sipping and puffing on those little straws that are connected to the vacuum switches. So that gives him the control that he needs that he couldn't, that he wouldn't be able to get from his hands. And he operates the little joy stick. You can see how it's placed pretty close underneath his chin. So he can operate the joy stick with his chin. He can sip and puff into those two straws and he can control his game controller that way. Now it's been modified in other ways too. He's got it mounted. There's a clamp on the bottom that actually mounts to his wheelchair. And there's other components to this as well. He's got some Velcro attachments on there so that it will hold it in place and what not. So he's actually gone through and hacked this because it's not meeting his needs. So what they actually start tod do with HTML5 was take a look at what developers and designers were doing at a code level and started to look at those patterns that were emerging and decide okay well that's something that people are consistently doing. There's a need for that.

So the needs were kind of identified by looking at the web as a whole or as much as they could, and looking at the pages that were out there and the code that was there and identifying common themes that developers were using and looked at those and said, okay, well let's take those things that people are doing and let's build those into HTML because that's what people want. They also took a look at making some syntactical changes. So the syntax of HTML5 is in some ways simplified. Let's take a look at some of the major changes of HTML5. These are by no means the only changes. But these are some of the significant ones, or at least ones that I feel are fairly significant.

So the first most obvious change is the doc type. And the doc type in HTML5 is absolutely simplistic. In fact this is probably something anybody can remember. Compare that to the old doc types that we needed for HTML 4.01 or XHTML 1.1 or other versions. The doc types were very difficult to remember. The way forward with HTML5 is the doc type is, we're basically saying this document is an HTML document. Really simple. Easy for anybody to remember. Another significant change is the lack of requirement for typing. So when we used to do, put Java script in our HTML four documents, in order to have it validated properly, we would need to say this is a script tag and the content that is found within this script has a mime type of text/Java script. Basically so that the browsers would in theory parse it properly and understand that this was Java script based content. What ended up actually happening is for the most part Java script was the assumed language. And so what ended up happening, we could do other things. We could say that a script had a type of V B script, for example, and that would only work in Internet explorer. What ended up happening was that we were able to say, okay, we're going to put a script in the page, we don't need to type it any more. We don't have to say text Java script. That just become script. And Java script is the default and that's what's going to be assumed.

Now one of the interesting things, again, with this is this certainly makes one of our typical requirements for sort of technical accessibility is it makes this much easier to write valid HTML5. As we typically forget the script type equals text Java script anyway. So bringing it down to just script makes it much easier for people to remember and it won't cause those validation errors.

Some of the elements are gone. So things that we used to have, frames, acronym, font, big, center, strike, all of those elements don't exist in HTML5. One thing that we should clarify right now, we do have some new elements as well. And there are changes in elements in terms of the attributes that are available. In some cases, there's a change in the meaning of the element. And one of the things to remember is that this is still something that is evolving. So it may not be, you know, we're not at a final stage yet. It is fairly stable in terms of the latest working drafts. But new elements are being proposed. I wouldn't say all the time. But there are still changes to HTML5 that are coming. So I wouldn't say that everything is finalized now. But there are things to look at. So it is an evolving speck. So you should be aware that it could change at any point. So always check the latest and greatest before you make decisions about what elements to use. So the elements that are gone, frames, acronym, font, big, center, strike.  There's changes in the meanings of the elements. So small, B for bold, I for italic site. And we've got a significant change in an anchor. So the A element, the one that we use for links has actually changed now so we can include block level content in it. We'll look at what that means as we go forward. But it doesn't have some impact on how we create links and what we do within a web page.

There's also lots of other new stuff. There are API's, application programming interfaces that are available to us. These don't necessarily have specific accessibility implications other than the fact that we might actually be able to use these APIs to make our web applications and websites better than they currently are. So one of the applications might be Geolocations. So if we, you know, if we put our minds to it, I'm sure we can think of lots of different ways where having Geolocation information so when we're sitting there with our smart phone or in our browser, you know, we could use that Geolocation API in a positive way to create new accessibility features or new accessibility information that hadn't been created before. So if we were on our smart phone and it could, on the smart phone and we happen to be, it picks up that we're in a museum, it might actually be able to give us dynamically generated accessibility information for that museum, for example.

There are lots of new elements and there's also a number of changes to the way that the document outline is created. And by the document outline, I mean what we create ‑‑ when we create a set of headings in HTML, we have a document line. The same as you would in a Word document. And what the document outline is is that outline that's created from the heading structure and the other structures that you use within the page. So the document outline has a new algorithm. There's a new algorithm for creating a document outline based on a lot of the new elements that are there. And it's definitely something that is a bit more, it's a bit more detailed that I want to go into today. There's still lots of debate about how the document outline works and it's kind of confusing. So I think it's best if you want to look at that one, then it's probably best to take a look in that a little bit deeper on your own.

So we'll start with some fairly straight forward stuff. A couple of resources here. If you're just getting into HTML5 one of the best resources out there is from my friend Jeremy Keith. He wrote HTML5 for web designers. It's not an over technical look at HTML5. It's a very quick read and a nice overview of what HTML is and what it's going to provide and the types of new elements that are going to be in there, or the changes that are in HTML5. So this is a really good overview. Another resource that goes into a little bit more depth and is definitely more technical is introducing HTML5 by Bruce Larson and Remmy Sharp. So those are two resources that you should definitely look at if you want to get into more depth in terms of HTML5.

So one of the things that happens with HTML5, we've created a number of new, there are a number of new elements that have been created and there's the elimination of some other ones. And we just want to take a quick look at the semantics. A lot of accessibility comes down to the interpretation of semantic mark up by assistive technology. That's not the only consideration but it's definitely something that we need to consider. So I'll just give you a quick overview. This is a screen shot of one of our main accessibility sites. Simply accessible.com. And in the past, what we might have done was said that this area at the top is a div with an ID of header. And we might give home archives about and contact a navigational block within our website. That might be an unordered list. So a UL with an ID of nav. Or a UL with a class of nav. And that imparts particular styles to it.

Then we might also have something like div ID equals main. Or div ID equals content. Something that says this is where the main content starts. In HTML5, you know, after analyzing a lot of that data, they took a look at it and said ‑‑ when I say they, they very generically. I don't know exactly the people who did it. I know Ian hickson was one of the main people who looked at all of that data. But there were other people involved as well. What they basically created in HTML5 was something like this where they could say well we don't want to use div equals header anymore. What we want to use is a tag or an element that's actually called header. And for navigational purposes we want to create a tag or an element called nav. And for the main content of the page, so this is one particular blog post, the main content should be within a block called article. So there's a number of other elements that came about. But essentially what we're trying to do is find a way to build in some of the semantics that those bigger blocks like we used to use just divs, those divs really were semantically meaningless. We were creating meaning by giving them nice easy to remember I Ds or class names. But they weren't actually giving any semantic value or creating any implicit meaning based on the element that was being used. And just to your comment here that this sounds a lot like XML. And in a way, it kind of is. HTML was always kind of an XML or an SGML flavored language in the first place. And what we're really doing here with HTML5 is kind of evolving it to the next level and saying we want a simple, mark-up language, but one that is rich and lets us express things in quite a meaningful way.

So pretty straight forward. Let's take a look at another portion on the same blog post, we've got some other things in the right hand side bar here. We've got over in the search box there's an input type equals search. And you can see in this particular case, there's a particular style that we've given to it. But the search box by default depending on which browser you're in, takes on certain characteristics. So some of this, by saying we have an input type equals search, the browser has some implicit behaviors and display that are associated with that search or with that field. And if you take a look down in the side bar, you can see there's a little subscription area. You can see input type equals e‑mail with place holder equal to e‑mail at domain.com.

So what we are able to do with this is say, you know, in the past what we've had is input type equals text. And that's really been about as deep as we've been able to do with it. Input type equals text. We've had passwords radio buttons, check boxes. But for entering information, it's basically been text and passwords and some text areas. Now what we're able to do is provide a richer experience and say input type equals e‑mail. What that does is it gives the browser clues and specific ways to deal with this. So if you take a look at different browsers you'll see that an input type of e‑mail, it can actually do some built in validation to make sure that the e‑mail address that somebody puts in there, has the correct format. And what that does is it means that in modern browsers, the developer actually has less work to do because the browsers all support, the modern browsers all support that input type. So what that does is it takes some of the burden off of the developer to create validation mechanisms for that. What that also means then is that if the browser is dealing with that validation, the browser can start to communicate whether or not that is actually valid or invalid. And we don't have to worry as much about providing error messages in for certain types of fields in our applications. The browser can deal with providing those. And what that means is in theory, this could be at least a little bit more consistent from one application to the next. And it would be therefore, easier for a user of assistive technology, for example, to get the information or get that error message presented to them.

The other thing that you'll see here is the place holder attribute. So input type equals e‑mail, place holder equals e‑mail at domain.com. The place holder is actually specifically set is up to provide an example and the browser deals with this itself. Once you click in that form field, you will actually see that the place holder attribute automatically gets cleared out as long as the browser has support for that particular input type. So it allows us to provide a pattern or an example of the data that we're expecting in there which, again, should lead to greater usability for everybody. And for most people, you know, a lot of accessibility issues are really usability issues. They just happen to impact people with disabilities in a much more severe way.

Take a look at the last screen here and you'll see the bottom of the simply accessible site. We again see those form fields in the comment form on a particular blog post. We have input type equals e‑mail again. And then we have input type equals URL. So that URL is just another input type that says something that goes in this box should be formatted or should be in the form of a valid URL. And if it's not, then the browser can provide that feedback to the user. At the top of the page we have a header in nav. On the bottom of the page we actually have a footer in nav. They're simply named and very straight forward logical names. Hopefully that gives you a quick idea of some of the things we have in HTML5.

I'm going to show you the next one and the next one is one of my favorites. I'm using this all the time. It's more for within the body content. And one of the things that I've always disliked about putting images in pages is that we have ‑‑ we don't have a way of tying say a caption together with an image in a meaningful way. So the only way that typically the way that we would do this in an HTML4 or XHTML1.0  context would be to place an image in the page with alt text and then we would create a paragraph with a particular class. So paragraph class equals caption or something like that on it. And we would just place that underneath the image. So it would be the next item in the source. So what we've done there in our current mechanism is to create an implied association based on the position of those pieces of content within the document. What we're able to do with this particular construct, the figure construct is to create a package. So the figure, if you take a look at this, we have a figure element. Inside that figure element we have two other things: We have an image and we have a fig caption. So now the fig caption is the caption for that figure. And you can put whatever text you want in there. But what this does now is it programmatically allows us to say this is a figure for this package and it consists of this image and this caption that goes with it. So that really opens things up for us in terms of being able to create a really strong semantic association. Where we're creating an association explicitly rather than implicitly relying on the position of these 2 pieces of content within the document. So when we get a chance we want to try and make things as explicit as possible.

Now when we built this site there was a few scripts that we needed to use. Some of the browsers work a little bit differently in terms of their support for different HTML5 elements. I see you put a question in here and I want to talk about this one right away. So the question is if you use fig caption should you have no alt text on the image so that screen readers don't hear that text twice? So if you take a look at that page itself, the alt text isn't actually going to be the same as the figure caption. So if you take a look at the screen, you'll see that the figure caption that I have on there is screen shot. Here's an example of off left positioning used in the name of accessibility because it is more accessible than displaying none even though the implementation is much less than accessible. The alt text that is on there is a shorter version of that. And it maybe it could be shorter but I certainly haven't replicated in the alt text. So the alt text I have on there right now is an example of errant use of off left positioning in the name of accessibility. So it gives a brief statement of what it is. And then underneath that fig caption actually goes into a bit more detail. So you definitely need to be more careful how you phrase things. And when I'm doing my fig captions, I like to put that first word to give an explanation of what it is. It's a screen shot or it's an illustration or I might call it figure one. So if I have my fig caption I might say figure one blah blah blah blah blah and give the entire fig caption. And then my alt text even on the image might actually include the phrase, it might simply include the phase figure one and maybe one or 2 words. And we have that explicit association between the images alt text and then the fig caption that goes with it. And it's also something that you can use so in your text you're actually talking about figure one or figure two or figure three.

The fig caption is not actually invisible. So I see another question here, is fig caption invisible to sighted readers the same as alt text. No, the fig caption is out there for everybody to see. Just like you see it here, the words that are underneath the image itself, where it says screen shot, here's an example of off left positioning, et cetera, that's all in the fig caption and that is stuff that is exposed to absolutely everybody. And that's one of things that I do like about it is it takes something and makes it explicitly available for everyone rather than hiding things in attributes. That's one of the biggest criticisms, I think, of long description. If you're familiar with that attribute. And I'd have to double check to see whether it's in HTML5 or out of HTML5. It's quite possible that it's been in and out of HTML5 several times. But I do love the fig caption because it takes something and makes it available to everyone and allows us to create that semantic association.

So let's keep moving. A couple of other things. These are some of the tools that we've had to use when we were building the site. Because we've got different levels of support for HTML5, one of the scripts that we use and you should probably look at it as well if you're going to get into HTML5, is a script called modernizer. And modernizer essentially goes through your website. And you don't even need to write a whole lot of Java script for this. You can plug this into your page. And essentially what it does is it goes through the page and detects the capabilities of the browser. And if a browser supports a particular feature, it will modify the HTML element to have specific classes on it so that you can then write, essentially, conditional cascading style sheets. So if you have a browser that doesn't support border radius then you can write styles that will look okay when border radius is not supported. And then you can write another set of styles after it so that if browsers do support border radius and other features like multiple background images or whatever, then those browsers will override the non‑cool features with the cool features. That's my technical term for it is cool features. So modernizer is a script that really helps you with that. And it's definitely something to look at.

There was also some problems with Internet explorer and its support for existing versions of Internet Explorere and its support for HTML5. So remmy sharp created this HTML5 shiv that essentially goes through and it's a little bit of Java script that essentially goes into your page and figures out if you're using Internet explorer. And if it does, it does a few things to give HTML5 support for those new elements like article that we looked at and header and footer and nav, and allows Internet explorer to access those things with Java script to give you full styling control over them. So it's a script that goes through and allows you to do that. And it's really just there as a tool for compatibility with existing versions of Internet explorer that were built before HTML5 support was even required.

Let's take a look at the next area. So we'll look at some of the changes in the elements. And I mentioned this one before. One of the important changes is block links. So block links essentially allows you to wrap a link around two other block elements. So it used to be that if we to have a heading, like iron man 2, the movie, and then have a brief paragraph or a brief statement that also linked to the same review. So we might be in a scenario where we link a heading and a small paragraph to the same resource. What we used to need to do was put a link inside the H 2 and then another link inside the paragraph so both of those two were links and took you to the same place. That causes some issues in that there's multiple links on the same page that go to the same place. But more importantly, if we had a whole list of movie reviews, for example, then instead of having just one link for each, you would actually have two links for each. So for a keyboard user, we're creating more tab stops within the page that might be necessary. So what they created was block level links where you could wrap a link around block level elements and it's completely valid.

So what you see here is H raf equals whatever, and then inside that heading level two, iron man two the movie, and then the paragraph, I haven't seen this movie but I'm sure it will rock might illy. That will set you up so that the entire block, both the heading and the paragraph will become a link. Now that has some implications. That in existing browsers is not really a great way to do things. And you would need to change the style of it. But we've put together a quick little sample here for you and you've got the address there so feel free to go and check this out. So it's examples dot further ahead.com slash HTML5 slash block dot HTML.

So you can see on the screen I've actually tabbed to that link, that block level link and you can see how the link actually goes around both the heading about me and then the paragraph next to it, find out what makes me tick. So this makes it one tab stop within the browser. So we could very easily hit the enter key there and I would go to that target. So this could be very useful. There are some issues with it though. Nothing can ever be that simple, right? So generally speaking, this should be a good thing. But the behavior is a little bit erratic. So the fact that it visually works and we see it as just one link is okay. But one of the things that happens in existing browsers, if we write HTML that it doesn't understand, the browsers all have fall back mechanisms and error recovery mechanisms.

So what ends up happening here is one of the things that happened here in the conversion from my slides over to this format is a bit of the formatting was lost. But here's the behavior with JAWS 11 with IE8 and Firefox 3.6, when you have the page summary, in theory we have two links in the page. We have the about me and the find out what makes me tick text. That should all be one link. And the logo, the company logo that links to our page, that should be the second link. So in theory there's only two links in the page. But when you take a look at it in JAWS 11 IE8 and Firefox 3.6, the page summary, when the page first loads, JAWS tells us that there's only two links in the page. That part is fine. When we go into say all mode and read everything out. JAWS actually says the block link has two links. So it would read out heading level two link about me link find out what makes me tick. When you're tabbing through the page, it finds and reads only one link. About me heading level two link. But doesn't say anything about the find out what makes me tick.

When you look at the links list dialog in JAWS, we get this, one single link about me find out what makes me tick. So you can see here there's a little bit of confusion and that's part of, you know, working with newer code in browsers that don't explicitly support it. Where we're relying on their error recovery mechanisms to interpret this information. So the picture isn't great in JAWS. Even though there's only two functional links there, in some cases we're hearing it as three links and some cases we're hearing it as two.

In window eyes, so this was tested in window eyes 7.11 with Internet Explorer 8 and Firefox 3.6 as well. The page summary announces that there are three links in the page and it recognizes the block link actually has two links and the link logo itself. In say all mode, we read the block link as two links heading two link about me link find out what makes me tick. In tabbing mode we find only one link and it reads only one link with a tab stop at each. So link about me and link find out what makes me tick. So the behavior in window eyes is actually different. When you're tabbing through, you actually have two tab stops for that block link instead of just one. And the links list says that it treats them as two separate links.

In VDA similar results. We'll skip past those and voice over, again, similar results. I'll leave that for you to check out in archives and you can go and do some of the testing yourself. But ultimately the question is, so we've got this block level link, we've got these discrepancies in how different screen readers handle them. But the question for me is why is that happening and does it even matter? So why it's happening? Well again, it's because it's not explicitly supported. Because we don't have that final spec and therefore final implementation yet and it relies on those error recovery mechanisms. But the question, does it even matter is an important one. We have to take into careful consideration if we're going to use these block level links, the impact that it has on somebody. So is it a problem that the screen reader announces that there's three links in the page when really there's only two. Maybe when there's three or two, it doesn't matter. But what if we were doing links on a page where there were links to hundreds of movie reviews? We then go from a scenario where we're saying in the page sum that there are 200 links when in reality in the body of the page we're going through, there are actually only 100. Does that matter? I'm not sure. I think it really depends on the context. But it's something to be aware of when you're using any block level links.

In theory, as we move forward and we get proper implementations and fine specification, then that issue will disappear. But right now when we're dealing with those browsers that don't have that full on support for block level links and assistive technology that actually knows what to do with those block level links, we should use that type of construct with a bit of caution.

The other thing that we have in HTML5 is that whole group of input types. And we'll go through these quickly because we've only got about 14 minutes left here. There's new form input types and attributes and these things can be potentially really useful. We've seen some of them already. You see here, we've got a list. Type equals e‑mail, type equals tele, type equals URL. So e‑mail address, telephone number, URL. Type equals date. Type equals search. So we use that specifically for a search field. Type equals range. So this would allow you to select from a range. And we'll take a look at what that looks like in a minute. Type equals number. Type equals color, even. And then a whole bunch of other date related ones. Type equals date. Type equals date time time. Date time local, week month. So all of these have some interesting implications. And one of the best things I love about the form field types in HTML5 is that the way that browsers already work and what I mean by that is if you have an existing browser and you just type the word input in your HTML and you don't give an explicit type, the default is that it creates a text field. So what we need to look at here is if I create a type equals e‑mail in a browser that doesn't support that field type, what happens to the browsers if it comes across an attribute value that it doesn't understand? It just ignores it and moves on. So it's default will have different type equals e‑mail. If it doesn't support that explicitly, it will fall back to a text box on its own. So there's some built in graceful degradation for different form field types.

So one of the things that we need to take a look at here, if you take a look, we'll just examine some of these form field types. And you can certainly go to this page on your own. We've just some things that we use to test. And you can see all of these different form field types all on one page. So just pull that up. Examples dot further ahead.com slash HTML5 has all of our form fields on it. So you'll see here type equals search. You'll also see in the first name text box you'll see the word test and that is done with the place holder attribute. We also have type equals e‑mail, type equals URL and type equals tele. Now one of the interesting things about those fields and I think this is really important for, thinking about this in different context, on a regular desk top computer it's not as big of a deal. But these form field types, when you use these on an I phone or on a specific smart phone, those form fields are recognized and you will get an appropriate keyboard.

So when you say type equals e‑mail, it's going to give you a keyboard that lets you easily type in an e‑mail address. When you use type equals tele and you go into that form field, it's going to bring up a telephone number dialing pad so that you don't have to type in the numbers on the Alpha numeric keyboard. You can just type them in with your phone number key pad. It's a very context sensitive type of form field. And that actually has some potentially positive implications for people that use assistive technology. So if somebody uses an on screen keyboard to type into web applications and pages, those on screen keyboards could become context sensitive the same way we have on the smart phone. Even things like word prediction software could be context aware and realize oh we actually want to type in an e‑mail here so we're going to predict things differently than if we were typing just regular text.

Just take a look at the rest of the field types here as they come up. So type equals color, that let's you specify a hex color. In different browsers, I think opera browser, when you go in there it's actually going to let you go into a color picker. Then you'll see type equals range. So the range is actually a native slider that is built in at the browser level. So you don't even have to worry about creating those sliders anymore. Those could be things that are created at the browser level for you. The fall back, when it's not supported, is to just draw back to a text field. You can see type equals number there. That's essentially what's called a spinner. You can type a number in it directly or use the up and down arrow keys natively to increase and decrease the number in that text box. So that's actually, you know, there's some nice keyboard short cuts that are there. Type equals date. So date time, date time local, date month, week and time. Those things are all from what I understand, I saw a comment before about different date and time formats. Those are actually configurable at the browser in the computer level. So if your computer is set to have a particular format for dates, then these fields because they are tied into the browser level, to the operator system, those dates should be formatted in your local format.

And then the final one and when you look at these, look in different browsers as well. In opera there's actually the date picker, when you look at an actual date, when you click in the field, you will actually get a calendar picker widget. You know, the types of date pickers that we've been putting into our pages with Java script for years.  Those things are actually going to, at some point, be within the browser itself so that you won't need to worry about adding Java script for that. You can rely on the browser to pick that calendar widget. And then the final one there is type equals data list. And the data list is kind of that traditional combo box where you can either choose from the types that are already there, sorry, from the data that's already there. Or you can start to type and it will treat it like a combo box where it actually starts filling in the letters for you and narrows down your choices in that data list.

So I see a couple of other questions in here. Do you need extra code to validate inputs? In theory there's two things that happen. One is that the browser will do some of that validation for you. The other part is that you can actually use a pattern attribute that you can specify a regular expression that will do extra validation for you. So you can say give it this pattern, the data has to match this pattern. And then if it doesn't, the browser will give that feedback to the user. So you don't have to deal with it. You still need to explicitly do something with it but it's not something that you need to worry about how the error message is going to be displayed or anything like that.

Another question, Ryan. Can you use the new input types when not using the HTML5 doc type? You quite possibly could. I'm not sure what the recovery mechanism would be for that, whether or not it would recognize them. It's quite possible. It might be worth a try. We haven't done that. I wouldn't do that but I certainly can see how, you know, if you were say retro fitting an application or something like that, where you might want to do something like that. To be honest with you, we haven't tried that but that may be something that is possible.

Do you need require expression editor to input into a certain format? I think that goes back to that pattern attribute that we talked about as well.

So feel free to go and play with that file, again, you'll have that address. You can go and see what's there and see how different things work with it. The HTML5 elements, we've also got a sample page that shows you different things to hear how they're read. We've got articles and different headings and different elements just to see what is there in terms of how these things actually work. So feel free to go and work with those.

We'll talk for just a minute about canvas. Canvas is a pretty amazing innovation. And one of the things that it lets you do is basically for doing dynamic graphics. Believe it or not, this is a screen shot of an asteroids game that was all created with Java script and HTML5 and canvas. It's really quite amazing. I'm not sure how accessible it is in terms of, you know, well I do know how accessible it is. You could be able to potentially use the keyboard with it, which is great. But the problem with this is that canvas is essentially a way of dynamically generating and creating images. It's inherently a very visual medium. Right now it is simply not accessible. You can provide a fall back within canvas. So it uses a traditional fall back object containership model where you have an element. And if you don't understand that element, so if the browser doesn't support canvas, it would just move on to the next content. So you could put alternative content within canvas. But that gives you really, that's a fall back issue. That's a more of an interoperability issue than it is an accessibility issue. So right now canvas is not accessible. There is work to find ways of creating some accessible content within canvas. That research is going to continue. And that's fine. This is really emerging technology and we need to keep moving forward with it. We can't expect it to all be perfect before we even have a fine specification.

So we're going to finish with a quick look at video and audio. And these are some of the things that people are really interested in in terms of HTML5 because doing video and audio on a web page used to require flash. And there's been a lot of people fighting over this. I'm not one of them. Again, I like to see work, see innovation and see what happens with it. So HTML5 has inherent audio, it has built in audio and video support. So again, a URL that you can go and check. One of the things, and you can do things where, you know, you can even set this up with external controls. So there's another example here. Examples dot further ahead dot com slash HTML5 slash video dot HTML. We've actually used a set of external controls for playing and pausing and for muting and turning the volume back on and that's for a very specific reason. One of the issues that we have with video and audio right now is that all the browsers have different implementations. So you'll see different things in different browsers. The native video and audio will be supported but the controls will be a little bit different. Then there's different ways of accessing the controls. So one of the things that you can do with video and audio is use controls attribute, that puts the native controls, displays the native controls. If you don't put it up there, then you don't have any way of controlling it natively. So we actually prefer right now to use our own set of controls, like we showed in that last slide with the external set of controls. The reason we like that is when I say the native controls may or may not be accessible, it's because in some of them, you can't actually get to those controls with the keyboard. So what we have done in different context so that we have a solution that works across all of the browsers is we do everything with an external set of controls so that there is consistency no matter what browser you're looking in, no matter what screen reader combination you're looking at. We've got them set up so that they're not even part of the audio. They're using Java script to control the audio and control the video. But there are buttons that live outside of that video or that audio container so that they're really easy to control and easy to get at with a keyboard.

There's also no built in way to do captioning. That will change over time. So right now you have to come up with your own solutions. So we've come up with our own solutions for the controls and for your own controls, your own mechanism for captioning because it doesn't exist by default.

So that's really a quick overview of HTML5 accessibility and the types of issues that are there. I hope you've got a number of, you know, there's a lot of examples in there that we've provided for you and hopefully you get a chance to go and play with those. HTML5 is a pretty exciting innovation for, you know, in my mind anyway. I think it's quite useful and will help to move the web forward. So getting native, getting some more semantic into the language force so that we can be a bit more expressive is something that I'm really looking forward to.

So just to wrap it up, just some other URLs for you, the simply accessible.com is our website. You can go there and look at it as an example. We also write about accessibility there. We also produce our own virtual seminars that you can get at store at further ahead.com. We've got a couple there and more coming soon. Another great site is the HTML5 doctor.com. One I forgot to put in the slides which I'll get a revision out there, HTML5 accessibility.com is another great one. Hopefully I've been able to answer your questions and give you a good introduction. If you need to get in touch with me, feel free to. We do lots of accessibility work. You can even call me, I don't mind. And I'm feather on Twitter. And if you're looking at any of our websites, we've also got a newsletter there that you're certainly more than welcome to sign up for. We've got lots of things that we publish including one thing that a lot of people like for our newsletters subscribers is we give them a discount on any of our training. Our training courses either in person or our virtual seminars. So with that I'll say thank you very, very much. It's been a pleasure to be here.

NORM COOMBS: I want to give a real vote of thanks for Derek and for all of his work in accessibility and HTML5. But in particular I want to thank him for extremely informative webinar that will help us all understand what's going on. While there are obviously problems, there are lots of room for optimism. So thank you very much Derek. And I'll make this the official end of the webinar. But if people want to hang around and talk to Derek or talk to each other, you can do that. Thank you very much.