I some comments to the code review, but I'll summarize the API pieces for those following here.
The main issue is that I think there's a little too much overloading going on: * ControlInfo feels like it should be split into more concrete subtypes with separate parameters. * onOpen/Close should be split into onWindowOpen/onMenuOpen, etc. * type parameters should use a formal enum Erik On Wed, Dec 16, 2009 at 10:20 PM, Erik Kay <erik...@chromium.org> wrote: > +chromium-dev > > On Wed, Dec 16, 2009 at 1:15 PM, Dominic Mazzoni <dmazz...@google.com>wrote: > >> Hi, >> >> Here's an experimental proposal I'd like to throw out there. All types of >> suggestions, criticism, and questions are welcome. >> >> - Dominic >> * >> * >> *Overview* >> This experimental API exposes information about focused controls in the >> native ui, like dialog boxes and the location bar. Specifically, it allows >> an extension to determine the current focused control and listen to events >> such as changing focus, selecting controls, and text editing. It optionally >> allows for generating keyboard events, too. >> >> Existing screenreaders on Mac, Windows, and Linux do a good job of >> exposing simple dialog boxes, but a poor job of exposing complicated web >> pages. Javascript-based screenreaders can often provide much better support >> for browsing the web, but are poor at exposing the user interface of the >> browser. This solution empowers javascript-based screenreaders. >> >> *Use cases* >> 1. Build a complete screenreader as a Chrome extension, similar to the >> "FireVox" screenreader for Firefox (see http://www.firevox.clcworld.net/). >> This would enable developers to create custom accessibility solutions for >> people with all sorts of special needs, using JavaScript, that will run on >> Chrome on any platform. >> >> 2. Enable pure-javascript testing of browser user-interface elements, like >> interacting with controls in a dialog box. This could potentially simplify >> some ui tests. >> >> *Could this API be part of the web platform?* >> No. >> >> *Do you expect this API to be fairly stable?* >> Yes. >> >> *What UI does this API expose?* >> It does not have a UI of its own. >> >> *How could this API be abused?* >> I hope that exposing information about focused controls and listening to >> focus and text editing events should not be risky; most of the information >> in these controls is already exposed via other APIs. >> >> Enabling automation of keyboard events is risky; a malicious extension >> could control the user's browser. This should only be enabled for trusted >> extensions or via a flag. >> * >> **How would you implement your desired features if this API didn't exist? >> *** >> The only way to provide accessibility or UI automation now requires >> writing platform-specific, low-level code that is beyond the reach of most >> developers. This API could enable new innovation in accessibility. >> >> *Are you willing and able to develop and maintain this API?* >> Yes. >> >> *Draft API spec* >> This changelist contains the API spec and an implementation that exposes >> information about most of the controls in the Options dialog for GTK: >> http://codereview.chromium.org/402099 >> * >> * >> In a nutshell, the proposed API exposes two functions: >> * getFocusedControl >> * simulateKeyPress >> >> and five events: >> * onOpen (for a dialog or context menu, for example) >> * onClose >> * onFocus >> * onSelect >> * onText >> >> Accessibility APIs such as MSAA on Windows are significantly more >> complicated than this, as they need to support a huge range of possible >> applications, including applications that were not designed with >> accessibility in mind. The main reason that this API can be much simpler is >> that we assume that the entire user interface is already accessible via the >> keyboard (or should be). Instead of allowing tools to traverse the user >> interface hierarchy and determine how it should be presented to a disabled >> user, we can just expose information about the control the user has >> navigated to using the existing keyboard commands. >> * >> * >> > > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
