To Hell with WCAG 2.0 is the response from the author of Building Accessible Websites to the latest production of the W3C‘s Web Accessibility Initiative.

Clearly, Joe Clark is not happy. And he’s not the first person to express dissatisfaction with the process and results of WCAG 2.0, either. John Foliot of Web Accessibility Technical Services has frequently expressed displeasure with their new yet fundamentally unchanged interpretation of the accesskey functionality.

In an effort to be all things to all web content, the fundamentals of WCAG 2 are nearly impossible for a working standards-compliant developer to understand. WCAG 2 backtracks on basics of responsible web development that are well accepted by standardistas.

Joe Clark, "To Hell with WCAG 2.0"

The three fundamental documents involved in the WCAG 2.0 package are the Web Content Accessibility Guidelines 2.0 (72 pages), Understanding WCAG 2.0, (165 pages), and Techniques for WCAG 2.0, which clocks in at 221 pages. Altogether, 448 pages of semi-legalese attempting to define the next generation of web pages.

No, these documents are not easy to understand. And they clearly contain a lot of extreme generalities which appear to be attempting to explain accessibility without reference to technologies. As Clark mentions, this separation of technology and theory makes it much more difficult to apply concepts to the practicalities of creating a website.

Joe Clark’s article is a must read towards understanding the politics and complexities of creating an accessible website. Accessibility is not about enslaving your design aesthetic to a set of guidelines – but it is about considering very carefully the needs of your users, testing your work, and making thoughtful decisions.

 Tags:

• wcag 2.0
• accessible web design
• w3c

Microsoft has long been cursed in my mind as the creator of the worst website creation software in existence – Frontpage. Littered with custom extensions, complex custom scripting, and an interface which makes it extremely easy to make a horrible website, their software has been responsible for some of the worst code I’ve ever had to clean up.

This month, Microsoft has at least unveiled their next generation web editor – Expression Web Designer. Although I never recommend a web editor as a replacement for learning the complexities of code, and no web editing tool available is capable of creating an accessible web site unless the person using the software is knowledgeable, Microsoft’s new product takes some valuable steps forward.

The very first statement on the Expression web site says a lot – it tells us exactly what goals Microsoft is espousing with this new product, and what they now consider to be important when it comes to selling web design products.

Microsoft® Expression® Web Designer gives you all the tools you’ll need to produce high-quality, standards-based Web sites the way you want them. Take advantage of the best of dynamic Web site design, enabling you to design, develop, and maintain exceptional standards-based Web sites.

I should make it clear that I don’t also believe that Microsoft is 100% dedicated to web standards. Internet Explorer 7 is a huge step forward, and I think that’s wonderful. However, when it comes to new web projects and services, Microsoft has not spent any significant effort on accessibility. They are beginning to recognize that accessibility and standards are the way of the future. It may take decades for that knowledge to filter through the entire company, however!

An interview from February of 2006 is posted on the Microsoft site which discusses a number of the commitments that Microsoft has made with this new project. This is, unsurprisingly, a basically glowing interview, but it does emphasize the fact that Expression will completely replace Frontpage, which will be discontinued.

The most exciting features, in my mind, are the built in html validation, browser compatibility reporting, and automated accessibility testing against Section 508 guidelines and the WCAG. As imperfect as automated accessibility testing is, it is a vast improvement to have it built in to a web editor. This greatly increases the likelihood that a designer will become aware of this important issue and at LEAST experiment with it.

The free trial should give a lot of web standards people their first chance to test it out and see what’s going to be happening. The trial is good through February of 2007, so there should be plenty of time in there to find any faults.

Cheryl D. Wise has written what is probably the first serious review of Expression Web Designer. She doesn’t go in depth, but will be posting additional reviews, articles, and tutorials to go with the software over the next few weeks.

 Tags:

• web standards
• microsoft
• html editors

One of the original reasons I started this blog was to track information about the ongoing accessibility lawsuit against Target Corporation. Recently, ComputerWorld published an extensive article discussing the lawsuit and surrounding issues. The article contains a number of interesting points, including a great quote on Ajax and Accessibility from Jeff Bishop, a blind application systems analyst at the University of Arizona in Tucson.

"It’s very, very, very scary. Before, so what? You had a missing [alternative-text]tag, but at least you knew there was an image. You could click on it, and maybe you could figure out what it was. Now, you don’t even know where to click. You don’t know how to interact."

Although the article doesn’t deal directly with the Target lawsuit, it does discuss the possible consequences if the lawsuit is successful. ZDnet.com also discusses this question in a lengthy article by David Berlind.

There’s clearly a slowly growing awareness of the potential of the Target lawsuit to radically shift the view of website accessibility in the United States. It’s already become law in the United Kingdom – it may become an economic necessity in the US!

 Tags:

• accessible web design
• target lawsuit

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.

 Tags:

• blogging
• accessibility reviews
• sphere

SiteMorse, for those of you who may not know, is a high-profile accessibility testing company based in the United Kingdom. They are well-known for the practice of releasing their "Rankings League Tables," which list the tested accessibility of government, banking, and other websites each month.

Their particularly product is entirely automated – and has, therefore, been attacked quite heavily in the world of accessibility auditors and consultants.

At the moment, there is a very interesting conversation going on at
Accessify Forum which is primarily a question and answer session between Grant Broome, a well-reputed accessibility consultant working with CDSM Interactive Solutions and Jon Ribbens, a director of the company which develops the SiteMorse product.

I will disclose, to start, the fact that I was already in the anti-SiteMorse camp before reading this interview. However, to date the Q & A session has done little to change my views. It’s my feeling that Jon has done little but attempt to avoid Grant’s question. With repeated accusations about vagueness and the irrelevance of Grant’s questions and points, Jon has done little to impress me with his company’s dedication to accessibility issues.

The core issue is whether automated testing can possibly fully address the accessibility of a website. I and many other accessibility consultants believe, quite strongly, that it’s simply not possible to judge a website entirely based on automated judgements. An automated tool can be helpful for resolving specific issues – but should NEVER be substituted for a human appraisal of accessibility.

Regardless, this conversation has already been quite interesting, and is worth following.

 Tags:

• sitemorse
• accessibility testing
• automated testing
• web standards

For the last two weeks I’ve been living an unusually isolated life. Specifically, one without a home internet connection.

Now that you’ve all finished gasping with shock, I’ll continue.

During this time, I’ve learned a lot about how much my normal life style (not just my work, which is naturally web based) is set around internet access. I retrieve almost all the information I normally need during the day through the internet. Restaurant menus, opening and closing times, phone numbers – all retrieved through internet search. If I have curiousity which I simply must satisfy, I’ll query Wikipedia.

But recently I’ve had to survive without that kind of access. I can still go off to cafes and restaurants and access free wireless service with some regularity, thankfully. This makes it at least possible for me to continue with my work. But it’s a lot more awkward.

At any rate, enough whining. Back to the topic at hand.

During this last few days, I’ve worked my through the code I use for a search engine with most of my PHP/MySQL web sites. I’ve documented it moderately thoroughly and written it up. However, lacking internet access, I haven’t really tested this version of it. Hopefully, there are no major mistakes!

If anybody happens to give it their time to look at, I hope you’ll drop me a line and let me know your thoughts. I’m particularly interested in hearing about anybody’s views about improving the security of the script, but will gladly accept comments on usability, functionality, etc.

 Tags:

• search
• php
• mysql

Since this article has been linked to now by a number of sites, I thought I’d provide a link to the actual post I wrote on AJAX and accessibility, to which this post is a follow-up! And, if you’re interested in a more recent and extensive article, try Accessibility and Usability Issues with AJAX, from October of 2007.

The incredible flexibility provided by Ajax technologies is a big frustration to the accessible design community. Speaking for myself, I’d LOVE to feel comfortable using these powerful tools to create accessible tools. But the situation continues to be limiting.

The limitations are, as I believe I’ve mentioned, at least partially contained in the way screen readers handle JavaScript events. Most non-visual browsers can support certain elements of JavaScript. Others don’t work as expected or at all! Any event which occurs upon the press of a mouse button is likely to be seriously limited, for example.

Recently, James Edwards has published a great article on Ajax accessibility at SitePoint.com. This article investigates in depth the behaviors of various screen readers with Ajax driven responses.

It’s great information, and I can only hope that it’ll inspire the designers of screen reader technology to work forward and build new functionality! For now, it mostly confirms just how unusable Ajax technologies are today.

Tags:

• ajax
• accessible web design
• screen+readers