The Linux Foundation


From The Linux Foundation

Revision as of 16:56, 28 July 2008 by Ptbrunet (Talk | contribs)

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

Agenda for 2008/07/29

  1. Introductions if needed
  2. Approval of minutes - Corrections? Approval?
  3. LF: Open A11y news - Janina
  4. AccProbe inspect tool - Mike Squillace
  5. Firefox - Marco Zehe
    • Firefox 3 is implementing text attributes. This is being tracked with bug 340809.
    • References:
    • Static text:
      • For Firefox this is text generated by the browser such as number and bullet prefixes in lists, and possibly in the future, things like tables of contents, indexes, footnotes, etc. This is bug 445516. Symphony will use the currently specified list attribute. For Symphony, tables of contents, indexes, footnotes, etc. are handled as any other kind of text.
      • Firefox would like to expose list prefixes (numbers, bullets) as an attribute named "static" rather than as a list attribute like Symphony does. Other examples of static text are footnote references and text inserted via CSS before/after.
      • Last week we discussed the following:
        • Should the attribute name be changed? Static text implies readonly text but we are talking about caretless text. The name "autotext" is one proposal (for automattically generated text).
        • There are three cases
          1. can move caret through text, i.e. the common case
          2. can only move caret to the first character, e.g. a date field in Symphony
          3. can't move the caret at all, e.g. list item bullets/numbers
        • static:all, static:first, static:none could be used for these cases.
        • Is there a use case where those three attribute values are needed?
        • Is there a reason, other than development convenience, that using the list attribute/subattribute concept won't work?
          • The lower development cost of implementing static text rather than list attributes might justify having two means of implementation. It's an extra cost for ATs to implement two means for accessing lists, but there will be more apps than ATs.
  6. IAccessibleText::caretOffset
    • From Mick:
      If you ask for the caret offset of an object that does not currently contain the caret, what should IAccessibleText::caretOffset return?

      Personally I would like it to return -1.

      Lotus Symphony does this, but Gecko seems to return something like nCharacters -- the offset past the last character in that object.

      It is very important for an AT to quickly find out if this object has a usable caret or not, especially with documents represented with multiple objects where the caret can jump between them.

      Once we come to a consensus it would be great if it could be noted in the documentation for IAccessibleText::caretOffset also.
    • From Pete:
      • The following paragraph is in the General Information, Error Handling section of the IDL notes:
        Note that the S_FALSE return value is considered a non-error value and the SUCCEEDED macro will return TRUE. S_FALSE is used when there is no failure but there was nothing valid to return, e.g. in IAccessilbe2::attributes when there are no attributes. When S_FALSE is returned [out] pointer types should be NULL and [out] longs should generally be 0, but sometimes -1 is used such as IAccessible2::indexInParent and IAccessibleHypertext::hyperlinkIndex.
      • The IAccessibleText::caretOffset currently only documents the S_OK return code, but to be consistent with the rest of the documentation the following should be added:
        S_FALSE if there is nothing to return, [out] value is 0
      • We may have to change that to -1 because of the limitation of the Python runtime environment not being able to sense the S_FALSE HRESULT.
      • In most cases the use of -1 has not been needed for the Python environment when S_FALSE is returned because the condition can be detected via the return parameters, but in this case since there is only one return parameter and 0 is otherwise valid, -1 may have to be used to signal this condition.
  7. IA2 1.0.2 review period has completed.
    • Pete implemented the changes in library statement as requested by Jamie.
      • use of enum for states
      • removal from the library statement of IAccessibleEventId, IAccessibleRole, and IAccessibleStates
      • Addition of enums for IA2CoordinateType, IA2EventID, IA2Role, IA2ScrollType, IA2States, IA2TableModelChangeType, and IA2TextBoundaryType
        • Is one needed for IA2TextSpecialOffsets?
      • Addition of structure tag names
    • Remaining work items:
      • There is a bug in doxygen 1.5.6 where the detailed descriptions are not in alphabetical order.
      • Complete rework of HTML to meet Open A11y guidelines. Gregory will merge his changes into the latest CSS file.
      • 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.
  8. Proxy DLL
    • Once Pete sends Jamie the latest IDL he will attach the NVDA proxy DLL to bug 110.
    • When the 1.0.2 files are added to BZR, Pete to include the files needed to build the proxy 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.
    • That wiki page probably needs other changes.
  9. Access to spelling and grammar errors
    • The OpenOffice team would like to solve this with a new interface. Oliver-Rainer Wittmann from Sun sent email some time ago describing an interface proposal. However, the NVDA team (and likely other ATVs) feel the most natural fit from a AT perspective would like to solve this with text attributes. The Firefox team is, at least initially, in favor of using text attributes.
    • In some cases using text attributes would require a bit of processing, e.g. when the substring associated with a lengthy grammar error also has a number of text attribute changes such as font face or font weight changes. Is this an issue?
    • A major issue is that internally OpenOffice doesn't maintain the error information as attributes so would have to always manufacture it. Also OpenOffice doesn't have any events that can be fired as the caret moves across the boundaries of spelling and grammar errors.
      • Aaron sent the following to Malte:
        I don't know if this helps, but Mozilla actually has to combine 4 kinds of attributes:
        1. Spell check (internally in Mozilla this is implemented using a selection with a type that causes a red squiggly line)
        2. DOM-based attributes (for now, just lang, but more in the future with WAI-ARIA)
        3. Whether text is static text (the a11y hierarchy tells us this)
        4. CSS-based text attributes (formatting)
        The algorithm Surkov (CC'd) used in Mozilla does a clean job of combining the attributes to get the range at an offset.

        He just starts with the first range, and as each range is computed, it can never increase the size of the range. The start offset can only stay the same or get larger, and the end can only stay the same or get smaller.

        We believe this is a good solution to combine multiple sources of text range information.
      • A meeting will be set up between the FF and OOo teams to work on this issue.
    • In a browser, ARIA provides for various reasons that a range of text could be invalid -- "spelling", "grammar", or "true" (the general case where data isn't valid in a particular context), for example in the case of an input tokenizer processing a list of email addresses separated by commas and one of the email addresses is incorrect. Are there any IA2 issues that need to be addressed?
  10. 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?
  11. 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?
      • How are comment only revisions handled?
      • Probably need more kinds of format changes besides insertion, deletion, and format change.
      • Use cases are needed.
      • getSegmentAtOffset (singular) needs to be getSegmentsAtOffset (plural) because unlink links there could be overlapping insertions and deletions.
    • Once these issues are resolved Li Yuan, the committer for ATK/AT-SPI will develop a patch.

enum IA2RevisionType {
  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;

// 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 );

// 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 issues from Calvin Gaisford, opened on the behalf of AIA.
  2. IA2 object attributes specification.
      • 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 add a "display" attribute with CSS2 values.
  3. 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.
  4. Eclipse
  5. Wikipedia
  6. 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.
  7. Oleacc.idl
    • No new status on when it will be back in the SDK.
  8. FAQ

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