Transcription: Web Axe Episode 81 (HTML5 and John Foliot)

[Introduction, woman's voice over music] Welcome to Web Axe, practical web accessibility tips. Web Axe dot blogspot dot com. Web Axe. Web site accessibility. Web standards. Web Axe dot blogspot dot com.

Dennis Lembree: Hi this is Dennis, and welcome to Web Axe podcast number 81, HTML5 and John Foliot. And I have John on the line.

John Foliot: Hey Dennis, how you doing?

Dennis: Good. How are you doing tonight John?

John: I'm doing very well. Thank you very much.

Dennis: Good. Sorry to take you away from your television show tonight. [laughs]

John: No worries. No worries.

Dennis: My wife and I missed our show. So…

John: Ah.

Dennis: There you have it. But this will be a much more interesting discussion I think than…

John: I hope so.

Dennis: …tonight's American television. So…

John: Yeah.

Dennis: [laughs] So John, you work, your day job is at Stanford University in Palo Alto, California.

John: That's correct. I run the Online Accessibility Program at Stanford. Essentially, I work with content producers on campus. It's a lot of education outreach. And then I work with developers on specific techniques to ensure that content is made accessible.

Dennis: Great, great. And I know last, well is that September you had a bar camp right? Like an unconference that I attended.

John: Yeah. We had the first of hopefully an annual event last summer where we had a number of attendees come. Working on something for this summer. Details are still being brought together.

But this year I hope to have a number of fairly high profile speakers join us. And to really try and get people to come on out. The day is going to be really sort of structured along the lines of, this is the web today. This is really cool. This is where it's going.

And rather than focusing exclusively on accessibility, I want to try and weave accessibility into the day, and just make it part of the day. Because I mean, for those that work in the accessibility field, and Dennis, I know you know this.

That the moment you start to ghettoize or sort of hold accessibility out at something special or different, sometimes you lose traction, you lose interest.

But the reality is that accessibility and accessible web development, needs to be part and parcel of everything you do. It just needs to be part of the whole process. So…

Dennis: Right.

John: … I want to try and weave that concept into the day as well. And stay tune for details. I'll certainly let you know. I know you have a lot of people that check your blog at a regular basis. So, I'll thank you for your advanced support.

Dennis: [laughs] You're welcome. And I will definitely try to attend. So what else do you do with your time? You are a member of the W3C I understand.

John: Well I am a member of the W3C. I mean anybody…

Dennis: An active member. [laughs]

John: OK. So I'm an active member. Anybody can be a member of the W3C. Basically, all you have to do is volunteer. They have very few people that are actually paid. It's a large of enough organization that there are paid staff. But most of the work that happens in the W3C is done by volunteers that step up to the plate and get involved in an area that interest them.

And so I've been very active in the WAI, the Web Accessibility Initiative at W3C. I've been working in that group for about 10 years now.

And specifically these days with the advent of HTML5, a task force was set up in November of last year to look at the various accessibility issues that were being highlighted or emerging in HTML5, and try and work in the consensus space approach that is the W3C, to resolve those issues and come up with solutions, and ensure that that gets added to the HTML5 specification.

Dennis: And…

John: And in that regard, I'm actually working very specifically in the area of accessibility of media content. So the new video element, the new audio element, and how to ensure that those things can be made accessible.

Dennis: OK. Great. I guess we'll just jump…well actually before we jump into it, I just want to mention other things that you do for the community on the web including your blog, Unrepentant.

[laughs]

John: Yeah. That's me.

Dennis: An awesome thing that you did and took the bull by the horns. Was a several weeks ago now, there was the US House of Representatives committee on the judiciary website, had some PDFs of what was just some hearings and testimony.

And the PDFs sadly weren't accessible in themselves when the testimony was about web accessibility. But you went ahead and did it and made it accessible. So thanks.

John: Yeah. Well, thank you. So I've always been a firm believer that it's really easy to stand on the sidelines and complain, but that's only half the job. And so you have to be prepared to sort of step up and do something, and do something about it.

So in this particular case, they're talking very seriously about opening up the ADA or extending the ADA specifically to cover web accessibility issues. And so there was a number of people that made presentations to this subcommittee. And yeah, their presentations in written form were submitted as PDFs. The PDFs were not tagged.

In one case, it was a really kind of old school PDF which is essentially a giant picture.

Dennis: Yeah, it's a scan.

John: Yeah, exactly.

Dennis: That's the first one that I came across. I thought they were all like that. So I wrote a Tweet. But yeah, that something …stuck with [overlapping talks]

John: There were a couple of people that were a little bit kind of flabbergasted at it, as was I. But again, it was kind of like, OK, well, it's really easy for the accessibility people to stand on the sideline and wave our fingers and going shame on you, you should know better. You should do better. But I thought well, maybe they don't know better.

And we have to give them the benefit of the doubt. I mean there was four documents. It took me about, I don't know, maybe an hour and a half, two hours all told. And I converted them into HTML and posted them as links off of my blog.

And it was kind of like, here you go. It's not that hard to do. Look, I was able to do it. And look at how much better this is and how much more accessible it is. And so, lead by example. And I even said… if the government wants to come and take them, please do, and use them because…

Dennis: Yeah.

John: … they meet the needs of people with various disabilities in a much better fashion.

Dennis: And I will of course, add the link to your blog in the show notes. So for everybody listening, look for that. Check it out.

John: Yeah. It's john.foliot.ca.

Dennis: OK. So let's get into the HTML now. Can you give us just a quick background of HTML5, how long it's been going on and…

John: Sure. So one of the things that I think a lot of people need to sort of understand is that HTML5 is almost becoming a brand, kind of like Web 2.0. Because HTML5 today encompasses a whole lot of techniques and technologies that are all interwoven together.

I guess the one common thread is that they're technologies that are delivered over the Internet and for the most part very much involve the use of a web browser.

So from there you have things like geolocation, and you've got local storage, and web workers. And all of these different types of things that are very cool technologies that are being extended to the browser and more importantly, the behaviors, the expected behaviors of how these things work are being very meticulously defined.

So that frankly, anybody who want to build a browser today or tomorrow, could take the specification and use the specification to build a browser that would stand shoulder to shoulder with the major browsers out there, whether it's Mozilla or Web Kit, which is Safari and Google or Opera.

Even IE 9, a lot of the work that's happening at Microsoft now, you know, IE nine is really leading very heavily into the work that is coming out of HTML5. So IE is not dead yet by any stretch of the imagination.

Dennis: [laughs] Hopefully not too little, too late for them. We'll see.

John: Well, so they've slipped and they may never have the full market share that they once had, but see what I'm seeing with some of the early work that's coming out of the development snapshots of IE 9. They're back on the horse. They're back in the game and I think they'll be a serious contender.

One of the goals of HTML5 is that browsers will almost be identical in terms of standard support and where they'll compete is on features. So for example, right now the Mozilla browser Firefox the feature that really sort of sets it apart from other browsers, although prone to a certain extent, but Firefox is really spent a lot of time working on the plugin architecture and the ability for third party authors to write plugins that work with Firefox.

And so a lot of developers and a lot of people use Firefox because of those plugins and when you ask people why do they use Firefox that's often the first reason. Oh, because I've got this plugin, that plugin and the plugin that I couldn't live without. So yeah, I think that's kind of an example of how the browsers are going to compete on features rather on the way they render documents in screen, on page.

Dennis: Right. Right. That makes sense. Or like how the date is like a new element or a date input and I believe browsers can like… so instead of everybody having to do crazy JavaScript and stuff to like render like a calendar to input in a date, like the browsers will eventually be able to do that. Right?

John: That's correct. So in forms and so forms in HTML5 is really based on previous work that was being done in a specification that was known as "Web Forms." And so they've introduced a couple of new input types of which date is one that you mentioned.

Right now the only browser that supports the input type of date is, in fact, Opera. And in the Opera browser when you put focus on that form input, the little calendar that we're all very familiar with seeing whenever you have gone to book a flight or book an event on a web page.

Rather than as you said, being done in JavaScript, it's being rendered natively by the browser. So the advantage there is that less code being pushed up and down the line because all of the functionality that's required to do that is built into the browser. As well, you have a more consistent user experience from site to site because if you're using that particular browser the date picker is always going to be the same.

Dennis: Yeah.

John: So always be the same, I mean, so there is some talk about the ability to be able to style it to a certain extent. We're not there yet. HTML5 is very much still a work in progress but I think those are some of the things that we're going to see.

You know, there's other keyboard… other import types that have been developed that… for example you'll see them on platforms like the iPhone, where depending on the input type you'll get the different keyboard on the iPhone. So there's three different keyboards available on the iPhone platform that are exposed to user depending on the input type.

So those are the types of things that HTML5 are starting to push forward.

Dennis: OK. And that brings us to one of the questions I had in my notes. Basically why or how is HTML5 better for accessibility? And it seems to me like in a nutshell that because it's standardized and because these elements and everything are the same across the browser, they're all more natively accessible to the browser. Is that in a nutshell why it's more accessible?

John: That's certainly one of the reasons. The problem with HTML4 as to HTML1 is that as an authoring language it really hasn't evolved much in 10 years. But the web has and so where 10 years ago the web was very much a one-way kind of push type of thing. You would go to a web page. You'd look at the page. You click on links and that was about the sum total of your interactivity.

Now we're starting to see a whole bunch of full blown applications that are being developed and delivered to the web browser. So the need to extend that semantic structure and to be able to understand what's going on, to be able to convey that directly to the user agent, the browser, so that it can be picked up by the accessibility APIs on the various operating systems.

It allows that to streamline considerably. But there's also been some new elements that are being introduced into HTML the markup language that will also improve accessibility.

So for example ARIA which is the accessible rich Internet applications had one of the foundations of ARIA's this notion of roles and states. And so we have a series of landmark roles that identify what this Div is and what that Div is. And so, the authors of HTML5 they started looking at some of the Div's that were being used or being replicated on a regular basis in a process very similar to what the ARIA people were doing.

And they identified common roles and so they've actually created new elements for those roles. So you've got a footer element and a header element and a side element and an article element. Yeah, …

Dennis: Yeah, section, article…

John: Right, because these are things that will be needed on a regular basis but they were DIVs with IDs or [overlapping talk] and so you could style them and visually you could see what they were. But a Div as far as adaptive technology concerned, it's a blank page, it's meaningless. It really doesn't have any inherent meaning or structure. So there's a lot of that that's emerging.

Of course I mentioned earlier, I'm very interested in some of the multimedia stuff and so you've got the canvas element and you have got video and audio. And so the advantage of those is that they're reducing the dependency on plugins…

Dennis: And JavaScript?

John: Well…

Dennis: Yeah, well the JavaScript is usually used with the Flash plugin and all that crazy stuff, but…

John: Right, so Java Script is still an important part of HTML5. Some of the functionality that's generated or that's being recreated time and time and time again in JavaScript is actually being moved into the browsers as native behavior. Again, we look at that day picker widget.

But the other thing that we're seeing and again, when we talk about HTML5 the brand is we're starting to see JavaScript really starting to come into its own. It's a fully fledged member of the authoring stack now.

One of the other advantages is that we're starting to see the emergence of all of these standardized libraries, whether it's jQuery or Dojo or YUI3 and so there's a lot of standardization and a lot of modularization that's going on. That these libraries are being tested and vetted for accessibility. And they're including ARIA. So ARIA is going to be part of the official HTML5 specification, which is really good.

Dennis: Let's take a good and maybe a not so good example. I believe there's a new dragon drop API in HTML5?

John: Right.

Dennis: Now that's a good example, in addition to like audio and video, of something that was difficult to do before and was difficult to make accessible, but it's looking like will hopefully solve the problem.

John: Well, to a certain extent, yeah. I mean, so we've got drag and drop and for many users the idea is in fact going to be a very useful feature. Because it's how many people are used to interacting with their computer already. But really when you think about it, all the drag and drop really is a variation on cut and paste or copy and paste but more cut and paste.

And so, that function of taking some data or taking a text string or something and cutting it to a temporary storage or like your clipboard and then pasting it somewhere else, whether you click on it and drag it from point A to point B or whether you click on it, cut and then click on point B and paste.

There's a fluidity for visual users but the functionality of moving content from point A to point B, because it's native to the HTML, it can be mapped to the accessibility API so that a non-sighted user can still focus on the content, copy it, and then move to the area where it needs to go and paste it. Right?

So, again, the whole thought process, the whole work flow of what it is that we actually achieve has been addressed and is being conveyed to the accessibility API. So, it's not a great example, but it certainly is an example of how the thought has gone into some of these things in HTML5 to ensure that accessibility is being baked in.

Dennis: Now, what about canvas? [laughs]

John: What about canvas? Well, so canvas is probably…

Dennis: Can you quickly explain what it is, and then the issues with accessibility and what are solutions?

John: Sure. So canvas is essentially a way where you…a developer can use JavaScript to actually paint pixels on the screen. And so it's, in some ways, very similar to SVG but, in other ways, very different to SVG. But it allows you to actually sort of paint pictures on the screen.

The problem is that because it's being done in JavaScript, those pixels and the movement of the pixels, which are all being scripted, they really don't have any kind of a hook in it for the adaptive technology to actually sort of understand or reinterpret and convey in an alternate means.

Dennis: There's no text in it either, is there?

John: No, there isn't.

Dennis: No native text, yeah.

John: There is no native text, really. It's all just pixels drawn to the screen. So, it presents a really huge accessibility problem and an accessibility challenge.

So, there are a couple of proposals that are sort of working their way through the process right now. The Accessibility Task Force at the W3C has one that's fairly well-formed and will likely be offered to a larger HTML working group in another week or so.

And it's been referred to by a couple of different names over the haul, but the name that I kind of like, because it really sort of illustrates it the best, is we're creating what's called a shadow DOM.

And so, what we can do is we can actually specify, using techniques similar to ARIA, key elements that are being painted or drawn by the JavaScript that can be mapped to the DOM so that adaptive technology, and specifically screen readers, understand what's going on. And so you may not be able to convey all of the visual richness that's being painted.

Dennis: Yeah.

John: But in terms of key functionality, you'll be able to get in and out of those types of things.

There's another proposal that is not as fully formed. A good buddy of mine, actually, Charles McCarthy Neville, or "Chaals" as he's known to the world…

Dennis: [laughs]

John: But essentially, there's a proposal that sort of originated out of some of the people out of the Opera web browser camp, where we can use the image-map technique that was defined in HTML4, and by making it a little bit dynamic, but still using the basic concepts of an image map. An image map, of course, is inherently accessible because the regions are defined, and so they're easy to pick up in the DOM, and inputs and whatnot can all be very easy to find in an image map.

So, the idea is to take an image map and, for interactivity, if your elements are moving around, then you can sort of map that using JavaScript, but the actual, key pieces of interactive information have been mapped and are being conveyed to the DOM.

So, one is kind of that the shadow DOM concept is very complex and complicated. But it's very, very complete. The image-map proposal is kind of a light version, or a lighter-weight version, that would be easier to implement but wouldn't be able to extend as much functionality. So…

Dennis: OK.

John: Both of these are still in the evolutionary stage. They've not yet been added to even the draft specification. They're being prepared to be presented to the larger working group.

Dennis: Let's move to the browser support. So in the latest browsers, the major browsers, there's pretty good support for HTML5 already, right?

John: There is. So the history of HTML5 was, originally, work on the specification that we know as HTML5 today actually started outside of the W3C, in a working group called the WHATWG.

And essentially, it was a group of engineers that worked for the number of the different browser companies, who were concerned with the direction that HTML was going at the W3C, back five, six, seven years ago, when the W3C was very heavily focused and invested on working on XHTML 2.

The problem with XHTML 2, as it was described, [Dennis laughs] was that it was not going to be backwards-compatible with XHTML 1. They basically were starting with a fresh sheet of paper. And the browser manufacturers were going, "Well, wait a second here. You want us to do two completely different rendering engines, two completely different software code bases under one browser hood. That's next to impossible."

And furthermore, they didn't think that the Semantic Web, as was being described by XHTML 2, was the only way that the web was going forward. They very much were looking at sort of the practical implications and web applications being delivered through the browser. So they split off, and they started working out on some specifications.

So, in the very early days, because you had the major browser vendors kind of all working in concert, working together, they were looking at things and going, "OK, well, this is what we want to do" and they agreed on how to get things done.

And equally important, they agreed on error handling so that, if you had a problem in one browser, you got the same kind of problem in all of the browsers. So they really were, again, looking to sort of level out the playing field with this concept of "compete on features, not on functionality."

So, after a couple of years of that, they kind of got folded back into the W3C family, as it were. Tim Berners-Lee essentially had a meeting where there was a discussion, and they decided to bring this work that the browser vendors were working on, bring it back into the W3C, and allow it to work and grow inside the W3C organization.

Which is really important for the browser vendors as well, because, for large organizations, governments, academia, financial sector, the medical sector, the energy sector, I mean, any industry outside of the tech sector, they very much need to have a very predictable and sort of rock-solid standards that they can rely on. And the W3C is, in fact, the home for that when it comes to things on the web. So…

Dennis: So they split off and brought it to W3C, and then it was kind of born from there, and then they called it HTML5?

John: Well, they were calling it HTML5 before it was rolled back into the W3C. But essentially, the work that had been done outside of the W3C was brought in and was taken up by the large organization that is the W3C.

A couple of things that happened as well is, there's a little more protocol, there's a little more process involved in standards creation at the W3C. While it still very much works on a consensus basis, they're very mindful to ensure that anybody that has a horse in any given race has an opportunity to comment and provide feedback and input.

One of the problems with the WHATWG was it was just browser vendors and a very sort of large developer community that was offering suggestions and feedback via mailing list, but there was no real kind of resolution process or structure.

If you had two camps that were sort of in disagreement at the WHATWG, basically the editor was solvent. He made the choice, and whatever he decided was the way it went. At the W3C there's more of a consensus building process. And there is a process whereby if consensus can't be built, there is an escalation process that…ultimately, if it needs to, will end up as a vote, although that's the least preferred method.

If it really comes down to irreconcilable differences, there is a voting mechanism in place. So having that kind of organizational structure brought some rigor and some respectability to HTML5 as well.

Dennis: OK. So if I wanted to implement HTML5 today, it seems like that's totally doable in the mainstream browsers that's supporting it except for maybe a JavaScript injection and IE, right? [laughs]

John: Right. The problem with IE is that they were kind of late in coming to the party. For whatever reason, Microsoft was not part of the WHATWG and still are not part of the WHATWG today. So their work on HTML5 started a little later than most. IE8 really doesn't support a lot of HTML5, almost none. I think we're going to have to wait to see IE9 before we start seeing it.

But that being said Microsoft is in horns, hats, and whistles as the expression goes. So it will take a while from the catch-up. But for developers today, there's a lot of stuff in HTML5 that you can use and you can use successfully. Some of the more experimental stuff, you take your chances. And all the different browsers have focused on different aspects of what it is that they want to support.

So for example, we were talking about web forms earlier. So right now the best browser for support of web forms is, in fact, Opera because that was important to them. And so they've continued to work on that, as is their work in SVG, which is scalable vector graphics. They've done a lot of work in that area.

Other browsers have focused on other aspects of the specification. I know WebKit in particular has done a lot of work on Jewel location because, of course, that's important to them because WebKit…

Dennis: [laughs]

John: Well, it's the browser on the iPhone, and so Jewel location and mobile devices is a really big and hot topic. The problem is that even though we've got these specifications emerging and the browser venues are agreeing on OK, that's how we're going to do this, that, or the other. The reality is that work is happening in asynchronous fashion.

So depending on the browser of choice, you're going to get more or less support on various…

Dennis: Yeah.

John: What I mean…

Dennis: The basic stuff is pretty widely supported, though.

John: The basic stuff is quite widely supported, and even some of the experimental stuff is getting there quite quickly.

Dennis: OK, that's good. Do you have any recommended resources for folks that want to start doing HTML5 or learning more?

John: So some of the best resources out there on the web. So a gentleman that I don't always see eye-to-eye with but who has done a lot of work in documenting and explaining what you can and can't do in HTML5 is Mark Pilgrim. Mark works for Google, and his regular blog is called "Dive Into Mark." But he also does numerous postings on HTML5, so that would be a good resource.

Dennis: Oh, yeah. I looked up, he has a Dive Into HTML5 site now.

John: Correct, correct, Dive Into HTML5, which eventually is going to be a book that he's also writing. So there's a number of books that are being authored right now that we'll probably start to see on bookshelves mid to late summer, certainly in time for that gift-giving season later in the year.

So they're starting to emerge. One group in particular that I know has been doing a lot of really good work, and I know two of the people involved with this personally, is HTML5 Doctor…

Dennis: Yeah, that's a good one.

John: …which is Bruce Lawson, whose works for Opera. He's part of the developer relations team at Opera. And Remy Sharp, who is a UK-based web developer. He's also very active in the jQuery community. He works quite closely there and has contributed code. And he's really involved in that.

Dennis: Those two are also very humorous on Twitter.

John: They are.

Dennis: [laughs]

John: They're great guys. Well, they're good friends, and they are actually working on a book as well. That's well on the way to …heading off to the publisher as a matter of fact. I think it's in editor review at this point. So that will probably be out in another couple of weeks as well.

So those are two resources that I would point to. Of course, there is the editor's or the draft specification, which you can find at the W3C website if you go to W3C.org and click on the link for HTML.

Dennis: Yeah, I'll put all these links on the show notes.

John: Yeah. So now the problem with that is that it's a very MIDI spec. I mean it's heavy. There's a lotta, lotta stuff in there. And for average web developers, there's a lot of stuff in there that may not really be of mainstream interest to them because it's really specifying how browsers should handle specific events or what have … [overlapping talks] .

Dennis: I found one resource in there that's pretty good. It's called "HTML5 Differences from HTML 4."

John: Right.

Dennis: And that's a good one maybe to start at, it explains which elements are not being used anymore and just a lot of the elements we talked about. It doesn't go into too much detail, you know?

John: Right. It really is a differences document, and that's being maintained by Anne van Kesteren who's been very active in the authoring of HTML5. So that's a good resource. It's a very accurate and up-to-date resource. There's another document floating around out there, Dennis. I'd have to go hunt for the URL for you, but it's called H.TML, which stands for HTML The Markup Language.

And so, that's being worked on by a guy by the name of Mike Smith. And it focuses on just the markup stuff that web developers would be interested in and doesn't really look at some of the other mechanical back-end things that browser implementers would be interested in that are also being specified in the HTML5 specifications. So we can dig that URL out and get it posted on your blog as well. But that's a good document…

Dennis: Anytime.

John: … and that's nearing completion as well. All of these documents are in draft status. They're all sort of working concurrently, simultaneously, at the same time as different people take on different aspects of the work and try and make it easy to understand because it is. It's complex. It's very, very intricate and very interwoven. There's a lot of moving pieces.

Dennis: Yeah. OK, great. Well, I think that's all I can handle for tonight. [laughs]

John: All right. Well…

Dennis: But I think we covered all the bases, and I really appreciate you taking the time out and coming on the show, and sharing all your expertise.

John: No problem, Dennis. Just maybe before we go, I just want to say to anybody listening that if you want to get involved in seeing how HTML5 is being crafted, if you have thoughts, opinions, comments, commentary, there's a lot of different ways that average mainstream nine-to-five web developers…little guys if I can say it that way…we need that input.

And it's certainly easy to do. If anybody wants to jump in, I would encourage them to do so. It's fun, it's interesting, it's exciting. And it doesn't really require a lot of effort. Just get involved.

Dennis: Good. Good advice. [laughs]

John: Thank you.

Dennis: All right, John.

John: All right, Dennis. Thanks very much.

Dennis: Thanks again.

John: All right. Take care.

Dennis: Yeah. You, too.

[music and commercial]

[END]