W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2009

Comments on proposed 4.1.9 through 4.1.13

From: Greg Lowney <gcl-0039@access-research.org>
Date: Wed, 10 Jun 2009 22:00:19 -0800
Message-ID: <4A309D73.30403@access-research.org>
To: w3c-wai-ua@w3.org
Here are some thoughts on the proposed 4.1.10 through 4.1.13 from the 
UAWG Survey for 4 June 2009. I will paste a link to this email in the 
survey form. (I haven't reformatted this as plain text, so I hope it 
comes through intelligibly; if not I can re-post a plain text version.)

I feel that wording inconsistencies between the proposed SCs 4.1.9 
through 4.1.13 lead to confusion. I think these are the goals they are 
trying to convey:

   1. Allow user to customize (disable/enable, edit, add, delete)
      keyboard shortcuts in UA UI (4.1.9)
   2. Allow user to customize (merely disable/enable?) keyboard
      shortcuts in rendered content (4.1.10)
   3. Allow use to save customization to keyboard shortcuts in UA UI and
      rendered content (4.1.11)
   4. Inform the user when the UA UI or rendered content has keyboard
      shortcuts which can't be generated on the current keyboard, and
      allow substitution (4.1.12)
   5. Allow user to reset UA UI keyboard shortcuts to their default
      values as a single operation (rather than having to look up and
      manually set each one back to its original value) (4.1.13)

I would add the following high-level goals:

   6. Leverage existing SCs where we can avoid adding new ones
   7. Harmonize with ISO 9241 and ANSI 200.2 where possible

My comments/suggestions are divided into two categories: Recommendations 
and Comments on Proposed Wording (which would often be made moot if the 
recommendations are followed).

*Existing Proposed 4.1.10: User Override of Author Keyboard Commands: 
*The user can override any recognized author supplied keyboard shortcuts 
(e.g accesskeys). (Level A)
* *
*Recommendations on the proposed 4.1.10 (allowing user to override 
keyboard shortcuts in rendered content):*

   1. I recommend using something like the following wording. It splits
      disabling all keyboard shortcuts (which is easy to do) from
      customizing them individually (which is hard). The latter could be
      omitted if you prefer.

    *4.1.10 Allow users to disable keyboard shortcuts in rendered content*
    The user should be allowed to disable and re-enable _recognized_
    _keyboard shortcuts_ in _rendered content_. (Level A)
    NOTE: The user agent may allow the user to disable and re-enable all
    recognized keyboard shortcuts together in a single operation, or may
    allow the user to disable and re-enable such shortcuts individually.
    4.1.10b Allow users to customize keyboard shortcuts in rendered
    The user should be allowed to disable, enable, edit, add, or remove
    _recognized_ _keyboard shortcuts_ in _rendered content_. (Level AAA)
    *Notes on relevant definitions:*
             _Recognized_ applies in markup language only
             _Keyboard shortcuts_ are not yet defined, but I'm writing
    up a suggestion
             _Rendered content_ refers only to sight and hearing

*Other comments on the proposed 4.1.10:*

   2. The draft wording is unclear whether it is requiring the user have
      (a) the option to turn on and off all shortcuts in rendered
      content as a single operation (that is, all are on or all or off),
      or (b) that the user be able to turn them on or off individually,
      or (c) that the user be able to substitute new shortcuts
      individually. I therefore split them into one SC for (a), which is
      easy to do, and one for (b) and (c), which are hard. (Note that
      the proposed wording of 4.1.11 says "all" keyboard shortcuts, in
      contrast to the proposed 4.1.10 which says "any".)
   3. ISO 9241-171 and ANSI 200.2 use a single SC for customizing
      keyboard shortcuts in both application UI and rendered content,
      and we could combine them as well. The main reason to keep 4.1.9
      (customize keyboard shortcuts in UA UI) and 4.1.10 (customize
      keyboard shortcuts in rendered content) separated would be if they
      have different priority levels, or so we could get rid of 4.1.9
      when and if we can simply reference ISO 9241-171 for all UI
      accessibility requirements that are not specific to Web
   4. ISO 9241-171 and ANSI 200 use the term "accelerator keys" for
      which "keyboard shortcuts" are listed as a synonym. The choice of
      terms for UAAG depends on what document we're trying to harmonize
      with. Which use "keyboard shortcuts" and which do we want to
      harmonize with?
   5. Per my comment #52, I recommend against using "author supplied
      [keyboard shortcuts]", and instead using a more inclusive phrase
      such as "recognized keyboard shortcuts in rendered content", which
      would include any specified by style sheets and the like
      regardless of their source.
   6.  If we wish to require or recommending allowing users to customize
      individual keyboard shortcuts in rendered UI, it would help give
      some specific examples of appropriate UI. Would that include
      something like (a) the user navigates to a link that has an
      accesskey property, invokes a popup context menu that includes a
      command to replace the accesskey, and/or (b) the UA provides a
      menu that displays a list of all recognized keyboard shortcuts in
      rendered content, and allows the user to disable, re-enable, or
      alter them?
   7. Per my earlier comment, *if* the meaning is to let the user
      replace (rather than just disable) existing keyboard shortcuts,
      why not allow them to assign new ones? I've made that explicit in
      my proposal.
   8. I recognize that saying "in rendered content" is redundant given
      the definition of "recognized" says it is only relevant in
      rendered content, but I think including the phrase helps greatly
      in making the SC clear when read on its own.
   9. Ideally I'd like to see us harmonize with ISO 9241-171 and ANSI
      200.2, and while I've had trouble changing this to their very
      general wording, but I'd be willing to go in that direction. Here
      is what they say:


     From ISO 9241-171 ("Ergonomics of human-system interaction -- Part
    171: Guidance on software accessibility"):

        *9.3.19 Allow users to customize accelerator keys*
        Software should enable users to customize the assignment of
        accelerator keys to actions.
        EXAMPLE 1 An application allows the user to create macros that
        carry out one or more actions and to assign these macros to
        accelerator keys.
        EXAMPLE 2 A user frequently presses "Ctrl+P" when he/she intends
        pressing "Ctrl+O", so disables "Ctrl+P" as a shortcut for the
        Print function.

    ANSI 200.2 ("ANSI/HFES 200.2 Human factors engineering of software
    user interfaces -- Part 2: Accessibility") uses identical wording

        * stylistic conventions (ANSI says "they mean to" while ISO says
          "he/she intends pressing", and ISO puts keyboard commands in
        *  conventions for indicating priority ( ISO says "shall" or
          "should", while ANSI always says "should" but adds tags for
          Level 1, Level 2, or Level 3)


Proposed Draft 4.1.11: "Keyboard Command Override Persistence: *The user 
must have an option to save the override of all keyboard shortcuts so 
that the rebinding persists beyond the current session. (Level A) [this 
may be covered in 4.5.1 Save Settings)"
* *
*Recommendations on the proposed 4.1.11 (saving keyboard shortcut 

   1. I recommend removing this as a separate SC and instead folding it
      into a general SC about the persistence of user preference
      settings. We could include a cross-reference, or include it in the
      list of examples of things that 4.5.1 requires saving.

*Other comments on proposed 4.1.11:*

   2. See most of my comments above re the proposed 4.1.10; most of them
      apply here as well.
   3. The proposed 4.1.10 is limited to "author supplied keyboard
      shortcuts" (meaning recognized shortcuts in rendered content") but
      the proposed 4.1.11 does not include any such limitation. Is it
      intended to be for both rendered content and UA UI?
   4. I don't feel it is reasonable to ask UA to allow the user to allow
      the user to replace individual shortcuts in rendered content and
      save those substitutions between sessions. Firefox can do it only
      with third-party add-ons (e.g. Greasemonkey); can any UA do it
      today natively? I would reduce that to AA or AAA. Accesskey in as
      interesting example because it cannot be used to provide
      functionality which isn't already available through other means.,
      which means the user could turn off access keys in the entire
      content without losing functionality, only efficiency.  This
      suggests that any success criteria around disabling or
      substituting access keys should not be Level A.  On the other
      hand, other Web technologies may allow content to specify shortcut
      keys that have no other means of activation, in which case this
      would have higher priority. On yet another hand, there are other
      means that the UA could provide to let the user access those
      functions that would allow avoiding shortcut conflicts but didn't
      involve substituting another keyboard shortcut. Another example of
      difficulty: if the user selects a field and overrides its
      accesskey using the UA UI, and this field is one of five on the
      Web page that are identical except for their accesskey values, if
      the UA is supposed to remember these settings, what does it use to
      distinguish one from another? The accesskey? The position in the
      document order? The spatial location? What if the document is
      different the next time it is viewed?


_/**Existing Proposal for 4.1.12: "Keyboard Command conflict:* The user 
agent should inform the user when a specified keybinding in content or 
the user interface is missing from the user's keyboard and allow an 
*Recommendations on the proposed 4.1.12 (notify of keybindings not 
available on the user's keyboard):*

   1. I recommend deleting this unless we can do a better job of
      explaining both the need and technical feasibility. Re need, most
      platforms allow the user to emulate those keys using key
      combinations or other utilities, and shortcuts are already not
      supposed to be the only UI for functions, so is the need really
      there? Re feasibility, are you sure it is possible on all major
      platforms for the UA to know when a specific key is lacking on the
      user's physical keyboard? Do any UA check it today for any reason?

*Other comments on the proposed 4.1.12:*

   2. The term "keybindings", not using the term "recognized", etc.
       here do not match the terminology of 4.1.9, 4.1.10, etc.
   3. The term "override" in this context is vague. If it means allowing
      the user to assign a replacement keyboard shortcut, we should say
      something that specific.


_/**Existing proposal for 4.1.13 "Keyboard Command Reset:* The user has 
the option to restore all keyboard overrides to their default values."
*Recommendations on the proposed 4.1.13:*

   1. I recommend omitting this, because I think this should be handled
      by a more general SC for resetting all user preference settings,
      rather than one specific to this group of SCs, another for another
      group, etc. I'll do a separate post about that, including the
      wording from ISO 9241-171 and ANSI 200.2.

*Other comments on the proposed 4.1.13:*

   2. Is this meant to cover both UI and rendered content, and just the
      current content or all rendered content? What level of granularity
      would be too much or not enough to meet the intent? For example,
      one could argue that the guideline allowing the user to change
      shortcuts would allow them to set them back to the default
      value--or any other value they choose, but I think the intent is
      that the user should not have to look up what the default value
      was, right? Similarly, if the user has carefully redefined
      hundreds of keyboard shortcuts on dozens of web sites, and then
      really needs to reset one but the only way to do so means
      resetting all of them, is that doing a good job of meeting the
      user's needs?
   3. The proposed term "keyboard overrides" is neither used nor defined
      in the document. Thus I'd change to something like "user-provided
      keyboard shortcut substitutions" or "user-substituted keyboard
   4. If you feel like keeping this as a separate SC, I suggest wording
      more like "_The user has the option_ to cancel, as a single
      operation, all user-specified _overrides_ to keyboard shortcuts in
      _keyboard shortcuts_ in the _user agent user interface_ and in
      _rendered content_", or "_The user has the option_ to reset all
      _keyboard shortcuts_ in the _user agent user interface_ and in
      _rendered content_ to their default values as a single operation."


/_**Other high-level comments: *

   1. Noting that Firefox allows the user to add persistent
      customization of keyboard shortcuts to specific Web pages only
      with a third-party add-on (Greasemonkey) brings up a more general
      question: If a UA complies only with the addition of third-party
      add-ons, does that let them claim compliance? Does it even if
      those add-ons cost money, or is not available for all platforms?
   2. Rather than have a new SC that says that the user needs an option
      to reset these specific user settings to their defaults, weren't
      we going to have a general one that allowed resetting all user
      preference settings to their default values? ISO 9241-171 has the
   3. Determining the appropriate Level of any proposed SCs should be
      based on a clear understanding of their benefits and costs to
      users and UA developers, but we have been lax about including
      those in the document or in our posts. I'll separately post some
      language about that.

Received on Thursday, 11 June 2009 05:04:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:39 UTC