Quietly released on the Saturday before Christmas, (what, are they trying to hide this news?) Google announced that their latest Toolbar release supports the Windows Accessibility API.

This is (obviously) a Windows-specific release, and even further, it’s just an Internet Explorer release. However, it’s definitely a step in the right direction! I was particularly glad to see the comment:

Version 5 comes as a part of our ongoing efforts to enhance accessibility in our client-side and web applications, which is a matter I hardly need to mention is very important. Jonas Klink, Software Engineer, Accessibility

(Emphasis added.)

Now, as many have commented, the accessibility level of much of Google’s code is atrocious. I like the idea that Google is actively invested in improving the accessibility of their products; but I have yet to see any serious evidence of this effort!

Still, in the holiday spirit, I will raise a glass to Google to encourage their accessibility efforts. (And if, as a side effect, I end up a little bit drunker, I will accept that.)

The justification that a web site is accessible because it “follows standards” contains a serious fallacy. Specifically, the assumption that standards support accessibility.

One root of current standard accessibility practice is conformance to the HTML or XHTML standards set by the World Wide Web Consortium (W3C). This is a fine practice, and certainly should be maintained. Using correct syntax and following a standardized method of communicating information is always a solid best practice. However, this should absolutely not be taken to mean that following these standards is the same as applying the principles of web accessibility.

Web standards only provide accessibility to the degree that they have been designed to do so — - and the guiding principle behind standards development (excluding accessibility-specific standards, of course) has not generally been to support accessibility. Web standards have been designed purely to establish a set, correct method of using the underlying code — - whether presentational (CSS), structural (XHTML) or behavioral (ECMAscript.)

In many (most) cases, web standards do not in any way require best practices — - they merely require conformance. Take HTML, for example. Web standards would permit the usage of table elements for layout, because they do not define semantic usage for the table element. Web standards also permit a variety of presentational elements, such as font, strike, or u. It all depends on what standard you have chosen to follow.

HTML5, most recently, is considering such contrarian steps as removing the requirement that alt attributes be required for images. This ensures the existence of a valid HTML5 web site which can radically fail basic accessibility guidelines. On the other hand, it may reduce the likelihood that some so-called “accessible” web sites will be littered with alt="this is a spacer graphic".

Does this necessarily mean that the standard is wrong or right? No, not as such. Different standards support different needs — - it is important to keep distinct the purpose of the standard. Conforming HTML is just that: Conforming HTML. It means nothing more.

Nonetheless, as an accessibility advocate, I feel that it’s important to support accessibility issues within the development of new standards. Taking the alt attribute issue in HTML5, for example, the lack of any perceived benefit to not requiring the attribute suggests to me that the better path would be to continue to require it. There are numerous examples of important accessibility aspects in HTML5 which are not yet included.

There seems to be a strong element of specious judgement: elements which are not supported by current user-agents are considered not to be needed. This seems a ridiculous expectation: after all, if unsupported elements aren’t needed, than why develop a new specification at all? What we’ve got must work just fine!

Practically speaking, user-agent support and developer use should both be only marginal issues when trying to decide what elements are most needed in a specification. The fact that elements are unused on either end are not a judgement on the value of that element; merely a judgement on the awareness of the element, on the clarity of the existing specification, or on the complexity of the implementation.

Nobody (or almost nobody) uses the q inline element. Does this mean that the element isn’t valuable, and should be discarded? No. It means that Internet Explorer should add appropriate support for it. The same is true for accessibility issues. The standards should support them to their best abilities: if an element or attribute could hypothetically add to the accessibility of a site, then the fact that it is little used or poorly supported should be entirely irrelevant. Support should follow the standards; not the other way around.

At the root of things, my stance is that I am unwilling to support a standard which specifically excludes features which are needed in order appropriately provide best-practice accessibility. HTML5 is still a long way from being done; and even further from being implemented (if it ever is,) but the removal of such attributes as the header from table markup, the inclusion of defined non-semantic elements such as b1, and the “WYSIWYG exemption” on the font element strike me as decisions badly in need of reconsideration.

1. In point of fact, I can accept the inclusion of one inline non-semantic element (span) and one block level non-semantic element (div). I feel there’s ample justification to allow elements which are not specifically defined on the grounds that not all situations can possibly be covered by the specifications of the language. I see no justification, however, for the inclusion of additional explicitly non-semantic elements.

If we call ourselves professionals, we owe it to our clients, their clients, and ourselves, to do our job properly. A chef must care about health, a builder must care about safety, and we must care about accessibility.

James Edwards, aka ‘Brothercake’ has published a very neat argument on the frequently-asked question “Why Accessibility?”

Read his comments at Why Accessibility? Because it’s our job!.

Every once in a while, somebody mentions to me how they’re concerned because their (or my) site didn’t “pass” some online accessibility evaluator or another. This always opens up the conversation for one big, complicated issue: why automated accessibility testing just doesn’t work.

This isn’t to say that automated testing doesn’t have a place; but it should never be considered the deciding factor for accessibility.

The Functional Accessibility Evaluator from the University of Illinois at Urbana-Champaign was pointed out to me recently. Naturally, I figured it was worth a look. In fact, it’s very interesting. (It has problems, but I’ll get to those.)

Read more: An Example of Automated Accessibility Testing

The Accessibility Cookbook: a Recipe for Disaster, by Aaron Cannon.

This is a very well-written article which provides an “insider’s” viewpoint from both an accessibility and an interface designer’s perspective.

The article remarks, in brief, on the importance of knowing the why’s and how’s of accessibility. If you don’t understand why or how you’re helping a disabled user, you are immediately opening up a gateway to create new barriers. It’s not about following a set of rules; it’s about sitting down and thinking about whether a given choice will actually benefit the user.

In accessibility, many choices aren’t black and white. Just following the guidelines is a good way to cause trouble!

Hat tip to Cameron Moll for the link.

For a major issue in accessibility, I have to say that this really hasn’t seen much press. Granted, major lawsuits tend to move slowly — - glacially, you might say. However, given the fact that the last announcement concerning the National Federation of the Blind v. Target Corporation lawsuit was in September of 2006, you’d expect some kind of blog coverage on the latest announcement.

In fact, I found it difficult to find anything about it at all, at first — - I only became aware of it because I was talking to a web development manager from Target. (Articles are now easy to find via Google News.)

At any rate, the major news is that the lawsuit has been granted federal class-action status.

Granting class-action status allows blind people throughout the country who have tried to access Target.com to become plaintiffs in the suit, which alleges violations of the Americans With Disabilities Act. Associated Press

Further, the Judge (Marilyn Patel) ruled that changes in Target’s web site since the date of filing do not provide grounds for dismissal of the suit.

Judge Patel’s order Friday noted that Target has modified its Web site some since the suit’s filing to make the site more accessible to the blind. Target claimed the suit should therefore be dismissed, but Judge Patel ruled against that argument. Associated Press

Turning the suit into a class action may place additional pressure on businesses to start considering web accessibility a priority. One can hope, at any rate!

See also: Update: Target ruling may force retailers to adjust Web sites (Computer World)

Recently, I wrote a series of posts about what I choose to call pseudo-accessibility — - part of which is the provision of website tools which emulate native browser functionality.

The reason these tools proliferate is because of developer laziness, not because of developer interest in accessibility. For some strange reason, it’s considered more difficult to educate the user about their browser than it is to build a text-resizing widget. (Granted, text-resizing widgets aren’t exactly rocket science.)

Ian Lloyd, of Accessify, has taken to video trying to address the text-resizing problem. You can see the video at his own relevant blog post — - Teach a man to fish (or how to resize text).

The video isn’t necessarily a finished product. As of this writing, it’s in it’s second version , as Ian has been graciously accepting comments and re-working the video in order to provide the best video tutorial possible on the subject.

Video, of course, isn’t a perfect solution — - but the transcript is available (not on Accessify.com yet, however,) and this is a good start towards user (and developer) education.

Thanks, Ian!

Thanks to Accessites and Mike Cherim for bringing this to my attention.