W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2000

MINUTES: W3C WAI User Agent Telecon 1 June 2000

From: Jon Gunderson <jongund@staff.uiuc.edu>
Date: Fri, 02 Jun 2000 09:16:41 -0500
Message-Id: <4.3.1.2.20000602091535.00d4f840@staff.uiuc.edu>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:50:03 GMT