I supposed they are AND. But it's a good question and a weakness of syntax if we miss OR feature. Anyway since we deal with a string then we can introduce new syntax when needed. Thank you. Alex.
On Thu, Aug 16, 2012 at 1:19 AM, Pete Brunet <p...@a11ysoft.com> wrote: > > On 8/15/12 1:02 AM, 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. > > Do all the attribute:value pairs have to match in order for a container to > be returned, i.e. is this an AND or OR situation? > > > 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 <p...@a11ysoft.com> 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 <p...@a11ysoft.com> 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 <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 > > > -- > 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 > > > -- > 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 > > > -- > 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
