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
