- 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