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
none
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
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)
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
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
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.