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 <[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
--
*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
