The Control module defines the control
element which allows an author to creating mappings between user input and document or webapp functionality and navigation options.
This document does not have any official W3C status!!!! It is a proposed revision of the XHTML Access Module draft specification produced by the W3C XHTML2 Working Group. It is intended as a proposal, and does not supersede that specification.
This specification was not produced by the W3C SVG Working Group, but it was developed with both X/HTML and SVG in mind.
Public discussion may take place on www-html@w3.org (archive) or www-archive@w3.org (archive).
control
element
target-attribute
= NCName
target-value
= list-of-strings
trigger
= Key Identifiers
activate
= ( true | false* )order
= ( document* | list )media
= MediaDescThis section is informative.
Most desktop applications provide a way for the user to navigate or activate specific functionality through the use of the keyboard alone, particularly by using keyboard shortcuts, which are a single key or combination of keys. Web pages and Web Applications have traditionally been less able to do so due to conflicting shortcuts within the operating system or browser itself, and due also to a lack of a coherent robust mechanism. Thus, Web resources have relied primarily on interaction via pointing devices, such as a mouse. This specification defines a way to assign character mappings (e.g. keyboard shortcuts, or keys combinations) to navigate to specific elements or sequential sets of elements, which may be activated by the user, or which may be activated immediately, based on the author's intent. It also addresses the need for end users to be able to remap these keys for personalizing the interaction, and describes how a browser might expose these character mappings to the user.
This document contains a single module designed to be used to help make more effective at supporting the needs of the Accessibility Community. It has been developed in conjunction with the W3C's
Web Accessibility Initiative and other interested parties. The module herein contains functionality that is the logical successor to the accesskey
attribute [HTML4], [XHTML1].
This section is normative.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Note that all examples in this document are informative, and are not meant to be interpreted as normative requirements.
Control is not a stand-alone document type. It is intended to be integrated into other XHTML Family Markup Languages. A conforming Control document is a document that requires only the facilities described as mandatory in this specification and the facilities described as mandatory in its host language. Such a document must meet all the following criteria:
The document MUST conform to the constraints expressed in its host language implementation.
If the host language is in the XHTML Namespace, there are no additional requirements. If the host language is not in the XHTML namespace, and the host language
does not incorporate this module into its own namespace, then the document MUST contain an xmlns:
declaration for the Control namespace [XMLNAMES]. The namespace for Control Module is defined to be http://www.w3.org/1999/xhtml
. An example start tag of a root element might look like:
Example
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" >
When Control is included in a host language, all of the facilities required in this specification MUST be included in the host language. In addition, the element defined in this specification MUST be included in the content model of the host language. The element defined in this specification MAY be incorporated into the namespace of the host language, or it MAY remain in the XHTML namespace. Finally, Control was designed to be implemented along with the XHTML Role Attribute Module [XHTMLROLE].
A conforming user agent MUST support all of the features required in this specification.
This section is normative.
This module defines the control
element.
Element | Attributes | Minimal Content Model |
---|---|---|
control |
activate , media , order , target-attribute , target-value , trigger |
PCDATA |
When this module is used, it adds the control
element to the content model of the head
element as defined in the XHTML Structure Module, or to the content model of any SVG element. This is not a rendering element in the SVG context.
Implementations: XML Schema, XML DTD
control
elementThe control
element assigns a mapping between key identifiers or specified events to elements within a document. Actuating the mapping results in the element gaining focus and potentially in additional events being activated.
The control
element allows an author to specify a relationship between key identifiers (or specified 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 combination of the target-attribute
and target-value
attributes, and the list of elements target by each control
element may contain multiple targets, to allow sequential focus by successively triggering the associated key(s) or event(s).
If the control
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.
A control
element must have a target-value
attribute specified. If this attribute is not 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.
The child content of the control
element shall serve as a human-readable description of the action performed by the element. For example, a control
element which creates a focus ring among all the elements with the role 'nav'
might be labeled by its child content as "Cycles through page navigation options", while a control
element which activates a media control may be labeled as "Play audio". A conforming user agent may display the textual child content, but should not do so within the context of the page content itself. For example, a browser may choose to present the control
options within a user-interface menu.
Attributes
target-attribute
= NCName
The value of the target-attribute
attribute indicates the name of the attribute which must be searched for matches to the values specified in the target-value
. The default value is "role", indicating that the role
attributes in the document will serve as matching candidates.
Note that the target-attribute
value does not enforce validity matches on candidate attributes or their values. For example, if a matching attribute value is found on an element which cannot have that attribute in a valid document, the matching of that element must still be mapped (unless the user agent omitted the attribute from the DOM).
target-value
= list-of-strings
The target-value
attribute specifies one or more space separated strings
, each of which serve as potential matches for elements with that same value in the attribute indicated by the target-attribute
. If a potential target attribute has more than one value (e.g., it is a list of strings, such as with the role
or class
attributes), then any given string in the list of target-value
values must be a match for the element to added to the list of matching elements; multiple matches must not add the element to the list of matching elements more than once.
Note that the target-value
values do not enforce validity matches on candidate attributes or their values. For example, if the attribute specified is id
, and multiple matching elements are found which have the same id
value, the matches must still be mapped, even though and id
value must be unique within a valid XML document.
trigger
= Key Identifiers
This attribute shall assign one or more key mappings to a control
shortcut. The value of the trigger
attribute shall be a comma- or space-separated list of one or more key identifiers from DOM Level 3 Events.
The trigger
attribute represents an abstraction. The use of the term "key identifiers" for the value type of 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 control
element processor as if the defined key identifier was entered.
When a user activates a control
element by means of its trigger
attribute value, the user agent MUST move focus from the document's current focus position to the next element in navigation order that has one of the referenced attribute values (see activate
for information on how the target 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 key identifier assigned to a key, and its relationship to an attribute value SHOULD be treated as an author suggestion. User agents MAY override any key identifier assignment (e.g., if an assignment interferes with the operation of the user interface of the user agent, if the key identifier is not available on a device, if a key identifier is used by the operating environment). User agents MUST also allow users to override author assigned key identifiers with their own key identifier assignments (see Checkpoint 11.3 of UAAG 1.0). If a user chooses to change the key identifier binding, the resultant user-defined remapping SHOULD persist across sessions.
If no trigger
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 control key identifier in label text or wherever the "access key" is to apply. If the user agent can recognize that the currently mapped control key identifier 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 control key identifier assignments (see Checkpoint 11.1 and Checkpoint 11.2 of UAAG 1.0).
Authors MUST NOT assign the same trigger
value to more than one active control
element. If more than one active control
element has the same trigger
value, a conforming user agent must only assign a mapping to the first active control
element in document order. Note that it is possible to have an control
element be inactive through the use of the media
attribute.
Authors are cautioned that not all characters are appropriate as control key identifier values, since not all characters can be accessed directly from the keyboard. Some key identifiers can only be generated when combined with base characters. Examples include: combining vowels or tone marks, such as are used in Arabic, Southeast Asian, or Indic scripts. These are more difficult to communicate to users because, while they can often be typed independently, they are not typically rendered independently and the user might not know which character is intended as the key mapping. Finally, authors are cautioned that any key available in one keyboard might not be available in a different keyboard layout, or might be located in a different position than the author anticipates.
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]).
If the activate
attribute has a value of "true", and if there is more than one matching element, then only the first matching element must be activated, in the navigation order determined by the order
attribute.
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).
order
= ( document* | list )The order
attribute indicates how this control
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 target-value
attribute values.
For the sake of determining navigation order, elements in the document that match the values in the target-value
attributes
are called matching elements, and all elements that match the same value are members of an element group.
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:
control
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.control
element already has focus:
The location of the next matching element MUST be determined each time the control
element is triggered, since it is possible that between events the
contents of the document will have changed.
A host language MUST define any circumstances under which an element would not qualify as a matching element (e.g., in XHTML 1.1 if a Form control were "disabled" it might not qualify.)
If the prefix is omitted from a CURIE, as the default value of http://www.w3.org/1999/xhtml/vocab#
MUST be used. [XHTMLROLE] Many common accessibility roles are defined by the vocabulary at that URI. See [XHTMLVOCAB] for more
information.
media
= MediaDescThe value of this attribute is a comma-separated list of media descriptors for which this control
element is intended. When the value of this attribute matches the current processing
media, the associated control
element is considered active and processed normally; otherwise it is inactive and ignored. The default value for this attribute is
all
.
Control element that focuses into a field
<control trigger="s" target-value="ss:number">Social Security Number</control>
Accessing a table of contents through the control element
<control target-value="toc" trigger="c">Table of Contents</control>
Control element that moves to the main content
<control trigger="m" target-value="main">Main content</control>
Control element that moves among form controls in document order
<control trigger="i" order="document" target-value="button checkbox option radio textbox">Form Controls</control>
Control element that moves among form controls in specific order
<control trigger="i" order="list" target-value="button checkbox option radio textbox">Form Controls</control>
Control element that goes to a specific element
<control trigger="u" target-attribute="id" target-value="username">Username</control>
Control element with no specific trigger mapping
<control target-value="navigation">Navigation bar</control>
This appendix is normative.
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xmlns:xh11d="http://www.w3.org/1999/xhtml/datatypes/" > <xs:import namespace="http://www.w3.org/1999/xhtml/datatypes/" schemaLocation="xhtml-datatypes-1.xsd" /> <xs:annotation> <xs:documentation> This is the XML Schema module for SVG Control $Id: Overview.html,v 1.2 2009/04/23 13:42:54 smccarro Exp $ </xs:documentation> <xs:documentation source="xhtml-copyright-1.xsd"/> <xs:documentation source="http://www.w3.org/TR/xhtml-role#A_role"/> </xs:annotation> <xs:attributeGroup name="xhtml.control.attlist"> <xs:attributeGroup ref="xhtml.Common.attrib"/> <xs:attribute name="activate" default="no"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="yes"/> <xs:enumeration value="no"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="key" type="xh11d:Character"/> <xs:attribute name="media" type="xh11d:MediaDesc"/> <xs:attribute name="order" default="document"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="document"/> <xs:enumeration value="list"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="target-attribute"> <xs:simpleType> <xs:list itemType="xs:IDREF"/> </xs:simpleType> </xs:attribute> <xs:attribute name="target-value" type="xh11d:CURIEs"/> </xs:attributeGroup> <xs:group name="xhtml.control.content"> <xs:sequence/> </xs:group> <xs:complexType name="xhtml.control.type"> <xs:group ref="xhtml.control.content"/> <xs:attributeGroup ref="xhtml.control.attlist"/> </xs:complexType> </xs:schema>-->
This appendix is normative.
DTDs are icky. This specification wouldn't touch them with a ten-foot pole.
This appendix is normative.
This section is informative.
Thanks to the W3C XHTML 2 Working Group and the accessibility community for providing the raw materials for this draft proposal. Particular thanks to the editors of the XHTML Access Module, listed below; the names of these editors were removed from this proposal out of courtesy, but will be reinstated should any wish.