Future of web accessibility

Trenton Moss wrote up his thoughts on the future of accessibility (via Accessibility Blog), and the general accessibility implications of some new technologies.

The points in the main section of the article are good, but I don’t think they provide sufficient basis for the predictions made. I could be reading too much into a brief article, as the problems highlighted are certainly problems now, but they are not without solutions in sight.

Several predictions are made in Trenton’s article, such as the accessibility of AJAX making separate accessible sites necessary. Some I agree with, some I think will pan out differently, but it’s a good discussion to think through! NB: please do read the original article, the quotes are cut down.

AJAX Accessibility

Alternative accessible versions will become the norm

… for the first time usability and accessibility are coming head-to-head with each other and rich interactive interfaces often can’t be made fully accessible.

This reminds me of what I heard of the switch from DOS to Windows, for people using screen readers at the time it seemed like a calamity! What would people do with these new fangled graphical interfaces?

Admittedly the different browsers and the scope of a programming language like JavaScript leads to many different situations for screen readers to account for. However, it is not that big a scope compared to the many applications on an operating system, and these problems have been overcome.

The application pointed out (Amazon’s Diamond search) is indeed completely inaccessible with the keyboard, and (at least partly due to lacking alt texts within the JavaScript) inaccessible to screen readers as well. However, Amazon are not known for their commitment to accessibility, so it is hardly surprising that this application isn’t accessible.

Is AJAX accessibility possible?

An AJAX application that has undergone post-launch usability testing with screen reader users is Basecamp, where Joe Clark found that:

this Ajax application is usable by screen-reader users some of the time. They aren’t totally shut out, but it isn’t totally easy for them, either.

I would put money on the fact that Basecamp hadn’t been designed with accessibility in mind, and yet this new fangled technology wasn’t a complete disaster.

I’ve tested the Apple screen reader Voiceover on James Edward’s AJAX test cases, and by the terms of the test, Voiceover passes three of them, and deals reasonably with the other tests. (With caveats that there are no announcements for screen updates, and within page links are useless.)

JAWs is undergoing significant updates to use the DOM and JavaScript more effectively. From version 7.1 you can read updated parts of the page easily, and in the version 8 beta several of the test cases work perfectly, taking the user to the updated part of the page. I’m not aware of what the other vendors are doing at the moment, however, when one supports a new technology the others tend to follow.

Accessible Solutions for Future

So what should a web developer do at the moment to ensure their AJAX applications are accessible? Well, at the moment it is a difficult question to answer, especially with the moving target of updating access devices such as screen readers.

Hmm, if only there were some standards to follow for this, where would one look for web standards? The W3C has already published a Roadmap for Accessible Rich Internet Applications, it looks like we will need to get to know the Role attribute a lot better!

In the meantime, the obvious best-practice method is Hijax, coined by Jeremy Keith:

1. First, build an old-fashioned website that uses hyperlinks and forms to pass information to the server. The server returns whole new pages with each request.
2. Now, use JavaScript to intercept those links and form submissions and pass the information via XMLHttpRequest instead. You can then select which parts of the page need to be updated instead of updating the whole page.

Another good option to use in combination would be one of the popular libraries, such as Yahoo’s User Interface Library. These may not be intrinsically accessible (I haven’t tested), but it is likely that the access device vendors will be testing against the popular implementations.

A known bad option would be anything that auto-generates markup and JavaScript, I have never come across decent markup that has been automatically generated.

Will separate sites be needed?

I don’t believe so. However, there is a compromise needed whilst we are waiting for screen readers to catch up. A Hijax application will work as a standard site when JavaScript is turned off. The problem is that screen reader users are generally on Internet Explorer, Firefox or Safari, which have JavaScript.

Therefore there should be an option built into the application to easily allow people to effectively turn off JavaScript (i.e. an option on the site, not telling people to turn off JavaScript in their browser!).

This option would also be useful for ‘universality’, as many phones, TVs and other devices make a complete hash of JavaScript. (Please note, I am not getting accessibility and universality confused.)

Evil Formats

I agree with this conclusion, but for different reasons:

JavaScript, PDF & Flash will no longer be thought of as ‘evil’.

In WCAG 1.0, web managers and developers were basically told that their websites shouldn’t rely on any of these three technologies. WCAG 2.0 on the other hand doesn’t stipulate this, and rightly so as most assistive technologies can now support these technologies.

PDF and Flash overcame their ‘evil’ several versions ago, when accessibility was built into the formats, applications and tools. I don’t think the use of Flash or PDF has often been prevented by the WCAG 1.0 guideline (Use W3C technologies when they are available and appropriate for a task). There have been times when Flash or PDFs have been appropriate.

Assuming you are committed to accessibility, the issue so far has been cost vs benefit. It takes a lot of effort to make Flash accessible, especially in previous versions, and the same can be said of PDFs. For accessibility and interoperability reasons, the path of least resistance has been using HTML & CSS.

A typical JavaScript example would be providing form validation. If you need to provide a non-JavaScript fall back, you need to have back-end script validation. If that back-end validation works well and you have a tight deadline, why use JavaScript as well? There are some good reasons to layer JavaScript on top, but when resource is scarce you do what is needed.

The business cost of creating accessible Flash, PDF and JavaScript is gradually coming down, but only gradually.

User Generated Content

The other part of ‘Web 2.0’ is user generated content, whether it is classifying pages with tags, or uploading videos to YouTube.

User generated content is likely to offer poor accessibility

Content created by users is becoming more and more commonplace on the web. This kind of content is being created at such a rapid rate that it’s going to be impossible to police it for accessibility.

I can only agree with that, content from the general public who know nothing of the technicalities, and only know the web as they experience it, will not provide good alternative text, or structured markup if asked to.

Policing user generated content will never be the answer. But it doesn’t need to be, prevention and good usability of the authoring interfaces will do more for accessibility than any amount of policing. With a good authoring interface the user would be able to add what they want, and the accessibility aspects would be included as standard without them needing to know.

For example, a publishing (blog) application that uses an accessible & usable WYSIWYG editor will allow the user to add content without even knowing that they are producing accessible markup.

Bookmarking applications like Digg take in very restricted content, so should prove relatively easy to accessify. The two examples that come to mind as worst case scenarios are YouTube, and MySpace. (I’m not going to touch MySpace here, it’s worthy of it’s own book!)

Some might ask why you would bother making a site dedicated to videos accessible? For the same reason blind people have televisions: because it can be an enjoyable experience. Moving beyond visual impairments, some people may have perfect vision but cannot use a mouse so the site and video player controls need to be keyboard accessible.

What I’m getting at, is that even if certain user generated content is not added with all the accessibility bells and whistles, that is no excuse for not making the site structures and navigation accessible.

There will be scenarios of use for various people that need supporting depending on the application. For example, when using a mapping application, a drag and drop map is of no use to someone using a screen reader, but a sortable list of locations and links to further information (including co-ordinates to transfer into an accessible GPS unit) would be very useful, and wouldn’t require a separate application.

Reduced guideline dependence

Accessibility will become less and less guideline-driven

With the advent of new technology (such as AJAX), and the technology-neutral and vague nature of the new W3C guidelines (WCAG 2.0), accessibility is becoming less and less guideline driven.

This is a very difficult prediction to judge. If the WCAG 2.0 doesn’t provide sufficient guidelines I have a feeling that larger organisations will either stick to version 1 (which isn’t technically replaced), or use the upcoming errata.

In some ways, the new landscape of interactive applications is in more need of guidelines and best practices than before, the sheer scale of interactions possible makes standardisation even more necessary.

The road ahead

There are certainly some bumps in the accessibility road ahead, however, there are significant efforts being made both by vendors of access technologies, and standards bodies that I don’t think separate ‘accessible’ sites will be necessary.

---

Technorati Tags:

• accessibility
• AJAX
• Flash
• pdf
• JavaScript
• Usability
• Screen readers