-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Malte Timmermann
Sent: Thursday, October 04, 2007 6:31 AM
To: Pete Brunet
Cc: [EMAIL PROTECTED]
Subject: Re: [Accessibility-ia2] IDeas for next IA2 spec
Peter, You mentioned that inDocument could be computationally
expensive for the app. Could you ask Malte?
Not expensive, but probably not nice to implement. An AccessibleObject
knows everything it has to know, but probably not the
AccessibleDocument. So it would walk up the hierarchy to look for it.
Why offering a special method for this? Can be done from
outside as well.
I don't see a performance issue here. Hierarchy below the document is
normally quite flat, 1 or 2 levels max. And we talk about fast and
simple getParent() here.
I also agree with Andres Gonzales that relations are not a good idea,
for design reasons.
Steve Lee quoted something from Peter Parente:
walking up may not always work
I disagree. If walking up doesn't work, the specific implementation is
broken, no reason to have work arounds in the API for this.
Malte.
Pete Brunet wrote, On 10/02/07 06:18:
Regarding the prior emails...
IA2 relations are strings. So all that's needed is an
agreement as to
the name and semantics and then for the app devs to implement the
relations. No need for IA2 2.0.
Mick, In the example you give of when focus lands on a link on a
heading object, please describe why you need to know the parent
document. (Maybe you don't; maybe you just need to know
you are in a
document.)
Mick, For inTableCell, I think you meant inTable since you said you
want to know when you are in the same table. Also, IATable
describes
a table, not a table cell.
Peter, Many times we've talked about more than one role on an object
but after discussing it with app devs, ATVs, and a11y
architects we've
never made a case for it. The convention for current
implementations
for buttons in cells is to use the a11y hierarchy, i.e. the
button is
a child of the cell.
Peter, You mentioned that inDocument could be computationally
expensive for the app. Could you ask Malte?
Mick, After Peter mentioned multiple roles you mentioned that each
node could have 2 roles, one being "documentNode". The same thing
could be done with inDocument:true in IA2::attributes.
Peter, IA2 states are in a 32 bit long bit strip (just like MSAA
states). IA2 (and MSAA) roles are 32 bit constants. For a
dynamically generated role or dynamically generated states
(for ARIA)
there is IA2::extendedRole and IA2::extendedStates. These
are strings.
*Pete Brunet*
IBM Accessibility Architecture and Development
11501 Burnet Road, MS 9022E004, Austin, TX 78758
Voice: (512) 238-6967, Cell: (512) 689-4155
Ionosphere: WS4G
*Peter Korn <[EMAIL PROTECTED]>*
Sent by: [EMAIL PROTECTED]
10/01/2007 01:07 AM
To
Michael Curran <[EMAIL PROTECTED]>
cc
[EMAIL PROTECTED]
Subject
Re: [Accessibility-ia2] IDeas for next IA2 spec
Hi Michael,
Sorry, I'm actually not that familiar with the way that the
Java/UNO/GNOME accessibility API was realized in Windows with
IAccessible2. In that first set, roles & states can be
strings (though
we have a bunch of pre-defined constants in GNOME for faster
performance). In particular, in Java string compares are
very fast due
to the way they are allocated in the VM.
Glancing now at the API docs, I'd think you could do
something like a
"primary role" and then some number of "secondary roles" in
a mechanism
similar to the extendedStates interface. [wow, I just had
a flashback
to being in a bar in Salt Lake City, attempting to order a White
Russian, and learning about primary and secondary liquors...].
Regards,
Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
Hi again,
Actually, if we do have role sets, there has to be a way
of ordering
them, I think bitwising won't do the trick. As in if
you're on a link,
which is in a document, the link role should be the
first role found,
documentNode should be after that, as an alternative. If
there was no
order, it would be very hard for screen readers to know
which role to
actually speak. I'm sure you could employ logic to do it,
but it would
be prefered if it was looked at as role, alternative roles, rather
than just roles.
Mick
----- Original Message ----- From: "Michael Curran"
<[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, October 01, 2007 2:38 PM
Subject: Re: [Accessibility-ia2] IDeas for next IA2 spec
Hi Peter,
I like the idea about role sets. However, with states, they are
bitwised as they are all powers of 2. Would roles become
powers of 2?
or would there be kind of an IEnumVariant thing going on
to get all
the roles?
For a role to suggest you're in a document, in that case
I'd suggest
that a role_documentNode be created, so that all roles
in a document
can have this role as well, rather than paragraph, which
might become
confusing.
Mick
----- Original Message ----- From: "Peter Korn"
<[EMAIL PROTECTED]>
To: "Michael Curran" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "Willie Walker"
<[EMAIL PROTECTED]>
Sent: Monday, October 01, 2007 1:39 PM
Subject: Re: [Accessibility-ia2] IDeas for next IA2 spec
Hi Michael,
For the table cell case, we've discussed a different
approach: make
the AccessibleRole become an AccessibleRoleSet, just as we have
AccessibleStateSet. Then things like table cells would have
potentially multiple rolls. A radio button in a table
cell would
have both the radio button role, and the table cell roll.
For paragraphs and heading information, I'm not sure the RoleSet
route would make sense, but it is also worth exploring.
Bringing in
relations for something like that can be fairly costly
- even with
lazy computation, it can still be a fairly large calculation to
make. I wonder if it would be more reasonable to
simply use a role
like "PARAGRAPH" which would be the trigger for NVDA
and other AT to
know they should walk up the hierarchy a bit. That way
you wouldn't
need to do so most of the time. That is also a nice way
of knowing
you are in a document.
Regards,
Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
P.S. I've cc-ed Willie Walker, whose team has
implemented Read Whole
Document for Orca & OpenOffice.org on UNIX. He may have some
suggestions for this for NVDA in IAccessible2 as well...
Hi all,
I'm not quite sure what the plans are for an IAccessible2 2.0
spec... or something after 1.0, but I do have a few
ideas on things
I would like to see implemented.
For now I'll list a few, and perhaps add to this
thread if I think
of any more.
a relation type of "inDocument":
IAccessible2 is being implemented in apps which
provide access to
documents (such as in Symphony, or Firefox). As a screen reader
developer, it would be nice to be able to tell if I'm in a
"document" so that I can better announce where the
user is with in
that document.
For example: usually NVDA just reads name, role, value,
description, shortcut, position, text when focus
changes etc. But
with in a document, I would rather it be able to track the
hyerarchy a bit better, as in say the focus moves from
a paragraph,
to a link with in a heading, I would want it to announce the
heading role, as well as the link. However this is a
little costly
as I need to check the ancestor chain for the object
I'm on, and
compare it with the ancestor chain of the previous object.
As it is a little costly, and there's not really any need of it
outside documents, I propose that a "document" relationType be
added, so its easy to find out a. if you're in a
document, and b.
the root node of the document.
Another reason its needed is for functions such as say all in
screen readers. NVDA currently has a say all function,
but it only
works with in a certain object, navigating its text.
But for new
IAccessible2 documents now in Symphony and Firefox etc, to read
continuously through a document, from an arbitrary
point, you need
to be able to not only read the text in the object
you're on, but
also navigate to its children, or if not, then next, or if not,
then parent and next. However, you also don't want to
bleed out of
the document and start reading toolbars or other widgets, so a
document relationType would allow for a. the screen
reader knows
its allowed to use the multi-object say all, and b. it
knows where
to stop (as in when it hits the root node it shouldn't go any
further).
Another relationType i propose is "inTableCell". This
is needed for
pretty much the same reasons as for inDocument as when you move
around with in a table (and you could be many
decendants down from
an actual cell) you still need a way to tell if you
are in a table.
As far as I understand, IAccessibleTable interface is
only on table
cells, not decendants of table cells, so when on a
decendant, we do
need an efficient way of getting the closest
IAccessibleTable, to
work out what row / column etc.
These are the ideas I have for now.
Mick
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
--------------------------------------------------------------
----------
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
