- From: Joshue O Connor <joshue.oconnor@cfit.ie>
- Date: Fri, 22 Jun 2007 14:04:57 +0100
- To: Sander Tekelenburg <st@isoc.nl>
- Cc: public-html@w3.org
Sander Tekelenburg wrote: > We know there are many, that's why I asked which one in particular you were > referring to (when you said they don't provide table captions before the > table unless authored so). Sorry Sander. It was JAWS. The screen reader doesn't provide table captions, the author does. > Well, if you rely on a GUI browser that ignores label, accesskey, scope, > headers, summary, speech/braille CSS, etc. then even though such is provided > by the author of the web page, it might never reach the screen reader at all. > Or does it? This is where the issue of support for attributes and elements by browser vendors is so important. If the browser doesn't support them the screen reader won't be able to use them either. > Then, as you say, it is interacting with the browser, not with "the web page > itself'. It's still relying on a GUI browser that is not aimed at the task. Again, it depends on the mode of operation. However, the browser handles the HTML in both instances so the more semantically correct the better. > Are you saying that all screen readers manage to receive every aspect of a > web page, Pretty much. Those that are supported anyway. > even when they rely on a GUI browser that ignores certain parts >> (label, accesskey, scope, headers, summary, speech/braille CSS, etc.) of that >> web page? The browser doesn't ignore these elements you, if you are a sighted user, just may not see them, as such. As I mentioned there are two aspects of this area, UA support (both the assistive technology and the browser support). The assistive technology is dependent on the browser supporting a particular attribute/element. Josh
Received on Friday, 22 June 2007 13:05:18 UTC