Maybe we need IA2::containerOfRole? HRESULT IAccessible2::containerOfRole([in]long role, [out, retval] IUnknown **container)
Pete On 2/23/12 8:40 PM, Alexander Surkov wrote: > I'd say we should consider interfaces performant by design. If AT > needs to get a containing document for accessible occasionally then it > makes sense to do: o(1) is always preferable over o(n). I don't have > good data when AT needs that but I should say that last year we were > asked by one AT vendor to provide a mechanism to find a tab document > having an accessible. We hacked IServiceProvider::QueryService for > that. Maybe it'll be nice if IA2 had built-in methods to do that. > > If you say yes to this idea in general then we need to consider > relation mechanism for this since I guess AT might need different > types of documents like > 1) containing document > 2) tab document > 3) window document > 4) application > > Relation mechanism allows us to avoid a method per document type (sure > we could have keep one method and pass document type as argument). > > Ale.x > > On Fri, Feb 24, 2012 at 12:57 AM, Pete Brunet <p...@a11ysoft.com> wrote: >> The apparent reason for this new method is for performance, i.e. the AT >> can already walk up the tree looking for a role of interest. Has there >> been a situation where walking up the tree is causing a performance >> problem? In my experience, AT (at least some AT) are constantly walking >> up and down the tree, and I haven't noticed a performance issue. Also, >> as Jamie implies, you'd only have to walk the tree once to find the >> parent of interest and then save a reference to it. I just want to make >> sure we are solving a real problem before inflating IA2. -Pete >> >> On 2/22/12 4:27 PM, James Teh wrote: >>> On 22/02/2012 6:54 PM, Alexander Surkov wrote: >>>> The proposed document accessible concept is close to DOM document. ... >>>> One example was get_accChild that can return child accessible >>>> by uniqueID. >>> True, though the only time you ever need that is to test whether a >>> given node is within a document. If you are trying to do that, you >>> probably already have a reference to the document accessible. >>> >>>> All caret/selection methods are >>>> fast on document accessible and slow on child accessible. >>> But in that case, we're probably dealing with an editable document, >>> which is a real ROLE_SYSTEM_DOCUMENT object. Trying to query for caret >>> or selection on an application or frame just doesn't make sense. >>> >>>> Theoretically anchorTarget is applicable to any document type, >>>> requirement is the URL should contain '#' pointing to element. >>> Technically, that's true, but I don't see any use case for this in the >>> wild. Why would an AT want to query for anchor target on an application? >>> >>> The problem is that all of this is abusing the idea of a document >>> property. In Gecko, an application might be the same internally as a >>> document, but that's not true from a user (and probably AT) perspective. >>> >>> One option is to note that the document property just returns the >>> nearest document. If necessary, add a note stating that this will >>> usually be a ROLE_SYSTEM_DOCUMENT accessible, but that the definition >>> of document depends on the application. This makes a little trickier >>> for clients to know what they'll get, but it does allow for a bit of >>> flexibility. >>> >>> Jamie >>> >> _______________________________________________ >> Accessibility-ia2 mailing list >> Accessibility-ia2@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2 -- *Pete Brunet* a11ysoft - Accessibility Architecture and Development (512) 467-4706 (work), (512) 689-4155 (cell) Skype: pete.brunet IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN) http://www.a11ysoft.com/about/ Ionosphere: WS4G
_______________________________________________ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
