"I got a grass-seed in my eye the New Year's Day before last," he remarked ... "I could n't see to catch a horse; and it took me about six hours to grope my way along the fences to Dick Templeton's hut. I thought I'd have gone mad."
Tom Collins, 1903, Such is Life.Note: This page was prepared for Making Links 12 November 2008. So any dates, predictions and timelines given here are accurate as of November 2008.
Gaynor Eccleston, from Vision Australia, apologises that she cannot be here. If she had been, I'm pretty sure that she would have given a much better talk than I am about to give.
For my part, I apologise that I am not Gaynor Eccleston. She is smart and wonderful and really knows her stuff, while I am... Jonathan O'Donnell. I'm from RMIT and I've been associated with Web accessibility for at least ten years.
And, lastly, I would like to apologise that you have to come to talk, and that I need to give it. Over the last ten years, we should have fixed these problems, not made new ones. Unfortunately, that isn't the case.
What is Web 2.0? I expect that I will get answers that include technical replies, like JavaScript (or ECMAScript) and Asynchronous JavaScript and XML (AJAX), and some examples like Wikipedia, Flickr, FaceBook. It is also about community and user-generated content. And I expect that I will get some answers that I don't expect.
What is Web Accessibility? I imagine that people might mention people with disabilities, adaptive technologies and the Web Content Accessibility Guidelines (WCAG), along with other things that I won't expect.
Second Life, it seems to me, fits the definition of a Web 2.0 site. It has a strong sense of community and people create the content on it. Judith, who has cerebral palsy, loves it. She uses a head wand to find her way around, as shown by this video, Wheeling in Second Life.
So what are the accessibility problems with Web 2.0? I expect that people might talk about JavaScript and AJAX again. They might talk about the poor descriptions that people give to images. They might talk about the widgets that drive you crazy on MySpace pages. They will probably mention Captchas. Really, I don't know what they will talk about.
Focus is important. For people using adaptive technology, focus is very important. It is where your cursor is. When you are reading a Web page, your cursor isn't anywhere really. More precisely, it doesn't matter where it is. But when you want to do something on a page, like click a link or fill in a form, it is really important where your cursor is. You need to be able to focus.
Lots of Web 2.0 stuff plays havoc with focus. Either it doesn't have it at all, so you never know that you can do anything with it, or it changes focus without telling you. AJAX is often used to do this. It updates one part of the page, without reloading the whole page. With some adaptive technology, that means that you never get told that anything has changed. Great! Just what you want.
At the moment, there is no way to indicate what role a part of a Web page might have. For example, most of us can recognise the navigation part of a Web page and the main content part of a Web page. But adaptive technologies can't because there is no way for an author to indicate this in a structured, coherent way.
This is particularly a problem for Web 2.0 because Web 2.0 widgets often are built as discrete blocks, as objects. In the Web 2.0 world, whole regions of the screen are being built as blocks that are essentially impenetrable to assistive technologies. That is a bad thing. Without being able to declare what their role is, there is no way to decide if you should skip over them. Or what to do with them. Think about a Google map, for example. How does an assistive technology know what to do with the map portion of the screen?
Pressing a key on a keyboard is an event. Clicking a mouse is an event. Adaptive technologies understand these events. There are defined ways to pass information about those events to assistive technologies.
Web 2.0 is full of events that assistive technologies don't know anything about. Think about Google maps again. What is the assistive technology to do with an event like sliding the zoom in - zoom out slider. A value is changing, but there is currently no way to pass that on to the technology. Something might change state (from on to off, for example) with no way for the assistive technology to see that it has happened, much less respond. And lets not talk about the situation where multiple events are happening at the same time, or very quickly, one after the other. That causes all sorts of confusion.
So there you have it. Web 2.0 applications have no focus, no role models and are organising all sorts of weird events. No wonder they are getting a bad reputation.
As at 8 November 2008, the World Wide Web Consortium (W3C) has released Web content accessibility guidelines 2.0 as a candidate recommendation. That means that it should become a Recommendation (W3C speak for standard) quite soon - possibly early next year. It has been a long time coming.
Please note that the '2.0' is a version number. It does not mean that WCAG 2.0 is explicitly related to Web 2.0. W3C was working on WCAG 2.0 well before the term Web 2.0 was invented.
It is a significant change from WCAG 1.0. It has been based on four principles:
Information and user interface components must be presentable to users in ways they can perceive. You have to be able to 'see' them, so to speak.
User interface components and navigation must be operable. You have to be able to make them work.
Information and the operation of user interface must be understandable. You have to be able to comprehend it.
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. It should continue to work in the future, too.
There are two features about it that I really like:
This is important for developers. When you build a Web page, update a page or design templates for a whole site, you want to be able to validate your pages. You should be able to validate your accessibility as easily as you validate your HTML code. If it is testable, people will build automatic tests. Where it isn't testable, people will give you warnings when you validate.
So, for example, imagine that you are building the next FaceBook. You are a conscientious coder, so you validate your code. The validation report points out three clear accessibility errors with your JavaScript, and gives you two accessibility warnings, mixed in with the rest of the report. Fixing them, and considering whether the warnings are valid, is part of your workflow. It becomes routine.
It doesn't just apply to HTML pages. It applies to JavaScript and to Flash and to Portable Document Format (PDF) and even Word documents if people load them onto the Web. And it applied to all those videos on YouTube, too, but then so did WCAG 1.0.
And there are techniques for making accessible JavaScript. Roger Hudson, in Sydney, is doing great work in demystifying WCAG 2.0 and understanding how it can benefit accessibility. Here is a short video of Roger and Andrew Downie talking about accessible JavaScript forms. It is drawn from Roger's fantastic tutorial on accessible forms using WCAG 2.0.
That is great for all the material that Web authors build. But what about all that wonderful Web 2.0 content that people are contributing? What about all that user generated content?
Well, it turns out that when you are writing a blog post on Blogger, or making a comment, or loading a photo of your cute cat onto Flickr, or identifying people in party pics on FaceBook, you are actually authoring the Web. Building a better world, one comment at a time.
And that means that, in W3C terms, you are using an authoring tool. That comment form, that tagging trickery, that uploading system all fall under the Authoring Tools Accessibility Guidelines. Given that the Authoring Tools Accessibility Guidelines were first ratified in ????, it is no surprise that they are being updated. Version 2.0 is currently a working draft, I think.
The Authoring Tools Accessibility Guidelines are our least best hope for peace. That is, I think that they are the best thing that the Web Accessibility have done, and they are the least known. The Authoring Tools Accessibility Guidelines work on two key principles:
Imagine that! That deaf, dumb and blind kid sure builds a great mashup! That is what Web 2.0 is all about. Inclusion! Empowerment! Cute cats and all that.
I haven't looked closely, but as far as I can see, the redevelopment of the Authoring Tools Accessibility Guidelines is all about reinforcing that it applies to all those cute Web 2.0 widgets that help add content to sites. To my mind, it would be very nice if Dreamweaver and FrontPage (does that still exist) were totally accessible and always built accessible content. But it would even better if Flickr and Twitter and FaceBook and Bebo and YouTube and LinkedIn and Google Docs (and all of Google's toys, actually) and Plaxo were, too. That would be great! And it be a lot of fun, too.
They say that HTML 5 and XHTML 2 will include all this stuff. In the meantime, some people are trying to fix things a bit faster. Web Accessibility Initiative - Accessible Rich Internet Applications is an attempt to get some things fixed while HTML 5 and XHTML 2 grind their way through the standards development process. It is targeting Web apps. Those things on Web pages that do stuff.
Remember when I talked about focus? Seems like a long time ago, doesn't it. Accessible Rich Internet Applications is trying to get things into focus. More particularly, it is adding things to the tab-order. If you tab through a page, you will skip happily from link to link, from form element to form element. Tab order shows you where you can focus to do things. Unfortunately, the only things that you can focus on on HTML 4 are links and form elements. Not widgets.
Following an idea that came from the Firefox crew, I think, Accessible Rich Internet Applications is trying to codify the use of two new developments in the tab order:
Currently, tab order starts at one and moves upward (two, three, four...), which makes a lot of sense. By adding zero to the tab order, we can add something into the tab order that wouldn't normally be there, like a widget. So zero provides a tab order to something that wouldn't normally have a tab order.
I have to admit, when I first saw that you could add negative numbers to the tab order, I just didn't get it. How does that work? Well, here is how it works. Negative numbers will only put something into the tab order if the author specifies that they should go into the tab order in response to something that happens. So, if a key is pressed (like the arrow key, for example, then focus can shift to that object.
Also, they are talking about giving roles to objects or regions of the page. This is something that is proposed in XHTML 2, but WAI-ARIA is aiming to make it happen quickly because accessibility needs it now. The banners that are currently being proposed for XHTML 2 are: banner; complementary (supports the main content but can stand alone); contentinfo (metadata like copyright or footnotes); definition; main (main content); navigation; note; and search.
Building from this, WAI-ARIA is trying to define almost 60 roles, including the ones listed above, that will help to define widgets. Examples include 'alert' and 'button'. More than this, it is providing a whole taxonomy of how these items should be dealt with. And because of the changes to focus, any of these items will be able to be added to the tab order, so that adaptive technologies will be able to grab onto them.
Also, it will define how these roles should trigger events and how those events should link to adaptive technologies, either through the Document Object Model (DOM) or through the appropriate accessibility Application Program Interface (API). It says that:
Changes in states MUST result in a notification to an assistive technology either through DOM attribute change events or platform accessibility API events.
The next versions of both HTML and XHTML will have accessibility built in, almost from the ground up. That is a good thing, but it will take a long time for them to grind through the standards process.
This is where W3C is trying to standardise Web applications, which most Web 2.0 sites are. This is not about trying to make them accessible. This is just about trying to get all the people coding them on the same page.
Co-chaired by Charles McCathieNevile, a local lad who now works for Opera. Charles used to work for the Web Accessibility Initiative, so I'm pretty confident that anything that comes out of his working group will be accessible. And he is working on Web applications, so that has to bode well for the future of accessible Web applications, as far as I am concerned.
Lets go all the way back to our definition of Web 2.0. To my mind, Web 2.0 is about community empowerment. It is about allowing you to do things that you couldn't do before.
So get empowered. If you see a problem, point it out. There are active user communities discussing the accessibility of Wikipedia, FaceBook and even MySpace, which can be an accessibility nightmare.
Some of this Web 2.0 stuff is built on open source software, I hear. Open source developers are often very open to suggestions about accessibility. They are often much more responsive than closed source developers, from my experience. So if you are evaluating a system for your organisation, feed your evaluation back to the developers. If you spot a bug or an accessibility blooper, tell them.
If you are building something or adding to your site, take these W3C recommendations into account. They are best practice, after all. And then do some user testing with people with disabilities. There are two benefits from that. First of all, you know that it will work with that particular adaptive technology and secondly, it is extreme testing - if it works for a screen magnifier and voice recognition, then it will probably work really well for everyone.
Vision Australia will help. For my money, they are the best people working on Web accessibility in Australia at the moment. Don't let the name fool you - they deal with accessibility for all types of disabilities. And they really know what they are doing.
If you are in Sydney, then I highly recommend Roger Hudson at Web Usability. He does extensive testing of sites with people with disabilities and really knows his stuff.
And wherever you are, the Web Standards Group is a terrific resource and lots of fun.
If you want to know more, I came across this course from the University of Illinois at Urbana/Champaign. It is called On-Line Web 2.0 Accessibility Course (using the W3C ARIA Specifications). It was run by Jon Gunderson in May this year. It cost US$295 for non-profits and government employees. I don't know much about it, so I thought that I would ask.
And finally, my own plug. OZeWAI 2009 is on from 21-23 January 2009. It is three days devoted to nothing but Web accessibility. I help convene it. It's good. Think about coming along.