Thanks Ben. I added some more descriptive steps and resources on the generation and lifetime of a MSAA request.
More comments inline. - Jonas On Tue, Dec 2, 2008 at 7:33 PM, Ben Goodger (Google) <[EMAIL PROTECTED]>wrote: > > Thanks for putting this together, Jonas. It's a good start. > > One area where I think you could expand on the views integration side > is to show richer detail for how the views integration works (maybe a > diagram with the relevant components, interfaces, etc). Perhaps give a > compact example of the lifetime of a MSAA request from the OS and how > we respond to it referring to the diagram to show the components > involved in formulating the response. > > Some specific feedback about the way things are right now: > > - I don't think the a11y code should use view ids to locate various > components. I actually don't find view IDs that useful and think they > should probably disappear, since they just clutter up the View > interface. Agreed. The generated MSAA focus events need to come with a child id, to uniquely identify the view that is receiving focus. As part of the original design, I chose to piggyback on the already existing ViewID enums, rather than creating an extra, redundant accessibility ID. However, if we feel strongly that the ViewIDs should go away, it would certainly be easy to add another ID system instead. > > - Related to this, code to obtain accessible wrappers for various > Browser constructs like the omnibox shouldn't be in the views/ > directory. (I think I filed some bugs on this a few weeks/months > back). The generic views stuff can live there, but the Browser > specific stuff should move into the browser/ dir, and maybe be part of > BrowserView. The outward dependency on browser/ is an impediment to > using views without browser. If the binding were to live with > BrowserView, the code would have direct access to the LocationBarView > for example and not need to use view ids. The trouble with the omnibox and the view/browser dependencies is that it itself has somewhat of a split personality. On one hand, it is a View (LocationBarView), which is expected to be included in the View MSAA hierarchy. On the other hand, it also has it's own window (with its own message handler) and can be hit directly with a WM_GETOBJECT through that. If we are fine with having references from browser into view (but not the other way around), I guess that can be done with some trickery. > > - I count at least 9 methods on views::View related to accessibility. > At least some of these, relating to name/role/action/shortcut/etc are > metadata. I'd prefer it if there were a metadata object that the View > returned through a single function that the wrapper code queries. Most > views would return a default metadata object. Specific views with a11y > roles would configure the metadata object to their liking. This allows > us to keep the View API compact. Agreed. I have a TODO in the code to put this into a metadata object. > > > -Ben > > On Tue, Dec 2, 2008 at 1:18 PM, Jonas Klink <[EMAIL PROTECTED]> wrote: > > > > Hi all, > > > > I have summarized the current state of the Chrome accessibility work, > > as well as ongoing efforts and outstanding issues (where anyone > > interested is more than welcome to help out): > > > > > http://sites.google.com/a/chromium.org/dev/developers/design-documents/accessibility > > > > Any feedback, questions or volunteers are as always welcome! > > > > Thanks, > > -- > > Jonas Klink > > Software Engineer - Accessibility > > Google, Inc. > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
