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

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

AJAX, or Asynchronous Javascript and XML, is one of the latest popular technologies to drop into a web developer’s bag of tricks. Although quite complicated to work with, the technique can provide an incredible variety of rich web application methods to work with. If you’ve ever visited any of the myriad "Web 2.0" applications, one common feature is the use of AJAX technologies.

The fundamental principle behind AJAX programming is that it works, as in the name, asynchronously. Most interactive web programming requires regular requests to a server. The general information flow is that you, the user, request a document. That document contains a form, where you fill in your information. You press submit, the page sends your information to the server, which does something with it such as signing you up for a mailing list, and then sends back a response – usually, an indication of success or failure.

In this process, every request requires a full refresh of the web page. However, AJAX works differently. Using the ability of Javascript to manipulate the DOM of a page (that is, edit page elements without refreshing) combined with the ability to make XML requests to the server, AJAX can send queries to the server and post the response to the web page without performing a page refresh.

For a web application, this is tremendous – although a server request may not actually be any faster than it was before, a programmer can now create a site which reacts to the information a user puts into the site instantaneously. Handling the server request no longer interrupts whatever the user is doing – they can continue working, reading, or moving ahead without having to wait each time for the page to refresh.

But! (And you knew there would be a but!) Accessibility and dynamic behavior have always had some significant conflicts. In a traditional format, a page refreshes and a user simply has to start reading from the beginning. Usually, at the beginning of the content section of the page, there will be a notice of what has happened – either "this section was not filled out" or "your submission was successful", or some response to that effect. Very easy to deal with from an accessibility point of view. AJAX changes all that. Suddenly, a dynamic site is updating areas all over the page without a refresh. How does a blind user know that anything has changed? To a visual user, you can see that a section of the page blanks out and refreshes. The content is now different. A blind user sees nothing, experiences no change.

This obvious issue with refreshing data is not the only accessibility concern with AJAX and DHTML. Thankfully, the new popularity of the AJAX technology family has spurred many large organizations to pioneer new methods of managing accessibility for dynamic technologies. Recently, the Mozilla Foundation teamed up with IBM to establish DHTML accessibility in Mozilla’s open-source browser, Firefox.
This accessibility is still rudimentary – but it’s definitely a start. The W3C has also begun to establish their own roadmap towards accessible dynamic content, having released their working draft on April 5th, 2006.

At this time, I will only employ AJAX in very limited circumstances – usually, for administrative backends where I can be certain that only a few specific people will have need to use it, and I can be assured that I will not be creating problems for others. However, the day may yet come when AJAX technologies are ready for truly accessible use.

 Tags:

• ajax
• dhtml
• accessible web design

For quite a while now I’ve been using Blogger as my tool of choice for this blog and for other’s sites. I’ve never been very happy with this choice, as the tool has limited options (no organization by categories, for example) and also restricts the designer’s control over the database. Furthermore, tweaking Blogger to provide more-or-less standards-based code is a fair amount of work.

Yet, none of this has been quite sufficient for me to decide to switch. The one thing I do like about Blogger is the single-page template format. I don’t need to edit a bottom section, navigation include, top matter, and content template to put together a design – I can simply compose the design within my own usual text editor and then stick that into Blogger.

I’m not sure why I’ve been so resistant to multiple-page templates – perhaps I’m just too accustomed to developing in my own way, and identifying what some new CMS has decided to call their various includes is too frustrating! Regardless, this is one of my goals for the next few weeks – learn somebody else’s CMS. It’s about time that I delved into something like WordPress or b2evolution.

 Tags:

• blogger
• blogging
• cms

It’s a common misapprehension that making an accessible website is expensive. Not exactly true – it’s more accurate to state that it’s expensive to make a website accessible. There is a subtle distinction between those two statements, but an important one.

The same is true in most issues regarding accessibility – it’s not significantly more expensive to make a building, a voting terminal, or a digital resource reasonably accessible from the beginning than it would be otherwise. However, it’s always significantly more expensive to retrofit your existing building to be accessible. You have to widen doorways, build ramps, replace bathroom fittings, etc. The same is true for a website – it’s not a simple matter to make a website accessible if it has previously been built in a less acceptable manner.

Part of what makes a website truly accessible is providing valuable, unique information embedded in the code. Writing alt tags which are descriptive and helpful, writing long descriptions of complex graphs and other visual aids, or providing meanings for acronyms and abbreviations. This is detailed work – and you can’t easily take shortcuts.

Automation is sometimes an incredibly valuable aid, but it’s too easy to perceive it as a solution. Making a website accessible takes time, patience, and attention to detail.

 Tags:

• accessible web design

One of the challenges in accessible web design is getting feedback from actual users. I know relatively few individuals with low-vision who regularly use screen readers. I know only a few people with handheld web devices – and certainly not enough to cover the entire range of possibilities in that area. This challenge is one of the reasons that web accessibility is so closely tied to web standards. Since most of us can’t test our work "in the field," we have to rely on our intuition, logic, and the fact that a careful adherence to standards will keep us from straying too far from the path.

There are a few places to go for valuable perspectives on these issues. First, and the most commonly used, for me, is the web design community. Interacting with other designers who are struggling with the same issues can provide valuable insights into potential problems which you yourself may not have considered. I belong to one major web forum, Cre8asite Forums, where discussions of standards and device compatibility have provided a lot of help. I’m also a member of the Guild of Accessible Web Designers, an organization committed to accessible web design. This highly focused group regularly considers the complexities of accessibility.

A second option is web accessibility testing. Disregarding the standard testing services for accessibility, Cynthia, WebXACT, and others, there are organizations such as Usability Exchange, a company which provides testing by actual disabled end users, giving you some of the best information you can get. The downside? It’s not free. And it never will be, I imagine. Still, for larger-budget projects it can be a hugely benefical step.

The third choice, is to read about the experiences of disabled users. It can be difficult to find this kind of information outside of lawsuits and news articles. These resources, though valuable, tend not to contain anything more than can be found in any number of online accessibility sources. Recently I’ve become aware of two blogs which can provide good insight: the American Foundation for the Blind and Blind Confidential, the personal blog of Chris Hofstater – a blind programmer heavily involved with the JAWS screen reader. The AFB blog is very general, but sometimes can provide an interesting link or story. Chris Hofstater’s blog, on the other hand, can sometimes provide fantastic insight into the experiences of the blind.

There’s nothing more valuable in accessible web design than getting a good sense for the experiences and frustrations of an actual user. If you can gain insight into the practical difficulties of a website, you’ve made the strongest step towards resolving the accessibility problem.

 Tags:

• Chris Hofstater
• accessibility testing