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 <[email protected]> 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 > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2 _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
