"Text Only" Versions Considered Harmful

"Text Only" makes false assumptions about users

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.

"Text Only" encourages bad practice

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.

"Text Only" links can be lost

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.

"Text only" sites do not guarantee accessibility

It is perfectly possible to make a site which contains no graphical elements, and yet is still inaccessible to some users.

A few examples:

• Frames will work with Links™ well, but poorly with Lynx™ (Lynx provides the option to view each frame individually, but this is a poor experience at best, and often completely useless).
• Navigation that works well in Lynx for sighted users may be confusing when rendered through Braille or speech.
• ECMA-Script can still be used on text-only sites for a variety of purposes, but is unavailable to many users, and many users will not have the same object model features that some ECMA-Script code may be use.
• Poorly thought out fragment identifiers may make links referring to them work well in Lynx and graphical browsers, but be useless to users of Braille and speech.

Choice is good - decisions are bad

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.

"Text Only" is often obsolete

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" is a poor use of technology

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.

"Text Only" makes false assumptions about text-based users

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?

Web pages should always be printable

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 one exception

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.

By Jon Hanna

A founder of Open, a collection of Irish mailing lists for Irish Web professionals, and an active participant in a variety of interest groups, including the W3C’s WAI IG and RDF IG and the IETF Language list (which amongst other things reviews proposed additions to IANA-registered language tags), and an ISOC member.

Source :: www.hackcraft.net

Related Articles :: Avoid Text Only Websites :: RNIB

[ printer friendly version ]  [ top of page ]