Text

s mentioned previously, from a computer's viewpoint, the most natural means of presenting information is plain text.  Moreover, HTML as a language is inherently text-oriented (remember that in its abbreviation, "T" stands for "Text").  Thus, by using plain text where possible you will significantly increase the accessibility of your content even without any further efforts.  Also, there are a number of situations where plain text accessibility can be improved by following some simple guidelines.

The rest of this chapter draws largely from an important document, "Unified Web Site Accessibility Guidelines," prepared under the authority of member organizations of the Web Accessibility Initiative.  I recommended that you consult this not-yet-finalized document for the most recent consensus and reference on the accessibility topics.

Note: To see if your document complies with various accessibility requirements, use the online accessibility checker.  This service will rate all the elements of your page and give recommendations on how to make it more accessible.

Text Markup and Formatting

The first thing to bear in mind when marking up text is to cling to logical tags describing what you mean rather than how you want it to look.  This drives out of favor a whole bunch of elements, including TT (monospaced font), I (italics), B (bold), BIG (enlarged font size), SMALL (reduced font size), STRIKE (strike-through), S (same as STRIKE), and U (underline).  Quoting the specification, "Although they are not all deprecated, their use is discouraged in favor of style sheets."  (The BLINK element is not even included in the HTML 4.0 standard.)

The same applies to the notorious FONT element that has long been a bone of contention between the proponents and opponents of Netscape HTML extensions.  The FONT and BASEFONT elements are deprecated in HTML 4.0, and all their attributes without exception are likely to pose accessibility problems.  The face attribute is obviously limited to the visual presentation and may fail not only for users with text-only or speech browsers but also for graphic browser users who don't have a particular font installed in their systems.

The size attribute of the FONT and BASEFONT tags is even more dangerous because, for inexperienced or frivolous users, the size of letters is very likely to pass as a substitute for the missing logical markup.  It is not uncommon to see sentences intended to be headings tagged by nothing but the FONT element with a large size value.

This formatting may look decent in a graphic browser, but for text-only or speech access, a sentence so tagged is nothing different from body text, which results in its being rendered in the same manner as what precedes or follows it.  Such a "heading" won't be marked by any pauses or tone change in the speech, nor by empty lines or character brightness in text mode.  Also, automatic indexers or parsing applications won't have access to the structure of your document---they won't be able to tell where one section ends and another starts.

Note: Sometimes authors slip into visual, not logical, presentation even without writing a single tag.  Borrowed from email style, emoticons (e.g. ":-)") as well as various arrow-like compositions (e.g. "-->") rely on how these punctuation characters look, not what they mean, and therefore are not portable into a non-visual medium.  Imagine a blind user trying to make any sense out of "colon---hyphen---closing parenthesis" dispassionately read aloud by the speech browser.  Not that it's going to sound very funny, so please avoid any unusual punctuation or fancy characters.

There's a counterpoint to this recommendation, however.  Many browsers (including Netscape Navigator and Microsoft Internet Explorer up to versions 3) do not allow accessing the Unicode character entity — to produce an em-dash (for reasons why you cannot access this character via the — entity, refer to Chapter 41, "Internationalizing Your HTML").  Thus, for those who are tired of deciphering puzzles like "...it is possible-even probable-to have...," the only way to produce something reasonably dash-like is to resort to "--" or "---" in the hope that users of speech browsers can guess what this stands for.

Color issues

The FONT and BASEFONT elements discussed in the previous section have one more attribute, color that indicates the intended color of text.  This attribute, along with the bgcolor, text, link, vlink, and alink attributes of the BODY element, pose another bunch of accessibility problems.  (Color-related properties of style sheets are also prone to similar problems, although they're easier for the user to turn off or override.)

Even sighted users are often embarrassed by the choice of colors that make some pages next-to-unreadable.  If the background is a too bright, flaming color or its contrast with the text is too low, reading the text becomes torture.  Only one thing can be worse than that: reading a text in small font over an image background with lots of small crisp details.

Obviously, a bad color choice is more likely to hurt those with low vision and color blindness than full-sighted users.  Therefore you should be very careful in color selection and, if possible, use the default values that are unlikely to pose any problems.  If you decide for an unusual color combination, you should not only check it for subjective readability, but also test it on a monochrome monitor to make sure you don't mistake contrasting hues (that may be indistinguishable for color-blind people) for the true contrast (which is mostly represented by contrast in brightness, not hue).

A monochrome monitor (or a desaturated version of the page's screenshot) isn't a true model of human color-blindness because most color-blind people are not incapable of perceiving any color but only some specific colors, usually green or red.  Yet such a test is a must given that there are numerous users of monochrome, laptop, or handheld web access devices. 

Last but not least, when setting non-standard colors in the BODY tag, do not forget to explicitly specify all the color attributes, including background, text, links, and visited links.  This is because some people set their own background or text colors in the browser, so any partial specification may result in a poor contrast of page author's text color with page viewer's background color (or vice versa).  Also, never forget to set proper background color if you're using a background image, or your text may become unreadable for those users who have turned off auto-loading images in their browsers.

Lists

Lists are often used in HTML documents for presenting collections of one-level or nested elements.  One common use of lists, namely the rows of links for navigating around the site (navigation panels), is now frequently implemented as graphics; also, lists of text elements sometimes use tables for layout and graphic images for bullets.  However, even when marked up by the purely logical OL and UL tags, lists may present some accessibility problems.

When viewing a page in a browser window, we may not realize how heavily our perception relies on the two-dimensionality of the canvas.  Even when reading plain linear text, your eyes not only follow the lines but often leap back and forth (mostly unconsciously) in attempts to find out where the current paragraph or section ends, what goes next, and so on.  The knowledge acquired from these eye leaps allows your brain to plan (again, unconsciously) for the near future, to make reading more efficient by skipping what seems unimportant and by "previewing" visually marked material even before we reach it in the flow of reading.

Now, try to imagine how a disabled user with a speech browser perceives the same information, being completely deprived of the visual clues.  Such users have no means to skip forward (being totally unaware of where to skip), and to refer back to what has already been read, they have almost no means but their memory.  For a sighted viewer, this limitation could be compared to reading a page through a tiny hole in a sheet of paper (so that only a couple of words can be seen through it) that is moving evenly and dispassionately along the lines of text.

All this helps to understand the two requirements set forth for lists in the "Unified Accessibility Guidelines" document referenced above: First, all items in a list should be numbered, and second, you should state beforehand how many items there are in a list.  For example:

Now let me summarize the above in a
list of 3 items:
<OL>
  <LI>Some item
  <LI>Another item; here follows
            a sublist of two items:
  <UL>
    <LI>First item
    <LI>Second item
  </UL>
  <LI>Last item
</OL>

As you can see, you don't have to always use OL elements (ordered lists) because sometimes it is more appropriate to "number" your items verbally by writing something like "First," "Second," and so on in the text.

The same advice applies to stating the total number of items---you don't have to be pedantic and stick to the formulas given above.  Follow the natural flow of your prose and just make it a little bit more self-explanatory when it comes to a list.  For example, "The two principles of accessibility can be summarized as follows:" will work just fine before a two-item list.  These provisions will make your lists much more friendly towards users with disabilities.