From The Linux Foundation

IAccessible2 SIG Conference Call Minutes 2008/07/01

1. Regrets: Mike Squillace, Janina Sajka
2. Attendees: Pete Brunet, Mick Curran, Jamie Teh, Marco Zehe
3. Last two meeting minutes - approved
   • two weeks ago
   • last week
4. Firefox - Marco Zehe
   • Bug 441888 was fixed and that exposed a new issue, i.e. an issue with the n of m info for menu items, e.g. menu separators are included in the count. This can be a source of confusion for groups of radio buttons. The would also impact IA2::groupPosition. For groups of radio buttons Firefox could determine if all the controls between two separators are radio buttons and expose the correct count.
   • Alexander is working on bug 434464
   • Marco is testing the higher level platform independent interfaces.
   • The NVDA team is doing a good job of exposing bugs in Firefox.
   • FF 3.1 will alpha in July, beta in Aug, release in Dec (but Q1 2009 is more likely).
5. IA2 version 1.0.2 RFC readiness:
   • The review period has ended. Three changes were made. See the notes in the agenda.
   • Once the 1.0.2 IDL is in BZR everyone needs to be notified and any further changes need to go into BZR.
6. IA2 object attributes specification.
   • NVDA has asked Mozilla to enhance their support for the "formatting" object attribute, i.e. rename it to "display" and instead of just using the value "block", also use the full set of CSS2 values.
   • This is bug 439566.
7. ChildID Support requested by Microsoft.
   • If the new interface is accepted we have to analyze the impact on apps and ATs due to changing the proxy DLL and the merged IDL file. There should be no problems but we need to make sure.
   • Jamie commented that the DLL should not be a problem because COM is "question and answer" based rather then a binary spec where things have to be at certain offsets.
8. Solution for smart tags, spelling errors, and grammar errors.
   • The OpenOffice team suggested that a new interface is needed.
   • Symphony used IAHypertext/IAHyperlink/IAAction for their autorecognizer (aka smart tags).
   • It's not clear to the NVDA team that interfaces are the best solution for an AT.
   • The following notes are a mixture of commentary both from the meeting and after the meeting.
   • The three arguments for text attributes vs interfaces are:
     1. Conceptually revisions aren't a good fit for attributes. Attributes tend to define the look of the text, e.g. font, color, bold, italics, etc.
        • Jamie: This is true. However, there is nothing inherent in the name "text attributes" that indicates that they must necessarily be limited to visual formatting alone. Also, revision information would be handled in a similar way by many ATs; i.e. it would be read as additional information when moving through or reading the text.
     2. Internally OpenOffice doesn't maintain the revision information as attributes so would have to always manufacture it.
        • Jamie: This is obviously a concern that may make the text attributes idea an impossibility for OpenOffice. We do want access to this information in some way or another, so if text attributes can't work, an additional interface will certainly do the job.
        • Pete: The OpenOffice team said this was an issue for revisions. I don't know if there is the same problem with spelling/grammar errors and smart tags.
        • Pete: There is no current requirement that start tags and spelling/grammar errors need to have the same solution. We could decide that an interface is needed for smart tags and text attributes for spelling/grammar errors.
     3. Conceptually revisions are a lot more like hypertext, i.e. it is meta meaning overlaid on top of sections of text.
        • Jamie: This is a fair point, although you could argue that text attributes sometimes present "meta meaning" as well. However, in support of your argument, it is worth noting that revision info could be quite lengthy, involving potentially large chunks of text which may not be considered by ATs at all in most cases. On further reflection, perhaps it is better to use an interface for this reason.
   • Jamie:

     What solution is currently being used/will potentially be used for footnotes, endnotes, bookmarks, comments, etc.?

     I do believe there is a stronger argument for using text attributes for spelling/grammatical errors. These do seem to be more similar to the current use of text attributes to me and are definitely presented in a similar way. However, if other ATs do need to access the possible choices using actions, etc., this may not be suitable.

     Our argument for using text attributes as much as possible is that this way, we can pick up all the meta information associated with a given run of text in one shot. For a screen reader, we generally want to simply read some or all of this meta information when reading or moving through the text.

     Ultimately, as long as the information is accessible, we are happy. However, it'd be good to make that accessibility as intuitive and consistent as possible.

   • Pete:
     • Symphony doesn't do anything special with footnotes and endnotes. The user can sense them because of the superscript and then use the content menu to navigate to the notes.
     • For notes (an embedded comment, activated in Symphony with Create, Note), IAHypertext/IAHyperlink is used. I don't remember how ATs are meant to handle this and I can't figure it out just using AccProbe.
     • Bookmarks are not exposed via MSAA/IA2, only via the native UI, i.e. use F5 to activate the navigator, choose bookmarks from the list box, then use the previous and next buttons.
     • Another point that was brought up during the meeting was that if IAHypertext/IAHyperlink is used for all sorts of hyper information, the AT UI would be the same, e.g. speaking the related text with a different pitch. We need to determine if this is a problem. If Symphony is only using those interfaces for links and autoreco text, that doesn't seem like a problem. The two concepts are pretty close, i.e. they both have actionable functionality. However, I suspect it would be a problem if misspelled words and grammar errors had the same behavior; they don't have the same sort of actionable functionality; the misspelling or grammar error can be corrected, but that functionality doesn't cause a context change like what happens when following a link or using an autoreco (smart tag) function to, for example, activate a mail program.

• IAccessible2 SIG's meetings page
• IAccessible2 SIG main page
• Open A11y Working Group Main Page