- From: Greg Lowney <gcl-0039@access-research.org>
- Date: Wed, 10 Jun 2009 22:00:19 -0800
- To: w3c-wai-ua@w3.org
- Message-ID: <4A309D73.30403@access-research.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).
*/_4.1.10_/
*
*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
content*
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
functionality.
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
except:
* stylistic conventions (ANSI says "they mean to" while ISO says
"he/she intends pressing", and ISO puts keyboard commands in
quotes)
* 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)
*/_4.1.11_/
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
customization):*
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?
*/_4.1.12
_/**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
override."
*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.
*/_4.1.13
_/**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
shortcuts".
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
/_**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
following:
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.
Thanks,
Greg
Received on Thursday, 11 June 2009 05:04:49 UTC