Re: Agreed recognition API?

On Fri, May 20, 2011 at 12:58 PM, Eric S. Johansson <esj@harvee.org> wrote:

> 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.


Work with browser vendors to add better user-modification features to
browsers. I haven't yet seen any evidence that API-level support is needed
to allow user modifications.


-- 
Bjorn Bringert
Google UK Limited, Registered Office: Belgrave House, 76 Buckingham Palace
Road, London, SW1W 9TQ
Registered in England Number: 3977902