Weblogs: Web Accessibility

CMSWatch have an opinion piece on creating accessible websites with a content management system. Written by Jim Howard, it starts off well with the title "Content Management can improve accessibility". No question, content management is based on structure and systematic process - two important foundations of accessibility.

However Howard shows his true ignorance of web accessibility with the following statement in his introduction:

In my opinion, the best way to achieve accessibility-compliant websites is to generate multiple sites. For starters, a publisher can create two sites -- one for use by those who navigate via a standard browser, and the other for those who rely on sound to navigate with a "screen reader" for the blind and visually impaired.

Content management systems can create multiple sites with the same content. Howard suggests: "The good news is that any organization with a web content management system in place should be able to publish multiple sites fairly easily, thereby meeting accessibility requirements in a much more successful way.". How does multiple websites meet accessibility requirements? (Or more precisely, what accessibility requirements does multiple copies of the same content meet?)

Howard's perception is that accessibility can be improved by creating separate websites for each range of disabilities. One website for the blind, one for the partially sighted, one for motor-related disabilities, one for dyslexics, one for colour-blindness (or should that be three to cover the main three colour blindness afflictions?).

I've covered the drawbacks of a multiple website approach to accessibility before, so this critique doesn't cover those issues again, although I recommend the reader to read both in conjunction.

Structure and content

Similarly, good web designs use visual cues to tell visitors how to navigate, show inter-relationships between content elements, weigh the importance of content, indicate content categories and hierarchies, and convey the type of content. All of these things tend to break down quickly for hearing-based navigators -- even when accessibility guidelines are followed. Delivering a quality site for hearing-based visitors requires totally different thinking about navigation and information presentation.

Last-century markup techniques were based on the "looks right in my browser" technique. As a result concepts like structure and consistency were discarded. In this mould, Howard suggests that visual cues are required to show structure and relationships, so they must be inserted into a website.

What Howard misses or misunderstands is elementary HTML. HTML has elements to describe inter-relationships (lists, tables, headers, fieldsets, generic containers). Showing inter-relationships between content is nothing more than having a well structured HTML document. Content is styled based on its structure.

Structured documents, by default, are rendered with visual or aural cues. For example, how do you tell a piece of text is a link? If you are visually-capable, you'd probably look for blue underlined text. If you were using a screen reader, you'd listen (using IBM's Homepage reader defaults) for a female voice. To get this effect requires nothing more than marking up the link text with anchor tags and specify a hypertext reference - a destination URL.

HTML describes the structure and relationships within a document. With just that level of focus a document is both visually cued, and sufficiently aurally-cued to meet these two audiences. The predilection that the web is first a visual medium, then second an aural medium is plainly false. The web is a structured medium first and foremost - from that both visual and aural representations are rendered.

A well structured HTML document requires no visual cue to remain structured, and the document's structure does not break down when a screen reader is used.

Usability studies (by Jakob Nielsen) suggests that people don't read content in a web page - they skim them. Speech-based browsing is very similar to visual-based browsing. Both groups skim pages instead of reading every word from the top down. So a typical technique to improve the readability of web pages is to create useful hooks in the content. Typical hooks are lists and headers - these list or summarise various points. Another important technique is to front-load content.

Navigation

Trying to have a single website that works for multiple navigational approaches results in a site that is difficult to use for all kinds of site visitors.

If a navigation scheme is too complex to render acceptably in a screen-reader, then it is also too complex for the sighted visitor. The typical human can deal with five to nine options at any one time (this is the seven plus or minus two rule well known in usability circles). A navigation scheme that is optimised for a typical sighted human being is ironically optimal enough for the non-sighted one.

How many ways are there to link on page to another. I count one - using an anchor link. This tends to be used in two ways:

1. Contextual links
2. Global navigation links

Both navigation schemes serve the abled and disabled readers well.

Correction: Jules over on accessifyforum points out that the link element is another way of linking pages. It can be used to describe relationships between documents.

Optimising for accessibility

Howard suggests the idea that an "accessible copy" of a website can then be optimised to improve the level of accessibility. He suggests the "accessible version" of the website can use "skip to content links" to allow a screen-reader to jump to the right part of the document.

This optimisation suggestion does not bolster the argument for multiple website since the very same technique can, and is used, to improve the accessibility of a website that caters successfully to both disabled and abled audience.

Detecting the web browser

Howard's contention is that all the webserver needs to do is detect the browser being used and deliver to that browser the optimised website for their particular disability. There is a fundamental problem with this suggestion - apart from the well established fact that browser sniffing is an awfully unreliable practice.

The current crop of screen readers on Windows use IE as the browser and interface to it using Microsoft's Accessibility Architecture (MSAA). JAWS, Window Eyes and IBM Homepage reader are effectively speech-capable interfaces on top of Internet Explorer. As a result, it is impossible to correctly and reliably determine whether a speech browser is being used.

Following on from that, it is not possible to do a browser detection that can identify a colour-blind user (or which form of colour-blindness they suffer from), not to mention whether a visitor is running with bigger fonts, or whether they are using a keyboard for navigation.

What benefits can a content management system offer?

A Content Management system can improve the general level of accessibility of a website. Its consistent and template-based approach to website management makes it easier to fix site wide accessibility problems cheaply.

Where most "enterprise level" content management systems fail is that it fails to enforce a structured approach to the content. Its great that the writing process is workflowed, but the content itself is treated as nothing but a blob of text. Major failings of enterprise level content management systems are:

• Checking whether proper headings are used instead of bold paragraphs which look like headers.
• Checking whether a page is valid markup before it gets published
• Producing gibberish unreadable URLs - for example the URLs for Amazon, the BBC and CNet are a nightmare to follow in a screen reader.
• Alternative text to non-textual media (images, flash) are not managed like textual content - so they are overlooked.
• Using HTML attributes and font tags to style a document instead of using style sheets
• Using nested tables instead of generic containers to structure a page.

---

[ Weblog | Categories and feeds | 2011 | 2010 | 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 ]