Text-friendly authoring topics Text-friendly authoring topicsLet me start by trying to dispel a common misunderstanding. "Text-friendly authoring" isn't in the least about eviscerating your web documents by cutting out all the other media such as images, sound, executable code etc. On the contrary: the intention is to use the appropriate media for each purpose, and to use them to the full; but to avoid those other media getting in the way for readers who cannot use them. Nor is it about creating a complete additional text-only version of your site: that might, very occasionally, be justified, but I don't recall meeting a situation where I would have chosen that approach myself, and have reviewed quite a number of examples of other authors doing this where I came to the conclusion that their approach had been misguided [1].
The point is that text (typically, text marked up in HTML) can be accessed by all presentation situations, not only graphical browsers and character mode browsers, but also speaking machines, indexing and summarising engines, etc. By all means use also images, audio, javascripts or whatever best suits the content that you are providing - but use them well: if you use them in ways that fence away your text content behind impenetrable javascripts, Flash, or other less-accessible media, you lose, both in terms of accessibility by users who are in unexpected situations, but also and importantly by the indexing robots. With many millions of documents on the WWW, competing for readers' attention, you need those indexing robots!
Text-friendly authoring also has a lot in common with the topic of disability access.
I'm sorry: like most of my stuff about WWW authoring, this started off as a short and simple briefing on a single topic, and then got filled out in response to usenet discussions until it has become a veritable patchwork quilt of explanations and advice. It certainly needs re-organising into a more accessible form. What is also certain is that I have a "day job", leaving me only limited time to hone my WWW documents.
Some thoughts on choice of ALT texts for IMGs, with a tabular summary, and some supplementary discussions.
An Italian translation of these articles has been provided by Michele Diodati in the scope of that author's W3C and Accessibility translations.
Technique: Floated discretionary image link with in-line text link.
Myths about accessibility at the WDG
I recommend Ian Hickson's "mini faq" page about alt text.
For readers of German: Warum ALT Attribute Pflicht sind by Björn Höhrmann.
Accessibility Valet and its Online demonstrator is well recommended for serious use, although for a casual beginner, the sheer number of different issues which it raises could at first be a bit overwhelming and demotivating.
A-Prompt is often mentioned, and has some features which could be advantageous relative to other browsers, but it's incomplete and is evidently no longer being maintained: I can't recommend it.
What used to be the Bobby accessibility checker is now part of WebXACT: this can be a useful tool when well-applied, but, like any other checker based on objective tests, is by no means appropriate to be applied "by rote" without understanding of the associated subjective issues. I say a little more about this below.
A collection of useful Bookmarklets including image alt/title diagnostics.
Lynx seems to rate as the most-frequently mentioned text-mode browser, although it is by no means the only text-mode browser which is still actively supported.
Even if you don't propose to use Lynx as an everyday browser, it can serve as a rather instructive authoring tool for helping to assess how a site might be "seen" by an indexing robot or a speaking browser.
The best source of general Lynx information is to start at http://lynx.browser.org. This includes pointers to ported versions of Lynx for Win32 OSes and even for 386+/DOS. Please do not confuse these Windows- and 386+/DOS ported Lynx versions, with the original "DOSLynx" (a much older package, that can be considered well and truly dead).
See also notes on INPUT TYPE=IMAGE.
Lynx incorporates excellent support for i18n, by the way, although you need a Unicode-supporting terminal emulation in order to take full advantage of it.
The Opera browser has a viewing mode which emulates text-mode browsing, and can be used by authors to review their pages for text-mode compatibility without having to load a separate text-mode browser. Look for it on the View-Style-Usermode menu.
was once a supported browser within Emacs; however, it currently seems to be resting
Toby Speight sent me some images of emacs-w3 displaying my demonstration document, and later sent me a report on forms handling in emacs-w3.
In this area I have been concentrating on text-mode access from the point of view of an otherwise "able" reader. I'm not claiming to offer specific disability access guidelines, as the W3C WAI are already doing a much better job than I could, but it's comforting to know that my notes have been cited in several papers and articles that were promoting disability access.
If you are interested in (or mandated to) the provision of disability access, then you'll certainly need some references that deal with the subject in its own right. May I refer you to the Web Accessibility Initiative area at the W3C for active discussions. Objective checkers such as Bobby (now: WebXACT) are no magic bullet - there are many issues where Bobby cannot determine programmatically whether you are following accessibility principles, and can only draw your attention to the potential risks of any techniques you are using, leaving you to apply good-sense and appropriate guidelines. And some of Bobby's more prominent suggestions for repair are distinctly suspect, e.g "provide an alternative text-only page" (something which the WAI, rightly in my opinion, rates as a very last resort for use only when all else has failed).
I'm no expert in relation to speaking browsers: apart from a few demonstrations at conferences etc. and a time-limited free trial of IBM Home Page Reader, I only know what I've read about how blind and partially-sighted readers deal with the WWW. I gather that the traditional way to handle the situation is a "screen reader" (it renders text strings into spoken form: an example was the IBM screen reader), taking its input from text in a screen window, which could be the Lynx browser (numbered links mode is said to be convenient for this), or might be any other browser. However, nowadays (written 2005), most "screen reader" software is significantly web-aware, and doesn't merely recite to the user what's displayed on the "screen". So the distinction between a traditional screen reader on the one hand, and a talking web browser on the other hand, is far from a definite distinction. Unfortunately for those who rely on server statistics, IBM HPR works via a normal web browser (nowadays MSIE), and so it doesn't show up in server access logs.
I think it's worth bearing in mind, though, that applications for a speaking browser are not limited to the blind: there are times when sighted readers like to rest their eyes or want to use them for something else, and would benefit from having information read out to them.
[1] Indeed, quite a number of the specifically "text-only version" pages that I have seen were distinctly inferior to what Lynx was able to do with their regular graphical version. One almost suspected that the author had no clear idea what text-mode browsers such as Lynx would do, and had constructed their "text-only" page on the basis of superstition and dead-reckoning. Paradoxically, these text-only pages (if kept properly updated, which is another bugbear with such pages) can be jolly useful on graphical browsers when network speed or cpu power is in short supply! - but I see little or no evidence that they are needed or even useful on text-mode browsers such as Lynx or w3m. What's more, the text-only pages have a tendency to outrate the graphical versions at the indexing services, which is I suppose a kind of poetic justice.
Original materials © Copyright 1994 - 2006 by A.J.Flavell