I would like to think of David Berlind, the executive editor of ZDNet, as an advocate for web accessibility. He skims the edges of advocating accessibility; giving mouth service to the principles of accessibility and giving some indications that he considers web accessibility of some importance. But, fundamentally, he doesn’t get it and he doesn’t support it.
Looking over my site statistics the today I noticed a few referrals from a site called Search and Go. Having never heard of the site, I figured I’d check it out and see what was up. Well, turns out it’s a project which is still in beta development which intends to provide a comprehensive information portal including articles, news, a directory, and various other tools.
One of the key aspects for Search and Go (as one might conclude from the title) is that it’s intended to be fully accessible by mobile internet devices, and also has a featured directory section of sites tailored for mobile devices.
Looking at their code, I’m pretty happy – they are using very clean, semantically appropriate design. Since it’s still in beta, and the front page is clearly labeled as a work in progress, I’m not going to go out of my way to criticize the site’s layout, although I’d suggest making their navigational skip links a little more transparent. That is, possible to be made visible. There’s a very interesting article on the subject of skip links by Gez Lemon and Mike Cherim available at Accessites.org which is worth looking at on this subject.
As for my own site, I was thrilled to see it organized under the category Internet > Web Accessibility > Accessible Designers. The sheer novelty of the existence of this category is worth noting, since many directory sites take so little effort to consider accessibility as to lack a category for it entirely.
Good luck, Search and Go!
I just became aware today, through the Guild of Accessible Web Designers newsletter, of an internet directory featuring exclusively accessible web sites. This is a great way to make the accessible web more usable for individuals with disabilities – although it has its limitations.
My first reaction, of course, is that in an ideal world, this would actually be equivalent to the Open Directory Project – because, of course, eventually all sites will be accessible! But, of course, for now, this is a very meaningful directory purely because there is such a paucity of meaningfully accessible web sites.
The only thing which will make this directory truly useful, however, will be to really start filling it up with great sites. I intend to submit my own accessible sites to the directory to maximize the potential of the site.
Directories are difficult beasts – they’re huge, unwieldy, and frequently just not used that much – search is much easier. However, developing a means to specifically search for accessible sites has a target audience which can really benefit from the difference, so I hope that this directory can take off.
The design of the site is literally LITTERED with empty table cells. This is, sad to say, a classic example of a highly complex and screen reader-unfriendly table-based layout.
Many links provide only a moderate background color change to indicate that they are active; no links have a useful indication for their :active or :focus states, which is necessary for keyboard navigators to easily locate their cursor.
All in all, the site has great potential; but has not yet realized that potential. I can see that they have a good aim in mind, and I fully support that ideal – but I also hope that they are working hard to improve the usability and accessibility of their own site in order to set a positive example.
- 1. A sudden gathering of force, as of public opinion: a groundswell of antiwar sentiment.
- 2. A broad deep undulation of the ocean, often caused by a distant storm or an earthquake.
I think, of course, that definition number one is most applicable here. What I’m finding particularly interesting about the recent surge in public commentary on WCAG 2.0 is how late it is in coming. This eleventh hour response, coming just days before the May 31st deadline for comments on the working draft document, seems somewhat tardy.
The document has been in progress since January 25th, 2001. Now, of course I can see why there was no need, at that time, for a huge response. At that time, and through most of the period of WCAG 2.0 development, the document was simply an acknowledgement that WCAG 1.0 was insufficient. The abstract of that first edition states:
Primarily, this is the first attempt to write checkpoints that may be applied to a wider range of technologies and that may be understood by a more varied audience. Since this Working Draft builds on WCAG 1.0 it has the same aim: explain how to make Web content accessible to people with disabilities.
At that time, their goals were straightforward and clear. The simple statement of the abstract was to make checkpoints have broader applicability and to make them more easily understood. In the second version, of August 24, 2001, they in fact state explicitly their goal "to use wording that may be understood by a more varied audience".
So far, so good. However, in the version of June 30th, 2005 a significant change appears in the abstract. This version no longer commits to a more understandable document. I’ll provide this abstract version in full:
Web Content Accessibility Guidelines 2.0 (WCAG 2.0) covers a wide range of issues and recommendations for making Web content more accessible. This document contains principles, guidelines, success criteria, benefits, and examples that define and explain the requirements for making Web-based information and applications accessible. “Accessible” means to a wide range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning difficulties, cognitive limitations, limited movement, speech difficulties, and others. Following these guidelines will also make your Web content more accessible to the vast majority of users, including older users. It will also enable people to access Web content using many different devices – including a wide variety of assistive technology.
WCAG 2.0 success criteria are written as testable statements that are not technology-specific. Guidance about satisfying the success criteria in specific technologies as well as general information about interpreting the success criteria are provided in separate documents. An Introduction to Web Content Accessibility Guidelines (WCAG) 2.0 Working Draft Documents is also available.
Until WCAG 2.0 advances to W3C Recommendation, the current and referenceable document is Web Content Accessibility Guidelines 1.0 (WCAG 1.0), published as a W3C Recommendation May 1999.
Try as you might, you can read no indication that this document will aim to be understandable. This is a significant and crucial change in goals. At this time, you might expect a protest to begin. Still; the drafts were a long way from being completed, and there was no real reason to see the full consequences of this change. Hindsight is, as they say, 20/20.
Unfortunately, this revision of the web content accessibility guidelines has been in progress for such a long time that an expectation of completion has been difficult to ascertain. Finally, now that they have announced last call, the community becomes aware that THIS document is the one we’ve been waiting for; and that it does not hold up to scrutiny. The last call working draft of April 26th contains a strong call for comments:
The W3C strongly encourages broad community review of this Last Call Working Draft, and submission of comments on any issues which you feel could present a significant barrier to future adoption and implementation of WCAG 2.0. In particular, we encourage you to comment on the success criteria and the conformance model. Reviewers are encouraged to provide suggestions for how to address issues as well as supportive feedback and endorsements of the document.
Although the surge of commentary in the last few weeks may be late in coming, we can only hope that the committee is sincere in there request and acknowledges the extensive criticism the document is now receiving.
Further reading on WCAG 2.0 as of this week:
- Roger Johansson – "WCAG 2 disregards Web standards"
- Kevin Potts – "In Joe we Trust"
- Gez Lemon – "Formal Objection to WCAG Claiming to Address Cognitive Limitations"
- Joe Clark – "Abandon all hope"
- Joe Clark – "Call for response from the Web Standards Project"
- Joe Clark – "To hell with swearing"
It’s rare that I find a topic which makes me blog on both this blog and my SEO Blog, but here we are. On May 8th, I posted about Sphere, a new tool focused on searching blogs. In that post, I was thinking generally about the concept of blog search and how it can effectively apply to local search. In the course of my brief research, I noticed that the design for Sphere had been done by Adaptive Path.
Although Adaptive Path is not explicitly a design agency focused on accessibility, they are sometimes considered to be at the cutting edge of usability, standards based design, and have certainly had some impact on the world of accessibility. So, when I noticed that they’d designed this new tool, I thought I’d take a look under the hood and see what they’d done. Also, of course, I read their own article about the design process.
In general, it’s pretty good. But there are a number of very basic accessibility features which are just flat out lacking – and which would have been very simple to incorporate. This is really kind of disappointing.
I started out with the very basic tack of doing some automated testing. As much as automated testing is imperfect, it does provide a great starting ground. Running Sphere’s results page through Cynthia Says, an online test for compliance with the Section 508 standards. Compared to the full WCAG 1.0, Section 508 standards are simple to match.
The site only failed on one point. But it was, frankly, a big one. The big input for the search field is unlabeled. It has no indicator anywhere what purpose it actually serves. To a sighted user, this is obvious – but if you were navigating blind, you would need to continue past the input form to the search button in order to know what should be entered there. However, having arrived at this button, you still wouldn’t know for certain that it referred to the previous input. Without an explicit labeling convention, it would still be quite possible for there to be another input field which was actually attached to the search button.
The second test was to validate the site. Again, the home page came up just a little short. Rather than a nice clean "this is valid XHTML transitional" message, I got a number of errors. They’re all minor errors, and probably won’t have any great impact on accessibility. There were a large number of unescaped ampersands, one invalid attribute ("valign") and a mistakenly capitalized anchor tag. Not terrible, but still disappointing.
Finally, the eyeball test at the front page. Again, not quite perfect. Sphere has this very cool feature, the "SphereIt" bookmarklet, which is advertised at the bottom of the page. The anchor text for information about the bookmarklet is the famous "Click Here". Fine for a sighted user, lousy for a screen reader.
This is just a very brief look over the site; but on the whole I’m a little disappointed. There are just a few things here which are lacking, but they’re all such easy fixes. Hopefully, I’ll check again in a few weeks and find these mistakes all cleared up – it is a brand new site, after all.