non-visual browsers

The suggestion that they should design web pages that can be used by the blind is something which most web designers will instinctively feel is beyond them. Surely this is a specialist task, akin to translating "ordinary" text into Braille? Or giving an audio commentary on a visual spectacle like a football match or an art gallery?

However, what you can do is remember that the visual aspects of any web page are essentially separate from the actual text. "Visual" browsers - meaning applications like IE, Opera and Mozilla which the majority of people use - are merely taking some text and markup and interpreting this in one particular way which happens to be the presentation of that information visually. But built into HTML and indeed into the whole idea of markup is the possibility of interpreting the instructions in a radically different way; that is, as sound or, more precisely, speech. In the end, this is little different to reading a book out loud. Same information, and pretty much the same method of delivering that information, but a different interpretation of it (at least for the listener).

There are various different interfaces that can be considered "non-visual" but the most commonly seen - or rather, heard - are "screenreaders". Screenreaders make use of speech synthesis to read a web page out loud for the benefit of users with restricted or absent vision. One of the most common screenreader applications is the package, JAWS. Rather than go into detail about this, you could look at the manufacturer's web site, which gives a good (if naturally biased) introduction. Other products are available, however: have a look at this summary page on screenreaders. If you want to know what a screenreader looks like, either check out one of the PCs at Leeds which has one fitted (ask ISS for details), or try this screenreader simulation - as you (obviously) need sound, however, you will not be able to use this properly in a university cluster unless you have headphones.

Writing pages that work well with screenreaders does, once again, develop from the general accessibility guidelines presented so far:

• write valid, well-formed code.
• use tags for the purpose for which they were intended. For example, JAWS will prefix each piece of heading text with "Heading level 2" (if it is between <h2> and </h2> tags). If all you've done is restyled a <p> tag JAWS won't consider this any differently from ordinary text, which means its users won't either. Note that for screenreaders, it is more appropriate to use the <em> and <strong> tags for emphasis rather than <b> and <i> as these latter two tags will be ignored by the reader.
• check how your page looks on text-only browsers as this is the closest visual approximation to how screenreaders will interpret the text. Pay particular attention to how your tables linearise. This is one circumstance in which the summary attribute is useful; for more information see the page on tabulated text.
• use alt on all images. Images without alt will have their filename read out, which sounds ugly. Don't overdo it with alt either, particularly for purely decorative images. If every little green button on your page has an alt attribute which says "Here's an image of a green button which I think is rather nice" your page will quickly become a very wearing experience to hear. Make the alt as descriptive as it needs to be if it matters. If it doesn't matter at all, include a dummy alt=" ". You might also like to consider the longdesc attribute, but I admit I've had no practical experience of this: for information, try the relevant W3C guidelines.
• people who use screenreaders are also invariably browsing using only the keyboard. As noted on the page about keyboard-only browsing, you therefore need to ensure that link text makes sense when read out of context and (should you be advancing this far into interactivity) that your forms are accessible as well (see that lesson for more details).

There are a couple of issues particular to screenreaders, however. Firstly, do watch out for their interpretation of some common punctuation marks. Many writers will use the ellipsis... for effect. But JAWS will read this out literally as "dot dot dot". That's fine if it's used in moderation but not if it's overdone. Myself, I admit to a tendency to use a lot of (parentheses) when I'm writing. JAWS reads these out as "left parenthesis - right parenthesis", however. Not necessarily a problem but worth bearing in mind.

More interesting, and useful, is the convention of a "skip navigation" link. If you look at the code for these pages you will notice, immediately after each <body> tag, the following code:

<a href="#startcontent" title="Click to skip over navigation" accesskey="2">
<img src="skiplink.gif" alt="Click to skip over navigation" />
</a>

"skiplink.gif" is a tiny, 1 x 1 pixel image filled with the background colour; in effect, it is invisible. But screenreaders have no concept of image size or colour so they still "see" the image and read out the relevant link text: in this case encoded in the title attribute (and note also the presence of an accesskey: explained in the section about keyboard-only browsing). The very first thing a screenreader will read out on these pages is therefore a link that can enable the user to immediately skip to the anchor, "startcontent". This is situated at the beginning of the table cell which contains all the main content of each page - once again you can check this by viewing the source code. So the link does exactly what it says. It allows the reader to skip over all the navigation and get straight to the content.

If you want to know why this is a good idea, have a look at Dive Into Accessibility lesson 10 first and then lesson 11. Lesson 10 suggests it is easier to rearrange your pages so that main content comes first, but this does conflict with standard usability recommendations - an example of why this web design lark is not always as easy as you think! And also note - and this is important - that their suggested method for using CSS to "hide" the skiplink from visual browsers will hide it from JAWS as well, which kind of defeats the object. The "invisible image" method works fine, however: or just leave the skiplink there for all to see. I am sure no one will get that offended, except maybe some graphic designers with a minimalist bent.

Back to the top

Back to the menu for lesson 6