Pending decision of AccProbe team as to whether or not AccProbe should be moved from Eclipse to LF.

It would have to be relicensed from EPL.

Firefox - Marco Zehe

There are some minor mismatches between the IA2 text attributes spec and the Mozilla spec and/or implementation. Pete needs to complete the investigation of this for Mozilla prior to December 10. See the notes below on IA2 text attributes.

IA2 as a LF standard

Recently the LF Open A11y WG voted to submit the IA2 standard to the LF BoD for approval.

Mick and Jamie felt Qt should enable their Win support. Janina to follow up with her recent contact at Nokia and Mick and/or Jamie to see if they can submit a request for this to be added. A product called VirtualBox uses Qt.

Access to document revisions - from the ODF AccSC

This was reviewed by the AIA Interop group. The following issues were raised.

What is the solution for non-text attributes, e.g. tables, images, charts, cells, spreadsheets?

Pending response from Malte regarding if support is being added for these.

From Niklas Nebel at Sun: Recorded changes in spreadsheets are somewhat different from text documents: The spreadsheet cell structure only contains the current state. Changes are not part of a cell's content, but separate. Possible changes are:

Content changes

Inserting/deleting columns/rows

Inserting sheets

Moving cell ranges

Pending response from Niklas to some questions:

Is there a link to the spec that describes those changes?

What if a sheet is removed? Only insertion is mentioned.

What is a cell range and what does it mean to move them? An example / use case would probably be enough to describe this.

I don't think the proposed set of a11y interfaces and methods will work for a spreadsheet. Does anyone have an idea for a solution that would work for both writer and calc (and other apps)? Should we move forward with the existing spec for text revisions and add a spec for spreadsheets. Or should we define a spec that will work with a wider range of applications?

How are comment only revisions handled?

Malte Timmerman doesn't think this is a feature of OpenOffice. Is there any request for this from the IA2 community?

Malte wasn't supportive of this. Is there any request for this from the IA2 community?

Is more granularity needed for format changes, i.e. is it enough to just say there was a format change or should the kind of format change be indicated?

Malte said that as far as he knows this was discussed and the decision was to keep it at the current level of granularity. Is there any request for this from the IA2 community?

Use cases are needed.

Does the IA2 community request use cases beyond what is already implemented in OpenOffice?

getSegmentAtOffset (singular) needs to be getSegmentsAtOffset (plural) because unlike links there could be overlapping insertions and deletions.

From Oliver-Rainer Wittmann at Sun: In OOo Writer there are no overlapping revisions/change trackings. The OOo Writer breaks a certain change tracking into corresponding pieces, if the user creates overlapping revisions/change trackings. Thus, revisions/change trackings are properly nested in OOo Writer. But nevertheless, there can be several change trackings at a certain cursor position. Thus, the proposed change is reasonable.

Once these issues are resolved Li Yuan, the committer for ATK/AT-SPI will develop a patch.

enum IA2RevisionType {
IA2_REVTYPE_INSERTION,
IA2_REVTYPE_DELETION,
IA2_REVTYPE_FORMAT_CHANGE // The revision is due to any change in formatting attributes.
};
typedef struct {
enum IA2RevisionType type;
BSTR time; ///< ISO 8601 format: YYYY-MM-DDThh:mm:ss (eg 1997-07-16T19:20:21)
BSTR author;
BSTR comments;
} IA2RevisionInformation;
IARevisionText:
// Note: an object that implements IARevisionText must also implement IAText
// returns the number of segments available for the
// block of text represented by the IARevisionText object.
// this number is 1 based
get_segmentCount( long* count );
// returns a specific segment based on the index passed in
// the index is 0 based.
// no two indexes should return the same segment.
// any index >= 0, and less than the segment count should return a valid segment
// any index outside those bounds should set HRESULT to S_FALSE and return NULL
get_segment( long index, IARevisionSegment** seg );
// returns a segment whose boundaries encompass the offset provided
// if there are no segments that correspond to the given offset, an error is produced
// offsets correspond identically to those used by IAText and IAHyperlink
get_segmentAtOffset( long offset, IARevisionSegment** seg );
IARevisionSegment:
// returns the bounding offsets of the segment within the IARevisionText/IAText object.
// the end offset is one past the last character in the revision text
get_bounds( long* start, long* end );
// returns a struct containing date/time, author, and comments
get_attributes( IA2RevisionInformation *revision_info );
// returns a set of name value pairs describing additional application
// specific attributes in the format "name:value;name:value"
get_extraAttributes( BSTR* extraAttributes );

No progress on the following

Access to smart tags

Symphony uses IAHypertext/IAHyperlink for smart tags. This seems reasonable because smart tags are very similar to links. They represent actionable text. IAHyperlink can represent more than one action which is common for smart tags.

One requirement is for links and smart tags to be differentiated. This can be done with an object attribute on the accessible that represents the link object. Are there any issues with that approach?

The Symphony and FF3 object attributes will be reviewed. The common attributes will become part of the IA2 object attributes spec and the spec will reference the FF3 and Symphony specific specifications. (The Symphony object attributes are not documented on any Symphony web site, but they'll soon be documented on the IA2 site.)

Developer Guide - Best practices document. We should start an outline for a best practices document. For starters it should define the following:

What events should be fired for each role and in what order.

What object hierarchy should be used. There are two today, a flat hierarchy as used in Symphony and a deeper hierarchy as used in Firefox. These two should be documented and in order to cut down on the proliferation of designs, future applications should attempt to use one or the other.