If there's not a clear need for it I'd prefer to not add childrenByAttribute. Is that acceptable?
On 8/15/12 8:02 PM, Alexander Surkov wrote: > 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 > -- *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
