<br><font size=2 face="sans-serif">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 http://www.linux-foundation.org/en/Accessibility/IAccessible2/Minutes/20071002
I received the following input from the ATVs:</font>
<br>
<br><font size=2 face="sans-serif">From Rob Gallo</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">&nbsp;</font>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">&nbsp;</font>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">&nbsp;</font>
<br><font size=2 face="sans-serif">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. </font>
<br>
<br><font size=2 face="sans-serif">and from Bill Smith</font>
<br>
<br><font size=2 face="sans-serif">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. &nbsp; 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.</font>
<br>
<br><font size=2 face="sans-serif">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. &nbsp; 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.</font>
<br>
<br><font size=2 face="sans-serif">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. &nbsp; With this
you could determine nesting of tables and whether the result of the query
is surrounding the IA2 or surrounded by. &nbsp; This one needs more thought
to reduce the complexity of its definition because of how it should interact
with tables. &nbsp;Ordering cells in a table could be solved in a few different
ways. &nbsp; 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.
&nbsp; </font>
<br>
<br><font size=2 face="sans-serif">It would also be desirable to be able
to choose between comparing the beginning of the IA2s or the end. </font>
<br>
<br><font size=2 face="sans-serif">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. &nbsp;I'm not sure what reaction this
would get as far as efficiency. &nbsp;Lazy evaluation of the collection
might be enough make it practical in some cases.</font>
<br><font size=2 face="sans-serif"><br>
</font><font size=1 color=#0060a0 face="Arial"><b>Pete Brunet</b></font><font size=3 color=#0060a0><strike><br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</strike></font><font size=1 color=#2f2f2f face="Arial"><br>
IBM Accessibility Architecture and Development<br>
11501 Burnet Road, MS 9022E004, Austin, TX 78758<br>
Voice: (512) 838-4594, Cell: (512) 689-4155<br>
Ionosphere: WS4G<br>
</font>