[Accessibility] Need use cases for solving Mick's
document/table issues
Pete Brunet
brunet at us.ibm.com
Tue Jan 29 09:14:16 PST 2008
Thanks Mick.
>But, it gets complex if the boundary ends are not contained with in the
node in question (i.e. they end outside the node), or they end in the
middle of one of the descendant nodes.
I'm quite familiar with Symphony but not as much with the Mozilla
implementation. Symphony's lines are always contained within paragraphs.
But I recognize that web documents can be much more complex. FF3 flattens
the hierarchy quite a bit but I haven't looked closely at what is actually
done. Can you point me at a web page that exhibits the problem you
describe?
>it would make the life of AT developers much easier if people could agree
on one standard way of representing documents.
The problem is due to the disparity between how the DOMs are structured
between OOo and browsers. I suspect that this will always be an issue but
perhaps others will have some good ideas for improvement for future
applications.
Regarding your request for support of out of process ATs two things come
to mind to enable that:
1) The AT-SPI Collection interface
Does that interface provide everything you need?
2) A new event mechanism that passes more event data than the current
WinEvents mechanism. Today's event mechanism relies on an in process AT
being able to fetch MSAA data on the event thread.
Regarding your four issues, I entered these into the IA2 bugzilla. Please
add any additional information you can think of
> *It should be possible to ask for a single relation, rather than having
to retreave the entire set and searching for one.
http://bugs.linux-foundation.org/show_bug.cgi?id=119
> *It should be possible to find out if any object is in a document, and
what that document's root node is. This could be easily done with
relations, but this would depend upon the first point for performance
reasons
http://bugs.linux-foundation.org/show_bug.cgi?id=120
> *It should be possible to find out if any object is in a table, and what
row or column its in. AccessibleTable lets you ask this of a direct child,
but not of a descendant more than one level down. Note that although Lotus
Symphony may not have descendants more than one level deap in a table,
Mozilla Gecko probably does.
http://bugs.linux-foundation.org/show_bug.cgi?id=121
> *Considder adding methods such as GetcommonAncestor(obj1, obj2),
getObjectDepth(), compareObject(obj1,obj2) -> -1 for before in hyrarchy 0
for equal objects, 1 for after in hyerarchy.
http://bugs.linux-foundation.org/show_bug.cgi?id=122
Pete Brunet
IBM Accessibility Architecture and Development
11501 Burnet Road, MS 9022E004, Austin, TX 78758
Voice: (512) 838-4594, Cell: (512) 689-4155
Ionosphere: WS4G
Michael Curran <mick at kulgan.net>
Sent by: accessibility-bounces at lists.linux-foundation.org
01/29/2008 05:39 AM
To
accessibility at lists.freestandards.org
cc
Subject
Re: [Accessibility] Need use cases for solving Mick's document/table
issues
Hi Pete,
I read over the ADoc specification earlier this week, and I think most
of it is quite appropriate. However, I feel it is missing some things.
I may have just accidentily skipped them, but it probably should mention:
*Starting at an arbitrary offset with in an arbitrary node in a
document, the AT wants to announce the line around this pointt. The
announcement must take all nodes and attribute info with in that line,
in to account. e.g. other than the text, the AT must be able to announce
links, list items, table cells, spelling errors etc.
This use case could be also said for any kind of text boundary (such as
word, paragraph, sentence).
This use case is quite easy to achieve if the boundary ends are
completely contained with in the node in question, and do not end in the
middle of one of the node's descendants, and any links, list items etc
are all descendants of this node. But, it gets complex if the boundary
ends are not contained with in the node in question (i.e. they end
outside the node), or they end in the middle of one of the descendant
nodes.
The major trouble with this also is that the ADoc specification talks
about one way of representing documents. However truthfully if we look
at the implementations of Mozilla Gecko documents, Open Office documents
and Lotus Symphony documents, they all differ in varying ways, some more
than others.
I am not going to say that one implementation is definitely more
appropriate than any other, though it is clear to me that it would make
the life of AT developers much easier if people could agree on one
standard way of representing documents.
I will also admit that I am currently much more biased towards the way
Mozilla Gecko does things, only because I have been working with that
implementation the longest. As we investigate the best ways, I'd
certainly like to hear from people about the advantages of other
implementations.
Much of the issues I bring up are probably more related to IAccessible2
than ATK, mostly because ATK now has collections, and also some great
work with moving to DBUS and how that may speed things up with
client-side caching etc.
I would also like to note that although the comercial screen readers on
Windows use IAccessible2 in-process, this is not really that feezable
for NVDA, or for any other open-source and free AT. In-process code has
great performance that can not be ignored, however the amount of work
and debugging that would have to go in to maintaining in-process code
would be huge I'm sure. NVDA plans to go in-process for its virtual
buffers (for read-only web documents) however with the growth of web
applications, editable web documents, and many more desktop document
editors, it is very important that ATs provide the same level of quality
and efficiency when it comes to these, as they would for their read-only
documents.
So, I would like to see that when IAccessible2 begins a 2.0 stage, if
that is planned that we take the following things in to account (to
enhance performance for out-of-process ATs):
*It should be possible to ask for a single relation, rather than having
to retreave the entire set and searching for one.
*It should be possible to find out if any object is in a document, and
what that document's root node is. This could be easily done with
relations, but this would depend upon the first point for performance
reasons
*It should be possible to find out if any object is in a table, and what
row or column its in. AccessibleTable lets you ask this of a direct
child, but not of a descendant more than one level down. Note that
although Lotus Symphony may not have descendants more than one level
deap in a table, Mozilla Gecko probably does.
*Considder adding methods such as GetcommonAncestor(obj1, obj2),
getObjectDepth(), compareObject(obj1,obj2) -> -1 for before in hyrarchy
0 for equal objects, 1 for after in hyerarchy.
These are all just possibilities.
Let me also say that although I'm throwing all these ideas out here, I'm
not for a second saying that app developers, or ATs for that matter
should change the way thei're doing things, or that we should all stop
right now and re-write accessibility. However, I am saying that I think
that we all should look to the future, and review how things are going
with current implementations, and just play with some new ideas, and try
and see where accessibility could be in years to come.
Mick
Pete Brunet wrote:
>
> Mick, There are some document use cases in the ADoc document at
>
http://accessibility.linux-foundation.org/a11yspecs/atspi/adoc/ADOC_ATSPI_draft.htm
>
>
> Please take a look at them and see if any of these address any of the
> situations you are thinking of. Also please write up use cases for those
> situations that you have encountered which are not already in that
> document. Having a crisp use case description will provide a very good
> starting point.
>
> Thanks,
> *Pete Brunet*
>
> IBM Accessibility Architecture and Development
> 11501 Burnet Road, MS 9022E004, Austin, TX 78758
> Voice: (512) 838-4594, Cell: (512) 689-4155
> Ionosphere: WS4G
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Accessibility mailing list
> Accessibility at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/accessibility
_______________________________________________
Accessibility mailing list
Accessibility at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/accessibility/attachments/20080129/978e5bd7/attachment-0001.htm
More information about the Accessibility
mailing list