Limitations of screen readers - html

Question

I'm a web developer, and I want to make the web sites I develop more accessible to those using screen readers. What limitations do screen readers have that I should be most aware of, and what can I do to avoid hitting these limitations.
This question was sparked by reading another question about non-image based captchas. In there, a commenter said that honey pot form fields (form fields hidden with CSS that only a bot would fill in), are a bad idea, because screen readers would still pick them up.
Are screen readers really so primitive that they would read text that isn't even displayed on the screen? Ideally, couldn't you make a screen reader that waited until the page was finished loading, applied all css, and even ran Javascript onload functions before it figured out what was actually displayed, and then read that off to the user? You could probably even identify parts of the page that are menus or table of contents, and give some sort of easy way for those parts to be read exclusively or skipped over. I would think that the programming community could come up with a better solution to this problem.

Answer 1

Are screen readers really so primitive that they would read text that isn't even displayed on the screen?
What you have to remember is that any HTML parser doesn't read the screen - it reads the source markup. Whta you see on the screen is the browser's attempt to apply CSS to the source code. It's irrelevant.
You could probably even identify parts of the page that are menus or table of contents, and give some sort of easy way for those parts to be read exclusively or skipped over.
You could, if there were a standard for such a thing.
I'm not very hot on the limitations of screen readers, however I've read a lot about them not being ideal. The best thing I can reccommend is to put your source in order - how you'd read it.
There are a set of CSS properties you should also look at for screen readers.

Answer 2

Recommended listening: Hanselminutes
It's an interview with a blind programmer.

Answer 3

How many forms just have a * or bold to indicate to a sight user that a field is required for correct submission? What's the screen reader doing? Saying "star"?
Below is an example of code that is helpful by articulating verbally but not visually.
(note - in the example below the word "required." is spoken but not seen on screen)
In the template:
<label for="Requestor" accesskey="9"><span class="required"> Requestor * </span><span class="hidden">required.</span></label>
In the CSS:
#hidden {
position:absolute;
left:0px;
top:-500px;
width:1px;
height:1px;
overflow:hidden;
}
or
.hidden {
position:absolute;
left:0px;
top:-500px;
width:1px;
height:1px;
overflow:hidden;
}
There can be a whole parallel view behind the "seen" in every X/HTML page.

Answer 4

#robertmyers
CSS contains the aural media type specifically to control the "rendering" of things when screen readers are doing their work. So, for you example, you would only set it as visible for the aural media type.
#Ross
I'm quite aware that the screen reader doesn't actually read the screen, but you would think that to work well, it would have to build a model of what a person with sight would see, otherwise, it seems like it would do a really poor job of getting across to the user what's actually on the page. Also , putting things in the order you would read them doesn't really work, as a sighted person would scan the page quickly and read the section they want to read. Do you put the contents first so that the user has to listen to them every time, or do you put them at the end so that they can get to the content first? Also, putting content in order would mean some tricky CSS to get things positioned where you wanted them to be for sighted users.
It seems to me that most web pages contain very similar construction, and that it should be possible to, in many cases, pick out where the repeated headers and side columns are. When viewing many subsequent pages on the same site with the same formatting, it should be easy to figure out which sections are navigation, and which are content. Doing this, the screen reader could completely skip the navigation sections, and move right onto the content, as most sighted users would do.
I realize there are limitations, and that doing these types of things wouldn't be easy. However, I feel like as far as screen readers go, we only did the bare minimum and left it at that.

Answer 5

Have a look at ARIA, it's a standard for developing accessible rich-web-client applications.

Answer 6

#Kibbee,
What you are describing as "primitive", is in fact a feature of screen readers that can be, and is, used to make sites more accessible. For example, if you have a tabbed interface, implemented with an unordered list and list items, then the sighted user would normally see the selected tab highlighted with a background color that is different (or some other visual treatment). Blind users cannot see this. So adding some additional text into the page and hiding it off screen is the technique used to communicate to the blind user what tab is active.
In the accessibility lingo, this information is known as role, name, value and state.
There are many other scenarios where this technique can be used to add information that is useful for a blind user.
More recently, WAI-ARIA has been added to allow this state, role, name and value information, so you can now implement a limited number of widgets (like tabs) using HTML attributes. However, the more general "off screen" technique is still useful.