It's not very flexible. For example, you need to call several times if you want to get an accessible having a role from desired set of roles. Actually it introduces the basics of traversal API which must be handy for ATs but these basics don't look enough.
Also I worry if document is mapped well always into role concept. For example, anchor target is applicable to any DOM document but role of DOM document accessible can be overridden by ARIA. If someone crazy enough creates a widget (like listbox) based on document and makes scrolling by passing '#' into URL then AT still might want to read that widget starting from anchorTarget. Thank you. Alex. On Fri, Mar 2, 2012 at 6:49 AM, Pete Brunet <p...@a11ysoft.com> wrote: > 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 > _______________________________________________ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
