The Linux Foundation

 
Accessibility/IAccessible2/Agenda/20080708

From The Linux Foundation

Revision as of 04:11, 8 July 2008 by Ptbrunet (Talk | contribs)

(diff) ←Older revision | view current revision (diff) | Newer revision→ (diff)

Agenda for 2008/07/08

  1. Introductions if needed
  2. Approval of prior minutes
    • Corrections? Approval?
  3. LF: Open A11y news - Janina
  4. AccProbe inspect tool - Mike Squillace
  5. Firefox - Marco Zehe
  6. IA2 1.0.2 review period has completed.
    • Three issues were fixed
      • clarification of handling BSTR when there was none returned.
      • Clarification of scroll constants.
      • Clarification of the description of IAAction. The second paragraph was changed to
        Every accessible object that can be manipulated via the native GUI beyond the methods available either in the MSAA IAccessible interface or in the set of IAccessible2 interfaces (other than this IAccessibleAction interface) should support the IAccessibleAction interface in order to provide Assistive Technology access to all the actions that can be performed by the object. Each action can be performed or queried for a name, description or associated key bindings. Actions are needed more for ATs that assist the mobility impaired. By providing actions directly, the AT can present them to the user without the user having to perform the extra steps to navigate a context menu.
    • Based on a discussion with Jamie Teh, IAHypertext may need clarification with respect to inheritance from IAAction.
    • Work items:
      • Complete rework of HTML to meet Open A11y guidelines.
      • Verify that there are no impacts on generated code from v1.0.1
      • Submit to the Linux Foundation Board of Directors for approval.
      • Move 3/26/2007 1.0.1 IDL to BZR.
      • When 1.0.2 is approved move the IDL to BZR.
  7. IA2 object attributes specification.
    • Jamie asked if Mozilla could 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 Mozilla bug 439566 and it has been fixed and verified and is available in Minefield/3.1a1pre.
    • No progress on the following:
      • 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.)
      • Pete to update the object spec to add a "display" attribute with CSS2 values.
  8. Proxy DLL
    • The rc file attachment was missing from bug 110. Pete added it.
    • The rc file is used to add version information to the DLL. Nobody has yet created the DLL using Visual C Express Edition so once someone has done that we need to update the process in the wiki.
  9. New agenda items from NVDA (Jamie):
    1. Making constants appear in the IAccessible2 type library:
      • High level languages, such as Python, use the type library built from the idl, rather than the .h files.
      • Constants defined freely in the idl are not included in the type library.
        • For example, this currently includes all of the IA2_STATE_* constants.
      • If these are defined as enums, they can then be included in the library definition.
        • Unfortunately, the IA2_RELATION_* constants obviously can't be an enum and there doesn't seem to be any other construct that can be used, so they cannot be included into the tlb.
      • Mick has made the appropriate modifications to the idl.
      • Pete: There are two sets of constants, the states and the relations.
        • The states could be coded as constants as follows. Would that work?
          enum IA2StateID { ..., IA2_STATE_ARMED = 0x2, IA2_STATE_DEFUNCT = 0x4, ...}
        • We need some help with solving the issue with strings.
    2. Proxy dll:
      • The IA2 registration in Firefox is not yet implemented. Even once complete, it will be several months before the next release of Firefox.
      • We are implementing an in-process hook for NVDA which registers the IA2 proxy for each process, thus allowing for portable Firefox and NVDA in the meantime.
      • We should decide on the guidelines that should be followed regarding this proxy dll.
      • We thought of the following:
        • Portable ATs such as NVDA should inject into other processes and register the proxy.
        • Installed ATs should install and register the dll as a shared file into %SystemRoot%\system32\IAccessible2Proxy.dll.
      • Should applications such as Firefox register the proxy in their own process?
        • Perhaps not if the ATs are going to do it anyway.
        • This also means less copies of the dll floating around.
      • Pete: JAWS doesn't need the DLL. JAWS is in process and injected into each process. I believe AccProbe is registering the DLL at install time and copying it to system32. I don't know what is being done for Window-Eyes. The approach AccProbe has taken is based on our original decision. The goal was to have the least amount of impact, i.e. only impact the ATs and not the apps. The suggestion for handling portable ATs is an extension of that so that would be good.
    3. Building the proxy dll:
      • Mick has managed to get the proxy dll building with the tools included with the Microsoft Windows SDK using a Makefile.
  10. Interop with AIA
    • IBM joined the AIA. Rich Schwerdtfeger is on the Steering Committee. Doug Geoffray from GW Micro is also a new member on the Steering Committee.
  11. IA2 issues from Calvin Gaisford, opened on the behalf of AIA. There is a new comment below for issue 114. See the second bullet under 114.
      • Issue 112: Commentary was added to the IDL.
      • Issue 113: This will probably remain as is.
      • Issue 114:
        • Microsoft attached the IAccessibleEx specification to the bug log. This spec is protected under the "UI Automation Specification and Community Promise". Pending review by Andy Updegrove.
        • 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.
      • Issue 115: Input is needed from Microsoft. This would probably be a version 2 issue.
      • Issue 116: Commentary was added to the IDL.
      • Issue 117: Input is needed from Microsoft. This would probably either be a version 2 issue or remain as is.
      • Issue 118: Commentary was added to the IDL.
    • Inter-organizational cooperation
      • UIA and UIA Express are now being developed within the AIA.
      • IA2 and ATK/AT-SPI are being developed within the Linux Foundation Open Accessibility workgroup.
      • How should Open A11y collaborate with AIA (Accessibility Interoperability Alliance)?
  12. Proposal for access to misspellings, grammar errors, and "smart tags"
    • Oliver-Rainer Wittmann from Sun sent email describing an interface proposal for access to misspelling, grammar errors and "smart tags".
    • Pete sent a note to the OpenOffice team (and the JAWS and Orca teams) suggesting that rather than creating a new interface, IAHypertext and IAHyperlink can be used. This is what Symphony has done. That note contained the following example:
      If the paragraph contained all of these (link, misspelled, smarttag, and grammar error) and they were all overlapped and the caret was at a point where they all overlapped there would be 1 hypertext and 4 hyperlinks and n actions for each hyperlink with each set of actions specific to the kind of hyperlink (link, misspelling, smarttag, grammar error). Even though the AT wouldn't be able to distinguish between the four uses of these interfaces, I believe the user would know what to do based on the action names and descriptions. And that's considering the case where the AT decides to expose the function using those interfaces and through a special AT UI. I suspect that most ATs will choose to not use these interfaces but will choose to let the user access the function through normal keyboard/AT access to the context menu, i.e. the menu activated with Shift + F10. (But apps should still implement IAHypertext/link because some ATs will want to use those interfaces.)
    • It's not clear to the NVDA team that interfaces are the best solution for an AT. The following notes are from during and after the prior IA2 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.
  13. Items raised by NVDA last year need to be put on the agenda for an upcoming Open A11y meeting
    • These are generic issues that need to be solved for both IA2 and ATK/AT-SPI dealing with objects contained in documents and tables
    • See items 4 and 5 in the October 2nd minutes for the history.
    • This was discussed during the January 22 Open a11y meeting.
    • These should be reopened and discussed with Willie and Li Yuan at a call convenient to the US, China, and Australia.
  14. Access to document revisions - from the ODF AccSC
    • This was reviewed and approved by Li Yuan the committer for ATK/AT-SPI. This will next be reviewed by the AIA. After that Li 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( IA2RevisionAttributes *attributes );
 
// 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

  1. IA2 text attributes specification.
    • Pending implementation in Firefox 3 and Symphony 2.
  2. IA2 proxy DLL and the USB key fob problem - can't run NVDA and FF3 on USB stick.
    • See this post to the IA2 list for more detail.
    • Marco opened a bug against FF3.
    • Symphony has already removed installation of the DLL as per the prior agreement but can add it back in around the August time frame.
    • Need a guideline document, linked to from the front IA2 page.
  3. Eclipse
  4. Wikipedia
  5. 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.
  6. Oleacc.idl
    • No new status on when it will be back in the SDK.
  7. FAQ


[Article] [Discussion] [View source] [History]