For role and states we could use fake attributes as you say like "role:3;states:34944" where numbers are predefined constants or a bitset in case of states. Agree, it looks different from rest of the API. However it seems we are hunting for flexibility in API and thus maybe it's ok.
Relations should fit imo. Thank you. Alex. On Thu, Aug 16, 2012 at 9:44 AM, James Teh <[email protected]> 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? > > 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 >> > > -- > James Teh > Director, NV Access Limited > Email: [email protected] > Web site: http://www.nvaccess.org/ > Phone: +61 7 5667 8372 > _______________________________________________ > 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
