One chronic problem in writing web development articles is keeping your writing readable. The world of web design, programming, and web accessibility is loaded with industry terminology which are undoubtedly not immediately obvious in meaning to someone who’s just begun researching the subject.

However, neither the option of excluding all industry terminology from an article nor the option of including a definition inline for every term is really palatable for me. With the first option, the article becomes simplified to a point of abstraction, and is less useful for the practically-minded designer trying to get a firmer grasp of the subject. Inline definitions, however, can easily interrupt the flow of the text, rendering the overall readability lower because of the extraneous information.

The fact is, a constant barrage of definitions is not the right choice for every audience; and neither is the assumption of too much or too little knowledge.

What I’ve done to attempt to tackle this sticky problem is begin work on a glossary of web accessibility terminology.
I will gradually be adding contextual links to these terms in articles where I deem it necessary or useful. Those who need the definition can follow the link, those who don’t won’t need to. I’ll also be implementing an alternate look for links to these definitions, to attempt to make it clear that these links are different from the normal, run-of-the-mill outbound links.

Why write my own definitions? So I can have continuous control over the definition of a term, and so I’m not dependent on some other authority site remaining authoritative or, for that matter, failing to include all the terms I may want to refer to.

The glossary has a long way to go – only 26 terms so far, but I’ll keep plugging away as time allows. Feel free to suggest terms I may want to define, as well…

There’s no doubt that the eventual release of Microsoft’s new Vista operating system is a big thing for the world of computing. Windows holds the vast majority share of office and home computing, and the release of their first new system in over 5 years will be very significant.

Matt Bailey recently pointed out Microsoft’s claims that Vista would be the most accessible Windows ever. His description of their new features sounds promising – one of the key improvements will be an extensive set up wizard which, rather than focusing on "normal" options and "accessibility" options, will interview the user about their work habits and demonstrate new features, hopefully resulting in operating system settings which match the needs of the user.

It’s a good idea – the interview process removes the stigma of disability from your computer settings, and instead focuses on the user experience. Whether it works, of course, is another matter – but that won’t really be testable until there’s a much larger body of users. Not to mention the inevitable bugs in a beta system…

Vista will also incorporate substantially reworked versions of existing accessibility options. These options will include speech recognition (now with a learning engine which will adapt to your own style and vocabulary) and more advanced magnification. The new magnification style will render images and text at a larger size, rather than simply stretching the view, which has always created distortion in the magnified view.

All of this is discussed at some length with Rob Sinclair, the Director of Microsoft’s Accessible Technology Group, in Microsoft’s PressPass. The press version, of course, carries the usual highly-positive spin of a Microsoft press document, but is thorough enough to give you a pretty accurate sense for what’s coming up.

Finally, Vista will incorporate a testing model to allow 3rd party software providers to incorporate accessibility features into their software. This is unquestionably a great addition. The easier you make it for developers to make their software accessible the more likely it will be they’ll take the time and effort.

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.

Limitations to the Net Guide

I said limitations, and I did mean it. The directory itself has imperfect accessibility. The search results page itself failes to validate – a minor flaw, but it’s lacking a required attribute on a Javascript block. In addition, there is no <noscript></noscript> tag set to provide information for users without Javascript support. Is this Javascript critical to the functioning of the site? No. In fact, it seems like it’s not even being used in the page – but regardless, for an accessible directory I’d have higher standards.

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.

groundswell

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"

Tags:

• wcag 2.0
• accessible web design
• w3c
• web standards

On occasion, I’ve needed to add various pieces of software to sites I’ve designed or modified. Particularly with database-driven projects I’ve found myself needing to heavily modify scripts I’ve found or simply write my own in order to massage the produced markup into some vestiges of accessibility.

Although I make no claims of perfection, I’ve recently posted three new articles in the articles section of this site:

• Basic Boolean Search Engine in MYSQL and PHP
• More About Boolean Queries in MySQL
• Simple poll using PHP and MySQL

None of these articles is going to provide you with rich, production-grade software or techniques for a large, heavily trafficked site. However, they should be easily sufficient to make it easy for you to add some small additional features to your
website which produces clean, valid markup.

Tags:

• accessible web design
• mysql
• php

Inline linking is the practice of incorporating hyperlinks into text passages within the main body of your website. Generally, this is a technique for providing contextual explanations or additional information as an immediately accessible resource for site visitors. I recently read two articles concerning this subject – the first, at Wolf-Howl questions the practice of inline linking as being bad for usability. The second, by Bill Slawski, discusses Graywolf’s ideas.

Both articles make a number of valid points – but I feel that the overall question is a matter of preference. Personally, I find the presence of links within a contextual body to be extremely valuable. For context, there’s nothing to beat it. Graywolf suggests that lists of links following the text are less disruptive to the flow of reading. This may be true, in certain circumstances. I certainly agree that it helps in the specific example he provides. However, it seems to me that what he suggests only works for short, tightly focused texts.

In his example, a single paragraph is followed by four helpful links. Given this density of contextual links and the length of the content, this is clearly useful. However, provided with a document which is significantly longer – a 1500 word article, for example, this technique would be rather clumsy. Either you would end up with a block of links every couple of paragraphs, which I feel would disrupt my reading quite significantly, or you have a lengthy set of links at the foot of the document – which may provide insufficient context to be clear on the referenced point.

I have to think about this from an accessibility standpoint, as well. If the links are provided only at the end of the article, a user with a screen reader has a significant amount of ground to cover before they can reach any further information. With contextual links, the user can decide right away if they’re interested in additional information. Either way, they can use keyboard navigation to quickly skip from link to link – but with links only available in the footer, it’s may be very difficult to quickly identify the context of the link.

I also mentioned the post by Bill Slawski. One talent that Bill has is the ability to aggregate a huge number of relevant sources on a subject very quickly. Bill points out several references I thought were very apropos, including information from Jakob Nielsen, the usability guru, the psychology department at Wichita State University, and others.

Bill doesn’t come down firmly on one side or the other – which I think is very fair. There are advantages and disadvantages every way you cut it for linking — either they’re disruptive or they’re convenient. They’re collected for easy reference or they’re separated for their immediate context. It’s always a choice you need to make — link to the most important references within your text, and leave a collection of additional links at the end of the article may be the best choice.

And always provide well structured internal navigation!

Tags:

• accessible web design
• usability
• inline linking