When IA2_EVENT_TABLE_ROW/COLUMN_HEADER/DESCRIPTION_CHANGED are fired the AT doesn't know which row/column changed.
It was agreed that we should add four new table object attributes, i.e. row-description-changed-index, column-description-changed-index, row-header-changed-index, and column-header-changed-index. Since the MSAA event model doesn't provide for the sending of event specific data, the currency of the values can be a problem for out of process users so servers should leave the values unchanged for as long as possible.
The same problem exists with getting inserted and removed text. At some point we should seriously consider defining an event mechanism that provides for sending a data packet with the event.
Four open questions:
Should the QS of IAccessible only respond to an IID of IID_IAccessible2 or should it respond to any of the IA2 IIDs?
Yes, when the service ID is IID_IAcessible2 you should be able to QS from IAccessible to any of the IA2 IIDs.
If IEnumInvariant is implemented, is it implemented on the same object as the rest of the IA2 interfaces?
It's not needed for IA2. It's only needed for IAccessible.
Will FF and Symphony respond without error based on this spec or will some bugs need to be written and a rollout plan put in place?
Once the text is updated Pete will get with Marco for Firefox and Xing for Symphony to determine if there is any impact.
Should IDispatch be allowed as an additional optional interface on the IA2 object?
Today IAccessible2 (mistakenly) inherits from IAccessible. There is documentation that implementations should not rely on this, e.g. QI the inherited methods instead of calling them directly. However, IDispatch is needed for scripting and even if inheritance from IAccessible is removed, inheritance from IDispatch should remain. Also a set of DISPIDs should be defined. Pete to check with Marco and Xing to determine if IDispatch has been implemented in either Firefox or Symphony.
For the next meeting: Is inheritance needed or is it OK to just allow access to IDispatch via QI?
Lightweight IA2 objects
The description of IAccessible2 says, "This interface must always be provided for objects that support some portion of the collection of the IAccessible2 interfaces." However, objects that support IARelation or IAHyperlink should be lightweight with no need to support IAccessible2 or IAApplication. Are there any objections to this restriction?
There are no objections. However, the wording should say this is optional on the part of the server. (Gecko already implements IAccessible2 on these lightweight objects.)
The following two paragraphs are part of the description for IAHyperlink:
An interesting use case is an image map where each area is associated with multiple actions, e.g. an image map of smart tags. In this case you would have to implement two levels of accessible hyperlinks. The first level hyperlinks would only implement anchor and anchorTarget. The anchors would all reference the image object. The anchorTargets would reference the second level accessible hyperlink objects. None of the IAccessibleAction methods would be implemented on the first level hyperlink objects. The second level hyperlink objects would implement the IAccessibleAction methods. Their anchors would also reference the image object and their anchorTargets would reference URLs or the objects that would be activated.
This use case demonstrates that in some cases there is no need for IAccessibleHyperlink to derive from IAccessibleAction. As a result it may be removed in a later version of the IDL and it is suggested that implementations should not rely on the inheritance.
Jamie points out that hyperlink anchors and actions are different concepts. Treating them as the same infers that a hyperlink can only have one action per anchor. They should be treated differently; i.e. that IAHyperlink should not derive from IAAction and there should instead be IAHyperlink::nAnchors. So this would require an additional method, not just the removal of the derivation from IAHyperlink.
Pete will add a note that in a later version the inheritance will be removed and a new interface, e.g. IAccessibleHyperlink2, will be defined to include the nAnchors method.
At some point we'll have to look at what needs to be changed for IA2 to be correct in both 32 bit and 64 bit environments. The 32bit world is also known as ILP32 where ints, longs, and pointers are all 32 bits. The 64 bit world is called LP64 where the longs and pointers are 64 bits. IA2 specifies all the integers as longs but they probably should have been specified as ints. There is a paper on ILP32, LP64.
Pete will investigate how MSAA handled this.
Types for IAValue
Should the VARIANT types for IAValue be limited to VT_I4 and VT_BSTR?
It was felt other numerics, especially floats, such at VT_R8 (double) should also be allowed.
For next time: Is VT_I4, VT_R8, and VT_BSTR sufficient? (There is also VT_I8 to consider.)
It was also felt that if the current value is a numeric then the min and max should also be numeric and of the same type.
It wasn't clear what to do if the current value is a BSTR. Pete will check with some developers.
IA2 and VirtualBox
Jamie finally got a reply from Harald Fernangle re IA2 in VirtualBox so Nokia/Qt is now aware it's wanted (for text support). Jamie filed a bug against VirtualBox.