W3C logo Web Accessibility Initiative (WAI) logo

WAI UA Telecon for May 25th, 2000

Chair: Jon Gunderson
Date: Thursday, 25 May


Review Action Items


  1. Notice of Proposed Rulemaking: Electronic and Information Technology Accessibility Standardsby the United States ARCHITECTURAL AND TRANSPORTATION BARRIERS COMPLIANCE BOARD. Comments will be accepted until May 30th


  1. PR#284: Consistent use of the words "control" and "configure" in checkpoints
  2. PR#283: Delete checkpoint 10.4 Allow the user to change the input configuration. [Priority 2]
    See Ian's analysis of the checkpoints that need minimum requirements:


Chair: Jon Gunderson

Scribe: Jim Allan

Kitch Barnicle
David Poehlman
Harvey Bingham
Gregory J. Rosmaita
Madeleine Rothberg
Tim Lacy
Denis Anson
Eric Hansen
Dick Brown

Ian Jacobs
Mark Novak

Mickey Quenzer Charles
Rich Schwerdtfeger
Al Gilman
Hans Riesebos

Action Items

Open Action Items


New Action Items

  4. EH: Propose new definitions for control and configure

Completed Action Items

  1. WG: Read Madeleine Rothberg review of the UAAG related to control and configure and re-read the guidelines document subsituting control for configure (except in Guideline 10).




JG: mr reviewed control & configure, control is set dynamically, configure is set up before, control is short term configure is persistent some want both when a control is set it can become permanent. set parameters before something starts (playback rate in video) mr most check points can be control jg says use control for all, then have configure option in gl10-default user configuration

EH: what is wrong with mr definitions?

DB: mr seems reasonable

JG: people like distinction

DB: yes


DP: if you want both then say both

EH: key thing, if priorities are same, then need to be accurate with priorities. if difference between control and configure priority then match checkpoint priority. would be nice if mr would look at need for control and configure in checkpoints. unease with locking in developers to tightly

JG: control and configure size of text. make it 2 checkpoints? need minimum requirement for priority 1 items 10.7 save in profile (p2) control is p1 configuration is p2 but can be seen as part of 10.7 --last control setting will be saved as configuration


JG: if setting only header then it should be persistent for headers. don't have a range for control of font sizes. group has tried for other checkpoints.

DA: don't always want last setting


JG: may be techniques, different OS may need different techniques - ij example of editing initialization file.

DA: what you want with configuration-this is the way I want this to behave, need reset to default, last use may be special case, don't want it to be default automatically.

EH: need many ways to set configuration

HB: in techniques have pointers to style sheets

EH: don't over proscribe what configuration means, unless all agree

DA: looking at priorities, control vs. configure, need to look at individual checkpoints to evaluate. mainly for control and configure are both important

JG: mr identified 3 cp for control and config. size of text, volume control/config size of text both p1?

MR: yes, checkpoint delineates

JG: is it impossible for some users to access content.

MR: p1 for one or the other

JG: p1 for control, need it dynamically config is for things that are difficult

MR: depends on what web authors are doing

GR: cognitive load for control is less than for config




DP: but may never use synthesized speech

JG: 10.7 not impossible



GR: yes, application in real world, config assumes UA source is properly marked up, client side CSS. if marked up differently then personal CSS doesn't affect page, then I need local control.

JG: 4.1 in IE need to use two controls,


Resolved: Checkpoint 4.1 is p1 for both control and configure.

JG: control configure for audio rate- p1

GR: yes

DP: yes

MR: question for screen reader- have configure for rate, but not dynamic (control) rate

DP: starting to have control for rate.

GR: also starting to have control for punctuation - change dynamically

HB: change in middle of document


DA: isn't this p2, don't have to have control

DP: talking about rate not punctionation, need quick way to fix rate problems, and a way to make it persistent, need both, so it is p1, config is a global setting, there are times that rate needs to be adjustable quickly depending on the task

JG: webspeak has control of rate, hpr may have control also, both have configure.


DA: no problem with control and config

JG: p1 for both control and config audio rate

DP: public ally available speech synthesis, have little or no control. such as Microsoft agent give audio but no control. important that we show developers that control is necessary .

EH: over time we get an understanding about what is a p1, etc. key point is apply same standard across all guidelines, don't front load everything just because we like it. implementation becomes difficult, if can only implement 50% then which are most important

GR: I get lots of requests for setting up user work stations in public settings. lots of people use public terminals, they are looking into ADA compliance, must have control

JG: first level is what is needed by pwd, spent much time working on priorities. few statements about priorities during last call, don't see much trouble with priorities in document. have pretty good consensus.

EH: no problem with p1

HB: reset to default, should that be a technique

GR: yes

JG: user may not have access to that. has been dealt with before. good for technique for public access terminals. Have checkpoints to restore to default 10.7 p2

Resolved:Checkpoint 4.9 is p1 for control and configure

JG: 4.7 config and control audio volume p1

DP: control is p1, similar to reasons for rate

JG: what about hearing impaired


DA: with synthesized speech isn't synthesizer with client.

JG: if using telephone, synthetic speech is in host

EH: control and configure for 4.10 is p1

JG: yes

DA: would set home terminal for something I can hear, public terminal may have default median volume

DP: synthesizers without front end from the author have not control. synth interperts the markup and outputs, if no markup for control of volume then no control.

DA: is an imbedded object

GR: acss have aural properties (lists properties), many things built into w3 spec

JG: control is p1, what about config?

GR: config, most screen readers use sound card cannot set volume through screen reader, must use OS

JG: can control volume through sapi, actual volume is sapi, master control, and manual speaker volume



GR: ok

JG: gr is config as important and control

GR: I lean that way

JG: note that for regular audio, 4.8 talks about audio volume (not speech) this is a p2, mr recommended p1 for control and configure. other audio events must have text equivalents

EH: language used in regard to audio, depends on how terms are used. 4.8 audio is a generic term, includes synth. speech

JG: long discussion on this


DP: syn. speech is a special case of audio


GR: control is situational.

JG: is config a p1?

DP: should be same as rate. same situations, need same type of control and config--should be p1

JG: objections?

DB: situations where you can configure but not control makes it impossible to use.

JG: if volume is so low that a person with hearing problem cant hear it then can

JG: most systems provide config but not control

DB: talking about UA not AT,


DB: I know it is not hard to do, little uneasy about it being impossible to use thus requiring a p1

JG: it is a present value, was reviewed as a p1, no comments during review process.

DB: I can live with it. not positive that it meets the impossible rule. can imagine many scenarios for all GL that can make all be a p1

JG: many public access computers, allow users to configure. set up a system, so individual profiles follow person around. then can config.

DB: if you log in than your last used profile


DB: cant control because you cant hear it

JG: system volume, get back to default value. argue about different situations where config or control is better or more needed. similar to speech playback--volume and rate are important for hearing impairment.

DB: can live with it, move on

Resolved :4.10 control and config p1


MR: already a p1 need for text equivalent. must have p2 to control and config audio volume

GR: if have page playing midi file, plays at a volume that cant hear synthesizer. OS control globally controls all volume. ability to control volume should be p1

DP: should be p1

JG: address both now


GR: cross reference 4.10 and 4.8 add note "if user agent supports sny speech natively then changes in audio volume should be independent of syn speech volume"

JG: minimum requirement that volume controls are independent.

EH: sounds fine to me

JG: how do I know when I comply. group working on this. 4.8, 4.11 independent control, two type of minimum requirements--provide structured navigation-minimum things are defined, another type is provision of a range - such as change rate

KB joins don't have range for audio (hardware limitations). syn speech playback rate was specified - use default of synthesizer else offer a range


JG: need action, why 4.8 is p2, check archives

Action GR: why 4.8 is p2, will post to list

GR: recollection, speech is p1 and audio is p2 is for reasons stated, audio overwhelms synth. speech.

EH: need to define that 4.8 is non synth. speech. or audio other than synthesized speech with pointer to 4.10

Action Editors: cross reference 4.8 and 4.10.

Resolved: independent control of synthetic speech and audio volume.

Action Editors: 4.8 indicate non-synthesized speech audio.

JG: combine volume control for audio and synth speech. must have independent control as a minimum

GR: originally 4.8 was turn on and off background audio.

JG: have separate check point for that adopt mr proposal

Resolved: Use the rest of MR proposal for changing the wording of control and configuration checkpoints

Action EH: Propose new definitions of control and configure.



JG: Checkpoint 10.4 currently does not have any clearly identified minimum requirements. Its minimum requires seem to satisified by other checkpoints:

  1. We already have a requirement that all functions be accessible through the keyboard (1.3)
  2. We say to use system conventions (5.8)
  3. Allow single key or command configuration (10.5)
  4. Configuration of graphical controls (10.9)
  5. Saving custom and restoring default configuration information (including keyboard bindings) are in checkpoint 10.7

What additional functionality does checkpoint 10.4 add that can be put in a minimal requirement for satisfying the checkpoint? We need just one requirement of a minimal specification to satisfy the checkpoint that is not covered somewhere else.

NOTE: I would modify the minimum requirement of 10.5 to include either single key or modifier + single key for configuration of systems with keyboards. This would generalize 10.5, but still provide the single key functionality for those that want just a single key.

EH: for 10.5 need to describe minimum requirements. so many steps. define functionalities.

JG: all things that need control need keystrokes. part of minimum spec for 10.5

EH: is there language for 10.5 minimum requirements. they are posted for Netscape.


KB: jg turning in 508 comments

JG: yes

EH: are you KB

KB: yes have lots of work
