- From: Scott Luebking <phoenixl@netcom.com>
- Date: Wed, 11 Mar 1998 15:31:24 -0800 (PST)
- To: phoenixl@netcom.com, poehlman@clark.net
- Cc: w3c-wai-ua@w3.org, w3c-wai-ui@w3.org
Hi, Dave I'm not quite sure of your approach here. Could you maybe give some examples of what browser-related functions should be in screen readers and not in browsers themselves? This would help give a better sense of what information the guidelines need to specify that browsers should make available to screen readers. I tend to lean towards putting more functionality in the browser and less in the screen reader as a way to minimize the lag between browser enhancements and screen reader releases. One area which I think is screen reader based is that the screen reader should be able to speak intermixed text and button labels without skipping. The browser should provide information to the screen reader in such a way that it can do that. I think that navigation is a shared responsibility. The browser should be able to change the focus via keyboard action and the screen reader should be able to speak the new area being focused on. (I'm not sure how braille output should be handled.) Scott > I'm not making myself clear. If on a technical level, there is a > universal standard set in place for certain types of behavior of browsers, > then the screenreader developpers can use that model to extract the > information needed. Windows.95 for instance can be readily used by people > with screenreaders in its basic form because of this focus. This was my > point scot. As I see it, we are reducing the need for code writing by the > screenreader developpers here and asking the browser developpers to > standardize on a set perhaps to be developped in the future. > annother point to keep in mind here is that if you put the onus on the > screenreader developper, unless you give them a fair amount of lead time, > the screen reader user will always lag behind everyone else when it comes > to upgrading and may even need to switch screenreaders in order to save > their job just because of the browser. I think the name screenreader is a > missnomer here the correct name is or should be speaking or braille > computer interface. The screen reader should be asked to present the > information in a way that the user can use it, but it is up to the > software developper to make it possible for the screenreader to do that to > a point at least. Perhaps what we need is a library that each browser > company can use to make it possible for screenreaders to see what is going > on and then to determine how to present that to the user.
Received on Wednesday, 11 March 1998 18:31:31 UTC