<br><font size=2 face="sans-serif">Thanks Mick,</font>
<br>
<br><font size=2 face="sans-serif">There may be overlap between the two
IA2 topics, i.e.</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; 1) interfaces/methods
needed for consistent document and table navigation and</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; 2) access to higher level
constructs such as spelling errors and revisions</font>
<br><font size=2 face="sans-serif">and the prior ADoc work and Collection
interface work.</font>
<br>
<br><font size=2 face="sans-serif">I'd like to propose forming a subgroup
of interested parties from the AT and application development communities
on both Windows and Linux to evaluate the two issues brought in from the
IA2 group and the prior ADoc/Collection work so we can determine if there
is some overlap and then identify the best solution.</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>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Michael Curran &lt;mick@kulgan.net&gt;</b>
</font>
<br><font size=1 face="sans-serif">Sent by: accessibility-bounces@lists.linux-foundation.org</font>
<p><font size=1 face="sans-serif">01/22/2008 06:19 AM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">accessibility@lists.freestandards.org</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">[Accessibility] Objects contained in
documents and tables</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>Hi all,<br>
<br>
In October last year I raised some issues about objects with in tables
<br>
and documents, in the IAccessible2 subgroup.<br>
<br>
The meeting minutes where the issues were talked about can be found at:<br>
http://www.linux-foundation.org/en/Accessibility/IAccessible2/Minutes/20071002
<br>
<br>
<br>
As these issues may not just affect IAccessible2, but ATK as well, It <br>
would be good if these issues were looked at by the wider Open A11Y group.<br>
<br>
The general issue is how to best make sure that ATs can provide <br>
efficient access to documents.<br>
<br>
A bit of background<br>
<br>
I am the creater and one of the core developers of NVDA (a free and <br>
open-source screen reader for Windows, mostly written in Python).<br>
<br>
One of my beliefs is that if application developers have a wrich but not
<br>
bloated accessibility API, and great documentation to go with it that <br>
explains best practice covering many situations, this should rappidly <br>
cut down on the amount of application-specific scripting an AT must <br>
provide to the user. In general IAccessible2 is a great API, and has <br>
certainly enabled NVDA wonderful access to such aps as Firefox and Lotus
<br>
Symphony. However, I feel one of the big things missing is generic <br>
support for documents.<br>
<br>
As an AT developer, I would like it if I was able to tell NVDA: &quot;If
you <br>
see a document, just do this&quot;... rather than saying &quot;if this
is a <br>
Mozilla Gecko document do this&quot; or &quot;if this is an IBM Lotus document
do <br>
this&quot;... etc.<br>
<br>
In most situations ATs and application developers have decided on some
<br>
general rules such as a list probably only contains list items, and <br>
there's probably no children inside a button. But when it comes to <br>
documents, it gets very complex.<br>
<br>
I think we can agree on some kind of description of what a document is
<br>
in abstract terms.<br>
*It can be viewed on particular devices or materials as a flat layout<br>
*It has a particular reading order<br>
*It has a caret which can travel the reading order path<br>
<br>
As far as an AT is concirned, it usually wants to be able to:<br>
*Navigate the reading order by character/word/line/paragraph<br>
*Do a continuous &quot;say all&quot; which auto navigates by preset chunks
along <br>
the reading order path<br>
*Possibly jump to particular landmarks such as headings, sections, other
<br>
field types<br>
*Posibbly navigate between tabular data such as cells, rows, columns in
<br>
a table<br>
*Detect when moving in and out of particular fields/sections, or detect
<br>
what fields/sections the caret is currently in<br>
*Speak or braille a particular chunk of data to the user, but also <br>
taking all field and section changes in to account and displaying them
<br>
appropriately<br>
<br>
However, accessibility APIs don't really have a particular protocol for
<br>
communicating with documents.<br>
<br>
App developers have devized their own ways of representing documents, <br>
some of them quite fasinating. However, a lot of them are quite <br>
inconsistant with each other. And what I would like to see, is some way
<br>
of breaking down these inconsistancies, either by providing much better
<br>
documentation on how to best represent documents, or make sure that the
<br>
accessibility APIs have specific ways of handling documents, so that its
<br>
clear both to the app developer and AT as to how best work with the <br>
document.<br>
<br>
Apps such as Firefox and Lotus Symphony use IAccessible2 to give access
<br>
to documents in such a way so that &nbsp;the document is a hyerarchy of
<br>
nodes. However, some of these nodes may contain text, and with in that
<br>
text, embedded object characters are used to denote where &nbsp;a particular
<br>
child of that node should be placed in the reading order of that text.<br>
<br>
This is a great solution where the AT is going to traverse the entire <br>
document and cache their own representation (known usually as a <br>
virtualBuffer).<br>
<br>
However, this way can cause issues when not caching the document, but <br>
when the user may be right in the middle of it somewhere, and wants to
<br>
know the current line or paragraph etc.<br>
<br>
ATs have come up with different logic I'm sure to handle these <br>
situations, but much of it is probably tied to a specific application,
<br>
and may be less efficient than it could be.<br>
<br>
Some ideas I propose we could think about are:<br>
<br>
*Provide a way for the AT to ask a particular accessible object if it is
<br>
in a document. Currently the AT must &nbsp;move up the parent chain untill
it <br>
finds a role of document. Note although most ATs build a chain of <br>
ancestors when the focus changes, my belief is that in-document logic <br>
should not only be available at the point of focus, but anywhere, wether
<br>
it be where the AT's navigator object is, or &nbsp;any type of virtual
<br>
position the AT may provide other than the focus. Perhaps accessible <br>
objects could have multiple roles, one of them being documentNode, or <br>
perhaps there can be a documentNode interface that has a way to get to
<br>
the root document node, or perhaps it can be an accessibleRelation that
<br>
can be checked for.<br>
<br>
*Like documents, provide a way for an accessible object to be asked if
<br>
it is in a table/row/column, no matter how deep down in the hyerarchy <br>
with in the table it is. Currently, the AT has to go up the parent chain
<br>
to find the table etc.<br>
<br>
*Provide a way for the AT to ask an Accessible object for the next <br>
object that is in the reading order -- as in where would the caret go <br>
once it leaves the greater side of this object. Same goes for the other
<br>
way -- previous. Of course the other option is to make sure that the <br>
hyerarchy reflects this, as in using &nbsp;depth-first traversal order,
it <br>
happens that you would always land on the next object where the caret <br>
would be. However this is increasingly becoming impossible as web <br>
documents are getting way more complex with sections and frames and <br>
tables etc.<br>
<br>
*A way to compare two accessible objects, and find out if 1. they are <br>
equal, 2. is the first before or after the second in the object <br>
hyerarchy. For instance, &nbsp;it may be useful for an AT to represent
a <br>
range in a document, as in two points with in the reading order. <br>
However, for this to mean something, and so that the AT can handle this
<br>
properly, it must be possible to know &nbsp;where these two points are
in <br>
regards to each other (lesser, greater, equal).<br>
<br>
I think it would be great if we could get the ATs together that <br>
currently support IAccessible2 / ATK, and really nut out our needs, and
<br>
make sure that the APIs 1. mirror each other, and 2. they provide <br>
exactly what we really need.<br>
<br>
As I am only representing myself here, I am not sure about what other <br>
ATs' needs really are, or whether these issues even effect them. <br>
However, I at least think it would be healthy to review all this stuff
<br>
together, and share tips and ideas, and see if we can make things easier
<br>
for ATs and app developers, on more than just one specific platform.<br>
<br>
I'm also aware of the big push from certain communities for ATs to try
<br>
and share scripting etc both for apps and the web, but the only way I <br>
see this ever remotely being a possibility is by making sure that <br>
IAccessible2 and ATK are improved completely in paralell, and that ATs
<br>
can share ways that they handle particular and generic situations.<br>
<br>
Mick<br>
<br>
<br>
_______________________________________________<br>
Accessibility mailing list<br>
Accessibility@lists.linux-foundation.org<br>
https://lists.linux-foundation.org/mailman/listinfo/accessibility<br>
</font></tt>
<br>