On 8/15/12 7:44 PM, James Teh wrote: > As much as I'd love a way to search descendants quickly (in theory), > one major problem with searching by attributes is that there are a lot > of properties which aren't attributes; e.g. role and states. I don't > really have a good alternative, but even if we make fake attributes > for the purposes of searching (i.e. they aren't actually exposed as > object attributes), this seems a bit contrary to the rest of the API. > > Also, is there a reason a relation doesn't fit for getting the > document accessible? I missed responding to this. Using relations is OK with me and seems to be preferred. I assume this would be implemented on a particular object and then point to a particular kind of containing object and that there would need to be several kinds of relations, e.g. ones for document, tab, window, and application have been mentioned, e.g.
IA2_RELATION_CONTAINING_DOCUMENT IA2_RELATION_CONTAINING_TAB IA2_RELATION_CONTAINING_WINDOW IA2_RELATION_CONTAINING_APPLICATION Are there others? Are these the right names, e.g. should it be TAB or TAB_PANE? Pete > > Jamie > > On 15/08/2012 4:02 PM, Alexander Surkov wrote: >> Hi, Pete. >> >>> containerByAttrbute is OK with me, taking a BSTR like >>> "document:anchored; >>> someOtherAttribute:someOtherValue;" >>> >>> Do all of the attribute/value pairs have to be true? >> >> I missed the question. >> >>> Regarding childrenByAttribute, although there hasn't been a request for >>> this, should we add it? >> >> It should be good for reserve even if nobody raised a hand for it yet. >> AT should have a fast way to find children complying the certain >> criteria. >> >>> 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? >> >> say if you look for children in the document from certain point, for >> example, you fetch all headings starting from heading #5 (because your >> virtual cursor is on it). If NULL then accessible itself. >> >>> - [in] bool lookIntoSubtree >>> Is this is false does that mean to only look into one level below the >>> starting point? >> >> I think yes but I started to think it would be more flexible to keep >> it as integer so that we can introduce more constant when we need. Of >> course any criteria can be specified in the list "attribute:value" >> like "lookIntoSubtree;". Jamie, ideas? >> >>> - [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.) >> >> Idea of max count argument is performance win when AT doesn't need all >> items, it's similar to relations and hyperlinks we discussed recently. >> Indeed if you need next item then you shouldn't calculate all items. >> >> Thank you. >> Alex. >> >> >> On Tue, Aug 14, 2012 at 5:45 AM, Pete Brunet <[email protected]> wrote: >>> 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 >> > -- *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
