[Accessibility] More input on API issues related to documents,
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
IBM Accessibility Architecture and Development
11501 Burnet Road, MS 9022E004, Austin, TX 78758
Voice: (512) 838-4594, Cell: (512) 689-4155
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Accessibility