Contents
This section is normative for purposes of defining the integration of the XHTML Access Module into XHTML 2. The semantics of the XHTML Access Module itself are normatively defined in [XHTMLACCESS].
This module defines the access element.
| Element | Attributes | Content Model |
|---|---|---|
| access | Common, @activate, @key, @media, @order, @targetid, @targetrole | EMPTY |
Implementations: RELAX NG, XML Schema
The access element assigns a mapping between "keys" or other events to elements within a document. Actuating the mapping results in the element gaining focus and potentially in additional events being activated.
The access element assigns a mapping between "keys" or other events to elements within a document. Actuating the mapping results in the element gaining focus and potentially in additional events being activated.
An access element must 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 dispatch any events.
The access element allows an author to specify a relationship between "key(s)" or other events and one or more elements within a document. When a mapped event is triggered, one of the specified target elements gains focus, and one or more other events (such as an 'activate' event) may also be dispatched to that element. The target elements are specified by means of the @targetid or @targetrole attributes, and these elements may each contain multiple targets, to allow sequential focus by successively triggering the associated key(s) or event(s).
If the access element's @activate attribute has the value 'true', then in addition to receiving focus, the target element will be activated, if permitted by the user's settings. Additionally, using XML Events [XMLEVENTS], one or more other events may also be dispatched to the element.
An access element must have either a @targetrole or a @targetid attribute specified. If neither a @targetrole nor a @targetid attribute are specified, or if there are no matching elements in the document, the user agent MUST NOT define a mapping for this element, nor change focus nor dispatch any events based on this element.
Attributes
User agents MUST provide keyboard mechanisms for "activating" any event associated with the focused element (as per Checkpoint 1.2 of UAAG 1.0). User agents SHOULD make available the list of events associated with the focused element (as per Checkpoint 9.6 of UAAG 1.0).
The
@key attribute represents an abstraction. The use of the
name "key" for this attribute is historical and does not mean that there is
any association with a specific "key" on a keyboard,
per se.
It is up to the user agent to provide a mechanism for mapping the document
character set value(s) of the attribute to the input methods available to the user agent.
For instance, on some systems a user may have to press an "alt" or "cmd" key
in addition to the access key. On other systems there may be voice commands, or
gestures with a mouse, an eye tracking input device, etc.
Regardless of the mechanism, the result is that it
appears to the access element processor as if the
defined key was entered.
A user entering any of the keys defined in an access element moves focus from its current position to the next element in navigation order that has one of the referenced role or id values (see @activate for information on how the element may be activated). Note that it is possible to deliver alternate events via [XMLEVENTS]. Note also that the concept of navigation order is a property of the Host Language, and is not defined in this specification.
User agents MUST 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. [UAAG1] The character assigned to a key, and its relationship to a role or id attribute SHOULD be treated as an author suggestion. User agents MAY override any key assignment (e.g., if an assignment interferes with the operation of the user interface of the user agent, if the key is not available on a device, if a key is used by the operating environment). User agents MUST also allow users to override author assigned keys with their own key assignments (see Checkpoint 11.3 of UAAG 1.0). If a user chooses to change the key binding, the resultant user-defined remapping SHOULD persist across sessions.
If no @key attribute is specified, the user agent SHOULD assign a key and alert the user to the key mapping. The resultant user agent assigned key mapping SHOULD persist across sessions.
It is common for user agents to provide a visual hint for accessing features via keyboard shortcuts, such as showing the shortcut next to a menu item, or underlining the shortcut character letter in a label. The rendering of such visual hints about access keys depends on the user agent. We recommend that authors include the access key character in label text or wherever the access key is to apply. If the user agent can recognize that the currently mapped access key character appears in the label text of the element to which it is mapped, then the user agent may render the character in such a way as to emphasize its role as the access key and distinguish it from other characters (e.g., by underlining it).
A conforming user agent SHOULD also provide a centralized view of the current access key assignments (see Checkpoint 11.1 and Checkpoint 11.2 of UAAG 1.0).
Authors MUST NOT assign the same
@key value
to more than one active access element.
Note that it is possible to have an access element be inactive
through the use of the
@media attribute.
access element is intended.
When the value of this attribute matches the current processing media,
the associated access element is
considered active and processed normally; otherwise it is
inactive and ignored.
The default value for this attribute is all.
Example
<style src="style.css" type="text/css" media="screen" /> <span src="photo.jpg" media="screen">Me at work</span> <span src="photo-hires.jpg" media="print">Me at work</span>
access
element should determine the navigation order for its
matching elements. The default value,
document, indicates that the items MUST be traversed in
document order. The alternate value, list,
indicates that the navigation order of matching elements
is determined by the author-defined order of items in the list of
@targetid or
@targetrole attribute values.
For the sake of determining navigation order, elements in the
document that match the values in the
@targetid or
@targetrole attributes are called matching elements,
and all elements that match the same value are members of an element
group. Note: since the id of an element must be unique
within a valid XML document, in such documents, each element
group based on
@targetid values consist of
no more than one
matching element.
For each navigation operation, the navigation order for both document-order and list-order is sensitive to the current focus element. For document-order, if no element currently has focus, the first matching element in the document MUST be the focus target; if an element does have focus, the next matching element in the document MUST be the focus target. For list-order, the focus target navigation order is determined as follows:
access element
currently has focus, the focus target MUST be the first
element in document order that matches the first element group.
If there is no such element, then the focus target is the
first element that matches the second element group, and so on.access element
already has focus:
The location of the next matching element MUST be determined
each time the access element is triggered, since it is possible
that between events the contents of the document will have changed.
Access element that focuses into a field
<access key="s"
title="Social Security Number"
targetrole="ss:number" />
Accessing a table of contents
<access key="c"
title="Table of Contents"
targetrole="toc" />
Access that moves to the main content
<access key="m"
title="Main content"
targetrole="main" />
Access that moves among form controls in document order
<access key="i"
title="Form Controls"
order="document"
targetrole="button checkbox option radio textbox" />
Access that moves among form controls in specific order
<access key="i"
title="Form Controls"
order="list"
targetrole="button checkbox option radio textbox" />
Access element that goes to a specific element
<access key="u"
title="Username"
targetid="username" />
Access element with no specific key mapping
<access title="Navigation bar" targetrole="navigation" />