Re: Minutes: UAWG 14 May 2009

I also had an action to review UAAG 2.0 to see if we needed to add in  
any more definitions to the glossary. Is it possible to add in actions  
retrospectively?

Cheers, Henny

On 14 May 2009, at 20:05, Jim Allan wrote:

> User Agent Accessibility Guidelines Working Group Teleconference
> 14 May 2009
>
> See also: http://www.w3.org/2009/05/14-ua-minutes.html
> Attendees
>
> Present
>    KFord, Jeanne, Greg_Lowney, Allanj, Henny, Kim_Patch, sharper
> Regrets
>    Jan, MH, Mark_Hakkinen, Jan_Richards
> Chair
>    Kelly_Ford
> Scribe
>    JALLAN, jeanne, allanj
>
> Contents
>
>    * Topics
>         1. Logistics (Regrets, agenda requests, comments)?
>         2. Survey Results from 5/7 survey
> http://www.w3.org/2002/09/wbs/36791/20090505/
>         3. #53
>         4. #55 from Greg
>         5. #65
>         6. #69 http://www.w3.org/2002/09/wbs/36791/20090505/results
>         7. new survey http://www.w3.org/2002/09/wbs/36791/20090513/
>         8. #64 http://www.w3.org/2002/09/wbs/36791/20090513/ 
> results#xq3
>         9. #71 http://www.w3.org/2002/09/wbs/36791/20090513/ 
> results#xq5
>    * Summary of Action Items
>
> Summary of Action Items
> [NEW] ACTION: Greg to rework 4.1.6 [recorded in
> http://www.w3.org/2009/05/14-ua-minutes.html#action04]
> [NEW] ACTION: Greg to take #63 and turn it into a proposal for next  
> week.
> [recorded in http://www.w3.org/2009/05/14-ua-minutes.html#action02]
> [NEW] ACTION: Jim to clean up Greg#55 (4.1.10 & 11) make proposal  
> [recorded
> in http://www.w3.org/2009/05/14-ua-minutes.html#action01]
> [NEW] ACTION: JS to assist GL to write a proposal for 4.1.6 to address
> concerns of this survey [recorded in
> http://www.w3.org/2009/05/14-ua-minutes.html#action05]
> [NEW] ACTION: JS to update the draft with the updated text for  
> 4.1.8: 4.1.8
> Important Command Functions: Important command functions (e.g.  
> related to
> navigation, display, content, information management, etc.) are  
> available
> using a single or sequence of keystrokes or key combinations. (Level  
> AA)
> [recorded in http://www.w3.org/2009/05/14-ua-minutes.html#action06]
> [NEW] ACTION: JS to update the glossary entry for Keyboard commands to
> include the synonyms. [recorded in
> http://www.w3.org/2009/05/14-ua-minutes.html#action07]
> [NEW] ACTION: JS to work with Greg to take #63 and turn it into a  
> proposal
> for next week. [recorded in
> http://www.w3.org/2009/05/14-ua-minutes.html#action03]
> [NEW] ACTION: KF to minor edit 4.1.9 "does not prohibit' overriding of
> platform keys [recorded in
> http://www.w3.org/2009/05/14-ua-minutes.html#action08]
>
> <trackbot> Date: 14 May 2009
>
> <jeanne> http://www.w3.org/WAI/UA/Overview.html
>
> <jeanne> instructions for scribing http://www.w3.org/WAI/UA/scribing.html
>
> <KFord> Scribe: JALLAN
>
> <jeanne> scribe: jeanne
>
> trackbot, start meeting
>
> <trackbot> Meeting: User Agent Accessibility Guidelines Working Group
> Teleconference
>
> <trackbot> Date: 14 May 2009
>
> <scribe> chair: KFord and AllanJ
> Logistics (Regrets, agenda requests, comments)?
>
> <KFord> http://www.w3.org/2002/09/wbs/36791/20090505/results
> Survey Results from 5/7 survey http://www.w3.org/2002/09/wbs/36791/20090505/
> #53
>
> KF: We finished discussion of #53 with an action item for KFord that  
> he will
> have for next week's survey.
> #55 from Greg
>
> KF: Last week we agreed that it needed more work but there are no  
> proposals.
> Would anyone take an action item to draft a proposal.
>
> http://www.w3.org/2002/09/wbs/36791/20090505/results#xq5
>
> <AllanJ> ACTION: Jim to clean up Greg#55 (4.1.10 & 11) make proposal
> [recorded in http://www.w3.org/2009/05/14-ua-minutes.html#action01]
>
> <trackbot> Created ACTION-183 - Clean up Greg#55 (4.1.10 & 11) make  
> proposal
> [on Jim Allan - due 2009-05-21].
>
> KP: For speech input users, it is important to have a central  
> listing of all
> keyboard commands.
>
> JS: We have a requirement for a central listing of all keyboard  
> commands.
>
> KF: Do we think an option to surface the keyboard abilities is a  
> level 2.
>
> <AllanJ> +1 to KS have level 2 option to reveal keys
>
> <Henny> + 1
>
> GL: It would be useful to separate out the keyboard shortcuts in the  
> user
> interface from the keyboard shortcuts i nthe content.
> ... I think it is useful to have a level A that shows all the  
> recognized
> shortcuts in the content, and then a AA requirement for the user  
> interface,
> because it is a greater cognitive load to expect the user to  
> remember the
> keyboard shortcuts for every site.
> ... by splitting it up, we get the advantages of the content, but  
> without
> the load on the developer
>
> <Zakim> AllanJ, you wanted to say keystroke to reveal, like word  
> ribbon
>
> <scribe> ACTION: Greg to take #63 and turn it into a proposal for  
> next week.
> [recorded in http://www.w3.org/2009/05/14-ua-minutes.html#action02]
>
> <trackbot> Sorry, couldn't find user - Greg
>
> KF: As a group we need to commit to taking the action items and turn  
> it
> around as a proposal within a week, otherwise we are getting too  
> bogged down
> and not accomplishing what we need to.
>
> <scribe> ACTION: JS to work with Greg to take #63 and turn it into a
> proposal for next week. [recorded in
> http://www.w3.org/2009/05/14-ua-minutes.html#action03]
>
> <AllanJ> http://www.w3.org/2002/09/wbs/36791/20090505/results
> #65
>
> <AllanJ> Proposed: Standard text area keyboard conventions: Views that
> render text support the standard text area conventions for the  
> platform
> including, but not necessarily limited to: character keys, backspace/ 
> delete,
> insert, "arrow" key navigation (e.g., "caret" browsing), cut, copy,  
> paste,
> delete, select all, undo, navigate to start/end, navigate by  
> paragraph,
> shift-to-select mechanism, etc. (Level A)
>
> <AllanJ> +1 to proposed wording
>
> <Greg> Re Simon's propsed wording of 4.1.6, to make the title make  
> sense out
> of context, I'd modify slightly to "Standard Text Area Keyboard
> Conventions".
>
> KP: I had comments that I put in about standard wordings, and I  
> would like
> to expand the examples.
>
> <KFord> Kim's answers/comments are at
> http://www.w3.org/2002/09/wbs/36791/20090513/results
>
> JA: 4.1.6 applies to text area boxes
>
> KF: We have a guideline that tells the agent that the user gets to  
> specify
> the precedence of the processing order of the keys.
>
> KP: Only Undo seems to apply.
>
> GL: I recommend that we don't try to make it an exhaustive list of  
> examples,
> but rather give an example of categories.
> ... a lot of platforms aren't going to have standards for these.
>
> JA: but that is covered by "avavilable on the platform"
>
> GL: because it is a long list, it appears to be exhaustive.
>
> <Greg> That's a very good point: if there is keyboard access to  
> static,
> rendered text, then the UA should support platform keyboard  
> conventions
> there, too. Not just text input fields.
>
> JS: I would like to standardize our wording, either "such as" or  
> "including,
> but not limited to,"
>
> KF: we need to get the gestalt of what we want to say and look for  
> the small
> wording changes later.
>
> <Greg> I'm fine either way on standardizing the wording of  
> "including but
> not limited to" or "such as".
>
> <AllanJ> Proposed: Standard text area keyboard conventions: Views that
> render text support the standard text area conventions for the  
> platform
> including, but not necessarily limited to: character keys, backspace/ 
> delete,
> insert, "arrow" key navigation (e.g., "caret" browsing), cut, copy,  
> paste,
> delete, select all, undo/redo, navigate to start/end, navigate by  
> paragraph,
> shift-to-select mechanism,...
>
> <AllanJ> ...etc. (Level A)
>
> GL: Does this only apply to text input or interactive fields, or  
> does it
> apply to all text fields? Do we need to make it more specific?
>
> <Greg> It seems that there are two basic types of text field:  
> interactive
> and non-interactive, and interactive can be read-write or read-only.
>
> <Greg> For all interactive fields, the functionality is already  
> required to
> be available via the keyboard, but we need to make sure it follows  
> standard
> keyboard conventions.
>
> KF: Interactive text areas also apply to rendered content if you  
> support
> carat browsing to that text. But it does not apply to the title bar  
> of the
> user interface.
>
> GL: THere is an example of a web application that is emulating MS  
> WOrd, and
> using the Word keyboard conventions, and is not supporting the user  
> platform
> standards.
>
> JA: the author can make the user interface do whatever it wants, but  
> the
> browser is not aware of what the author has remapped how the keys are
> supposed to work.
> ... if the author alters that, the user agent can't be responsible  
> for what
> the author has done.
>
> <Greg> However...what about content like a text editor that  
> intentionally
> provides its own keyboard UI. For example, EmacSpeak is UA that  
> doesn't
> support platform standard keyboard UI, does it fail level A?
>
> GL: Use EMAC-speak as an example. It uses a different keyboard  
> shortcuts
> than Mac or PC or Gnome.
>
> KF: THis is only referring to editable text fields.
>
> <AllanJ> scribe: allanj
>
> <Greg> It is not currently written so as to apply only to editable  
> text
> fields.
>
> KF: good understanding of what 4.1.6 means
> ... can we defer and say technical note will clarify
> ... concerned we are going to deep
>
> JS: change views thta render text support the rendered editable text  
> areas
>
> views that render text, support the editable text area conventions
>
> KF: If you have a text box, do what is expected to support as keyboard
> accessible.
>
> <Greg> Perhaps "rendered text that can be selected or  
> modified...follow
> platform keyboard conventions" such as editing, navigation, copy and  
> paste,
> etc."
>
> GL: Emacs speak uses different UI form the platforms on which it  
> works. does
> it fail this SC
>
> All: discussion
>
> GL: at least put in ability to not use standard keyboard
>
> <Greg> Need to at least provide escape clause for cases where the  
> user wants
> to use keyboard UI that differs from the platform standard.
>
> <Greg> E.g. VIM using Ctrl+V to start selection vs. Windows using  
> Ctrl+V for
> paste.
>
> <scribe> ACTION: Greg to rework 4.1.6 [recorded in
> http://www.w3.org/2009/05/14-ua-minutes.html#action04]
>
> <trackbot> Sorry, couldn't find user - Greg
>
> <jeanne> ACTION: JS to assist GL to write a proposal for 4.1.6 to  
> address
> concerns of this survey [recorded in
> http://www.w3.org/2009/05/14-ua-minutes.html#action05]
>
> <trackbot> Created ACTION-184 - Assist GL to write a proposal for  
> 4.1.6 to
> address concerns of this survey [on Jeanne Spellman - due 2009-05-21].
>
> JA: 4.1.6 is supposed to apply to only editable areas in content -  
> iniput,
> textarea, etc.
> ... does not apply to entire viewport
>
> JS: one way to address...platform or platform emulation
> #69 http://www.w3.org/2002/09/wbs/36791/20090505/results
>
> <Greg> On Jim's 4.1.8 wording, I'd remove "unmodified keystrokes" to  
> "a
> single or sequence of keystrokes or key combinations"
>
> proposed: 4.1.8 Important Command Functions: Important command  
> functions
> (e.g. related to navigation, display, content, information  
> management, etc.)
> are available using a single keystroke, key combination, or a single  
> or
> sequence of keystrokes or key combinations. (Level AA)
> ... 4.1.8 Important Command Functions: Important command functions  
> (e.g.
> related to navigation, display, content, information management,  
> etc.) are
> available using a single or sequence of keystrokes or key  
> combinations.
> (Level AA)
>
> +1
>
> <sharper> +1
>
> <Greg> That looks good to me (except of course "Important" is vague,  
> but
> that's another issue.)
>
> <Greg> +1
>
> <KimPatch> +1
>
> Resolved: 4.1.8 Important Command Functions: Important command  
> functions
> (e.g. related to navigation, display, content, information  
> management, etc.)
> are available using a single or sequence of keystrokes or key  
> combinations.
> (Level AA)
>
> <Greg> Are we going to drop the issue of key sequences being  
> memorizable?
>
> <jeanne> ACTION: JS to update the draft with the updated text for  
> 4.1.8:
> 4.1.8 Important Command Functions: Important command functions (e.g.  
> related
> to navigation, display, content, information management, etc.) are  
> available
> using a single or sequence of keystrokes or key combinations. (Level  
> AA)
> [recorded in http://www.w3.org/2009/05/14-ua-minutes.html#action06]
>
> <trackbot> Created ACTION-185 - Update the draft with the updated  
> text for
> 4.1.8: 4.1.8 Important Command Functions: Important command  
> functions (e.g.
> related to navigation, display, content, information management,  
> etc.) are
> available using a single or sequence of keystrokes or key  
> combinations.
> (Level AA) [on Jeanne Spellman - due 2009-05-21].
>
> GL: memorized, user can enter without having to review or read to  
> see the
> next command, alternate
> ... huge cognitive issue
> ... may not belong in 4.1.8, but we don't want it to be unusable
> ... select files from a list, rather than enter whole file.
> ... need to find wording. If take away wording specifics. Do we need
> something to address - efficiency.
>
> KP: applies to speech as well
> new survey http://www.w3.org/2002/09/wbs/36791/20090513/
>
> Issue: keyboard efficiency, for screenreaders and speech users.  
> cognitive
> load from GL comments (micorsoft wordding)
>
> <trackbot> Created ISSUE-36 - Keyboard efficiency, for screenreaders  
> and
> speech users. cognitive load from GL comments (micorsoft wordding) ;  
> please
> complete additional details at
> http://www.w3.org/WAI/UA/tracker/issues/36/edit .
>
> <mhakkinen> lurking comment: use of mnemonics where possible, taking  
> into
> consideration localization issues
> #64 http://www.w3.org/2002/09/wbs/36791/20090513/results#xq3
>
> *KEYBOARD OPERATION*
>
> The functions provided to operate a user interface using only  
> *keyboard
>
> commands*, without any need for pointer actions. Examples include:
>
> sequential keyboard navigation through a GUI, keyboard shortcuts, and
>
> command line interfaces.
>
> =============================================
>
> *KEYBOARD COMMANDS*
>
> The set of signals that a user interface will accept from a keyboard  
> or
>
> keyboard emulator in a given context (e.g., with focus in a document  
> vs.
>
> with focus in the menus). Signals may be composed of one keyboard  
> event
>
> (e.g., the "Tab" key") or multiple keyboard events that occur either
>
> simultaneously (e.g., "ctrl"+"S") or sequentially (e.g.  
> "alt","F","S").
>
> For the purposes of UAAG 2.0, several types of keyboard commands are
>
> identified:
>
> (a) *Sequential Commands* are those that are not tied to any  
> particular
>
> UI controls or application functions, but rather support traversal of
>
> sets of controls (e.g., repeating "Tab" to move between all active
>
> controls, "arrow" keys to move focus through items in a list).
>
> Sequential commands help users explore what is available.
>
> (b) *Direct Commands* (also called "keyboard shortcuts" or  
> "accelerator
>
> keys") are those tied to particular UI controls or application
>
> functions, allowing the user to navigate-to or activate them without
>
> traversing any intervening controls (e.g., "ctrl"+"S" to save a
>
> document). It is sometimes useful to distinguish direct commands that
>
> are associated with controls that are rendered in the current context
>
> (e.g., "alt"+"D" to move focus to the address bar) from those that may
>
> be able to activate program functionality that is not associated with
>
> any currently rendered controls (e.g., "F1" to open the Help system).
>
> Direct commands help users accelerate their selections.
>
> (c) *Spatial Commands* are those in which the keyboard is used to
>
> control the position of controls in space (e.g., using the arrow  
> keys to
>
> move a mouse pointer by set numbers of pixels). ACCESSIBILITY NOTE:
>
> Spatial commands do not typically enhance exploration or  
> acceleration of
>
> selection of selection and should not be considered an alternative to
>
> direct or sequential commands.
>
> above from
> http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/0004.html
>
> GL: def of Direct commands looks good.
> ... replace in document "direct keyboard command' with 'direct  
> commands'
>
> JS: important to keep 'keyboard'
>
> KF: proposal is to use this as definition for 'keyboard command"
>
> <Greg> I recommend tha t the glossary entry explicitly include any  
> synonyms
> used in the document (e.g. include "Direct KEYBOARD Command" along  
> with
> "Keyboard Commands" so that a user doing a text search for the  
> string used
> in the guidelines will find the glossary entry.
>
> all: discussion of glossary structure
>
> JS: have a protocol for covering this - definitions, synonyms, etc.
>
> Resolved: use Keyboard Commands defintion at
> http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/0004.html
>
> <jeanne> ACTION: JS to update the glossary entry for Keyboard  
> commands to
> include the synonyms. [recorded in
> http://www.w3.org/2009/05/14-ua-minutes.html#action07]
>
> <trackbot> Created ACTION-186 - Update the glossary entry for Keyboard
> commands to include the synonyms. [on Jeanne Spellman - due  
> 2009-05-21].
>
> HS: question about definitions and incorporating new defintions
> ... still some missing. see
> http://lists.w3.org/Archives/Public/w3c-wai-ua/2009AprJun/0052.html
> #71 http://www.w3.org/2002/09/wbs/36791/20090513/results#xq5
>
> KF: reviews survey comments
>
> GL: this is not a Level A priority in general software guidelines
>
> KF: as I read 4.1.9, does not allow rebinding of platform  
> keybindings (alt,
> etc.)
>
> <Greg> Sounds like there are two issues: (1) should this be level A,  
> and (2)
> confusion about which keyboard UI the UA is required to let the user
> redefine, and what if any it prohibits the user from redefining?
>
> KF: what to we want UA to do with this requirement.
>
> GL: UA, minimally accessible. ??? thinking...
>
> KF: in IE* add hot key for private browsing - ctrl shhift p
> ... but if conflict, user should be alble to change that key
>
> <Greg> Why allow someone to remap keyboard commands? (a) make it  
> something
> easier for them to enter, (b) make it something that doesn't  
> conflict with
> assistive technology.
>
> KF: but not allow user to change cntl+o which opens page.
> ... if UA wants ... fine
>
> KP: speech user, trouble speaking, certain key strokes may be  
> difficult
>
> KF: should the UA allow more accessibility that the platform on  
> which it is
> running
> ... are we asking too much?
>
> <Greg> I feel it shouldn't be level A because (a) most software  
> doesn't
> allow this, thus pretty much all UA would fail to meet Level A (b)  
> because
> most assistive technology allows (or should allow) their commands to  
> be
> remapped, (c) ISO 9241-141/ANSI 200.2 make this lower priority than  
> the
> highest priority, and I don't think it makes sense for the  
> requirements for
> UA to be higher than general...
>
> <Greg> ...software in this regard.
>
> KP: having the option is good. not sure if it is too much.
>
> SH: problem conflating UA and platform accessibility.
>
> GL: rationale, make it easier to use, remove conflictions.
>
> KF: 2 questions - 1. which level
> ... 2. override ALL, or not allowed to override 'platform
> ... keys.
> ... perhaps needs to be rewritten.
> ... lower priority, leave workding
>
> agree: SH, HS, JA, JS, KF
>
> GL: concern: "except" - not prohibiting the overriding of Ctrl+o
>
> <KimPatch> agree as well
>
> <scribe> ACTION: KF to minor edit 4.1.9 "does not prohibit'  
> overriding of
> platform keys [recorded in
> http://www.w3.org/2009/05/14-ua-minutes.html#action08]
>
> <trackbot> Created ACTION-187 - Minor edit 4.1.9 "does not prohibit'
> overriding of platform keys [on Kelly Ford - due 2009-05-21].
>
>
> Jim Allan, Accessibility Coordinator & Webmaster
> Texas School for the Blind and Visually Impaired
> 1100 W. 45th St., Austin, Texas 78756
> voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
> "We shape our tools and thereafter our tools shape us." McLuhan, 1964
>
>




-- 
Henny Swan
Web Evangelist
Member of W3C Web Accessibility Initiative Education and Outreach Group
www.opera.com/developer

Personal blog: www.iheni.com

Stay up to date with the Web Standards Curriculum www.opera.com/wsc

Received on Friday, 15 May 2009 07:23:39 UTC