IAccessible2 SIG Conference Call Minutes 2007/10/02
Pete Brunet, Janina Sajka, Andres Gonzalez, Mick Curran, Mike Squillace
CSUN 2008 - IA2 related activities
There will be an IA2 panel. Participants will include representatives Open A11y, Adobe, IBM, Mozilla, Sun, Ai Squared, Dolphin, Eclipse, Freedom Scientific, GW Micro, and NVDA.
Janina will chair a panel on the status of the LF Open A11y standards, i.e. the IA2, atk/at-spi, keyboard and expert handlers specs.
There will be a session on Expert Handlers which may cover IA2 to some extent.
IA2 may be mentioned in any FF3 based presentations.
There may be a panel on IA2 as implemented in Lotus Notes 8 / Symphony. Depending the rollout of the IBM contribution to OpenOffice.org, this may include an update on the accessibility portion of that contribution.
Objects contained in documents and tables - from Mick Curran
On the IA2 list this week Mick Curran asked for the following
A way to know when an object is in a document or a table
A way to know the parent object with role document or table
This would make it easier for an AT to know when to apply document centric logic and it would make it easier to know when navigation as moved outside of the current document or table.
From the list prior to the meeting:
Mick: Provide new inDocument and inTable relations.
Peter Korn: The relations might be expensive to for the app to compute and suggest that at least item 1 could be solved by giving an object more than one role, e.g. a secondary role indicating inDocument or inTable.
Pete Brunet: Prior consensus was to use only one role but that the same thing could be done using IA2::attributes.
Andres Gonzalez: The document could be found via a new IA2::document method.
Andres: Relations are great because they allow you to link two nodes in an "arbitrary" way, but I don't think they should be used to replace important pre-defined relations between nodes, like parent/child and owner document.
Mick: Should we add new interfaces, e.g. IAccessibleDocNode and IAccessibleDocument?
IAccessibleDocument could have methods like: getFilePath, getLastModifiedTime, getTitle, etc.
IAccessibleDocNode could have methods like:
getRootNode -- the actual document
getNextInCaretOrder - where the caret would move after this one
getPrevInCaretOrder - where the caret would move before this one
getRevisionFieldAtOffset -- to do with ideas about revisions/authors/copyrightting of part of a document
Discussion during the meeting:
Adobe has IPDDom, Microsoft has DOM interfaces.
AT-SPI has a document interface. It has methods for getting the locale and attributes. IA2 has IA2::locale and IA2::attributes, i.e. those methods are located in a different interface.
Discussion on the list prior to posting minutes:
Malte: Regarding performance of creating the inDocument relation, it's not expensive, but probably not nice to implement. An accessible object knows everything it has to know, but probably not the accessible document. So it would walk up the hierarchy to look for it. But why offer a special method for this? This can be done also be done by the AT. The hierarchy below the document is normally quite flat, 1 or 2 levels max and the fast and simple getParent() can be used. Relations are not a good idea.
Andres: Many document types, e.g PDF, have complex and deeply nested hierarchies. Also it's more complicated just getParent(), i.e. a loop of getParent; getRole == document; times the number of nodes in the tree, for a single "multi-object say all" operation that Mick was talking about. Does not sound very efficient to me. An accessible document and accessible document node interfaces is a better design and implementation approach.
Peter Korn: For "multi-object say all", you first need to know what the logical reading order is. If I recall, tagging in PDF is supposed to contain this underlying reading order for this very purpose. We explicitly use a linked-list-style set of relations specifically for this purpose, with next and previous relation pairs to determine the reading order. That way, if you are on an object, and it has a next and previous, you can immediately start reading from it and go to the end or beginning or trace your way back to the beginning. Likewise, if there was a single role (in a role-set or a state in a state set) indicating that this object was a descendant of a document, then going up the tree to find that document, even if 20 levels deep, will be fast. Yes, finding all of the leaf nodes of a document could take time. But what are the use cases, and do we have them otherwise covered?
Andres: To my knowledge, the reading order has always been determined by the accessibility tree traversal order, depth first and then breath. That's exactly what tagged PDF allows, to present an accessible tree to an AT client with the correct traversal order. I've never heard before the use of relations to override the reading order determined by the tree itself. I like relations a lot, but think that there is an appropriate use for them, and also the risk of overuse or abuse. Think about it this way, the container of accessible objects has been traditionally a tree structure. With relations you are making it a more general graph. How far the general graph route you want to go, considering all the computational complexity that a general graph would add.
AT-SPI has a document interface which could be used as a model.
Pete: AT-SPI's document interface has methods for getting the locale and document specific attributes, IA2 also has these but on the IA2 interface rather than on a separate IADocument interface. Where there more methods planned for the doc interface in AT-SPI?
This needs further discussion.
Access to document revisions - from the ODF AccSC
The ODF AccSC asked for an investigation into how to give access to ODF's document change tracking info. ATs will need
Access to whether the text at a certain offset is: unchanged, added, deleted, or changed plus the ability to access all the related descriptive information such as author and date.
The ability to get a list of all revisions in a document.
For item 1, suggestions included:
Implement IARevisions on each revised paragraph. IARevisions would return one or more dynamically created paragraph objects implementing IARevision (singular) with methods giving full access to the change information plus start/end index in the revised paragraph.
Use IAText::attributes with new attributes indicating the kind of revision and the associated descriptive information. (This makes it difficult to decode if there revisions and attributes overlap.)
For item 2:
Implement IACollections to return the revisions, e.g. find all of the revisions; or only the revisions made by a certain individual; or only the revisions that were insertions (vs. deletions). This gets around the problem on Linux/Unix where only visible accessibles exist.
Provide access to the internal list that OOo maintains either through the existing OOo GUI or through a new method, such as IA2::revisions, which would return a list of revisions or fail in some appropriate fashion if there were no revisions.
This needs further discussion.
Version 2 of the text attributes
Aaron is not sure if they will be able to implement this in FF3.
Addition of IAText::defaultAttributes - raised by Aaron
Aaron needs to talk to the ATVs but is heads down on FF3.
Inspect tool - Mike Squillace
r0.2 will be ready any day now.
Until it's moved into Eclipse, hopefully next month, an IBM license agreement will have to be signed.
New features: keyboard focus tracking, highlighting, a find feature, and a user's guide.
Firefox Status - Aaron Leventhal
Working on stability and shutdown problems that are difficult to track down.