Okay, let’s be honest here. Not every day is necessarily spent being productive. Today, for example, I’ve spent a significant chunk of my time doing something which was fun, but not necessarily describable as work. I wrote an alternate lyrics version of Gilbert and Sullivan’s "I am the very model of a modern Major-General", from Pirates of Penzance. Don’t know it? Shame on you.

• Pirates of Penzance Page
• Wikipedia: The Pirates of Penzance
• Cast Recording from Amazon

Read more: Gilbert and Sullivan do Web Design

After the less-than-positive reaction to the complexity of the WCAG 2.0 working draft released for last call comments on April 27th, the WAI appears to have responded with the release of a quick reference to the success criteria and how to meet them.

One of the main reasons that WCAG 2.0 is so difficult to understand is that it was written with the intention not to require reference to a particular technology. Thus, from a practical standpoint, it is a very difficult document to manage. This quick reference has been written explicitly to provide reference for currently used standard web technologies – CSS, scripting, Multimedia technologies and others. In addition, it allows the ability to disable technology references which have no bearing on your current project – if you aren’t using SMIL, then you can disable this option in the quick reference.

Although the content guidelines themselves still have problems, particularly in reference to cognitive impairments, at least it will now be noticeably easier to make relationships between your practical, day-to-day work with code and the new guidelines for content accessibility.

As an aside, the guidelines for WCAG 2 are in no way binding until WCAG 2 has been moved to full recommendation status. This will likely take quite some time yet – I don’t anticipate that the draft will move to recommendation until at least sometime late in 2007.

Accessible web design is a big subject – so I’m trying to break it down into a group of the constituent parts of a website. I’ve gotten started with an article discussing the infamous task of constructing your main navigation structures, thanks to a stimulating question from Elizabeth Able through Cre8asite Forums.

I intend to continue forward and try and tackle some of the other big quandaries of web design, as well – next up will be accessible content, although I can’t really say when I’ll find the time for that. A very different beast from navigation, I think.

At any rate, the new article is available now – Check it out!

My little boolean search engine has been receiving a fairly substantial amount of traffic, so I thought I should make it a little bit more user friendly. I just uploaded a new version of the zip package which includes a template file to connect to your MySQL database and, most importantly, a little readme file with some very basic instructions for installing and modifying the search engine for your site.

Finally, I put up a example implementation so you can try it out for real. Also made some minor changes to the script itself, but no real spectacular changes – it should be a TINY TINY bit faster now, but that’s about it.

Edit: put up the wrong link to the search script. Oops!

I just fixed an error in the code for my PHP based poll script – please download the new version! No change to the version number; this wasn’t that major of a fix, but if you are producing a poll which will have fewer than 5 result choices you will need to use the new version.

Thanks!

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