E-Learning Concepts and Techniques

Sections of the Book

Sections of the HTML version will be added throughout Fall 2006.

• Introduction
• Authors
• Contributors
• About the IIT
• 1. What is E-Learning?
• 2. Instructional Design Models for E-Learning
• 3. E-Learners
• 4. E-Learning Tools
• 5. Instructional Strategies for E-Learning
• 6. Information Ownership
• 7. Development
• 8. Delivering E-Learning
• 9. E-Learning Evaluation
• 10. Managing the Data
• 11. Web Standards
• Site Map

Excerpt from Chapter 7 Development

7.3 Hearing Your Web Pages

Charles L. Chen

You can recite the 508 guidelines by heart. You've added alt tags to all of your images. You've added a skip to main content link on every last page. You've run everything through Bobby, twice. So that means you have a perfect website that can't possibly be made any more accessible, right?

WRONG!

While you have certainly been doing all the right things, there is still one more step that you can take to bring the accessibility of your site to a whole new level. That step is to put yourself into the shoes (or perhaps ears) of someone who uses a screen reader. There is simply no substitute for hearing your Web pages being read aloud by a screen reader; closing your eyes and just concentrating on listening to how it sounds can give you invaluable insights into the way that visually impaired users will experience your site. Until recently, this involved buying expensive screen reading software or putting up with the various restrictions placed on trial copies of such products. However, there is now Fire Vox, a freely available, open source screen reading extension for the Firefox Web browser. This guide will explore some of the best practices for evaluating your website using Fire Vox. Note that although this guide is aimed at using Fire Vox, the general principles and techniques apply to testing your website with any screen reading application.

Just Because It Validates Doesn't Make It Right

This is an example of a page that validates but is completely unusable. The problem here is that although the alt tags on the images are accurate, they do not convey enough information for someone who cannot see the images. Remember, validation tools, as useful as they are, are just tools - they can't do your thinking for you and tell you when your alt text simply doesn't make sense.

Tip: When listening to what your page sounds like, try putting yourself into the frame of mind of a new visitor who has no idea of what is there. Does your page still make sense? If not, why not, and is there any information that you can add to fix it?

Appearances Can Be Deceiving

Sometimes, there are just quirks that are not obvious until you encounter them. Usually, there is nothing in the HTML standards that says you can't do things a certain way; however, in practice, some ways of doing things are more likely to be problematic than other ways. In an ideal situation, these differences would not exist, and one would have a perfectly working Web page as long as it follows the HTML standard. Unfortunately, reality is not so simple and each browser has its own quirks. As a Web developer, you should try to choose approaches that not only obey the HTML standard but also avoid quirky behavior as much as possible.

An example of quirky behavior can be seen in the way link targets are handled in Firefox 1.5.0.2. Firefox will not place the cursor on a link target if that target is completely empty. Instead, it will scroll the window to that position and then take away the navigation caret. For screen readers that rely on the navigation caret to determine the user's position, this will cause a problem. On the surface, the skip link on this page appears to be working just fine. However, upon closer inspection by reading through with Fire Vox, it becomes apparent that there is a problem since the reader will not realize that the skip has occurred.

The moral of this story: Just because something appears to be OK, doesn't guarantee that it is. You should always double-check and go through it once just to be safe. You should not try to bend over backwards and break standards just to get things working (and you should not need to), but if a minor tweak that is just as correct makes everything smoother, then why not do it?

Tip: Creating an anchor element that has no text content can be risky. It might not always work correctly depending on the combination of browser and screen reader that the user is working with. In this case, trying to jump to a DOM node with no content caused Firefox's cursor navigation to turn itself off. An anchor element with text content is always safe, so you should always place the anchor tags around some text. Again, there is nothing in the HTML standard that says jumping to an empty DOM node is bad. However, jumping to something with content is an equally valid approach and much more likely to work correctly; hence, that should be the method that you use.

Say What???

You may be thinking to yourself, What could possibly be wrong with the example on this page? It has nothing but text, and the entire example consists of a mere four sentences! Is it even possible to get something this simple wrong? The answer to that last question is a resounding yes, unfortunately. If you tried listening to this example, the problems become apparent; the heart shape is interpreted as less than 3, one street name is mispronounced, saint is confused with street, and none of the titles are read correctly. This content would be incomprehensible to visually impaired users who rely on screen readers since it sounds nothing like the way it would sound if a human were reading it.

Tip: If your page sounds terrible and things are not being read the way they should be, then try rewording it if possible to avoid the problematic words. For any part of it that simply cannot be said in any other way, consider using CSS3 speech module properties, especially the "say-instead" property. While the CSS3 speech module is not supported by every screen readers, Fire Vox is one reading tool that does have support for it. Note that different text to speech engines perform differently; some voices may say parts of your page correctly without the need for any hints from say-instead while others choke. To be safe, you should stick with using the barebones, generic voices that come by default as part of the engine. For Windows users, it would be one of the Microsoft voices (Mary, Mike, or Sam).

Last updated April 20, 2007

Graphics by David Cerreta