Raw minutes from 6 January UA Guidelines Teleconf

WAI UAGL Teleconference
6 January 2000

Participants:

Jon Gunderson
Ian Jacobs
Kitch Barnicle
Harvey Bingham
Gregory Rosmaita
Dick Brown
Denis Anson
Jim Allan
Mickey Quezner
Marja Koivunen
Rich Schwertdfeger

Regrets:
Charles McCathieNevile
David Poehlman

NEXT MEETING: 12 January 2000

Agenda [1]
[1]
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0018.html

1) Review Open Action Items

   1.IJ: Draft a statement for time of publication, there is no
         authoritative body that validates claims of conformance 

   Pending

   2.IJ: Repropose the delivery mechanism of conformance statement to
allow
         documentation as an option 

   Pending

   3.IJ: Propose a technique for using XSL to transform content 

   Done
   http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0030.html

   4.IJ: Follow up on EH's e-mail with some comments from this meeting
         related to issue LC#138 (will post as new issues if any) 

   5.IJ: Publish a new draft of requirements document that incorporates
         JG'sand other comments. 

   6.IJ: Send this resolution of issue LC#158 to the list for
         comment. 

   Done
   http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0020.html
   Objections from JG, DP.     

   7.JG: Review techniques for Guideline 8.3, 8.4, 8.6 to 8.9 

   Done (or almost).

   8.JG: Draft a preliminary implementation report for CR
         consideration 
 
   Not Done.

   9.DA: Identify the general items that apply to all software from ones
in
         the current list in Ian's requirements proposal. 
   
   Done
   http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0028.html

  10.DB: Ask IE Team about publication of review of IE 5 and Pri 1
         checkpoints. 

   Pending.

  11.DB: Find out how developers find out which appropriate triggers to
use
         in Windows for using built-in accessibility features
         (i.e. sound sentry, show sounds, ...) 

  12.DP: Propose new Checkpoint 1.5 for access to system messages 

  13.GR: Send to the list techniques for how to use and control focus to
         not have new windows cause problems for usability. In
         particular, how this will work with ATs. 

  14.GR: Write a technique on how to create accessible installation
     Satus: May already be integrated. 

  15.MR: Review techniques for topic 3.1 (Multi-media) 

  16.MR: Review techniques for Guideline 4 (Multi-media) 

  17.MR: Run a multimedia player through the guidelines for January. 

  18.MQ: Ask Mark about meaning of comment raised in Issue #167 

  19.RS: Send editorial comments on Ian's proposal. 

  Done
  http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0029.html

  20.WC: Take form submission to GL WG to discuss issues related to
         inadvertent submission. 

  Pending

  21.EVERYONE: Review the "Unknown" category of Ian's proposal and we'll
     discuss them at tomorrow's meeting. 

  Done.

2) Announcements 

   1.Extra UA telecon scheduled 12 January 2000 at 12:00 pm to 1:30 pm
Eastern
     Standard Time, USA 
     http://www.w3.org/WAI/UA/2000/01/wai-ua-telecon-20000112.html 

   2.Protocols and Formatting are holding a FTF meeting on 26-27 January
2000
     at Sun's Microsystem in Cupertino - Silicon Valley 
     http://www.w3.org/WAI/PF/Group/2000/01/agenda.htm 

Discussion 

   1.Ian's proposal for a rational document related to user agent
     accessibility responsibilities 
     http://www.w3.org/WAI/UA/1999/12/ua-resp-19991228

    DA: Recall, some of the "native" checkpoints apply to
        every app.
       
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0028.html

    IJ: I may implement DA's list with, e.g., an asterisk to indicate
        which ones may be system-wide. 

    GR: I think this info should be put in the Techniques document.

    KB: Don't forget that the UA may do it better than the OS...

    IJ: On to the "Unknown list"

    a) Checkpoint 7.3 Allow the user to navigate all active elements. 

       KB: Since we require device-independent access to active
           elements, I need to get at these with the keyboard. 

       KB: There's a debate on the "CHI" list about whether content
           brings interface. 

       GR: This fits in with the argument that UI provided by the
       author is on par with UI provided by the UA.

       Resolved: Navigation of active elements required because 
       these are user interface elements. If you can't identify
       an active element for activation, it's useless.
      
       Add to category "Requirements for content rendered natively",
       though it's UI in nature.
    
    b) Checkpoint 7.4 Allow the user to navigate just among all
                      active elements. 

       IJ: This is just a special case of 7.3 and so once 7.3
           is settled, this one will follow. 

    c) Checkpoint 7.5 Allow the user to search for rendered
       text content, including text equivalents of visual and 
       auditory content.

       DA: If the content is streaming and it hasn't arrived yet,
       is it available for searching?

       IJ: Searching is done in a time-independent manner.

       MK: You can interrogate the server of the streamed text.

       Action MK: Find out techniques for sending text search
                  requests to servers of streamed text.

       HB: Rendered text excludes many attribute values.

       Arguments: 
         a) UAs already do this.
         b) Searching is essential for people with disabilities
            and a convenience for all users.
         c) Users render the text content.

       Notes: NN, IE, Opera don't allow you to search for it today.

       Issue: Should searching equivalent text be an AT responsibility?

       KB: Is it an argument that because ATs do this today that
           means that mainstream UAs should not?

       RS: Suppose you have images turned on and search for alt
           text. You may confuse users by landing on the image.

       IJ: But the text isn't rendered in that case. The goal
           is that: as soon as any user has access to the content,
           all users should have access to it.

       Resolved: Create a category "The WG felt that this
       functionality is essential to users with disabilities."

    d) Checkpoint 7.6 Allow the user to navigate according to
       structure.
       
       Thoughts:
        a) User shouldn't have to understand underlying structure
           of a document to navigate it, but should be able to
           navigate. Thus details of "structural navigation" left
           ambiguous.

        b) No minimal requirement obvious except that navigation
           is required as an essential functionality, otherwise too
           burdensome to have to reread the page from top to bottom.

        c) ATs may provide specialized navigation, but some native
           implementation of navigation essential for access.

        d) Structure available through the DOM. The Guidelines should
           encourage navigation in a manner appropriate for the 
           rendering handled by the type of user agent being used.

       DA: If we say that you have to do something natively, we have
           to be able to say what to do.

       JG: This is closely linked to 7.6 for me. Like searching, it's
           a way to access content.

       JG: Structured navigation hasn't been a requirement for
           desktop user agents.

       IJ: 
         - Backwards compatibility issue? Require structured
           navigation until the DOM is available.

       JG: This functionality is useful for different media.
           Opera does this. Auditory browsers do this. We think
           that general purpose user agents should incorporate 
           these for general audience.

       IJ: Native structured navigation gets you part of the way
           for others.

       KB: Structured navigation will help some users with
           disabilities: low vision, motor impairments.

       Resolved: Essential functionality for some users with
                 disabilities (low vision, physical).

    e) Checkpoint 7.7 Allow the user to configure structured
       navigation. 

       IJ: This one follows 7.6 

    f) Checkpoint 8.1 Convey the author-specified purpose of each
       table and the relationships among the table cells and headers. 

       KB: The UA should convey all of the information specified by
           the author. I don't think we can ask the UA to go beyond
           what the author has specified.
 
       IJ: Agreed. This is a special case of "access to all content".

       DB: What does "purpose" mean? There's no "purpose" attribute?

       GR: Minimal satisfying of this checkpoint: tool tip of the
           "summary" attribute.

       Resolved: This is an important special case of access to
                 content.

       GR: (For the record, I think 8.3 (link info) should be P2).

       DA: As user agents start to render summary, etc. authors are
           more likely to provide the information.

       IJ: I think that it's important to make relationships inherent
           in markup available to all users, and developers may not
           realize this.

       RS: Does 8.1 mean through programmatic means?

       IJ: Not specified.

       Action IJ: Make clearer that this is "information provided
                  to the user."

       DB: I'm not sure this should be P1. This is a tricky one since
           I don't think it's impossible to get at the information.

       Summary:

       1) WG decided that table navigation was important, but could
          fall under general structured navigation provided that 
          table semantics be preserved in a checkpoint as a native
          requirement.

       2) This is important to render, whatever medium you're
          rendering to.

       3) Important for users with blindness, motor disabilities,
          and cognitive disabilities since you have to 
          memorize header information.

       IJ: In this case: 
         - Render to user in the way you're rendering (e.g.,
graphically).
         - Provide programmatic access (covered by DOM).

       (In short, IJ doesn't think a change necessary since rendering
        is always "However you render it...")
      
       Action Ian: Harmonize language in the spec so that a single
       expression is used to indicate "provide information to the user".
       (as opposed to programmatically). Indicate both explicitly
       when both.
      
       Resolved: Leave "unknown" for now.

    g) Checkpoint 8.5 Provide a "outline" view of content, built 
       from structural elements (e.g., frames, headers, lists, forms,
       tables, etc.) 

       DA: This is a P2. 

       Resolved: Essential functionality for some users that must
                 get through content serially or cognitive
                 disabilities.

    h) Checkpoint 8.6 Allow the user to configure the outline view. 
             This one follows 8.5.

    i) Checkpoint 10.3 Allow the user to change and control the
       input configuration. Allow the user to configure the user
       agent so that some functionalities may be activated with a 
       single command (e.g., single key, single voice command,
       etc.). 

       IJ: If native configs only, the issue is resolved (since
           configs provided natively).

       DA: You could have a macro program that intercepts your
           keystrokes before they get to the UA.

       Resolved: Required natively since it mostly addresses natively
                 provided functionalities.

    j) Checkpoint 10.8 Allow the user to configure the arrangement 
       of graphical user agent user interface controls. 

       IJ: This is a special case of 10.8. 

       Resolved: These controls are provided natively by the UA.

       Action IJ: Indicate that this is a special case of 10.3

Adjourned 15:38 ET

Received on Thursday, 6 January 2000 15:39:59 UTC