W3C logo Web Accessibility Initiative (WAI) logo

WAI UA Telecon for May 18th, 2000

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


Review Action Items




  1. Update on extending charter
  2. PR#281: Proposed rewording of checkpoint 8.4 and 8.5
  3. PR#282: Proposed rewording of checkpoint 7.6 and 7.7 to reflect minimal requirements
  4. 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

RSVP Present:
David PoEHlman
Ian JAcobs
Tim Lacy
Mickey Quenzer
Eric Hansen
Dick Brown
Mark Novak

Harvey Bingham
Gregory Rosmaita
Charles McCathieNevile
Kitch Barnicle

Denis Anson
Rich Schwerdtfeger
Al Gilman
Hans Riesebos
Madeleine Rothberg

Action Items

Open Action Items

  1. IJ: Draft a preliminary executive summary/mini-FAQ for developers. (No deadline.)
  2. CMN: Propose a technique that explains how serialization plus navigation would suffice for Checkpoint 8.1.
  3. GR: Look into which checkpoints would benefit from audio examples in the techniques document.

New Action Items

  1. WG: Read Madeleine Rothberg review of the UAAG related to control and configure and re-read the guidelines document subsituting control for configure (except in Guideline 10).

Completed Action Items

  1. IJ: Propose new 7.6
  2. IJ: Propose a clarification to 8.4 to indicate that what is intended is to hide content (and why).
  3. IJ: Propose synthesis of 7.6/7.7/8.4/8.5
  4. IJ: Find out what HTTP gives you in the way of resource name
  5. EH: Propose definitions for auditory and visual tracks. - For synthesized speech (4.9)


1.Update on extending charter

IJ: leaves to fix phone

JG: charter up in April, extend current through Aug (or proposed rec), deliverables same, implementation status report can be done after proposed rec Questions?...(none)

2.PR#281: Proposed rewording of checkpoint 8.4 and 8.5


JG: questions and comments on list Ian message synchronize with 7.5 still questions about 8.5 and 7.7 sound ok to you DP

DP: reviewed it and its ok, ties itself to things important to the user

JG: or specification

DP: yes

JG: 8.4 if there is important structural info then use this for ouTLine TL: fine with me

mq: ok

JG: word important not defined anywhere, some elements are more important than others for understanding document TL: techniques will flesh this out?

JG: yes, critical part of 8.4 and 7.6 is configuration, users know what is important to them, or dependent on situation. 85. and 7.7 are configuration

DB: sounds fine to me

MN: navigation and orientation, must be tied together, then I am comfortable with it.

Resolved: to adopt may 13 IJ email wording for 8.4

3.PR#282: Proposed rewording of checkpoint 7.6 and 7.7 to reflect minimal requirements


JG: move to navigation

/* IJ rejoins */

JG: 7.6 navigate to and among elements, 7.7 configure navigation review IJ questions propose 7.6. to stay same change 7.7

JG: 7.7 config of minimal requirement user navigate elements of document, Al gilman responded same, leave 7.7 borders

IJ: what's a little broader, was intention of 7.7 to be both or just set of element, what to nav and how to nav.

JG: allow for config of navigation, more general than set of elements, other ideas dh: not certain, config how nav is done, along with elements you can navigate to

JG: what keystrokes go with what functionality, can change those, select nav method-sequential,

JA: what is broader than nav elements

JG: pick between hierarchical or sequential

IJ: how are they different JG: nav between human understandable, or walk tree

IJ: what mean by hierarchical, have a tree, use depth first JG: move to parent, then child

IJ: 7.6 minimal nav abilities, forward, clarify that 7.7 both nav capabilities and element set. proposing only elements, if we mean more nav abilities then how much more.

EH: question-what is difference between 7.7 and replacing word configure with control, what is different

IJ: control is change dynamically, configure is persistent but not necessarily dynamic, if only have linearization to depth of tree, configure rough

EH: control is overarching concept, config is a refinement. don't work about config until after you have control. if only say config, leaving out things

DP: differentiate between the way things done on fly, and way things are done in advance

JG: not clear how affects interface, control is hot key, configure is dialog box, may be

IJ: control is about instances, config is classes control is in subtree and I want to expand to explore, not sure how to configure for this in advance config-for any document for all classes of table I don't want to see, broad general setting (font size) but I want to increase font of parag

EH: want control over features before you configure

IJ: focus on control, want a global setting

JG: user set config once

IJ: Madeleine sent info EH: other thoughts, distinction is not clear. 7.7 navigable according to 7.6

IJ: documents change, that is difficult, can say in html I don't want to see anything below h3, problematic, how to set that EH: are there rules of logic, if we call for config but not control, then why do we think this, that we can config but not control

JG: EH proposed definition control-governance-render control, in user interface, depends on system config-save profile.

EH: creates unified concept -- control, config give emphasis to persistence

IJ: some checkpoint have explicit config options, i.e. # of viewport. some have emphasis on config not control. prompt for focus change

JG: on 4.2 config related to persistence then becomes default bEHavior until changed, control is dynamic - change bEHavior now

EH: save preferences to a profile, some events change persistence, degrees of persistence. hard to prescribe these

JG: may effect 4.2 font family, change word to config and control

IJ: pick priority, choose config where it is a sub class of control where persistence is important

JG: 4.2

IJ: is dynamic changing a requirement

JG: what is

IJ: specificity, change for whole document, config. hard to change for just 1, what is more important global setting or specific setting, how global is config. change font size is less important than change font for all doc

EH: 4.8 donfig audio volume, set ahead of time and is persistent, do we have a control to change as needed

IJ: variable priorities for dynamic or persistent, cant change highlight dynamically, can edit a file config then restart, no control

EH: Madeline allow control and configure IJ: have initialization file, case of config without dynamic control, does this fit EH model?

JG: comments TL: important, ouTLines how a ua works, it is far less important, difference between them is less important than implementation of config or control.

JG: clarify

IJ: cant adjust font of particular, but in editor can change dynamically

TL: if editing then need to change on fly. don't feel strong one way or other depending on "granularity"

IJ: granularity is important for navigation, less so for font size

DP: use persistently control versus dynamically

IJ: granularity is different that control or config

DB: litTLe lost, talking about nav.

JG: summarize (IJ leaves) number of checkpoints with config and control. need to define. config is global setting applied uniformly across sessions, control is on doc by doc basis, gives example EH proposed config is super class of control, config mean control with persistence. part is definitional and part is availability of function. IJ example of initialization file, is not usable to dynamically change font. How immediate is functionality for accessibility and

EH: we need to define as precisely as we can.

JG: right, want to be clear, need to define control/config

DB: control is immediate, config dialog box applied globally

JG: in config, takes user longer to do it, but always there control easy for user, but may not stay. may control something and ua remembers change from session to session. can be combined depending on implementation. this concerns me, depends on how we define this. may confuse developers

EH: message at 2, synthesized speech, change configure to control, not sure if I did right with revision. control is over arching concept. may need to leave what is configurable to marketing and design rather than proscribe

JG: focus on control, leave config to user. have a config section. 10.7 for config have a p2 to allow saving of profile based on what user can control.

EH: wow, ability to save in a profile. need to review guideline 10. need to avoid attacking same problem in to many different way. if gl10 applies to config. then other cp need to specify control

MN: trouble understanding granularity. if I can configure things the way I want then I have control. trouble separating. leave things the way they are.

DP: need to make clear - there are configurable things that don't have control. propose minimum requirements to set then dynamically address. config working download directory, but no keystroke for that and don't need it.

JG: 10.5 can config a one keystroke command to change font.

EH: leave all configs to guideline 10

Action group: Read Madeline comments of 5/10 on control and config, then except for guildeline l10, review document, substitute control for config and discuss at next meeting--

JG: persistence about guideline 10. separate persistence from control

JG: 7.7 is it about only elements, should it be what elements are nav to, IJ rejoins

TL: leaves (meeting to attend)IJ has right idea in 7.7--elements is it

JG: hierarchical, depth of focus, broader checkpoint. if change to elements than we can be clear

EH: if we leave it out is it addressed elsewhere

JG: yes, can reassign keys for navigation.

EH: like specificity if it is covered elsewhere mq: elements don't do it for me

JG: rewording-talking about what to nav to but not how. limiting to elements then are more specific for developers IJ leave (much phone trouble)

JG: if only one type of nav then don't have config.

EH: think rewording is ok. don't have crisp feeling about these issues.

JG: if we accept proposal, checkpoint is more verifiable and understandable for developers. propose to accept IJ revision **

Resolved: accept IJ revision of 7.7

4.PR#257: Difficult to know when a UA has conformed.


See Ian's analysis of the checkpoints that need minimum requirements: http://www.w3.org/WAI/UA/2000/05/ua-minreqs.html

JG: min requirements for 10.4 change input config, voice browsers, gui browsers-shortcuts, button, (see 10.9) what is min--change all menu items and placement, keyboard bindings,

EH: dependent on ua, can narrow it to gui/wimp environment

JG: related to 10.5 - user config most need function to one keystroke bare minimum-rebind keyboard commands to different functionalities. or allow ua to assign keyboard to functionality.

EH: applicability problem. allow user to config applicable menu items, make it broad to make it easy for browser to implement.

JG: possibility-if support keyboard then support changing binding. window alt-f-o or control-o have same functionality. but cant set keystroke to jump to preferences. do we say allow any key to any function. is it important for accessibility

DB: this is expansion of original intent

JG: should be able to change control-p to open preferences rather than print. review techniques- restore defaults, prepackaged config, save in profile, do not allow over writing system commands, assign macros to keystrokes.

EH: should a user be allowed to change left and right mouse button. put pieces in applicability context. hard to fit techniques in min requirement.

JG: where it fits, brian cambell, limited range of motion, need to remap keyboard. these are covered under 10.5. what are we asking in 10.4 that is not covered in 10.5. is this about going against system conventions. reads 10.4 config input reads 10.5 single keystroke

DP: 10.5 commands available from one keystroke

JG: 10.4 and 10.5 have same priority.

DP: 10.4 allow reagranceing controls then 10.5 implements what 10.4 sets

JG: is there any subset in 10.4 that is good for accessibility. if don't like menu system, change it. may have implications for cognitive disabilities.

DP: if combine then can make 1 keystroke commands

JG: have that in 10 5

EH: 10.4 rearrange desktop elements, not sure of intent.

JG: 10.5 make customized menu, what is purpose of moving commands around

DP: who actually proposed this, need to know intent of this.

EH: what are techniques for 10.4--some visual accessibility needs in 10.4

DP: arrange common commands to be close together

JG: 10.9 has move graphical elements around

JG: 10.4 seems to be persistence issues. if there are no minimum requirement then we don't need cp.

EH: allow to change things within limits

JG: macro language is too broad. how is 10.4 different from 10.5 and 10.9. if remove techniques related 10.5 and 10.9 then we are left with persistence and restoring defaults.

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.