- From: Jon Gunderson <jongund@staff.uiuc.edu>
- Date: Fri, 02 Jun 2000 09:16:41 -0500
- To: w3c-wai-ua@w3.org
Attendance
Chair: Jon Gunderson
Scribe: Jim Allan
Present:
David Poehlman
Gregory J. Rosmaita
Charles McCathieNevile
Kitch Barnicle
Mickey Quenzer
Harvey Bingham
Dick Brown
Tim Lacy
Eric Hansen
Rich Schwerdtfeger
Regrets:
Mark Novak
Ian Jacobs
Absent:
Denis Anson
Al Gilman
Hans Riesebos
Madeleine Rothberg
Action Items
Continued 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
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0397.html
2.GR: Research history of the priority of checkpoint 4.8 on audio volume
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0393.html
3.JG: Add issue to issue list related to raising 4.8 to P1
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#285
Minutes
Announcements
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.
Discussion
Review history of auditory checkpoint priorities.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0393.html
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]
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#283
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.
Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
MC-574
College of Applied Life Studies
University of Illinois at Urbana/Champaign
1207 S. Oak Street, Champaign, IL 61820
Voice: (217) 244-5870
Fax: (217) 333-0248
E-mail: jongund@uiuc.edu
WWW: http://www.staff.uiuc.edu/~jongund
WWW: http://www.w3.org/wai/ua
Received on Friday, 2 June 2000 10:16:51 UTC