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

Raw minutes from 12 October UA telconference

From: Ian Jacobs <ij@w3.org>
Date: Thu, 12 Oct 2000 16:07:12 -0400
Message-ID: <39E619F0.232752FD@w3.org>
To: w3c-wai-ua@w3.org
12 October 2000 UA Guidelines Teleconference

 Jon Gunderson, Ian Jacobs, Gregory Rosmaita, 
 Mickey Quenzer, David Poehlman, Kitch Barnicle, Eric Hansen,
 Charles McCathieNevile, Rich Schwerdtfeger

Regrets: Tim Lacy, Jim Allan, Harvey Bingham

Absent: Denis Anson

Next meeting: 19 October

Minutes of previous meeting 10 October:


    1.FTF meeting update and call for participation

      MQ: I will probably attend by phone due to costs.
      DP: I'll be commuting from my house every day and
          have room to put someone up.
      JG: We have 9 confirmed (three by phone), 
          3 regrets, and 3 maybes.
      DP: Are there any people we haven't heard from?
      JG: Rich and Denis.
      DP: Will AOL participate?
      JG: No confirmation yet.
      MQ: I'll talk to someone from VidPie.
      Resolved: No objections to having a meeting with 9 people. 

    2.Review list of invited last call reviewers
      JG: Still looking for multimedia companies.


    2.Proposed Simplification of Checkpoint 8.7

    Resolved: Adopt proposal.

    8. Delete G9

      - Move 9.1 to G4
      - Move 9.2, 9.3 to G8
      - Recycle G9 prose

    9. Delete document source
    GR: I think that people might have an easier time understanding
    "document source view". 

    EH: One possibility is to say in the document object view
    definition that people may call this a "document source view".

    MQ: Perhaps too close to "document object model".

    IJ: I would argue that fewer terms will make it easier to use.

   CMN: Given that "view source" and "show source" is a well-known
        name of a feature, I recommend with not defining it and
        leaving it there.

    IJ: What's the difference between document source view and
        document object view?

   CMN: The document object is constructed from the source.
        The common understanding is that source view means 
        what came over the wire.

    EH: I think that with "document source view" in the UA Guidelines,
        there's a conceptual mismatch between checkpoint and the
        Note. The Note talks about source, the checkpoint talks about
        document object.

    IJ: Document object includes source.

    IJ: Another proposal is to just use "document object view"
       and talk about variance (e.g., from doc source to more than

    EH: And say that there is value in providing a view of the source.
      - Leave "document source view" in 2.1 and in glossary
      - Add to definition of "document source" that it's a subset of
        the "document object".

    3.Definition of User Agent

      GR: There's a difference between a composite user agent and
      one that conforms natively.

      DP: Works for me. Makes the guidelines easier to use.

      GR: All the components of a composite claim must meet the
      requirements that apply to it. 

      /* Discussion that claims are made about a collection of things */
      Resolved will dissent from GR and MQ:
       - Accept proposal and amended proposal

    4.Scope, Intro, Inside/Outside Analysis

     IJ: Summarizes EH's proposal, and EH and IJ prioritization
         of some topics.

     MQ: My problem with a list of things we aren't going to talk
         about is that some people may feel left out.

     DP: Fix that by pointing those readers to relevant sources
         of information.

     GR: On the assumption that we're dealing with WCAG-conformant
         content: people have not been waiting for this after three

    CMN: I don't think that this document assumes in all cases 
         WCAG-conformant content. 

     GR: The UA needs to override shortcomings.

     JG: Most of the checkpoints don't depend on WCAG, but we
         built some of them based on WCAG requirements.

    CMN: Does it hurt us to put in "dependency on WCAG-conformance

     GR: The first principle is do no harm. 
     EH: I think that we have made a number of assumptions along the
         way in order to make the scope of the document manageable
         as well as to meet accessibility requirements. If we don't
         state that we expect WCAG-conformant content, then it opens
         the floodgates of potential repair issues. It makes us
         more responsible for repairing bad authoring. I think there
         are valid reasons not to tackle that.

     IJ: We have not emphasized repair functionalities.

    CMN: I think that it's not true that we've avoided repair
         in content.

     GR: Document not useful if it expects all conformant content.

    CMN: To say that this document assumes wcag-conformant content
         will undermine its credibility.

     IJ: I propose:
        - Designed with some WCAG requirements in mind
          (to promote authoring of conformant content).
        - Looks forward (e.g., conformance to specs required)
        - There are some repair requirements built-in.

    CMN: I think this is editorial...

     EH: Are we satisfied with the amount of repair that we
         have in this document? 

     DP: I'm hesitant to soften the wcag language because we
         want to promote wcag-conformant content.

     Resolved to add scope prose along the lines of:
        - Designed with some WCAG requirements in mind
          (to promote authoring of conformant content).
        - Looks forward (e.g., conformance to specs required)
        - There are some repair requirements built-in, and
          techniques as well.

     Who has read the 29 Sep draft: IJ, CMN, JG, EH, DP.

     Resolved: Editors will filter out editorial proposals in:

    5.Repair Text, Definitions, Etc.

       - Adopt EH's 1.5 wording.
       - Repair content could be in the DOM, but not required. No
         statements about whether DOM repaired before-load/after-load
         etc. [
       - Adopt suggestion 4 (2.6: do not generate repair text).
       - Add support, implement, and conform to the glossary.

    GR: I think that 2.6 should include a requirement to generate
        repair content when configured to do so.

    DP: If the author specified empty alt, then there may be
        something behind it.

       - Add configuration requirement to 2.6 so that the
         UA generates repair text  la checkpoint 2.5. (repair).

    6.Conformance Claim and keyboard API support
      RS: Due to target of this document, no problem with this.

     CMN: I don't see that this is necessary.

        - Even if there isn't a standard system keyboard API, 
          the subject must implement some keyboard API.

      Action CMN: Send comments about whether a keyboard API
          always necessary.

    7.Revised Abstract

Other proposals:

   10. APIs standard?

Decision to go to last call:

   IJ: Note that Tim Lacy has already agreed to go to last call.

   Agreed: CMN, EH, DP, KB, GR (with reservations but don't want
      to hold up the process), JG, RS, IJ, MQ.

   Resolved: The WG agrees to go to last call with modifications
      to the 29 September draft indicated above.

Completed Action Items

    1.IJ: Propose text for a note explaining the implementation issues 
    related to providing user agent generated content through the DOM

    Status: Done in techniques document, but I will check.

    4.JG: Talk to Ian about adding a column to the impact matrix for 
    supporting authors in creating accessible content

    GR: Most authoring tools let you look at sample rendering.
    EH: Sounds like validation and repair. We don't have much about
        that today. 
    IJ: I think that impact matrix should only say "this checkpoint
        is meant for this type of disability".

    Status: Dropped.

Open Action Items

    2.KB: Submit technique on providing information on current item and 
    number of items in search

    Status: Not done.

    3.RS: Send information (if you can) about tagging for information
    improving performance

    Status: Unknown.

    5.EH: Will propose text to be added to the guidelines document to 
    discuss the scope and the limitations of the current document

    Status: Done.

    6.TL: Check with Microsoft Multi-media group to find a reviewer

    Status: Unknown.

    7.TL: Check to see if MS can send representative to FTF meeting

    Status: Unknown.

    8.GR: Contacts for Dolphin for reviewing UAAG.

    Status: Not done. Intend to call today.

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:28 UTC