[Accessibility] Need use cases for solving Mick's document/table issues

Michael Curran mick at kulgan.net
Tue Jan 29 03:39:03 PST 2008

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 

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
> 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

More information about the Accessibility mailing list