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.
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?
Is AJAX accessibility possible?
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.)
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!
- 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.
XMLHttpRequestinstead. 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.
Will separate sites be needed?
I agree with this conclusion, but for different reasons:
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.
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.