- From: Ian Jacobs <ij@w3.org>
- Date: Thu, 06 Jul 2000 16:04:27 -0400
- To: w3c-wai-ua@w3.org
6 July 2000 UA Guidelines Teleconference
Present:
Jon Gunderson
Ian Jacobs (Scribe)
Harvey Bingham
David Poehlman
Eric Hansen
Dick Brown
Tim Lacy
Gregory Rosmaita
Charles McCathieNevile
Rich Schwerdtfeger
Regrets:
Mark Novak
Next meeting: 13 July.
Agenda [1]
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0010.html
Agenda
A. Review Open Action Items (see details below)
B. Announcements
none
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
calls).
4.Min / Max requirements for speech synthesis rates.
Refer to Gregory's proposal:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0482.html
Ian's proposal
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0003.html
JG: Provide access to the full range of values available from
hardware.
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
user.
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
P2.
JG: Control of synthesizer by the user should be P1.
For certain characteristics, we could provide min/max
values.
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
guidelines.
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
sufficient.
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?
Resolved:
"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
on
speech synthesizer mins/maxes for various articulation capabilities (as
we
did for speech
rate).
Status: Done
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0000.html
5.GR: Pursue speech synth ranges for other properties than speech
rate.
Status: Done, will done.
4.GR: Look into which checkpoints would benefit from audio examples
in
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
can
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