W3C

The Access Element

Enabling Generic Document Accessibility

PFWG Internal Draft, 19 May 2010

This version:
http://www.w3.org/PF/2009/ED-access-element-20100519
Latest version:
[short URI not yet available]
Previous versions:
http://www.w3.org/TR/xhtml-access
http://www.w3.org/TR/2008/WD-xhtml-access-20080526
http://www.w3.org/MarkUp/2009/ED-xhtml-access-20090423
Editors prior to May 2009:
Mark Birbeck, webBackplane mark.birbeck@webBackplane.com
Shane McCarron, Applied Testing and Technology, Inc.
Steven Pemberton, CWI/W3C®
T. V. Raman, Google, Inc.
Richard Schwerdtfeger, IBM Corporation
Editors since 2010:
ToDo: get list of editors from chair; those listed below are those who have either volunteered to work on this draft or who have significantly contributed to it.
Shane McCarron, Applied Testing and Technology, Inc.
T. V. Raman, Google, Inc.
Gregory J. Rosmaita, invited expert
Doug Schepers, W3C (contributed @order and @media)
Richard Schwerdtfeger, IBM Corporation

The English version of this specification is the only normative version. Non-normative translations may also be available.

Copyright © 2007-2010 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

Abstract

The Access Element defines an element that, when used in conjunction with XML and HTML derived markup languages, enables a more robust accessibility model than is presently possible. The Access Element also provides a means of designating a navigational flow for document formats, such as SVG, which lack an inherent navigational document order.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

Although this document is a first editor's draft, it is based on the Last Call Working Draft of the XHTML Access Module, produced by the XHTML 2 Working Group. The XHTML Access Module has been used as the basis of this document, as the XHTML Access Module reflects a consensus among the members of the XHTML2 Working Group, in conjunction with extensive input from the User Agent Accessibility Guidelines Working Group and others in the accessibility and standards community.

[Insert boilerplate W3C charter and patent policy info here]

Publication as an Editor's Draft does not imply endorsement by the W3C Membership or any particular W3C Working Group. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

ToDo: ascertain correct emailing list pointers. Please report errors in this specification to public-pfwg-comments (public archive for the public-pfwg-comments mailing list). It is inappropriate to send discussion email to the public-pfwg-comments address. Public discussion may take place on wai-xtech@w3.org (public archive for the wai-xtech mailing list).

Document Formatting Conventions

Every effort to keep the document format as simple and clean as possible has been made. This is not only a "editor's draft", but a model of how W3C documents should be marked up in order to maximize their usability, by documenting conventions used in the formatting of the draft.

The document's format is a product of Cascading Style Sheets (CSS). In this draft, items which need to be done or investigated further are presented as white text on a black background. Code samples and examples are set to display green text on a white background. Improper code samples and examples are set to display red text on a white background.

Use of WCAG 2.0 Technique C7 has been used in this document to disambiguate links with identical hyperlink text, particularly in the References section.

Table of Contents

1. Introduction

This section is informative.

This document contains a single element designed to be used to help make XML and HTML-family markup languages 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. It provides a generic mechanism for defining the relationship between document components and well-known accessibility vocabularies.

2. Conformance Requirements

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.

2.1. Document Conformance

The Access element is not a stand-alone document type. It is intended to be integrated into other XML and HTML Family Markup Languages. A conforming implementation of the Access element 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:

  1. The document MUST conform to the constraints expressed in its host language implementation.

  2. If the host language is not in the XHTML namespace, and the host language does not incorporate this element into its own namespace, then the document MUST contain an xmlns: declaration for the XHTML Access namespace [XMLNAMES]. The namespace for XHTML Access Element is defined to be http://www.w3.org/1999/xhtml. An example start tag of a root element might look like the following:

    Example

    <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" >

2.2. Host Language Conformance

When the Access Element 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, the Access Element requires the availability of the Role Attribute Module [ref XHTML Role Successor] and of the HTML5/XHTML5 Global Attribute Collection as defined in Section 3.2.3. of HTML5/XHTML5 [HTML5].

2.3. User Agent Conformance

A conforming user agent MUST support all of the features required in this specification.

3. The Access Element

This section is normative.

This document defines the access element.

Elements and Attributes in Text Module

Element:
access
Attributes:
Common, activate, key, order, targetid, targetrole
Minimal Content Model:
EMPTY

ToDo: Ascertain if the following are needed, and if not, what is needed in their stead

Implementations: XML Schema, XML DTD

3.1. The access element

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.

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 deliver any events.

Attributes

3.1.1. activate = ( yes | no* )

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 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 [UAAG1]).

3.1.2. key = Character

This attribute assigns a key mapping to an access shortcut. An access key is a single character from the document character set.

Triggering the access key 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 (consult activate for information on how the element may be activated). Note that it is possible to deliver alternate events via [XMLEVENTS].

The invocation of access keys depends on the implementation. For instance, on some systems one may have to press an "alt" or "cmd" key in addition to the access key.

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 (consult 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.

The rendering of 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 (consult Checkpoint 11.1 and Checkpoint 11.2 of UAAG 1.0 [UAAG1]).

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

MediaDesc

The MediaDesc attribute is a comma-separated list of media descriptors. The following is a list of recognized media descriptors:

screen
Intended for non-paged computer screens.
tty
Intended for media using a fixed-pitch character grid, such as teletypes, terminals, or portable devices with limited display capabilities.
tv
Intended for television-type devices (low resolution, color, limited scrollability).
projection
Intended for projectors.
handheld
Intended for handheld devices (small screen, monochrome, bitmapped graphics, limited bandwidth).
print
Intended for paged, opaque material and for documents viewed on screen in print preview mode.
braille
Intended for braille tactile feedback devices.
aural
Intended for speech synthesizers.
all
Suitable for all devices.

Future versions of HTML, XHTML and XML-derived dialects, may introduce new values and may allow parameterized values. To facilitate the introduction of these extensions, conforming user agents must be able to parse the media attribute value as follows:

  1. The value is a comma-separated list of entries. For example, is mapped to:
  2. Each entry is truncated just before the first character that isn't a US ASCII letter [a-zA-Z] (ISO 10646 hex 41-5a, 61-7a), digit [0-9] (hex 30-39), or hyphen-minus (hex 2d). In the example, this gives:
  3. A case-insensitive match is then made with the set of media types defined above. User agents may ignore entries that don't match. In the example we are left with screen and print.

Note. Style sheets may include media-dependent variations within them (e.g., the CSS @media construct). In such cases it may be appropriate to use "media=all".

3.1.4. 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:

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.

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

3.1.5. targetid = IDREFs

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

3.1.6. targetrole = named role values

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

If a targetid and a targetrole are both specified for an element, the targetid attribute value MUST take precedence.

The default value of http://www.w3.org/1999/xhtml/vocab# MUST be used.

Address the following issue and remove issue marker from draft.

In furtherance of completion of PFWG Issue 211 (query XHTML2 and SVG on whether mixing roles and ids with targetrole and targetid for @order is ok), here are some scenarios to consider:

  1. targetid and targetrole defined:
    • document says targetid gets precedence;
    • SHOULD (rather than just "MAY") the user agent have to make the targetrole values available on user command/override?
  2. targetid and targetrole values used for @order:
    • is this problemmatic?
    • how are user agents expected to handle this mixed list? follow it from ID to named role value to ID to ID to named role value, ad infinitum?

Examples

This section is informative.

ToDo: Improve quality and variety of examples. Those which appear below are inhereted from the XHTML Access Module

Access element that focuses into a field

<access key="s"
title="Social Security Number"
targetid="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"
activate="yes" />

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

ToDo: Ascertain if the following appendicies are needed, and if not, what is needed in their stead

A. Schema Implementation

This appendix is informative.

The schema implementation of the Access Element conforms to the requirements defined in [XHTMLMOD]. It is included here as an example implementation.

A.1. Access Element Module

<?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 XHTML Access
      $Id: Overview.html,v 1.1 2008/05/26 22:15:16 jules 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.access.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="targetid">
            <xs:simpleType>
                <xs:list itemType="xs:IDREF"/>
            </xs:simpleType>
        </xs:attribute>
        <xs:attribute name="targetrole" type="xh11d:CURIEs"/>
    </xs:attributeGroup>
    <xs:group name="xhtml.access.content">
        <xs:sequence/>
    </xs:group>
    <xs:complexType name="xhtml.access.type">
        <xs:group ref="xhtml.access.content"/>
        <xs:attributeGroup ref="xhtml.access.attlist"/>
    </xs:complexType>
</xs:schema>

B. DTD Implementation

This appendix is normative.

The DTD implementation of XHTML Access Module conforms to the requirements defined in [XHTMLMOD]. Consequently, it provides a Qualified Names sub-module, and a module file for the XHTML Access Module defined in this specification.

B.1. Qualified Names Module

<!-- ....................................................................... -->
<!-- XHTML Access Qname Module  ............................................ -->
<!-- file: xhtml-access-qname-1.mod

     This is XHTML Access - the Access Attribute Module for XHTML.

     Copyright 2007-2008 W3C (MIT, ERCIM, Keio), All Rights Reserved.

     This DTD module is identified by the PUBLIC and SYSTEM identifiers:

       PUBLIC "-//W3C//ENTITIES XHTML Access Attribute Qnames 1.0//EN"
       SYSTEM "http://www.w3.org/MarkUp/DTD/xhtml-access-qname-1.mod"

     Revisions:
     (none)
     ....................................................................... -->

<!-- XHTML Access Attribute Qname (Qualified Name) Module

     This module is contained in two parts, labeled Section 'A' and 'B':

       Section A declares parameter entities to support namespace-
       qualified names, namespace declarations, and name prefixing
       for XHTML Access and extensions.

       Section B declares parameter entities used to provide
       namespace-qualified names for the XHTML access element:

         %XHTML-ACCESS.access.qname;   the xmlns-qualified name for access
         ...

     XHTML Access extensions would create a module similar to this one.
-->

<!-- Section A: XHTML Access Attribute XML Namespace Framework ::::::::::::::: -->

<!-- 1. Declare a %XHTML-ACCESS.prefixed; conditional section keyword, used
        to activate namespace prefixing. The default value should
        inherit '%NS.prefixed;' from the DTD driver, so that unless
        overridden, the default behavior follows the overall DTD
        prefixing scheme.
-->
<!ENTITY % NS.prefixed "IGNORE" >
<!ENTITY % XHTML-ACCESS.prefixed "%NS.prefixed;" >

<!-- 2. Declare a parameter entity (eg., %XHTML-ACCESS.xmlns;) containing
        the URI reference used to identify the XHTML Access Attribute namespace
-->
<!ENTITY % XHTML-ACCESS.xmlns  "http://www.w3.org/1999/xhtml" >

<!-- 3. Declare parameter entities (eg., %XML.prefix;) containing
        the default namespace prefix string(s) to use when prefixing
        is enabled. This may be overridden in the DTD driver or the
        internal subset of an document instance. If no default prefix
        is desired, this may be declared as an empty string.

     NOTE: As specified in [XMLNAMES], the namespace prefix serves
     as a proxy for the URI reference, and is not in itself significant.
-->
<!ENTITY % XHTML-ACCESS.prefix  "" >

<!-- 4. Declare parameter entities (eg., %XHTML-ACCESS.pfx;) containing the
        colonized prefix(es) (eg., '%XHTML-ACCESS.prefix;:') used when
        prefixing is active, an empty string when it is not.
-->
<![%XHTML-ACCESS.prefixed;[
<!ENTITY % XHTML-ACCESS.pfx  "%XHTML-ACCESS.prefix;:" >
]]>
<!ENTITY % XHTML-ACCESS.pfx  "" >

<!-- declare qualified name extensions here ............ -->
<!ENTITY % xhtml-access-qname-extra.mod "" >
%xhtml-access-qname-extra.mod;

<!-- 5. The parameter entity %XHTML-ACCESS.xmlns.extra.attrib; may be
        redeclared to contain any non-XHTML Access namespace 
        declaration attributes for namespaces embedded in XML. The default
        is an empty string.  XLink should be included here if used
        in the DTD.
-->
<!ENTITY % XHTML-ACCESS.xmlns.extra.attrib "" >


<!-- Section B: XML Qualified Names ::::::::::::::::::::::::::::: -->

<!-- 6. This section declares parameter entities used to provide
        namespace-qualified names for the XHTML Access element.
-->

<!ENTITY % XHTML-ACCESS.access.qname  "%XHTML-ACCESS.pfx;access" >

<!-- end of xhtml-access-qname-1.mod -->

B.2. Element Definition Module

<!-- ...................................................................... -->
<!-- XHTML Access Module .................................................. -->
<!-- file: xhtml-access-1.mod

     This is XHTML Access - the Access Module for XHTML.

     Copyright 2007-2008 W3C (MIT, ERCIM, Keio), All Rights Reserved.

     This DTD module is identified by the PUBLIC and SYSTEM identifiers:

       PUBLIC "-//W3C//ELEMENTS XHTML Access Element 1.0//EN"
       SYSTEM "http://www.w3.org/MarkUp/DTD/xhtml-access-1.mod"

     Revisions:
     (none)
     ....................................................................... -->


<!ENTITY % Character.datatype "CDATA" >
<!ENTITY % CURIEs.datatype "CDATA" >
<!ENTITY % IDREFs.datatype "CDATA" > 

<!ENTITY % access.element  "INCLUDE" >
<![%access.element;[
<!ENTITY % access.content  "EMPTY" >
<!ENTITY % XHTML-ACCESS.access.qname  "access" >
<!ELEMENT %XHTML-ACCESS.access.qname;  %access.content; >
<!-- end of access.element -->]]>

<!ENTITY % access.attlist  "INCLUDE" >
<![%access.attlist;[
<!ATTLIST %access.qname;
      %Common.attrib;
      activate     ( yes | no )             #IMPLIED
      key          %Character.datatype;     #IMPLIED
      targetid     %IDREFs.datatype;        #IMPLIED
      targetrole   %CURIEs.datatype;        #IMPLIED
>
<!-- end of access.attlist -->]]>

<!-- end of xhtml-access-1.mod -->

C. References

This appendix is normative.

C.1. Normative References

[DOM2EVENTS]
"Document Object Model (DOM) Level 2 Events Specification", W3C Recommendation, T. Pixley, ed., 13 November 2000.
Available at: http://www.w3.org/TR/DOM-Level-2-Events/
The latest version of Dom Level 2 Events is available at: http://www.w3.org/TR/DOM-Level-2-Events
[HTML5]
"HTML5".
Available at: http://www.w3.org/TR/html5
The latest version of HTML5 is available at: http://www.w3.org/TR/xhtml2
[IRI]
"Internationalized Resource Identifiers (IRI)", RFC 3987, M.Duerst, M. Suignard January 2005.
Available at: http://www.ietf.org/rfc/rfc3987.txt
[RFC2119]
"Key words for use in RFCs to indicate requirement levels", RFC 2119, S. Bradner, March 1997.
Available at: http://www.rfc-editor.org/rfc/rfc2119.txt
[XMLNAMES]
"Namespaces in XML", W3C Recommendation, T. Bray et al., eds., 14 January 1999.
Available at: http://www.w3.org/TR/1999/REC-xml-names-19990114
The latest versionNamespaces in XML is available at: http://www.w3.org/TR/REC-xml-names
[XHTMLROLE]
"XHTML Role Attribute Module", W3C Working Draft, M. Birbeck et al., eds., 7 April 2008.
Available at: http://www.w3.org/TR/2008/WD-xhtml-role-20080407/
The latest version of XHTML Role Attribute Module is available at: http://www.w3.org/TR/xhtml-role

C.2. Other References

[CURIE]
"CURIE Syntax 1.0", W3C Working Draft, M. Birbeck, S. McCarron, ed., 2 April 2008.
Available at: http://www.w3.org/TR/2008/WD-curie-20080402/
The latest version of CURIE Syntax 1.0 is available at: http://www.w3.org/TR/curie
[UAAG1]
"User Agent Accessibility Guidelines 1.0". Ian Jacobs et al., 17 December 2002.
Available at: http://www.w3.org/TR/2002/REC-UAAG10-20021217
The latest version of User Agent Accessibility Guidelines, 1.0 is available at: http://www.w3.org/TR/UAAG10
[XHTMLMOD]
"Modularization of XHTML™ 1.1", W3C Working Draft, D. Austin et al., eds., 5 July 2006.
Available at: http://www.w3.org/TR/2006/WD-xhtml-modularization-20060705
The latest version of XHTML Modularization, 1.1 is available at: http://www.w3.org/TR/xhtml-modularization
[XHTML2]
"XHTML™ 2.0". J. Axelsson et al., 26 July 2006.
Available at: http://www.w3.org/TR/2006/WD-xhtml2-20060726
The latest versionof XHTML 2.0 is available at: http://www.w3.org/TR/xhtml2
[XMLEVENTS]
"XML Events", W3C Recommendation, S. McCarron et al., eds., 14 October 2003.
Available at: http://www.w3.org/TR/2003/REC-xml-events-20031014

D. Acknowledgments

This section is informative.

ToDo: Obtain definitive list from Shane or Steven Pemberton.

At the time of publication of the Last Call draft of the XHTML Role Module, the participants in the W3C XHTML 2 Working Group were:

Special thanks for the extensive review of the First Last call draft of the XHTML Access Module, and for its input to the Second Last Call draft of the XHTML Access Module, to the User Agent Accessibility Guidelines (UAAG) Working Group; its members; chair, Jim Allan; and staff contacts Jan Richards and Jeanne Spellman.

ToDo: Obtain definitive list from Janina or Michael Cooper.

At the time of publication, the participants in the W3C's Protocols & Formats Working Group were: