Optimizing Pages for Screen Reader Accessibility
By Veli-Pekka Tätiläp>Alasdair - broken links and unavailable files have been removed from this page and are lost forever.
This is a guide to making accessible Web-pages for blind screen reader users. The page is basically a structured collection of design choices and explanations on what will be difficult or won't work if you don't adhere to them. One major point is raised per paragraph so you might like to skip around a bit, particularly as some of the explanations are pretty involved. This page does not attempt to give a generic picture of keyboard operation and screen reading, I won't concentrate on the sighted user's convenience much on these pages. For a more extensive take on Web accessibility I recommend you check out the W3C Web Content Accessibility Guidelines as well as this INteractions article on Blind User's Web browsing .
Du not use flash, unless you know how to make it accessible, no matter what fancy features your site will loose. I Actually, Flash content will work with Flash 6 or later supporting Microsoft's Active Accessibility (MSAA) but this support also requires a fairly new screen reader. The current versions of popular screen readers, at least Supernova and Jaws, will work ok with truely accessible Flash but there are still people using the older versions since the upgrade costs quite a bit of money. Flash based content is totally inaccessible with the older software. By saying totally, I mean it! Not a single Flash-control or text will be spoken. Some people are able to use magnification to navigate Flash pages (like I) but the situation is very bad for totally blind screen reader users and most Flash scripts don't have very good keyboard support.
Speaking of Flash controls, please avoid audio players which have a mouse-only interface. As most blind folks rely heavily on synthetic speech, you might create a situation in which the music, which the keyboard user cannot turn off, drowns out the speech used to access the site. For an analogy, think of visual distractions like semi-transparent, always-on full-screen videos overlayed on top of the Web page. Yes, loud music can be that bad for a speech user.
Animation and Java
If you want to keep your web page accessible, don't include any fancy scrolling texts, animated gifs or other animations. These tend to draw screen readers focus away from the main text and other important content. Often, if there's a scrolling text, a screen reader will try to read a part of the text but as the text changes continuously, it has to start all over again all the time, and this makes it impossible to use the site without using a so called virtual cursor. Virtual cursor or navigation mode (the name varies) is a kind of pseudo-cursor that can be used to navigate cursorless areas as if you were in a text field. Besides, not all screen readers include virtual cursors, although most do.
The current screne readers are able to handle the form elements quite well. Try to keep the forms as simple as possible, don't rely on the user to know the info between fields since he or she might tab from field to field, and preferably testthe forms with a screen reader program.
I should also mention that some kind of textual indication of required fields in a form is recommended e.g. putting the word required in parenthesis after the text on the left side of a textbox control. another way is using some sort of default input for the field if possible, that is the text required or something along those lines. Using a character, such as an asterisk, to mark that a field is required is bad form as a screen reader may have been set up so that it won't read special characters. Even worse is to use color coding for the fields mainly for three reasons. Firstly, if Internet Explorer's automatic font and color formatting features are used, the color coding is fully ignored. And secondly, some color blind people may not be able to tell the difference if you choose the colors poorly. Finally as with the punctuation, the user might have turned off notification of color changes to make the spoken output less redundant.
One essential element in forms is that each control in a form must have a visible label. Some screen readers are able to guess the text's labelness based on its visual layout but you should never rely on this. In stead, use the label tag or some other means to mark a piece of text as a label for a particular input type. For example, titles can be used to add further, optional information to controls, but they should not be used as substitutes for labels. The reason is that many screen readres, including HAL and Voice Over, don't read them by default at all.
As a bonus for using these label semantics, mouse users are now able to click on a label text to set the focus to the relevant control, at least in most graphical browsers. If there is no label text, the screen reader cannot tell the user anything significant about the form element in question, unless it guessed the label on the page based on visual layout. An unlabelled search field would be read out as "edit area" with no hints that it is a search field at all. Only when you proceed in the tab order to a button called Go or Search does the role of the previously unlabelled control become clear. It is good practice to give the first form element the focus by default when it makes sense, such as on login or search pages. This can save a lot of sequential tabbing from the keyboard user's point of view.
Another surprising revelation is that aural CSS is not supported by current screen reader software apart from EmacsSpeak, to my knowledge at least. Screen readers, as their name implies, read the screen. Thus what they get is the browser's document object model for the media type screen rather than anything targetting a speech synth in particular. Having Aural CSS support would require the use of speech browsers or some powerful accessibility API for exposing aural information to screen readers. As far as I know, no such API exists in Windows. Another issue is the lack of being able to specify whether CSS should be able to override screen readder settings. In Dolphin products, the screen reader would always take precedence.
Using navigation list boxes (drop down menus) is a good idea in theory as it let's you condense a number of navigation links in a single item in the tab order. In order to make it easy for the users to reach the list quickly using the tab key, you might consider using the tab index property to make the list box the first item in the tab order? Additionally, you should avoid using indescriptive list element names or names entirely made of punctuation characters. In the latter case, the screen reader may read nothing at all if punctuation is set to none. Also notice that elements should have some clear ordoring, alphabetical will do if there's nothing better. Element names should never have redundant beginnings such as at least 500 words, at least 50000 words etc... This is because speech is a linear medium and thus you need to listen to the redundant at least bit for every list item, slowing down navigation considerably. Secondly, Internet Explorer let's you only search list items by typing in their first letter such as a. Starting all list items with a text starting with the same letter makes it impossible to jump to a particular item directly using the keybord.
Be sure not to use a list box with an auto-jump option for navigation. The problem with this approach is that if you cursor through the list with the keyboard, each element is activated in turn and automatic page navigation is usually based on element activation. I've seen all too often navigation lists in which one doesn't have time to read through the list item description with a screen reader before the browser navigates to the selected and usually unwanted Web page. I recommend placing some activation button you have to press before navigation. Binding enter as a shortcut to this button wouldn't be bad either. one option to work-around auto-jumping list boxes on the browser side, is to use the shortcut alt+down arrow in Internet Explorer. It let's you open the list and cursor through it in piece. Only after pressing enter on the desired item will the list close and generate an item selected style event.
Oh, and one thing. IF your site has a search engine with some buttons, please bind some shortcuts to them so that enter will launch a search and esc will clear the search field. This is standard and expected behavior.
Although the newer screen reader software usually works quite well with frames, older screen readers have severe difficulties with documents utilizing frames. Often it seems to be difficult to navigate between different frames and ssometimes it's hard to get a screen reader read a frame properly without reading some text from another frame as well. For the sake of accessibility, it's usually best not to use frames, for instance, to make a table of contents menu. A better solution for this kind of application would be a link list at the top or bottom of the page. But if you use a link list, the links are easier to use and navigate if they point to physically different HTML files and are not just anchors pointing to different sections of the same HTML file. This is because even if an anchor link to the same page will jump you instantly to another part of that page, the focus remains still in the previously selected link. If you press tab after jumping to the middle of a page, the link after the selected anchor will be selected, not the first link below the "jump point". Try this out on a Web page and you'll know what I mean. The virtual focus mode in screen readers has made it considerably easier to use anchors linking to the same page, though.
One common application of frames is to make a floating menu or text at the top or on the left side of your web page. This is not usually a good idea and was a real problem in the past. With ancient screen readders, they read the text linearly from left to right line by line unless column detection was on. If you have a floating table of contents bar at the top of the site for instance, such readers would have read it every time the user scrolls the page without using a virtual cursor.
Generally speaking, tables should work quite well with modern screen reading software as long as you keep your tables relatively simple. If you want to ensure maximum accessibility, do not use tables at all as some very old screen readers may not work well with them. Generally speaking, you can, however, include tables when necessary but do consider pre-formatted text as an alternative for simpel tables. For some magnification users (me included), borders make crowded tables look messier, so you might want to avoid them.
Tables should have clearly identifiable column and row labels and it is best to avoid tables having numerous columns, The real issue behind these recommendations is that screen readers only read the columns at the top so the screne reader user must remember the order of the columns to get their meaning right. Cross-tabluation is particularly cumbersome to read with speech. appending the column header at the end of each item in the column or writing a good text summary may be helpful in some cases.
If you have a table with links in it, be sure to redifine the tab order in the HTML code so that it's logical and not necessarily from left to right and from top to bottom.
One popular application of tables used to be text formatting. A table was often and sometimes still is used to create a column layout for a page. This is bad practice because, firstly this approatch is not generally recommended as far as I know, and secondly ancient screen readers didn't get the column semantics from the Web page itself. As a result they would ignore the column layout and read the first line of column one, then the first line of column two and so on until there's a line break (either hard or caused by word wrapping to window size). After the line break, the screen reader would then jump to column one in line 2. Need I say more? The order of the paragraphs and liens was quite effectively messed up by this behavior. Some PDF documents still suffer from this same basic problem.
The best position for a navigation list tends to be the top or the bottom of the page. And if the link list is at the top, you should include a link called To Main Content which jumps directly to the main text. Without this link the screeen reader will first read the link list at the top of a page unless you scroll or tab past the link list to avoid this. Lastly, don't use a non-link separator character such as a vertical bar to delimit a list of links. Some ancient screen readers used to read link to text and text to link changes so that the end result sounds like: link some stuff, normal vertical line, link thing 2 normal vertical line, link mail me normal and so on.
Accessing your page is going to be difficult if it's full of image links with no descriptions. First, those who have turned pictures off (or are using a text-only browser in a terminal) will suffer as they get no textual data about the links. Thus Navigation in this case is quite impossible. Secondly, the situation is equally bad for screen reader users as there's no way for a screen reader to determine what's in an image with no description. A good solution here is to use the alt attribute of the image tag to provide a description of the image. Graphical browsers tend to render the description as a tool tip. In addition, those with pictures turned off, can still navigate as they see the alt texts you provided in stead of the pictures. Screen reader users will benefit greatly as well, as new versions of Internet Explorer and newish screen readers support MSAA, which basically means that IE can pass the image description to the screen reader and thus screen reader users can navigate the page as if the image links were replaced by alt texts. If you want to include longer image descriptions for the blind and visually impaired people, you could use the special longdesc attribute. In practice at least Supernova V7 won't read the longdesc at all, however, so you should provide alt-text still and make it a viable fallback option.
I'll also mention that you should carefully think of the link texts. They should be informative and brief. Click Here , for example, is extremely bad form. Link texts should be context free meaning that even if represented with a link list only, you have an idea of where a given link will lead.
Sometimes it is acceptable to make some of the links context sensitive but only when the other focusible controls provide the context. A typical time saving mode for blind Web users is to tab around all the focusible controls on a page to get the big picture and navigate rapidly. So the types of controls that get the focus and their ordering can make a huge difference on how the page is perceived. Google's search results make a good example and they also do include some context sensitive links. The links cached and similar pages would not be ordinarily clear from the context. In this case they are, however, because the page title which always preceeds the two links, gives the blind user enough context to navigate. Sometimes you do wish to only hear the primary changing links such as the page titles. In such cases one has to hit tab multiple times to skip around, in case of Google trice. page navigation will be easier if the tab distance between your important links is a constant and a small constant at that, too.
You should avoid placing all too many links on a page. Many sites do this basic mistake and browsing such sites is straining for Screen reader users because they'll have to navigate the links one after another using speech. There's no way to get the big picture by voice and most auto-summarizers aren't too good. On the browser side, sequential traversal with tab and shift tab is the only way in most cases. There are screen reader specific link lists but they are hardly an ideal solution and do have their share of problems. SO put the most important links first and kepe the total number of links down.
HTML lets you bind keyboard shortcuts to links. Don't bind a keyboard shortcut to every link as it's soon really hard to remember what key did what. In stead, bind some shortcuts to the most commonly used links (e.g. navigation links for the major sections of the site) and be sure to tell on the main page what keyboard shortcuts can be used.
Avoid multi-line links. This may not seem like a big issue as links spanning across multiple lines are common these days and work well with most screen readers. However, I used to have a screen reader (an old version of Supernova)that was unable to read multiline links. It read the first line just fine but nothing after that.
Finally, if you are using tree structures of links in HTML you should make sure, either through server or client-side scripting, that the focus returns to the last item being operated on. If you don't do this, after opening or closing a tree item the user needs to tab down the page to the very same item manually, which can be highly annoying if the tree is big. And what's more, it would be even better if you could indicate the state of the tree items with some labelled graphic or bit of text such as opened or closed. Moving in the tab order, the only bullet-proof way of finding out whether a tree branch is open is to tab over the branch. If you get a child item after a parent, you know that the parent node is open. If, on the other hand, the focus moves on another familiar parent node,, the parent node on which the focus was previously is closed for certain.
Using images of randomly generated text seems to be an increasingly common practise in preventing various bots from roaming the Web freely. The uses include random download codes., words that need to be typed in when joining a mailing list as well as representing e-mail addresses as images. The fundamental problem is that none of the usual accessibility measures, representing the same information in text, cannot be used as this textual information is also available to bots and thus renders image-based protection useless.
I've found only two good solutions so far. The first is using some code that will always work regardless of which image is being displayed. This strategy requires that you are able to distribute this info to the people truely needing it, such as the visually impaired, while making sure the bot authors don't get a clue on it. As soon as they do, your protection will be totally ineffective. The other solution revolves around a logical and intuitive step. If your client cannot see the thing being displayed, he or she can most likely still hear it. Thus in stead of an image, you can use slightly scrambled bits of on-the-fly synthesized audio that spells the letters in the information in question. one could use this second tactic for even longer pieces of info such as e-mail addresses. You could generate the audio on the server side and capture it in a file either upon information change or every time the info is needed. There are free ynths for all platforms including the MS SAPI synths for Windows, Festival for Linux and the Macintalk synths for the Mac. I don't think scrambling the letters is really necessary, though.
The only problem with spoken text is unambiguously distinguishing between words and even individual letters like c Vs k. Long e-mail handles or other bits of info that canot have spaces are sometimes read as words. To remedy that, one could use mixed case or underlines. Another possibility might be to use a spelling alphabet. It would make individual letters clearer and would enable you to raise the speed considerably. Secondly, some speech synths don't make much of a difference between certain letters e.g. m and n. Festival and some voices in Macintalk in particular, though this is only my view on things. You might also consider offering two versions of the speech bits, the faster for experienced speech users that need the info real quick.
Styles and Style Sheets
When defining sizes of elements e.g. font sizes, margins etc... do not use absolute values e.g. 10pt. Using relative values, that is percentages, makes it easier for a browser to scale the sizes for different devices and resolutions.
As for color selection, you should generally have a high contrast between the background and foreground colors to make the page easy to read for everyone (even if converted to 1 bit black and white, the text should still be readable). Clear, large fonts wouldn't be bad either. In addition, be sure to define both a background and a foreground color and don't assume anything about a browser's color settings as they can be overridden with automatic formatting.
You should consider using hover colors for links. Having a clear hover for both keybord and mouse navigation makes it easy for a sight impaired person to determine on which link the mouse rests or which is the most recent link in the tab order. TO make the changes you should define both a:active and a:hover in your CSS file. The highlight colors themselves should stand out well against the page background. Switching the page foreground and background colors might be one way.
You should generally speaking keep the colors of your web page pretty conventional. You'd probably want dark text on a light background in most cases. For maximum accessibility, do not use white as the background color of a page. I heard from an accessibility expert that this may cause dazzling to some visually impaired and sometimes I find a white background sstraining to my eyes, too. I was recommended the background color of #FFFFCC (255, 255, 204) as the background color and this is exactly what this site uses by default, too. For maximum accessibility, you should override the default list, field and button colors in CSS to make them such that the forms are easy to see against the background (do take into account the selection color, mine is, for instance, totally black). On a black page white forms go very well but these are hard to see against a light background like in most search engines for example.
Test Your Page with IE's Automatic FormattingSome sight impaired WWW users are using automatic color and font formatting to override the colors, font styles and font sizes in every web page.
This automatic formatting works well in nine cases out of ten but at times I run across sites which clearly have not been tested with IE's automatic formatting. A good indication of this is that the vertical spaces between lines are so small that the lines will partially overlap. So before making the final decision on how your site wil look, be sure to test IEs automatic formatting first. Here's how:
- in Internet explorer specify the font settings in Tools/Internet Options/General/Fonts dialog.
- Be sure to specify the colors as well in the Tools/Internet Options/General/Colors dialog
- As a reference, here are the settings I am using for fonts and colors:
- Background color RGB: 0, 0, 0 (black)
- Text (foreground)color RGB: 255, 255, 255 (white)
- Visited and unvisited links RGB: 255, 0, 0 (red)
- Hover color RGB: 0, 255, 0 (green)
- Proportional Font: Arial Black (this is easy to read for me at
- Plain Text (fixed-width) Font: Courier New
- To enable the formatting settings, go to Tools/Internet
Options/General/accessibility and chekc the boxes:
- Ignore Colors Specified on Web-pages
- Ignore Font Styles Specified on Web-pages
- Ignore Font Sizes Specified on Web-pages
- To make sure that no text overlapping or other unpleasant artifacts occur, test your pages with different font sizes from smallest to largest (to change the font size go to View/Text Size sub-menu and select a size).
- Test your site with different resolutions and window sizes, too,
Note that a user can choose to use a custom style sheet in stead of the formatting specified in IE's font and colors dialogs. It is almost impossible to test a page for a custom style sheet but I'll guess not many will have an exotic style sheet for formatting, because such style sheets won't usually work well. So no worrying here as you cannot do anything about user's custom style sheets. Just try to keep the page generaly accessible.
Testing Your Site with a Screen Reader
The final step of ensuring your page is accessible, is to test your site with a screen reading program. There are plenty of screen readers out there (almost all of the big ones commercial. The good exceptions are MS Narrator built into Windows and the free reader Non Visual Desktop Access . The big screen readers are Jaws , WindowEyes and Hal . An on-line screen reader emulation which requires no local application installation. It is a great way to get a quick picture of how browsing the Web blind is like.
I would suggest taking some time to read the help of the chosen reader and to familiarize your self with the program and it's features to be able to really test how your site works with it. You can practice using the reader in Windows and in Windows applications as well as on various Web-sites.
And if you want to have a more authentic screen reader session with just speech, try turning off your monitor and relying fully on built-in speech.