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

Raw minutes from 24 November teleconf.

From: Ian Jacobs <ij@w3.org>
Date: Wed, 24 Nov 1999 13:44:08 -0500
Message-ID: <383C31F8.14785FF7@w3.org>
To: w3c-wai-ua@w3.org
User Agent Guidelines
24 November 1999


Jon Gunderson (Chair)
Ian Jacobs (Scribe)
Kitch Barnicle
David Poehlman
Dick Brown
Charles McCathieNevile
Gregory Rosmaita
Marja Koivunen
Denis Anson

Mickey Quezner
Rich Schwerdtfeger
Mark Novak
Jim Allan

NOTE: Ian will chair next week. Jon back 7 December.

Agenda [1]

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0386.html

1) Review Open Action Items 

   1.IJ: Propose how the conformance checklist will be delivered 

   Proposed IJ: Suggest including a URI to all pertinent information.
                This would amend the "How to claim conformance" section.

   2.IJ: If W3C Comm Team develops a statement related to NFB vs. AOL, 
         keep the UAGL WG informed. 

   IJ: No Comm Team input.

   3.IJ: Review techniques for topic 3.2 

   IJ: Not done.

   4.IJ: Bring table header algorithm problem to html wg 

   IJ: Pending.

   5.JG: Review techniques for Guideline 8.2 to 8.9 

    8.2 Done.

   6.JG: Contact David Clark about UCP contact and personal 
         review the guidelines 

    Status: DC will review. Also Steve Mendelsohn (who is on
         the board) will also review the document.

   7.KB: Update impact matrix based on 5 November draft. 

     Status: Pending.

   8.KB: Review techniques for Guideline 7 

     Status: Partially done.

   9.RS: Send last call document to IBM's Web Team in Austin. 

     RS not here.

  10.JA: Review techniques for topic 3.1 

     Status: Done.

  11.JA: Review techniques for Guideline 4 

     Status: Done.

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

     Status: ?

  13.MR: Review techniques for Guideline 3 (Multi-media) 

     Status: ?

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

     Status: ?

  15.DB: Contact Dave Bolnick about SAMI accessibility features to
in techniques document and see if he would be willing to review the

     Status: Done.
     DB: He didn't think there was much that pertained to SAMI. But
         will take a look at it. Is anyone looking at HTML+Time?
         I'll ask him about that.

  16.DB: Review techniques for Guideline 5 

     Status: Done. I've also asked Tim Lacy to do a review. He'll 
             be back next week. I'll also send to the IE Team.

  17.DB: Contact person in Windows media group to agree to 
         review last call draft when available 

     Status: Pending. The IE Team may consider the Ian/Charles meeting
         at MS part of their review.

  18.CMN: Review techniques for Guideline 9 

     Status: Done/Dropped.

  19.CMN: Review techniques for topic 3.6 

     Status: Pending. Some email sent already.

  20.GR: Review techniques for topic 3.5 

     Status: Done.

  21.GR: Send example of using CSS pseudo element list 
         numbering using content tag 

     Status: Pending.
     IJ: Re links to middle of a document; Team seems to think
         this is a good idea.

  22.GR: Check if their is a css pseudo class for lang change in

     Status: Pending.

  23.HB: Send problem statement to the ua list and
         related to table header algorithm 

     Status: Done.

  24.MRK: Send proposal for configuration options for checkpoint 2.2.3
         the list, GR will help 

     Status: ALmost done.

  25.MRK: to send SMIL examples to the list of problems related SMIL
          rendering of time-dependent links 

     Status: Pending.

2) Face-to-face

   DB: I can't make it. Can I conference in?

   IJ: We could use IRC and possibly a W3C bridge.
   DB: MS could pay for the setup.

   Action JG: Talk to Rich about setting up teleconf.

3) Announcements:

   a) <strong>Today</strong> is the registration deadline for

   b) Teleconf scheduled for TUESDAY 7 December at 12pm (for 90 mins)
      We'll set the agenda for the ftf meeting at this teleconf.
   c) No teleconf 8 December (due to travel).

   d) We need to renew the bridge for the first quarter of 2000.
      Some suggestions to see the call moved to Thursday at the
      same time. Would start first week in January.

      CMN: I'll be in Australia. It would be a big help to me.
      DA: Much better for me.
      DB: No problem for me.
      IJ: Works for me.
      KB: May be a problem for me.
      MRK: May be a problem for me. Later better.

      Proposed time at 13:00 ET. 
      Action Jon: send to the list.

4) Issue 114

   JG: Rich isn't here, I'd rather hold off on this.
   DA: Any language that would refer to the most recent DOM REC
       should be ok.

   We will wait until Rich is on the call.

5) On incorporating techniques

   CMN: In ATAG, we decided on a model that unless someone complained
        about a technique, it made it into the document.

   IJ: That's the way I've been working on the techniques.

   GR: We are anticipating a final techniques review?

   IJ: What form would that take? I think a teleconf doesn't work.

   IJ: I propose:
     a) Ask for review
     b) If no objections, I'll just add and edit.

6) On incorporating editorial changes to guidelines

   IJ: Will there be a new GL draft for the ftf? I propose that
       we do, that take into account Eric's edits.

   Resolved: Ian will produce a new draft 6 December 
       for the ftf that takes into account suggestions from Eric.
       People can send comments/objections and we can discuss
       issues at face-to-face.

   DP: Comment on the introduction: In the bulleted list in
       the intro, put cognitive in the same group with visual, 
       auditory, physical. Might separate disabilities
       from universal access issues.

   IJ: Ok.

7) Issue 111      

   IJ: Eric Hansen thought 6.1 should be relative priority.

Issue #6: Checkpoints 10.1, 10.2, and 10.3 need restructuring and

   Proposed: new checkpoint "Provide single-stroke access
   to user agent functionalities".

   DA: Not enough keys to go around.

   DP: I think the proposal is too vague.
   KB: Do we want the UA developer to make the choice of
       what should have single-key access? Second level
       is allowing the user to make that choice? I worry about
       the case where the developer builds in a lot of 
       single key access and that the user inadvertently
       activates functionalities.

   MRK: You could have some single-key defaults.

   JG: Highlight in navigation section? for high-frequency

   GR: Point to common single-key defaults per platform (conventions).

   KB: What's an example of single key access? Is "Alt-F" a single

  CMN: In Opera, there are a lot of single-key ways to access
       functionalities ("F5") and Lynx.

   IJ: I don't think "Alt-F" is single key.

  CMN: Tricky on a smaller keyboard like Intellikeys or switching

   DB: What need are we meeting?

   JG: People with motor disabilities.

   DB: Single key can be tricky since so few keys. What can't
       Bryan do with current browsers?

   KB: Opera allows him to jump from header to header with a single
       letter key. 

   CMN: Or link to link in IE or Lynx.

   CMN: You need to be able to configure access. You may have
        a strong need to include single key access.

    IJ: That's what the current checkpoint 10.3 currently says.

    IJ: I think EH misunderstood the checkpoint text and
        based on that, I propose that we leave as is.

        From EH's comments:

           I feel that the _requirement_ for single-stroke
           changing of configuration is too restrictive.

        We didn't mean that configuration had to be single
        stroke but rather that one be able to activate
        important functionalities with a preferred keystroke.

    Resolved: Leave as is.

  Issues #7/#8:  Break checkpoint 6.1 into two separate checkpoints -
             and 6.1.B. 

    IJ: I understand this to mean "UA developers should implement
        what WCAG tells them to do."

    KB: The "until user agents".

    IJ: We already cover all the "until UA" clauses in other

    MRK: Having a generic checkpoint means less maintenance over time.

     IJ: I have some problems with future-looking checkpoints.
         "I can't forgive you for things you haven't done yet." 
         (Elvis Costello).

     DB: How can I miss you if you won't go away?

     CMN: If you can't live without me, why aren't you dead yet?
     /* End country western quotes */

     DP: If there will be a later version of UAGL, wouldn't it
         be better to evolve in a new draft?

    CMN: The ATAG does both: we say "Do what WCAG says." This
         ensures modularity. You don't want to have to 
         change one document everytime every other one changes.
         I think a new checkpoint is not a bad idea in principle.
         But you don't want to write too many blank checks to
         other working groups.

     JG: Is a redundant checkpoint a problem?

     Resolved: Action Ian to work with Eric on a proposal.

Issue #11: Change "closed captions" to "captions" throughout the

     MRK: I think the change is ok. We would need to define it.     
      JG: Any objections?

     Resolved: Use "caption". In definition of caption, make clear that
               in context, may refer to table captions not
               accessibility captions.

More minor:
 -  "Braille" or "braille"?
     GR: Capital "B" is the convention in print since derived
         from a proper name, although lowercase "b" also used.
         I think uppercase "B" would stand out more. Websters
         prefers capital "B".

     IJ: My issue is inconsistency with WCAG. Websters online
         shows small "b" preferred.

     Resolved: uppercase "B" is chosen since no objections.

 - Issue #13: Is braille accepted as a natural language? 

      GR, CMN: No. 

      IJ: What about contractions?

      GR: Braille is an abstraction. There are implementations
          with contractions.

      Resolved: Remove from defn of natural language.

 - Is braille also haptic?

   CMN: Yes. But refer to Al's comments. 

Issue #16. Eliminate the use of  "continuous equivalent track".

   IJ: EH proposes "synchronized equivalent" instead.
   IJ: Fits with WCAG. Any important info other than the
                       the synchronized part?
  MRK: I prefer "continuous" since it captures time-dependency.
   DP: I prefer "continuous" as well.
   JG: This refers to alternatives, you would want the
       content synchronized.

   Action IJ: Take "synchronized equivalent" to SYMM WG.

Issue #17. Simplify checkpoint 2.5.

   JG: We use "rendered" consistently.
   Resolved: Add "relevant". Use of "synchronized equivalent"
             pending SYMM WG feedback.

Issue #18. Handle "on the fly" auditory descriptions.
           This is a proposed new checkpoint to mirror WCAG 1.3

   IJ: EH wants a requirement to render text to speech within
       a year of a W3C spec on that topic.

   MRK: In what language?

   CMN: I don't think we should require this.
    DB: I think the expectation is that the system as a whole 
        will do this and the UAs will take advantage of those

   MRK: Does spoken text have to be synchronized? It's not easy
        to synchronize auditory descriptions. How do you synchronize

   CMN: This is very techniquey, but if your text if synchronized
        already, you can use that.
   MRK: But text sync is different than audio since you have
        to mix different audio tracks.

   MRK: My problem is that WCAG doesn't make sense because 
        of the difficulties of synchronization.

    IJ: Two options:
      a) WCAG is wrong
      b) "User agents" in WCAG doesn't necessarily mean
          mainstream browsers. Therefore, since UAGL 
          not catering to all user agents, no need today
          for an additional checkpoint.
      c) Also, if you already support text to speech, your
         UA will already be required to render the text
         equivalent as speech.

   Resolved: No additional checkpoint.
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel/Fax:                     +1 212 684-1814
Cell:                        +1 917 450-8783
Received on Wednesday, 24 November 1999 13:43:47 UTC

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