W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2000

Raw minutes from 13 April teleconference.

From: Ian Jacobs <ij@w3.org>
Date: Thu, 13 Apr 2000 15:40:37 -0400
Message-ID: <38F622B5.4B469EC4@w3.org>
To: w3c-wai-ua@w3.org
WAI UA Teleconf
13 Apr 2000

 Jon Gunderson (Chair)
 Ian Jacobs (Scribe)
 David Poehlman
 Jim Allan
 Gregory Rosmaita
 Harvey Bingham
 Madeleine Rothberg

 Mickey Quenzer 
 Mark Novak
 Kitch Barnicle
 Rich Schwerdtfeger	

Next teleconference: 20 April

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

1) Announcements 

1a) Progress

  12.GR: Look into which checkpoints would benefit from 
         audio examples in the techniques document. 
         GR: Any example given for a self-voicing browser. 
             Still seeking tech assistance for capturing voiced output.

  13.GR: Review techniques for Sections 3.7 and 3.8 
         Status: Working on a technique proposal.

  14.GR: Send to list screen shot of JFW Window list. 
         Status: I have the screen shot. Will send.

  17.JG: Identify the minimal requirement for each checkpoint. 
         Status: Started

  18.HB: Take scoping issue of the current guidelines to the EO working
         Status: Sent to UA WG. Will send to EO tomorrow.

  20.MR: Talk to Geoff Freed about implementations that slow down
         multimedia presentations. 

1b) No progress

   1.IJ: Draft a preliminary executive summary/mini-FAQ for
         developers. (No deadline.) 

   2.IJ: Propose three terms to the list: Document Source, Document
         and Rendered Content 

   3.IJ: The content/ui division in G1 needs to be fixed 

   4.IJ: Actions from FTF meeting 

   5.CMN: Find out from I18N how to generalize the accessibility
          by sans-serif fonts. 

   6.CMN: Propose a technique that explains how serialization plus
          navigation would suffice for Checkpoint 8.1. 

   7.DA: Send name of new organization to list that was mentioned by
         from the US Census Bureau 

   8.DA: Review techniques for Guidelines 7 and 8 

   9.DB: Get Tim Lacy to review G+ 

  10.DB: Review techniques for Guidelines 3, 4, and 11 

  11.DP: Review techniques for Guidelines 1 and 2 

  15.JG: Write email to the list asking for information about which user
         groups require the ability to slow down presentations 
         othewise access it impossible. 

  16.JG: Take conformance grandularity issue to the WAI CG. 

  19.MQ: Review techniques for Guidelines 9 and 10 

  21.RS: Take notification of focus and view changes to PF as possible
         3 requirement. 

2) On the FAQ.

   Action HB: Ensure that EO documents their commitment to 
              to the FAQ.
   DP: We might want a FAQ for the users.

   JG, IJ: Let's wait for EO proposal before we draw up any other

3) Announcements

 1.FTF for Evaluation and Repair Tools working group in Amsterdam

 2.Notice of Proposed Rulemaking: Electronic and Information Technology
   Accessibility Standards by the United States ARCHITECTURAL AND
   May 30th

4) Update on proposed Rec.

  IJ: Keep resolving those issues!

5) Open issues after ftf

5.1) Issue 207

     Refer to summary of 6 April minutes on "where we are":

     IJ: I understand the open issue to be whether 2.1 scope should be
         reduced to content for humans or left at "all stuff".

     CMN: Human-readable content through the UI 
          is part of a minimal requirement for conformance to 2.1.

     GR: I think the scope should be "all", not human-readable only.
     DP: I'm still not sure what's lost if we don't include machine

     IJ: I think that the UA should use machine content to do repair
         strategies, but that it should not be required to do so.
    CMN: I think that if the user has access to all the content, then
         the user can make repairs the UA couldn't make.

     JG: Is this a requirement only for markup languages, or
         also binary stuff?

    CMN: Good question. It's harder to use a GIF image in source mode.
         But I would continue to require them.

    CMN: There's no requirement that if you make content available
         through the UI that you also have to make it available
         through some other means. There is no statement about 
         how many times you must make content available.
       a) Everything has to be available.
       b) Things for humans must be available through the UI
          (not through a source view).

       In the real world:
       c) There's no requirement for a source view. It will
          meet requirement for things meant for machines.
          However, if all the information meant for machines
          is rendered somehow through the UI, then no other
          view required.

     IJ: I disagree that the user needs to know that "id"
         is there.

    CMN: Rendering is not sufficient. 
         You need to make available the fact that the content
         is styled by "id". You need an interface that lets
         you do everything you can do with an id.

     IJ: But the "id" value is not required. What about a processing
         instruction at the top of an XML document? I think that
         we're talking about processing, and the effect if what's
         important to the user, not the PI itself.

    CMN: I would agree that that's an edge case.

     IJ: What about the fact that all info is available through
         the API?

    CMN: Not sufficient.

     HB: I want to be able to view all the content, including the
         META information.

     JA: I think I agree with HB.

     DP: I don't see the validity, for the general user, of
         having binary available to the general user.

     JG: This machine stuff could be useful, but there's no

     IJ: Suppose a user agent doesn't support PNG, must it
         make it available?

    CMN: No, only the URI to the PNG.

     IJ: For those things not made available through the UI,
         what's the minimal way to satisfy the other stuff?

    CMN: A source view would meet the requirement. But the 
         minimal requirement would not be for a source view.

     IJ: Why is this checkpoint different from other checkpoints
         that allow some information to be handled through an

    CMN: We should require native support for access to
         all content.

     GR: In the case of rendering things natively, whether you
         need to view binary: Lynx exposes the alternative or
         puts in a place-holder - you can turn anything it can't
         render natively into a hyperlink.

    CMN: Lynx gives you access to applicable content, otherwise
         gives you access to things it can't deal with (through 
         a link).

     IJ: Should we adopt similar wording as ATAG about the "average
         user"? That is, that the user is not expert. I have a problem
         with P1 access to information that is not meant for humans
         and will not be useful to most users. I do agree with
         Charles, however, that if some of that "content" is not
         available directly to users, it may not be accessible.

    DP: What does it mean to "make available" information?

    JG: Originally, some things through the UI and some through an

      2.1.a: Ensure that the user has access to all content meant for 
             human consumption, including equivalent alternatives for 
             content, through the user interface.
             Note: A source view does not meet this requirement. P1

      2.1.b: Ensure that the user has access to all content meant for 
             machines either by processing it according to
             specification or by making it available directly to the
             user through the user interface.
             Note: A source view would suffice to meet this

       IJ: Clearly 2.1.a a P1.
           I agree with the first half of 2.1.b as P1, but
           not sure about priority of second half since information
           is available through an API. I'm not sure that the source 
           view would provide access to most people; I've heard people 
           say that most users would not be able to use this

      Consensus: The split is reasonable, as long as it covers
                 the requirements.

      GR, CMN: Unfortunately, people count the numbers of P1s. Also
               consistency with current PR.

      IJ: I think both should be sacrificed for the sake of clarity.
      JG: We've missed something if we've said that the other
          checkpoints don't cover the accessibility of the user
          interface and you need a source viwe.

      IJ: This can be seen as a way to catch thigns that we've missed.

     CMN: (Use case) I went to a Web site. The URI you could
          use to get to the site started with "javascript:". The
          only problem with my user agent was that it didn't support

      IJ: If you don't support javascript, then applicability kicks

     CMN: But it's in HTML, which is supported. The UA can either
          provide some form of access or tell me to buzz off. 

      IJ: Sounds like you're requiring minimal repair strategy
          is native support for source view.

      JG: Sounds like what I'm hearing mostly is that 2.1.b is
          not to improve accessibility of the user agent, but
          to repair broken content or deal with (in)applicability.
          We have another repair checkpoint (2.3). Do we need
          another guideline for repair?

      JA: UAs have already repaired broken content. It's one
          of their primary duties.

     CMN: I think the document's already too big. I don't
          want another guideline.

    Action IJ: Propose split to the list. Identify why and
               issue of priority.

5.2) Issue 208

     HB: I think we have to be careful about form submit buttons
         that aren't obvious.

     GR: I think this should be addressed in the techniques document.

     No objections to proposal:

     Action IJ: Adopt wording of proposal.

Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783
Received on Thursday, 13 April 2000 15:40:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:26 UTC