- From: Jon Gunderson <jongund@ux1.cso.uiuc.edu>
- Date: Thu, 18 May 2000 15:54:35 -0500
- To: w3c-wai-ua@w3.org
Attendance
Chair: Jon Gunderson
Scribe: Jim Allan
RSVP Present:
David Poehlman
Ian Jacobs
Tim Lacy
Mickey Quenzer
Eric Hansen
Dick Brown
Mark Novak
Regrets:
Harvey Bingham
Gregory Rosmaita
Charles McCathieNevile
Kitch Barnicle
Absent:
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).
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0354.html
Completed Action Items
1.IJ: Propose new 7.6
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0287.html
2.IJ: Propose a clarification to 8.4 to indicate that what is intended
is to hide content (and why).
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0362.html
3.IJ: Propose synthesis of 7.6/7.7/8.4/8.5
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0361.html
4.IJ: Find out what HTTP gives you in the way of resource name
Done
5.EH: Propose definitions for auditory and visual tracks. - For
synthesized speech (4.9)
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0374.html
Minutes
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
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#281
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
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#282
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.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#257
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.
Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Chair, W3C WAI User Agent Working Group
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 Thursday, 18 May 2000 16:54:40 UTC