W3C home > Mailing lists > Public > public-xg-htmlspeech@w3.org > May 2011

Re: Agreed recognition API?

From: Eric S. Johansson <esj@harvee.org>
Date: Fri, 20 May 2011 07:58:13 -0400
Message-ID: <4DD65755.8020301@harvee.org>
To: Bjorn Bringert <bringert@google.com>
CC: "public-xg-htmlspeech@w3.org" <public-xg-htmlspeech@w3.org>
On 5/20/2011 3:46 AM, Bjorn Bringert wrote:
>> I also suggest giving the user the ability to inject their own  grammar,
>> code, css into the applicatiion. I believe this capability is critical to
>> accessibility because in my opinion, accessibility is defined by what the
>> user needs, not what a vendor is willing to give them.  what the user needs
>> is something no vendor can afford to create which explains a lot about the
>> current state accessibility.
> User modifications are a user-agent feature, not something that should
> be in the JavaScript API. Greasemonkey and the Chrome developer tools
> are examples of user-agent features that let the user modify web apps.
> As far as I know, they require no special support in the web app APIs.

I've looked at grease monkey. It's great if you're an expert user who is the 
into the application  Web application. The let's say you're an ER nurse who 
figures out a better way model some series of tasks that are important to the 
patient recordkeeping. Today,  she can do this with the NaturallySpeaking tools 
with a modicum of knowledge. And yes, they can and do this in the field. Users 
see a better way and implement it.

Doing the same with grease monkey requires a significantly higher level of 
knowledge that non-IT experts are unlikely to have. You have the just removed an 
important capability for a speech recognition user be they disabled or tab.

Also, the grease monkey approach does not require a commitment to interface 
stability on the part of the application developer. They can change whatever 
they want whenever they want and the user is left without any grounds for 
complaint or a capability they may have been counting on. The users left to 
chase taillights every time a new instance of the application is rolled out 
complete with reverse engineering all the changes.  An explicit method as I'm 
suggesting would provide stability that disabled people can count on so they can 
get work done like anybody else and enable the development of third-party 
extensions that could be shared.

I am willing to entertain other options because it's not uncommon for 
technologists to get a hold of the wrong and the problem. I don't think I'm 
wrong about the grease monkey solution. It is pretty  ugly. If we are going to 
put in the ability to inject your own elements into a page, where and how? Are 
we talking about a proxy that looks for markers to tell you where you can inject 
certain pieces?  Are we talking about a cultural/legal standard whereby the user 
or regulator can thump manufacturer for denying them what they should be able 
to? Is there a shared responsibility between browser and Web application developer?

Where first heard about this effort, I was thinking "yippiee, I can tell Nuance 
to go pound sand". It's not that Nuance has a bad product. It's that their 
attitude towards disabled users taking care of their own needs is scary. There's 
a significant number of technically astute  people that use the 
NaturallySpeaking equivalent of grease monkey to make their lives easier. 
Instead of embracing it like Dragon had before them and working with the mostly 
self-supporting disabled community, they have engaged in a course of not so 
benign neglect and are actively causing disabled people hardship.  several of us 
have tried to talk with nuance about this issue several times and have been 
rewarded with silence.

We don't want much, we just want to be able to take care of ourselves without 
interference. this effort all of  you are engaging in could have provided us 
with that kind of capability or at least be the thin edge of the wedge in 
heading towards that goal. Instead what I'm seeing is the same old solutions 
that have been part of my life for the past 15+ years and I'm trying to figure 
out why something so bad keeps getting recycled again and again and again.

What's the best way to go about solving this problem? a solution that can 
provide the user with stability, clearly documented interfaces or methods, not 
require significant knowledge or training (i.e. something you can learn from 
ashort manual or less than eight hours of training), and removes control of the 
accessibility interface from the application vendor.

--- eric
Received on Friday, 20 May 2011 11:59:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:16:49 UTC