[Accessibility] More input on API issues related to documents, tables, revisions

Pete Brunet brunet at us.ibm.com
Mon Jan 21 19:22:36 PST 2008

Regarding the two issues on Tuesday's agenda that were initially raised 
during an IA2 meeting last October as documented in items 4 and 5 at 
I received the following input from the ATVs:

>From Rob Gallo

Having implemented this a couple of times now, I don't really see how not 
having a function to get the current document or table would keep an AT 
from making an IA2 enabled app accessible. The information is there; and 
the hierarchy, if correct, would have the document or table within reach. 
When in process, the calls to get parent are not expensive. And the AT 
could optimize if performance were an issue.
I like the idea of a document interface, because it provides a 
standardized set of useful information for IA2 implementers to expose. I 
also like the attribute approach, because it allows IA2 implementers some 
leeway to expose non-traditional document information (i.e. it's easily 
extensible). Perhaps a combination of these two approaches would be best. 
However, I recommend that the document interface only be required for 
objects with the role of ROLE_SYSTEM_DOCUMENT.
As far as I know (and I am by no means an expert), the DOM support 
provided by Microsoft in IE and Office, only provides a top-down approach 
to the document contents. In other words, you can definitely get the child 
objects of a document, but I don't know that you can get the document 
object from its children. Of course, because of focus events, IA2 and MSAA 
have more of a bottom-up approach in most cases. But I think this would be 
an interesting data point in deciding how to resolve this discussion.
And lastly, but importantly, I think we need to be judicious about how 
much we ask IA2 implementers to do. The more involved we make the 
interfaces - the more we ask them to maintain complex relationships 
between objects - when we place more of the burden on them - the more 
reluctant they will be to implement IA2, and the less likely they will be 
to get it right. We need to respect that the implementers have limited 
resources, and may be new at this. So I think we need to distinguish 
between those things which are nice-to-have, and those things which are 
truly a barrier to accessibility. 

and from Bill Smith

What would be useful is a function or functions that let you start with an 
IAccessible2 and get a collection of the tables that contain the 
IAccessible2 as well as tables that that IAccessible2 contains.   This is 
fairly important because it makes it practical to enumerate all the tables 
in a document as well as identify the caret's location relative to tables.

For other information such as revisions and spelling errors the same 
function that I mentioned could also be used if it had an additional 
parameter indicating what kind of information the AT was looking for. For 
a situation where you can select a disjoint set of cells (for example in a 
spreadsheet) this function could also help identify the argument IAcc2's 
location concerning those selections.

An additional item that would enhance the above would be to be able to 
compare two IAccessible2's and determine their relationship with each 
other in document order.   With this you could determine nesting of tables 
and whether the result of the query is surrounding the IA2 or surrounded 
by.   This one needs more thought to reduce the complexity of its 
definition because of how it should interact with tables.  Ordering cells 
in a table could be solved in a few different ways.   Either the order 
could be globally defined as row major or column major; there could be an 
attribute of the table indicating which order is being used by the table 
or as a third option is an input to the comparison function would specify 
which order it wanted the server to use. 

It would also be desirable to be able to choose between comparing the 
beginning of the IA2s or the end. 

These two or three functions seem like a unified interface that gives 
access to many of the differing sets of information such as tables, 
revisions and spelling errors that an application would want to present to 
the AT.  I'm not sure what reaction this would get as far as efficiency. 
Lazy evaluation of the collection might be enough make it practical in 
some cases.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/accessibility/attachments/20080121/c21726ec/attachment.htm

More information about the Accessibility mailing list