Craig Francis

Features

Screen Readers

Screen Readers allow visitors to access a website without the use of a monitor.

They do this by describing the page using an output like an audio voice or braille display, of which the description includes the content and structure of the page.

It should be noted that screen readers are not necessarily used just by the blind, they can also used by people with with learning difficulties, cognitive issues, partially sighted, etc. For these users, the screen reader becomes more of an additional aid, which helps them get better access to the websites content.

When developing a website, the authors need to be aware that screen readers currently cannot read text found in images, most interactive content becomes confusing or even unusable (Flash / JavaScript), and that simple references like "on the left", have no meaning, as a screen reader only reads though the page top to bottom.

Please see below for some more specific notes, of which I want to say a big thank you to Steve, John and Tom from Test Partners, who gave a wonderful demonstration of a screen reader in use. This demonstration allowed me to create most of the notes below, however I also want to point out that Steve Green wrote the list about the "normal JAWS behaviour" on the GAWDS mailing list, which has been duplicated here for everyone's reference.

Normal JAWS behaviour

External links are read as "link".
In-page links are read as "this page link".
External visited links are read as "visited link".
In-page visited links are read as "this page link" (the same as un-visited in-page links).
If a new page is opening, JAWS (Internet Explorer) makes a click noise and announces the page loading progress by reading "five percent", "fifty percent" etc.
When a new page has fully loaded, JAWS automatically reads the title, the number of headings, the number of links, then starts to read the contents.
When an in-page link is clicked, JAWS automatically reads the number of headings, the number of links, then starts to read the contents from wherever the link pointed to. JAWS does not read the page title for in-page links.
If a user clicks any kind of link, JAWS should read something without any further user action. If JAWS does nothing, the user will be confused.

General notes

Users only see the content in a linear fashion, have no idea of left and right (visual representation).
Most users do not change default settings (they may use multiple computers and are usually scared of breaking them).
British users like the lang attribute to be set to "en-GB".
Sometimes a screen reader might skip content that is perfectly visible (bugs?) and need to be manually checked.
Do not refresh a page automatically, the screen reader probably has not finished reading the content yet.
Avoid ASCII art, even something as simple as "::" can be distracting.
Avoid long words which might by difficult for a screen reader to pronounce.
Providing an "accessible alternative" version of the page is usually ignored as they are usually out of date.
The site map is a fail safe just incase the normal navigation bar cannot be understood or used.
PDF content can rarely be made accessible. It is nearly always easier to convert to HTML.

Media

Do not use visual attributes to convey meaning (e.g. do not use a table-cell bottom-border to show a divide line in a calculation).
Flash should include an alt="" tag to explain what it does (e.g. decoration Flash should tell the user they can ignore it, not left wondering).
JAWS has poor JavaScript support, but it still ignores the <noscript> tag, as it thinks that it can handle the JavaScript.
It is very difficult to get JavaScript to alter the content and still inform the user it has happened (e.g. image rollover to show a description).

Words

The title attribute (title="") on most tags are ignored by default.
Abbr tag is ignored by JAWS (again title attribute), first time the abbreviation is used, it should be written in full (abbr in brackets).
Do not expect something to be written in caps to be spelt out, sometimes it might try to pronounce the word.
If you have an image (e.g. company employee) with their name printed afterwards, set the alt to blank (no point repeating the name twice).

Shortcuts

Access-keys are rarely learnt and frequently interfere with normal shortcuts (e.g. "alt" followed by "0" and "233" is for the e-acute).
Users frequently use the [h] key to skip between headings (quick page navigation).
Users can quickly skip to the next "edit field" (perhaps looking for a search field) by pressing [ctrl]+[e].
Search results are naturally difficult to sequentially look though, as by there are all very similar (helps putting the results in an <ol>).
Users take a risk by following links, so they like to be sure, instead of just guessing (to avoid getting lost).
Users can pull up a list of all the links on a page (can be sorted by the source, or alphabetical), so use meaningful text (not "click here").
Avoid foot notes (e.g. "*"), as the user will have to decide if they should risk looking for the relevant foot note (anchor links can help though).

Navigation

Navigation bar should be consistent, do not remove links between pages, re-organise or move the nav (as moving to the next page might appear to be a new site).
On entering a page, a list of links is presumably a navigation bar... but an off-screened <h2>Navigation Bar</h2> should help avoid confusion.
Sub Navigation should avoid using nested <ul>'s as the user is unlikely to listen to the nav on each page AND notice the differences.
Bread-crumbs are difficult to understand especially when they use the ">" character. Although they are easier with "you are here" starting text.
Do not use a <select> with onchange for a nav... most users do not know how to expand the field, using the [space] bar, to avoid the onchange event triggering.

Forms

Every field needs to have a label.
Do not follow WAI guideline "10.4" (include place-holding characters in fields) as the user will rarely realise the need to delete the text.
Additional information for a field (possibly in a <p>) should appear before the field and refer to the field "below".
A user can move into "forms mode" which only reads the label and field (no other content in the form).
Each label is prefixed with the <legend> value.
Use an asterisk to mark mandatory fields (not background images).
When the form is submitted for server side validation, it helps to use the page <title> to tell the user immediately that something has gone wrong, as this is one of the first things to be read on page load.
Using a <ul> to list form errors is easy to identify, although the fields with an error should also be marked with something more than red text.
Avoid the use of JavaScript text injection validation. Usually very difficult to get it to inform the user why the form did not submit (on some screen readers the user expects to hear a "click" to indicate a new page loading when the form is submitted).
Ironically, the best form of JavaScript validation uses an alert() box as it steals screen reader focus, although this is not good for users of screen magnification software.

Tables

Tables need a summary / caption if the meaning is not well defined.
Each table should use the scope (th) OR headings (td) attributes to help identify each table cell.
Never use tables for presentation (very distracting with the screen reader announcing the begging of a table with row and col count).

Example screen readers

Notes regarding these screen readers are from Alex Midence.

NVDA - Open source screen reader which is rapidly becoming extremely popular with blind people for work and home use since it is highly functional and free (portable version).
JAWS - Over a thousand dollars and it goes up from there depending if you want home or professional versions. So typically used in a commercial environment or with government aid in the USA.
Orca - Screen reader for the Gnome desktop on Linux and Open Solaris. An excellent screen reader that can go toe to toe with the best of them. Very scriptable and also quite good at "flat review" which lets someone review a webpage in a non-linear manner.
Speakup - Screen reader for the Linux command line, used with browsers like Lynx, w3m, and Elinks. There are lots of blind people who use Linux.
Emacspeak - Self-voicing wrapper around the Emacs desktop for Linux and Unix which was written by blind programmer T. V. Raman who now works for Google and on the Android project.
Vinux - A re-mastered version of the Ubuntu Linux Distribution optimised for visually impaired users.