# 15. XHTML Access Module

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.

## 15.1. The access element

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

The Common collection
  A collection of other attribute collections, including: Bi-directional, Core, Edit, Embedding, Events, Forms, Hypertext, I18N, Map, Metainformation, and Role

activate = ( "true" | "false"* )
  The @activate attribute indicates whether a target element should be activated or not once it obtains focus. The default value for this attribute is "false", indicating that the element will not be "activated". 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 per Checkpoint 9.5 of UAAG 1.0 [UAAG1]).

  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).

key = Characters
  This attribute assigns one or more key mappings to an access shortcut. The value of is attribute is one or more single characters from the document character set.

  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.

media = MediaDesc
  The value of this attribute is a comma-separated list of media descriptors for which this `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>

order = ( "document"* | "list" )
  The @order attribute indicates how this `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:

  - If no matching element of this `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.
  - If a matching element of this `access` element already has focus:
    1. If there are additional matching elements of the same element group in document order, then focus MUST be sent to the next matching element of the same element group.
    2. Otherwise, focus MUST go to the first matching element (in document order) of the next element group.
    3. If there are no remaining elements groups, then the search MUST resume from the first element group.

  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.

targetid = IDREF
  The @targetid attribute specifies one or more space separated IDREFs related to target elements for the associated event (i.e., the node to which the event should be delivered).

targetrole = CURIEs
  The @targetrole attribute specifies space separated list of CURIEs that maps to an element with a @role attribute with the same value.

### 15.1.1. Examples

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" />