W3C logo Web Accessibility Initiative (WAI) logo

WAI UA Telecon for June 1st, 2000

Chair: Jon Gunderson
Date: Thursday, 1 June
Time: 2:00 pm to 3:30 pm Eastern Standard Time, USA
Call-in: Longfellow Bridge (+1) (617) 252-1038


Review Action Items




  1. Review of volume control priority changes for audio and synthetic speech
  2. PR#283: Delete checkpoint 10.4 Allow the user to change the input configuration. [Priority 2]
  3. PR#257: Difficult to know when a UA has conformed.
    See Ian's analysis of the checkpoints that need minimum requirements:


Chair: Jon Gunderson

Scribe: Jim Allan

David Poehlman
Gregory J. Rosmaita
Charles McCathieNevile
Kitch Barnicle
Mickey Quenzer
Harvey Bingham
Dick Brown
Tim Lacy
Eric Hansen
Rich Schwerdtfeger

Mark Novak
Ian Jacobs

Denis Anson
Al Gilman
Hans Riesebos
Madeleine Rothberg

Action Items

Open Action Items

  1. Editors: Update document based on MR proposal for control and configure and the resolutions made during this telecon
  2. Editors: Cross reference 4.8 and 4.10 and make clear that checkpoint 4.8 for non-syntheisized speech audio
  3. IJ: Draft a preliminary executive summary/mini-FAQ for developers. (No deadline.)
  4. CMN: Propose a technique that explains how serialization plus navigation would suffice for Checkpoint 8.1.
  5. GR: Look into which checkpoints would benefit from audio examples in the techniques document.

New Action Items

  1. JG: Contact Denis Anson related to importance of control of objects within control objects
  2. KB: Propose a minimum or preferred set of functions that should be available to single command configuration
  3. All: Review config and control definition proposal by EH
  4. All: Send situations/comments on why Checkpoint 4.8 should move to P1

Completed Action Items

  1. EH: Propose new definitions for control and configure
  2. GR: Research history of the priority of checkpoint 4.8 on audio volume
  3. JG: Add issue to issue list related to raising 4.8 to P1



HB: WAI comments for 508 are available.

JG: 508 and WAI need correspondence to make things easier to implement. have one set of guidelines. Comment period still open.

EH: to send comments this afternoon

HB: was JG involved in comments, they refer to uaag. Judy mentioned W3 copyright.

CMN: w3 has some lawyers on staff, not sure of approach w3 will take.

JG: send specific questions to Judy

HB: thought comments were well done.


Review history of auditory checkpoint priorities.


CMN: concern about mixing volumes

EH: concern about mixing, e.g. auditory description that is synthesized, mixed with other audio, do we need to say...a way to have one be a slave to another

JG: minimum requirement-must have separate volume control, can do more and more complex

DB: maybe p2 checkpoint that negotiate

GR: after research, 0ct 99 draft, allow user to control synthesized volume becomes separate checkpoint at p1, control of synthesized speech different from midi etc, one must be able to adjust synthesized speech on the fly

MQ: may not be technically possible. software synthesizer uses wave,

JG: Microsoft products can manipulate the synthesized volume

MQ: if playing wave file, if you change volume then you change volume of synthesizer

DP: some allow it, it is not implemented. can change volume of synthesis if you go to sapi control, not the wave control.

KB: know how split came about, why is synthesized important

JG: volume adjustable, developer cannot control what synthesizer is used. other audio must have text equivalent, and

KB: if using synthesized speech, means text is available to read if I use synthesized speech, must I supply the text,

CMN: by definition, text must be available for synthesizer to speak. or you can record

DP: controls not implemented, media player is to control it.

JG: synthesized speech not a lower priority. is there new information to take into account. does the priority need to change.

EH: issues involved?

JG: issue is...discrepancy between synthesized speech and regular audio, review history, make aware of previous discussion, do folks have new information to change the existing priorities

EH: change 4.8

JG: its a priority issue not wording,

KB: in early discussions about assisted listening devices, discussing compatibility issues. what do we expect people to use

JG: amplification device plugged into audio. 3 main arguments-for not being p1
1) developer doesn't control hardware
2) text equivalents for any audio (p1)
3) assistive listening device could be used

DP: support this, audio volume can be control outside environments, change speakers, or system volume

GR: what is objection to be separate

CMN: why separate, synthetic

GR: listening on web, I need to hear event to know what is going on, separate from web audio

JG: do we need to merge 4.8 and 4.9...concentrate on 4.8 moving to p1, must have independent control of volume

MQ: can control through sapi

JG: that is 4.9, volume of sampled speech, wave files get reading of people should 4.8 be a p1

TL: no

DB: no

HB: no

MQ: unsure

KB: arguments support p2 but don't like them different CMN: yes, should be same as

GR: yes

DP: no, 4.9 deals with rendered content, described audio, primary purpose of this checkpoint, goes back with wcag, 4.8 could be p2

ja: unsure

EH: not sure, need more info on synthesized speech, mixing apple and oranges, essentially, not sure we are using terms consistently, multimedia, audio presentation, synthesized speech. audio presentation is primary content. synthesize speech is not primary content, headings are misleading, synthesized speech is a way of presenting audio, or alternative content as audio

JG: as 4.9 doesn't matter how synthesized speech is being used, adjunct to visual display, no condition about source on that you generate speech from text content

EH: heading the precedes 4.5 rich swerdfeger joins

JG: move 4.8 from p2 to p1, reoccurring theme is to talk about 4.9

EH: before I comments, need to review proposed revision of the language

EH: undecided

JG: reasons for change...group made a mistake

GR: yes

CMN: yes

KB: I guess so

MQ: yes

JG: split vote, think about it, put it on issue list.

RS: don't move anything to p1

Action JG: add 4.8 discussion to issues list proposal to making it p1.

Action working group - post arguments for/against moving to 4.8 to p1

1.PR#283: Delete checkpoint 10.4 Allow the user to change the input configuration. [Priority 2]


JG: define minimum requirements--could not define any that were not already covered in other checkpoints keyboard 5.8 system conventions rearrange control looking for something new, move menu items, is this an accessibility requirement, what is accessibility

CMN: classic case is cognitive impairments, simplify the user interface.

JG: what would be minimum requirement

CMN: being able to add and remove menu items and graphical buttons,

KB: removing specific ones or just advance features

JG: would have to come up with groups

DP: must consider also putting them back

JG: in Wimp interface--add and remove items in menu bars

CMN: where does minimum lie, can turn on and off button bars, turn of graphic buttons is one thing as a block or individual buttons, turning off menus is another thing. some are replicated items.

TL: buttons are replicated menu items

CMN: button bar is simple interface for most people

JG: getting to simpler interface is what this is about

KB: not sure this is input configuration

JG: input has perceptual motor component, it does change user interface. block level control, turn on off ua components, tool bar, nav bar, etc. manipulate interface elements to provide required functionality. CMN: looks good, can see problems more than solutions. questions about defining user interface details

JG: have checkpoint- allow user to configure user interface control--menu bars etc. and a second level for individual controls

DP: does this include arrange moving menus or buttons to one side of the screen,

CMN: is it a minimum requirement, it is covered in the checkpoint.

JG: turn on/off interface controls, make tool bar appear/disappear, or menu or status line

EH: allow user to customize interface

JG: must be user interface controls. 10.7 covers rearrange graphical items, where does status line fall

EH: user interface fall in any checkpoint, user interface as used, is sight and sound centric, make assumption about people seeing and hearing

JG: user interface used in 1.1, 3,5

KB: what's the problem

EH: user interface means

JG: its in glossary

EH: doesn't refer to sight and sound, would meaning of checkpoints change if the way people interact with the interface, such as braille

JG: none are excluded, can comply

EH: user agent has braille interface, all functionality in braille interface is available through other apis available in the user agent.

JG: braille device would have to comply with standard interface controls, then can adapt to other technology

EH: will look at this and clarify.

JG: back to minimum requirements for 10.5...turn on/off block or user interface control objects button bars, is this minimum

CMN: yes

DB: what is priority

JG: p2

DB: in general customize interface

JG: make it general, what are minimums, give examples of user interface objects...menus, button bars

DB: fine with it, little concern about saying all components, some must be there for basic functionality.

JG: balance against 5.8 use system conventions.

DB: ok with it.

CMN: 5.8 is p1, should be clear that this is what you do after

JG: any disagreement....(none)

JG: what is second level

DP: that would be customize

JG: take things out of menu

RS: this could be a tough thing, msaa and java does not support this, this customization is a com level

CMN: word does it

RS: it is a proprietary com interface

CMN: turn off whole component, how important is it to turn of individual pieces. messaged rob seiler about this. he suggested that this functionality was pretty important

RS: if something flashed, you might want to remove it. why is this check point so important

CMN: important for people with cognitive disabilities, unclutter interface. if mobility problems then need shorter menus

DB: can change word, add short cuts, can not remove menu items. may not want to use this as an example

CMN: question comes back to what does use need...looking for message

KB: removing menu items is hard

DB: not minimum word, adding and removing is not trivial

DB: people with cog. disabilities need less cluttered screen, but menus pull down to limit information on the screen. more important to remove buttons not change the menus

RS: windows com is easy, other operating systems could be difficulty

JG: have not made burden a consideration

JG: in java, have menu create api, and dynamically add remove item, the problem is making the user interface to be able to do this easily. not sure of xwindow environment

CMN: some standardization in GNU. another example is mozilla, not a clean user interface. underlying architecture is there to change interface

RS: we have awt and swing, many frameworks being developed

JG: this is not new, file menu--change files in menus list. most modern applications have api that support dynamically creating menus. if group wants to consider this as a minimum requirement. cmn has said it is useful for cognitive disabilities. is it a nice thing or does it make it difficult

Action JG: Write dennis anson about this cognitive impairment

Resolved: minimum requirement is turning on/off interface control objects (i.e. menus, toolbars)

KB: also keyboard users. would be a p2 for efficiency

JG: in office 2000, uses most frequently use menu items appear, then other appear later, would this satisfy this checkpoint, if you don't use function it doesn't appear

DB: it certainly unclutters, but the user cant configure

HB: need an indicator of more menu items

KB: doesn't add items to end of menu but places them

DB: ops menu-extends menus

GR: submenues

DP: talking about components, not interface control, it is a learning thing, it applies to file or edit menu, good as a technique, may not apply to checkpoint.

JG: basically allow people to change what is available to them

EH: does on/off mean hide from user

JG: yes, remove voice commands

CMN: remove keyboard control also

Minimum Requirements for 10.5

JG: talk about 10.5 - preferred one step command, subset of 10.4. minimum requirement- specify which commands to be used as one step. discussed control and configure. one step should cover all checkpoints with "control" in them, control is dynamic. any thoughts about developing minimum set of controls for one step commands

EH: beyond scope of group

DP: may be self explanatory, don't need to box things in,

GR: implicit in the word control, don't need to draw it out. explicit state in discussion that it applies to checkpoints with control word control is not used in

KB: not sure of a list is needed. if we cant say what it is, then it is not implicit

JG: bringing up about box, is this as important as changing font size, is presenting thousands

DP: check point allows user to pick from a list

JG: should we have a minimum list

DP: what is important to me may not be important to others

JG: ua may have 1000s of choices and user has to pick 20, is that functional

DP: go through checkpoints search for control

JG: no checkpoints for go to next link, etc. have in techniques a list of Netscape commands

KB: how many keyboard commands

JG: what about voice commands, or a tool bar

DB: who decides the "some" from which the user gets to pick. the developer makes the "some" list.

JG: do we what to guide developers on the list

GR: include in the note--all checkpoints that have control in them

KB: one key brings up interface to make a change, or one key makes the change directly

JG: is dialog box sufficient, or how to I hit a key to change to Arial 44, do I need a separate one for each font and size. not intuitive to all. what is critical set for people with disabilities. i.e. changing font size up or down, but getting to about dialog box is not critical. need to guide developers as to critical set

DP: about changing fonts. hold key down then size changes, is this still single key

EH: would this qualify as single key

Action KB: draft list of minimum commands, see Netscape list, opera, checkpoints with control. post by Tuesday

KB: not on call next week.

Action All: review proposal of definition for config and control.

CMN: joint call between Authoring tools and ER groups.

JG: may have joint call between UA and ER, need to finish document then add more later.

CMN: developing techniques, evaluation tools, most is post rec work

EH: may not be on calls, getting special assignment.

JG: if not on call, send comments to list.

Copyright  ©  2000 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.