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
Chair: Jon Gunderson
Scribe: Jim Allan
Gregory J. Rosmaita
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.
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
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
KB: arguments support p2 but don't like them different CMN: yes, should be same as
DP: no, 4.9 deals with rendered content, described audio, primary purpose of this checkpoint, goes back with wcag, 4.8 could be p2
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
JG: reasons for change...group made a mistake
KB: I guess so
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
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
DB: what is priority
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
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
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.