I see we have a few things to finalize yet, one of which is this thread. containerByAttrbute is OK with me, taking a BSTR like "document:anchored; someOtherAttribute:someOtherValue;"
Do all of the attribute/value pairs have to be true? Regarding childrenByAttribute, although there hasn't been a request for this, should we add it? Alex, Please explain the second, third, and fourth parameters: - [in] nsIAccessible* anchor Is this where to start the search? Why not just start the search from the current accessible? - [in] bool lookIntoSubtree Is this is false does that mean to only look into one level below the starting point? - [in] long desiredChildrenAmount, What is the purpose of limiting the array? (There was a miscoding in the original IDL for IAccessible2::extendedStates, IAccessible2::localizedExtendedStates, IAccessibleAction::keyBinding that included a maxMembers parameter, but this has been fixed for IAccessibleTable2::selectedCells, IAccessibleTable2::selectedColumns, and IAccessibleTable2::selectedRows.) I'd like to finalize all these discussions ASAP so we can finish off the 1.3 update so please comment. Pete On 3/4/12 9:44 PM, Alexander Surkov wrote: > I find interesting the 5th option: containerOfAttributeValuePairs. It > looks flexible. Its syntax covers 2-4 options. Not sure I like the > name since it's pretty long (maybe containerByAttribute or selector? > similar to DOM API). > > If we discuss the traversal API then we should consider an opposite > method to get a children like childrenOfAttributeValuePairs > (childrenByAttribute) that takes a point in accessible tree where we > should start a search and returns an array of children like > > HRESULT childrenByAttribute( > [in] BSTR attributes, > [in] nsIAccessible* anchor, > [in] bool lookIntoSubtree, > [in] long desiredChildrenAmount, > [out, array] nsIAccessible** children, > [out] long* childrenCount); > > Thank you. > Alex. > > > On Sat, Mar 3, 2012 at 2:13 AM, Pete Brunet <[email protected]> wrote: >> Some other thoughts: >> 1) containerOfRoles, passing in an array of roles, returning the first one >> found when looking up >> 2) containerOfAttribute, passing in a BSTR identifying the attribute and >> then looking up the tree until an accessible with that object attribute is >> found, e.g. "document". >> 3) containerOfAttributeValuePair, passing in the BSTR "document:anchored" >> 4) containerOfAttributes, passing in a BSTR with more than one attribute, >> e.g. "document; someOtherAttribute;" >> 5) containerOfAttributeValuePairs, passing in a BSTR with more than one >> pair, e.g. "document:anchored; someOtherAttribute:someOtherValue;" >> >> Are any of those useful? Are there other ideas? >> >> Pete >> >> >> On 3/1/12 11:16 PM, Alexander Surkov wrote: >> >> 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 <[email protected]> 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 <[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 >> >> >> -- >> Pete Brunet >> >> a11ysoft - Accessibility Architecture and Development >> (512) 467-4706 (work), (512) 689-4155 (cell) >> Skype: pete.brunet >> IM: ptbrunet (AOL, Google), [email protected] (MSN) >> http://www.a11ysoft.com/about/ >> Ionosphere: WS4G >> >> _______________________________________________ >> Accessibility-ia2 mailing list >> [email protected] >> 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), [email protected] (MSN) >> http://www.a11ysoft.com/about/ >> Ionosphere: WS4G >> >> _______________________________________________ >> Accessibility-ia2 mailing list >> [email protected] >> 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), [email protected] (MSN) http://www.a11ysoft.com/about/ Ionosphere: WS4G
_______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
