[Accessibility] Need use cases for solving Mick's document/table
mick at kulgan.net
Tue Jan 29 03:39:03 PST 2008
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
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
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
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
*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.
Pete Brunet wrote:
> Mick, There are some document use cases in the ADoc document at
> 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.
> *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
More information about the Accessibility