This is a document that I wrote some time ago, indeed it was the very first document on hackcraft.net’s predecessor. It was lost during an update to that prdecessor site some time ago, but I've found some people trying to access it when looking through my logs. I then found a copy (an unexpected benefit of allowing people to copy your work) and this is it.
Since then two things have changed. The first is that the approach to web accessibility I complain of here has become less common, as I had hoped. The other is that I have become less dogmatic in my views and can see that while there is rarely any point in a text-only version of a site, the ideal of one version of a site suiting everyone irrespective of their abilities and their equipment's abilities may not always be obtainable — though hopefully technologies like CC/PP will improve the way we implement different versions of the same resource.
While I don't feel as strongly as I did when I wrote this, the arguments made are perhaps still worth publishing, so here they are…
The Irish Web Accessibility User Group [now defunct] was formed after a discussion on Open in which I criticised “Text Only” versions as a mechanism for producing accessible websites. Since this is a common practice, and appears to be mandated by some governments (it is used on all UK government sites), it is worth explaining why I frown upon it.
The decision to handle accessibility problems by providing a text-only version is predicated on poor assumptions about the variety of users that may encounter a site. While this is an improvement on the assumption that all users will be fully sighted, fully hearing users of IE5 or NS6 with good motor control it doesn’t go far enough.
Taking, as many do, the task of making sites accessible to only include those users with physical disabilities, there are many that may not be served well by either version of a site.
Taking accessibility in its widest sense, which I personally believe should be it’s only sense as far as designers are concerned, as making sure a site works for everyone, text-only versions are a poor mechanism for doing this. A user of a less up to date graphical browser, or a browser other than the “big two”, or who turns off some of their browsers features will often be provided with a choice between a version of a site which doesn’t work on their browser, and a “text-only ghetto” which doesn’t provide as rich an experience as could be provided, and which lacks many visual cues which aid usability.
People are naturally lazy, and often the best coders are those who are laziest because they come up with cunning workarounds for tasks which are sometimes less strenuous for the computer they are programming as well as for themselves. However laziness is not always a good teacher.
When given the task of producing two versions of the same site, one of which must be
text-only, there is a natural tendency to ignore all accessibility guidelines for the
version which uses graphics. It is easy to fall into the trap of thinking that there is
no need for alt
attributes for <img> elements on the
graphical version. Hoping that other guidelines would be followed seems very optimistic.
Many sites which offer a text only version link to this version from a home page which in all other regards was designed from a graphics only point of view.
Since this link is of little aesthetic value there is often little thought put into its placement and it can be hard to find, especially for text only users.
If, as is often the case, the rest of the page was not designed with accessibility considerations in mind it can be next-to-impossible to find the text only link.
It is perfectly possible to make a site which contains no graphical elements, and yet is still inaccessible to some users.
A few examples:
While website designers should strive to give their users as much choice as possible, they should also work to reduce the number of decisions they have to make.
There is a generally understood principal of information architecture that the fewer links one has to follow to find the information or resource one is looking for the better (the so-called “three-click” rule). A “text-only” link increases the number of links to be followed by one for every resource.
It is also a fact that while people want to have choice made available to them they don’t like making decisions. Any door-to-door salesman can tell you that it’s a good idea to get their product into the hands of their potential customers as quickly as possible; when they don’t have it in their hands they have to decide to buy it, when they do they have to decide to give it back.
If a user is making a decision that comes from choice being offered then the gain more than offsets the psychological difficulty. The user is also relatively confident about their decision (as long as the user-interface is sufficiently self-explanatory).
If a user is given an arbitrary decision to make; text or graphics, Flash or HTML, etc. they do not gain from their decision.
Many users wonder which is the “right” choice. If the user would prefer the text but can cope with the graphics they may ask themselves if the graphical version is updated more often, or were some features of the graphical site apart from the graphics scrapped in producing the text site.
A site loses users at every link. If users of your site may equate to customers a “text-only” link will cost you money.
I have come across websites, generally hacker websites since use of text browsers has a certain kudos factor amongst hackers, which offered both a graphical and text only version which were identical in at least some text browsers. The extra effort involved in producing the text version of the site was wasted, and the extra link for the user to follow offered nothing to the user.
Text only versions of sites are needless. HTML has had the ability to produce text-only
renderings of graphical elements since the <img> element was
introduced. While the mechanisms provided are poor in comparison to what would be
available to us if browsers made better use of the <object> element,
they are still rich enough that any good graphical design should work well as text.
Website designers often assume that text-only users are all blind, and that there are no circumstances in which a blind person may wish to download a graphic.
A user of a text only site may be fully sighted and have the technical capability to view graphics. A common example of this in practice is that if a graphic is a real resource on a site, (e.g. a site which shows examples of artwork, publicity photographs of products or screenshots of a program) then linking to a large version of the graphic from a thumbnail (a standard practice) should enable a user of Lynx to download the graphics file and view it in another program.
Ideally it should be perfectly possible for a blind user to download graphics as they
see fit [one thing I should have added here, is that there are indeed blind web users who do this]. If a blind user has a good understanding of what that image represents (from
the mandatory alt attribute, and perhaps the optional longdesc
attribute) they may be able to use that file when communicating to sighted friends and
colleagues.
Aren’t people discussing your site/artwork/products a good thing?
One of the reasons for developing text only versions of websites is that they are often easier to understand when printed.
As an accessible-to-all ideal any HTML document should be understandable when printed.
In terms of standards and browser development it is easy with some browsers ( IE4+ in
particular) to improve print rendering of a document. If an author provides a stylesheet
for a web page with a media
attribute of “print”
they can prevent elements such as navigation that make little sense in a print context
from being rendered and alter element widths, heights and fonts to improve the appearance
of print versions.
The only exception I can think of to this is downloadable versions of entire sites. If someone is downloading a 4MB zip file of a site they may appreciate the option to download a 500KB text-only version.
The Creative Commons license referenced below is equivalent to that I placed on the original.
Jon Hanna
