- From: jaap van lelieveld <Jaap.van.Lelieveld@inter.NL.net>
- Date: Tue, 07 Apr 1998 20:25:26 +0100
- To: w3c-wai-ua@w3.org
-------- Forwarded message -------- From: jvleliev@inter.nl.net (jaap van lelieveld) To: Joe Roeder <Jroeder@nib.org> Hi Joe, Thanks for your message. Because of its interest I reply through the list as well. On Mon, 6 Apr 1998 16:51:08 -0400 Joe Roeder <Jroeder@nib.org> wrote: > > Jaap said: > >It is my opinion you should - if possible - solve a problem > only once. > >Since a browser is only one of the applications I run the screen > readers > >must give the intelligent support needed anyway. > > >Therefore ... do NOT implement non-browser specific reading > >requirements in the browser - This will only complicate the browser, > >- increase costs and/or wait time (before the browser is ready) > >- Reduce the chance of rapid upgrades, > >- increase the change of reading conflicts. > > There are limits to how much "intelligence" you can put into a > screen reader without some help from the browser or some mediator like > MSAA. Everytime major changes in products are put out, there is a lag > of a year or more before the screen readers can catch up. And they are > not really becoming more "intelligent", they are just building some > browser-specific capabilities. You can't expect them to try to do that > for every browser on the market. O, know I fully agree with you, but your arguments do not let me use my screen reader system wide either. I think initiatives like MSAA and maybe even better: JAVA API are the only way out for the screen reader builders. A well documented API to reach accessibility allows the "screen reader" builders to leave the screen for what it is: a media to look at. It will allow them: - to have access to the context of the information allowing them to implement more intelligent features easier. - to get rit of the "of screen model" which is slow, memory consuming and - most important - always inconpatible. - to make platform independant "readers" in the future. > The browsers already have user selectable options to accomodate > individual preferences. Why not add a couple to accomodate the > disabled? Chances are pretty good that they will please more than just > the disabled community by putting in some electronic curb cuts. > > Joe Roeder > Access Technology Specialist > National Industries for the Blind O, yes that is true, but in the future we will not do a good job if we wait for the pieces that fall of the table of the rich. I need to ask for features from both the browser venders and the screen reader builders. That is why I listed some of these features on my web page (which is available again). Our task is to make sure APPLICATIONS are accessible in the future. This concerns more then only browsers. On the other hand a wish list for browser venders will help everybody who needs access on the short term. It is my opinion though these features must concentrate on accessible formats and not on "screen reader' behaviour. The (screen) reader must develop to a tool that reads information instead of screens. The period between now and full API support - if that time will ever really come - will be difficult. The screen reader builders need to support the "of screen model" approach, the MSAA and teh JAVA API. A hard time for these (too ?)small companies. Still building specific applications with screen reader capabilities will splinter up the market. The only way to solve this is to concentrate on some not too small companies that are able to build a generally oriented reader. Up to now MSAA support - both of MS and of the screen reader builders - is limitted. As far as I know no-one uses the JAVA API; the IBM (demo ?) reader excluded. I wonder if IBM will be the first to introduce a reader that supports both traditional screen reading and JAVA support in ONE product. Best regards, Jaap Message from: Jaap van Lelieveld The Netherlands Chairman of EBU commission on Technical Devices and Services E-mail: Jaap.van.Lelieveld@inter.nl.net USING: YARN V0.92 as an offline reader, and UQWK / OLMENU under UNIX for mail and news transfer
Received on Tuesday, 7 April 1998 15:38:48 UTC