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

Raw minutes from 31 August UA teleconference

From: Ian Jacobs <ij@w3.org>
Date: Thu, 31 Aug 2000 16:04:34 -0400
Message-ID: <39AEBA52.CF7645F@w3.org>
To: w3c-wai-ua@w3.org
31 August 2000 UA Guidelines Teleconference

 Jon Gunderson (Chair)
 Ian Jacobs (Scribe)
 Mickey Quenzer
 Denis Anson
 Harvey Bingham
 Dick Brown
 Gregory Rosmaita
 Eric Hansen
 Jim Allan
 Tim Lacy
 Kitch Barnicle 
 Charles McCathieNevile
 Rich Schwerdtfeger

 David Poehlman

Next meeting: 7 September

Minutes of previous meeting:


  1) Implementation report
     IJ: I'm starting to gather information for an updated 
     implementation report. 


    1.Proposed editorial changes to UAAG 1.0 (short) 

    Resolved: Adopt unless there are objections on the list.
    Action IJ: Adopt in next draft.
    GR: I think this is more than editorial.
    IJ: Already in introduction (section 1.2, part one).

    2.Checkpoint 4.6: question about "rewind" 

    HB: Propose putting my ideas in the Techniques.

    Resolved: change the wording to
      "start, stop, pause, resume, fast advance, and fast 
       reverse content that is audio, video, or animations."

    GR: Do we have a minimum requirement?

    HB: Audio32 is another player that lets you do rewind.

    Action IJ:
       a) Change checkpoint as resolved.
       b) Work to incorporate HB's techniques (e.g., step by song
          on a CD). 
          IJ: Stepping from song-to-song is structured navigation.
       c) Ensure that technique that involves timing also states that
          you have to be able to rewind and fast forward in a
          manner. Issue of fine motor control. Issue of

    3.Issue 297: Style vs. content and background sounds.

     Q: Should we distinguish important from unimportant content? Is
        this too hard? Short sounds? Any information used for
     Q: Should the UA be required to repair bad authoring practices?

     MQ: Sometimes you'd like to throw away background music, sometimes
         you want background sounds.

     DA: I don't know that we can assume that background sounds are
     not content. A page could talk about the sounds that play.

     GR: Include "onload" configuration techniques.
         Load, Don't load this time, don't ask me again.

     MQ: I think we should differentiate onload sounds from regular
     audio. It's good to be able to turn them off. However, you should
     be able to control that audio which cannot be rewound for fast

     GR: I want to distinguish playing audio that the user chose to
     play v. audio played without express user request.

     IJ: Summarizing:
       a) I may want to turn all audio off.
       b) For audio, video, animation that I choose to play, I want
          fine control.
       c) For other audio, video, animation that I don't choose to 
          play, I want to be able to turn off (3.2) while still
          being able to play that sound that I can control
          (or send to a helper application).

     IJ: AG has also talked about short clips (e.g., less than a 
     sentence) that you don't need to rewind in practice.

     IJ: If we have a requirement for the UA to repair bad
     authoring (misuse of bgsound and style sheets), we need to
     tell people in the document that this is a repair requirement.

     TL: You can't trap an onload event. You can have a script
     react to an onload event. On Windows, the latest versions of IE
     allow the user to set a sound to be played for all loads (one
     for starting the load and one for ending the load).

     RS: What about this: If the UA provides a mechanism for
     allowing the user to control audio or video, then control is
     IJ: IE Mac handles background sounds natively (IJ asked Tantek).

     IJ: How do we know which audio the author intended the user
         not to control? Assumptions today are that "bgsound"
         are not meant to be controlled by the user. Why make this
         assumption? How do you justify lack of control for bgsound?
         I think it's just how implementations work today.

     DA: (To developers) Would a browser process background sounds
     differently? Is it easier or harder to special case background

     IJ: I'm moving away from the "onload" model since there is
     other content that is played onload (e.g., any OBJECT). Instead,
     I like GR's expression of the problem as being "on request from
     the user".

     KB: If I get an electronic greeting card, so I have to download
     a media player just to hear some background beeps.

     JG (around the table): Are background sounds different from other

     IJ: Notes that WCAG 1.0 checkpoint 1.1 says 
        "sounds (played with or without user interaction)"

     EH: In light of that, no difference.
     DA: From an implementation viewpoint, sound is sound.
     MQ: Background sounds and more important audio are different.
     GR, HB, DB: I don't see much difference between background 
                 and other audio.

     JA: Because authors will do goofy things, it's a simple 
         repair to say all sound is the same, and the user needs
         control of all of them.

     TL: I'd agree that a sound is a sound and that programmatically
         we treat them the same, whether or not we bring up a player.

     EH: Should there be a configurability requirement? For instance,
         for some types of audio, just have on/off control.

     GR: Note that sounds played on load are synchronized with
         anything else played onload.

     JG: But not important for unrelated sounds.

     IJ: Summarizing:
        a) The WG is saying that the UA needs to provide control
           over all sounds, even if all users wouldn't have the same
           level of control.
        b) GR is requesting requirements for element-level control
           of rendering audio/video even when there's a global
           configuration to supress rendering.
           IJ: However, if the UA lets the user control all sounds
           (including stop), then the ability to configure all sounds
           off on load but play sounds individually is no longer a P1
           requirement. It's just a convenience function (P3).
        c) Background sounds are misused to convey 
           information. Hence, providing control even over background
           sounds is repair.

     JG: What about scripts that play sounds?

     IJ: Invoke "recognize" (applicability).

     IJ: If the browser lets me turn off sound globally, how
         do I get at them individually?

     RS: I think that if something is intended for the background,
         I think on/off is sufficient. You don't need to rewind or fast
         forward it. 
     EH: Checkpoint 1.1 of WCAG 1.0 calls for a text equivalent of
         all non-text elements. I have argued that this should only
         be P1 for primary content. You could add further that the
         priority drops for "unimportant" content. 

     IJ: But it's much harder on the UA side to determine what
     is important.

     EH: So say "in the absence of sufficient rules, then I'll use
     these rules of thumb (e.g., based on media type)" 

     IJ Proposal:
        a) P1 requirement to control sound that is not stylistic
           (by specification).
        b) P2 requirement to control all other sound.
     GR: Risk is too high that content will not be available.
     EH: Yes, I think that something along that line is appropriate.

     IJ: We could say something arbitrary about short sounds,
         like "P1 to control any sound that takes less than 3 seconds,
         P2 for anything longer."

     EH: We can't judge priorities unless we make some assumptions
     about a level of authoring compliance to WCAG. 

     JG: We are largely assuming content that conforms to WCAG.

     Action IJ: Write a proposal to the WG about control of audio,
                video, animations.

     Action GR: Write a proposal explaining what more should be done
                in UAAG 1.0 in the way of repair functionality.

     Action IJ: Document the assumption that content (unless 
     explicitly indicated as a repair functionality) is expected 
     to conform to WCAG.

    4.Issue 257: Checkpoint 2.7: Natural language information 
     Resolved: Adopt proposal from Jon with editorial changes:

    5.Issue 257: Checkpoint 2.3: Access to text equivalents

      EH: The usage of "primary content" is different from the
      meaning I proposed. I have used the term "equivalency
      target". It looks to me that whether something is primary 
      or alternative could be ascertained through existing markup
      in some cases. I wanted to reserve the term "primary content"
      to mean that which the author intended without users with

      Resolved: Version in 18 August Guidelines is ok, but 
      may go back and re-examine use of "primary content".

    6.Issue 257: Checkpoint 9.3: 

       Resolved: Delete checkpoint 9.3.

    7.Issue 257: Checkpoint 10.8: Single step access to frequently 
      used functionalities, list of functions and wording

    IJ reviews proposal:

    Resolved: Adopt proposal.

   8. IJ: Please add discussion of "primary content" to next agenda.

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

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