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

Raw minutes from 6 July UA teleconference

From: Ian Jacobs <ij@w3.org>
Date: Thu, 06 Jul 2000 16:04:27 -0400
Message-ID: <3964E64A.8819A349@w3.org>
To: w3c-wai-ua@w3.org
6 July 2000 UA Guidelines Teleconference

 Jon Gunderson
 Ian Jacobs (Scribe)
 Harvey Bingham
 David Poehlman
 Eric Hansen
 Dick Brown
 Tim Lacy
 Gregory Rosmaita
 Charles McCathieNevile
 Rich Schwerdtfeger

 Mark Novak

Next meeting: 13 July.
Agenda [1]
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0010.html


A. Review Open Action Items (see details below)

B. Announcements


C. Discussion

    1.Additional or longer telecons
      JG: Tuesdays at the same time? Add 30 minutes to regular time?
      /* Only DB participates in WCAG actively */
      JG: Who could attend extra 30 mins: DP, DB, TL, IJ, JG, HB, EH
      Resolved: Extend teleconf extra 30 minutes (for a couple of

    4.Min / Max requirements for speech synthesis rates. 
      Refer to Gregory's proposal:
      Ian's proposal

      JG: Provide access to the full range of values available from

      IJ: Proposal to require full access to available range.

      EH: Should it be P1 for lower bound of speech rate, 
          P2 for upper bound of speech rate?

      GR: If the speech experts say that not having a lower bound
          to the upper limit, then I favor P1.

      JG: We discussed a year ago: speech rate is analogous to
          allowing someone to change font-size, colors.

      IJ: One could pursue the analogy to fonts: should shrinking
          text size be P2?

      JG: Several issues:
         a) Priorities?
         b) What should the user should be able to control?
         c) What ranges?

      About priorities:

         JG, DP: I think high-speed speech is a P1 issue.
         GR: When speech is your only means of getting at content,
             you need lots of control over the rate.
         EH: In favor of P1, if you want to be able to scan large
             amounts of data quickly, it makes sense to synthesize
             at high rates.

         Resolved: Leave speech rate checkpoint a P1 requirement.

      About ranges:

         EH: I have some concerns about referring to what the 
             speech device supports. That assumes that the speech
             output device is not part of the UA. Some UAs include
             the speech component. I'm still in favor of saying
             something about ranges.
         EH: If you are using an external synth and it doesn't
             accommodate the range you can handle, applicability
             kicks in.
         JG: I think that adjustability is required over the range
             supported by the engine. So if a user picks a slow
             synthesizer, that's not the UA's problem.
         EH: If we establish the range for the user agent, that will
             take care of everything: applicability will kick in for
             devices that are independent.
         JG: Be careful, a lot of different technologies could be
             employed. Ranges and enumeration are important.
             If a syn provides more than we require, then we still
             want the full range of values to be available to the
         EH: What makes sense to me:
              1) 100-600 words / minute is a P1 requirement. 
              2) If you want to require speeds above that, that's
         JG: Control of synthesizer by the user should be P1.
             For certain characteristics, we could provide min/max
         GR: I think that it's the wrong approach to have min/max
             for speech rate. It's like colors. The minimum
             requirement should be about fidelity when you change
             pitch, applicability of configurations.
         GR: I think it's dangerous precedent to set min/max values.
         DP: My only problem with not specifying ranges is that we
             make it possible for a synthesizer to be selected by
             the user agent that will not allow access.         
         IJ: Should we push off these requirements to other
             resources as we do for fonts/colors.

         JG: It's like a video card: the video card is
             a requirement - the video card is not a
             user agent, nor is the speech engine.

         IJ: There's a difference between "should" and "must".

         /* Discussion of philosophy of min requirements */

         GR: Risk of min requirements appearing in other
         GR: A better tack for speech rate would be:
             a) To support ranges offered by the speech engine.
             b) You must choose an engine that supports the
                following range ...

         IJ: If you establish min/max as P1 requirement, I don't
             understand why it's a P1 to provide control outside the
             range. I agree that control within the range is a P1
             requirement. Having two ends: 100 and 800 is not

         GR: In case of increments, let's talk to experts.

         IJ: I agree!

         DP: We need complete access to the capabilities of 
             they synthesizer. 

         RS: The accessibility issue is what is slow enough
             and what is fast enough.

         EH: I think there's a nervousness here on the part of
             some that our range is not wide enough. Then I suggest
             that our range go from some really low speed to some
             speed known to be what's perceptible to the human ear.
        CMN: That hurts the ability of tools to conform.

         GR: The P1 requirement is to be able to use the speech
             engine. There are there parts:
             a) I want complete access to the engine
             b) I want min/max for rate.
             c) Increments

         GR: I don't want the number of checkpoints to grow.

         JG: One other issue - different speech rates may be required
             for users with different disabilities. UAs may use
             several technologies to meet requirements.

         /* JG tries to get WG consensus */

         JG: Can we pick a range and some increments? 
            - P1 requirement shall include a range and increments.

         GR: Best way to meet the needs of all the users is
             to give access to the full range. The range is
             a clarification.

         DP: I think that we need to make all three of GR's
             points P1. I don't want anything to get lost.

         EH: I agree with IJ's explanation. I would encourage
             us to be cautious to get the best advice we can about
             what the range is.

         DP: Consider pitch. If you deal with pitch, different
             synthesizers with different voices deal with pitch
             differently. If you set a range for pitch, results
             may not be accessible to some users.

         EH: I propose P1 for range + increment and P2 for
             access to the full range.

         DP: I think that not having control in some cases
             might preclude access. 

        CMN: I instinctively agree with IJ. If you say that
             800 is enough for accessibility, then more than
             800 is more than enough. But we don't have a 
             mathematical understanding of what is required
             for accessibility. 800 would not be a hard line.
             If you don't give access to the capabilities of
             people's tools, you're going to cut people out.
             People might implement stuff that only a few
             people need. There may be a pretty good case
             for saying: this is the conservative range
             (and if you don't do this, life will be impossible)
             and furthermore, you should give them everything
             that's possible.

         JG: I agree with CMN - as soon as you pick numbers,
             you lock someone out. 

         CMN: You can guarantee that we're not going far
             enough to meet the needs of some people.

         JG Proposed: Two checkpoints:
            - Control and configure rate (within range, with increment)
            - Access to the range of values of speech synth parameters
              (add this to 4.11 - include additional values beyond
               the range). Add to this checkpoint full control
               of what's available to the synthesizer.

         GR: I would switch the priorities: control is P1. The
             range is normative as well.
         DP: I agree with GR's proposal.

         RS: I agree with JG's proposal.
         DB: I can't support GR's proposal.
         HB: I would prefer two checkpoints.
        CMN: I would support GR and DP's position with the
             proviso that I would looking for a small range
             being the required range. 
         GR: Yes, I can agree with that.
         IJ: That's consistent with CMN's all content stubbornness.
        CMN: If we set a range where we're pretty sure we catch
             everyone, then I'm sure we will exclude some people.
             "Provide access to the full rate of speech available
             in the speech synthesizer, going down to [100] and up
             to [500]. People can live on 400. It's not ideal for
             a bunch of people.
         IJ: EH, can you live with this proposal?
         EH: I'm concerned that it may be weakening the requirement.
         JG: Arkenstone goes from 120-350. Increment: 10 wpm.
         DP: A percentage may be better.
         EH: I think it's tricky to have an open-ended requirement;
             are we willing to tolerate this type of conformance.
             What is the requirement to cover the full range? 

             "Provide access to the full rate of speech rates available
             in the speech synthesizer, going down to [120?] and up
             to [500?], increments of 10 wpm?

Resolved action items:

    1.IJ: Produce a new draft that folds minimal requirements into the 
          checkpoints. Should be ready about 7 July.

    2.IJ: Pick up GR's action item to send out a request for information
speech synthesizer mins/maxes for various articulation capabilities (as
did for speech

    Status: Done

    5.GR: Pursue speech synth ranges for other properties than speech

    Status: Done, will done.

    4.GR: Look into which checkpoints would benefit from audio examples
          the techniques document.
    Status: Dropped. May do.

Open action items:

    IJ: Moving along!

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

    6.GR: Re-examine the orientation checkpoints and see whether they
         be clarified to account for control of rendering of audio 
         (and possibly other content) on load.

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

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