Raw minutes from 24 Feb UA Guidelines teleconf.

WAI UA Teleconf
24 Feb 2000

Jon Gunderson (Chair)
Ian Jacobs (Scribe)
Dick Brown
Gregory Rosmaita
Mickey Quenzer
Harvey Bingham
Mark Novak
Hans Riesebos
Jim Allan
Rich Schwerdtfeger
Denis Anson
Kitch Barnicle

Next meeting: 1 March

Agenda [1]
[1] http://www.w3.org/WAI/UA/2000/02/wai-ua-telecon-20000224.html#agenda

1) Continued Action Items

   No change on any of these:

    1.IJ: Propose checkpoint to address event notification timing issue 
    2.JG: for 5.3: Find out windows/mac accessibility guidelines. 
    3.JG: Check with Ian about adding reference in 
          4.5 to 4.6 in regard to stepping through
animation/video/audio. 
    4.DB: Ask IE Team about publication of review of IE 5 and 
          Pri 1 checkpoints. 
          Status: notes have been lost and are being reconstructed 
    5.JA: Rewrite techniques for 3.3 (see minutes) 
    6.MK: For 4.8 check if any media players do this? 
    7.MK: Find out techniques for sending text search 
          requests to servers of streamed text. 
    8.MR: Review techniques for topic 3.1 (Multi-media) 
    9.MR: Review techniques for Guideline 4 (Multi-media) 
   10.MR: Run a multimedia player through the guidelines for January. 
   11.RS: Take timely and synchronization issues to WAI PF. 
          Get input from MSAA developers as well. 
          Craft email to PF WG with Ian 

2) Adoption of Ian's wording for general access to content
     
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0347.html 

   Resolved: Add this checkpoint, but say "access to content" only
    (don't emphasize "write"):

       <BLOCKQUOTE>
       Provide programmatic access to content using standard
       APIs (e.g., platform-independent APIs such as the W3C DOM, 
       standard APIs for the operating system, and conventions 
       for programming languages) [Priority 1] 
       </BLOCKQUOTE>

   HB: Is it a problem that there is not a closed set of standard
       APIs?

   RS: Do we want to say "standard or published"?

   JG: Express preferences in the document:
      - Expose information through accessibility APIs that are
        platform specific.
      - Use formats based on XML.

3) Continue discussion of Jon Gunderson's Proposal to Resolve #190 and
#203
     
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0359.html
      Issue CR#190: Reduce the scope of 5.1 to say "write access only 
      for that which you can do through the UI."
      http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#190
      Issue CR#203: Checkpoint for access to content for non-HTML or 
      non-XML WWW documents (i.e. Shockwave) 
      http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#203 

   Resolved: Replace 5.1 with:

    Provide programmatic access to XML amd HTML content by 
    conforming to the W3C Document Object Model (DOM) level 2 Core and 
    HTML module specifications and exporting interfaces defined 
    by those modules. [Priority 1]  

   IJ: How do you define export? What's the scope of export?

   IJ: Is content source content or rendered content?

   Action IJ: Find out whether rendered content from style
              sheets appears in the document source.

   /* DOM Level 2 CSS Module */

   JG: Do we add a checkpoint to access style sheet information?

   JG: May be useful since the AT may want to access style sheets
       that aren't used by the user agent.

   RS: I think that this is important. For example, suppose you had an 
       audio style sheet and the browser doesn't support it. You
       should be able to navigate the DOM and attach style.

   IJ: Pseudo-elements are not in the DOM tree.

   IJ: ATs definitely need to know 'display: none', for example.

   RS: You might want to set high contrast through the AT.

   IJ: But you also need to be able to do this through the
       browser's UI.

   IJ: I'm not convinced of the need to write styles. I see
       the need for computed property values since the AT
       doesn't know the browser's default value.

   IJ: This is tricky. We've talked about searching on rendered
       content. This is source + style sheets + user settings.
       So you need more than the source tree.

   RS: Add caveat that if a browser support style sheets it
       needs to do this.

   JG: That's part of the applicability clause.

   DA: Should we have generic language that requires access to the
       rendering structure?

   JG: I'm afraid to refer generically to the rendering structure.

   IJ: 
      a) You want to know what the host browser has rendered.
      b) You don't want to depend on that rendering.

   IJ: I think that the CSS DOM is not required for access by ATs
because they either should apply style sheets themselves, of if they
are relying on the rendered content, the access to style doesn't
matter. I think you need access to style sheets, but not to edit them.

   HR: Suppose I'm interested in rendered data. When I change the
style sheets, I can make links stand out in some special way. I might
want to change the style sheet to see that the rendering is a
particular.

   IJ: The browser needs to allow this through user style sheets. But
   you don't need to do this through the AT (programmatically).

   IJ: In short: You need the style sheets, but I don't think you
       need the DOM CSS module. 

   RS: Have a general requirement that for other supported DOM
       modules, to export the information.

   JG: Do we need a requirement that the AT have access to what's
       really being rendered? There's an issue of computation
       time required by the AT to come up with a rendering structure.

   MQ: There may be contexts where you want the source (plus style
       sheets) and some where you want the rendered structure.

   IJ: How do you provide access to what's rendered?

   HR: Today, an offscreen model is used. 
       How would programmatic access to the rendering structure
       help ATs? If the AT only gets the full content, it has
       to do its own rendering and becomes a full user agent.

   DA: Can we talk about being able to write a style sheet?
       The Kurzweil 3000 is a screen reader/scanner for reading
       disabilities. Something that works well: having a word
       spoken and highlighted in the rendered document. Thus,
       the AT would like to have access to the rendered structure.

   RS: One of the things the DOM WG is considering for DOM 3 is the
       concept of views. Related to rendered content. Maybe we
       should leave this until then.

   JA: VIP Infonet already does this.

   IJ: Style sheets and rendered content are distinct.

   JG: I think that the CSS DOM module should be added as
       a P3 requirement to allow ATs to know what was rendered.
       (For those UAs that implement CSS). This will allow
       synchro between what was rendered visually and another
       rendering (e.g., speech).

   IJ: I have doubts.

   Resolved: Add the following requirement

   Provide programmatic access to style sheet content by conforming to 
   the W3C Document Object Model (DOM) level 2 StyleSheet and CSS module
   and exporting interfaces defined by that module.
   


-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel/Fax:                     +1 212 684-1814 or 212 532-4767
Cell:                        +1 917 450-8783

Received on Thursday, 24 February 2000 15:36:27 UTC