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

access module summary

From: Jim Allan <jimallan@tsbvi.edu>
Date: Fri, 9 May 2008 07:50:34 -0500
To: "WAI-ua" <w3c-wai-ua@w3.org>
Message-ID: <006f01c8b1d3$45d8efc0$d18acf40$@edu>

Open issues
1. Gez question about "Persistence" of users override of author "key" value.
This should go in Keybinding
2. Keybinding - see comments below


Unless there are serious issues related to the AccessElement and the
ActivateAttribute (approve wording below) I would like us to focus on the
Keybinding editing.

We have approved the following wordings:
http://www.w3.org/WAI/UA/wiki/AccessModule/AccessElement
The access element assigns an accessibility mapping to elements within a
document. Actuating the mapping results in the element gaining focus (either
the document focus or an inspection focus, as determined by the user agent),
and, if set by the author and permitted by the user's settings, in one or
more other events being activated.
=======
http://www.w3.org/WAI/UA/wiki/AccessModule/ActivateAttribute
The activate attribute indicates whether a target element should be
activated or not once it obtains focus. The default value for this attribute
is "no", indicating that the element will not be "activated". User agents
may provide mechanisms for overriding the author setting with user-specified
settings in order to ensure that the act of moving content focus does not
cause the user agent to take any further action, as required by UAAG 1.0,
Checkpoint 9.5.

In any case, user agents MUST provide keyboard mechanisms for "activating"
any event associated with the focused element, as required by UAAG 1.0,
Checkpoint 1.2.
======
http://www.w3.org/WAI/UA/wiki/AccessModule/KeyMappingBinding

This attribute assigns a key mapping to an access shortcut. An access key is
a single character from the document character set. (editor's note: the
following sentence should either be moved or deleted entirely) <DEL>Note:
Authors should consider the input method of the expected reader when
specifying an accesskey.</DEL>
<jim> ok </jim>

Triggering an access key defined in an access element changes focus to the
next element in navigation order from the current focus that has one of the
referenced role or id values. Note that it is possible to deliver alternate
events via XMLEVENTS. It is also possible to have the target element
activated through the use of the activate attribute. Finally, it is possible
to associate additional event handlers with target which might then perform
additional actions once focus is changed. <INS>If an element accepts
multiple events that dispatch different actions, the user agent MUST provide
a way for the user to discover the all events, which events are available,
and how they are triggered.</INS>
<jim> I have concerns about the <ins> about multiple events, the activate
will only active one thing. </jim>

An access element <INS>MUST</INS> have either a targetrole or a targetid
attribute specified. If neither a targetrole nor a targetid attribute are
specified, the user agent MUST NOT define a mapping nor deliver any events.
<jim> ok</jim>

The invocation of access keys depends on the implementation. For instance,
on some systems one may have to press the "alt" key in addition to the
access key. On other systems, one generally has to press the "cmd" key in
addition to the access key. A conforming user agent MUST allow the user to
override any author-defined binding.
<jim> ok</jim>

The rendering of access keys depends on the user agent. We recommend that
authors include the access key in label text or wherever the access key is
to apply. <DEL>User agents should render the value of an access key in such
a way as to emphasize its role and to distinguish it from other characters
(e.g., by underlining it).</DEL>
<jim>I think the deleted section should stay. The author can only label what
the author knows about. And, should provide that information for all users.
IF a user chooses to change the binding, it should persist across sessions
(a UA issue not for this document).</jim>

The character assigned to a key, and its relationship to a role or id
attribute, are a suggestion of the author. User agents may provide
mechanisms for overriding, disabling, or re-assigning keys. In such user
agents, user-specified assignments MUST take precedence. <INS>A conforming
user agent MUST allow the user to override any binding that is part of the
user agent default input configuration except for conventional bindings for
the operating environment (e.g., for access to help). The keyboard
combinations offered for rebinding SHOULD include single key and key plus
modifier keys if these are available in the operating environment, as
specified in UAAG 1.0, Checkpoint 11.3</INS>
<jim> ok</jim>

If no key attribute is specified, the user agent MUST assign a key.
<INS>When a user agent assigns key values to access elements that have no
key defined for them, the user MUST provide the user with multi-modal
notification that keys have been defined for the following values: x, y, z,
etc. and that there are no specific keys defined for "foo" and "bar", so
"foo" and "bar" have been assigned keys 1 and 2.</INS>
<jim> ok - "the user MUST provide the user with multi-modal..." should be
"the user agent MUST provide the user with multi-modal..."</jim>

<INS>A conforming user agent MUST also provide a centralized view of the
current author-specified input configuration. (UAAG 1.0, Checkpoint
11.2)</INS>
<jim> ok</jim>

The activate attribute indicates whether a target element should be
activated or not once it obtains focus. The default value for this attribute
is "no", indicating that the element will not be "activated". User agents
<INS>must provide a means of identifying the shortcuts that can be used in a
document. This may be accomplished in different ways by different
implementations, for example through direct interaction with the application
or via the user's guide. The key defined by the author might not be made
available by the user agent (for example, it may not exist on the device
used, or it may be used by the user agent itself).</INS>
<jim> suggest removing the <ins> seems redundant give previous paragraphs
about override and centralized view. The <ins> seems more of a UAAG
technique.</jim>

<INS>A keyboard user will not know the value of activate when invoking the
appropriate 'key' defined for an ACCESS element. A conformant user agent
MUST, therefore, allow the user to exercise control over the user interface
in accordance with the requirements set forth by the User Agent
Accessibility Guidelines, 1.0 [UAAG10]:

    *

      Allow the user to activate, through keyboard input alone, all input
device event handlers that are explicitly associated with the element
designated by the content focus. (UAAG 1.0, Checkpoint 1.2)
    *

      Allow configuration so that moving the content focus to or from an
enabled element does not automatically activate any explicitly associated
event handlers of any event type. (UAAG 1.0, Checkpoint 9.5)
    *

      For the element with content focus, make available the list of input
device event types for which there are event handlers explicitly associated
with the element. (UAAG 1.0, Checkpoint 9.6)</INS> 
<jim> ok</jim>

<INS>Therefore, the user agent MUST make the specified action(s) available,
but may map the shortcut to a different user interaction behavior. Note that
timely notification of any remapping or reassigning of an author-defined
"key" MUST be issued to the user through the user agent's native interface,
so that the user is aware of the reconfiguration. A user agent SHOULD
provide a broad option of alert mechanisms, all of which must be issued in
conformance with user-defined settings for alert mechanisms (for example, if
an audio file is played to signify remapping or reassignment, it must be
fired in such a way that the operating system's "Show Sounds" or "Sound
Sentry" or equivalent mechanism can be used to alert a user whose device is
incapable of rendering the aural cue or for whom the processing of an audio
clip is either impractical or impossible).</INS>
<jim>This also seems like a UAAG technique. To me, it provides too much
information for the Access Module. I think the statements and references in
the previous paragraph referencing relevant checkpoints is sufficient. This
<ins> should be deleted </jim>

Jim Allan, Webmaster & Statewide Technical Support Specialist
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
Received on Friday, 9 May 2008 12:53:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:51:57 GMT