- From: Eric S. Johansson <esj@harvee.org>
- Date: Fri, 20 May 2011 07:58:13 -0400
- 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