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
