Per Jamie's comment I think no, at least for 1.3 version.
Alex.
On Tue, Sep 11, 2012 at 12:28 AM, Pete Brunet p...@a11ysoft.com wrote:
The new IDL for version 1.3 is pretty much ready to go. The only thing
I haven't done is to add the 4 relations:
IA2_RELATION_CONTAINING_DOCUMENT
The new IDL for version 1.3 is pretty much ready to go. The only thing
I haven't done is to add the 4 relations:
IA2_RELATION_CONTAINING_DOCUMENT
IA2_RELATION_CONTAINING_TAB
IA2_RELATION_CONTAINING_WINDOW
IA2_RELATION_CONTAINING_APPLICATION
Is there an issue with plugin container or can that be
On 8/15/12 7:44 PM, James Teh 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
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?
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,
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
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
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
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
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
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)
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
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
Hi, Pete.
The proposed document accessible concept is close to DOM document. I'm
not sure maybe there's a better name for it. This concept might make
sense for AT because many methods (DOM oriented methods) called on the
document are much faster than if they were called on some document
child.
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.
https://wiki.mozilla.org/Accessibility/IA2_1.3#Document_accessible
proposes that IAccessible2_2::document will return the containing object
that implements IAccessibleDocument. Since it's possible that we will
decide to not add IAccessibleDocument I'd prefer to specify that the
object returned
On 22/02/2012 12:34 PM, Alexander Surkov wrote:
In Firefox a document accessible can have following roles:
# ROLE_SYSTEM_APPLICATION
# IA2_ROLE_FRAME
# ROLE_SYSTEM_DOCUMENT
# ROLE_SYSTEM_DIALOG
I'd argue all of the roles other than ROLE_SYSTEM_DOCUMENT are not
documents in the user sense of the
Right, but other things like get_accChild taking uniqueId are still applied.
On Wed, Feb 22, 2012 at 12:05 PM, James Teh ja...@nvaccess.org wrote:
On 22/02/2012 12:34 PM, Alexander Surkov wrote:
In Firefox a document accessible can have following roles:
# ROLE_SYSTEM_APPLICATION
#
Hi Alexander, In the case of IA2 I'm not aware of an interface being
used as a marker like you are proposing. Maybe the method name should
be something other than document. Some use cases would be helpful. I
am doubting that the AT would be asking for the containing object which
can provide the
19 matches
Mail list logo
