Role Attribute 1.0

An attribute to support the role classification of elements

W3C Editor's Draft 03 July 2012

This version:
Latest published version:
Latest editor's draft:
Previous version:
Shane McCarron, Applied Testing and Technology, Inc., shane@aptest.com
Ben Adida, Creative Commons
Mark Birbeck, webBackplane
T. V. Raman, Google, Inc.
Richard Schwerdtfeger, IBM Corporation

This document is also available in these non-normative formats: Diff from previous Draft, Postscript version, PDF version, Zip Archive, and Gzip'd Tar Archive.


The Role Attribute defined in this specification allows the author to annotate markup languages with machine-extractable semantic information about the purpose of an element. Use cases include accessibility, device adaptation, server-side processing, and complex data description. This attribute can be integrated into any markup language. In particular, schema implementations are provided to facilitate with languages based upon XHTML Modularization [XHTML-MODULARIZATION11-2e].

The role attribute is necessary to support Accessible Rich Internet Applications (WAI-ARIA) [WAI-ARIA] to define roles in XML-based languages, when the languages do not define their own role attribute. Although this is the reason the Role Attribute is published by the Protocols and Formats Working Group, the attribute has more general use cases as well.

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

This version incorporates changes in response to public comments received on the previous version. A history of changes to Role Attribute 1.0 is available.

This document was previously published by the XHTML 2 Working Group, part of the HTML Activity, as XHTML Role Attribute Module. The XHTML 2 Working Group has been closed and the Protocols and Formats Working Group has taken over this deliverable in order to provide the role attribute needed by WAI-ARIA. A history of changes to Role Attribute 1.0 is available.

Feedback on the information provided here is essential to the ultimate success of the Role attribute. The PFWG asks in particular:

Start with the instructions for commenting page to submit comments (preferred), or send email to public-pfwg-comments@w3.org (comment archive). Comments should be made by 25 February 2011. In-progress updates to the document may be viewed in the publicly visible editors' draft.

This document was published by the Protocols and Formats Working Group as an Editor's Draft. If you wish to make comments regarding this document, please send them to public-pfwg-comments@w3.org (subscribe, archives). All feedback is welcome.

Publication as an Editor's Draft does not imply endorsement by the W3C Membership. 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.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

1. Introduction

This section is non-normative.

This document defines an attribute designed be used to help improve the accessibility and semantic markup of documents. It has been developed in conjunction with the accessibility community and other groups to make it easier to describe the semantic meaning of document content.

2. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words must, must not, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [RFC2119].

2.1 Document Conformance

The Role Attribute does not represent a stand-alone document type. It is intended to be integrated into other host languages such as SVG, HTML, or XHTML. A conforming Role Attribute 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:

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

  2. If the host language is an XML [XML10-4e] markup language and is in the XHTML Namespace http://www.w3.org/1999/xhtml), there are no additional requirements. If the host language is an XML markup language and is not in the XHTML namespace, and the host language does not incorporate this attribute in 'no namespace', then the document must contain an XML namespace declaration for the Role Attribute Module namespace [XML-NAMES11]. The namespace for Role Attribute Module is defined to be http://www.w3.org/1999/xhtml. An example start tag of a root element might look like:

    <mylang xmlns="http://www.example.com/dtd/mylang" 
            xmlns:xh="http://www.w3.org/1999/xhtml" xml:lang="en" >

2.2 Host Language Conformance

When the Role Attribute is included in a host language, all of the facilities required in this specification must be included in the host language. In addition, the attribute defined in this specification must be included in the content model of the host language.

3. The Role Attribute

This specification defines the role attribute. The role attribute takes as its value one or more whitespace separated TERMorCURIEorAbsIRIs. Each component of the value maps to an IRI that corresponds to a vocabulary term that should be defined using RDF.

The datatype used for @role permits the use of a TERM, a CURIE (as defined in [RDFA-CORE], or a full IRI. A TERM is an item from a vocabulary. The default vocabulary for use with @role is defined in [XHTML-VOCAB]. A host language may define a different default vocabulary.

The specific vocabulary terms from the default vocabulary are not included in this document. They are defined in [XHTML-VOCAB] to ease maintenance. The terms are drawn from [WAI-ARIA] and from the original work on this document by the XHTML2 Working Group.

The attribute describes the role(s) the current element plays in the context of the document. This can be used, for example, by applications and assistive technologies to determine the purpose of an element. This could allow a user to make informed decisions on which actions may be taken on an element and activate the selected action in a device independent way. It could also be used as a mechanism for annotating portions of a document in a domain specific way (e.g., a legal term taxonomy). Although the role attribute may be used to add semantics to an element, authors should use elements with inherent semantics, such as p, rather than layering semantics on semantically neutral elements, such as div role="paragraph".

The following is an example of a good, appropriate use of the role attribute:

<ul role="navigation">
    <li href="downloads">Downloads</li>
    <li href="docs">Documentation</li>
    <li href="news">News</li>

3.1 Extending the collection of roles

It is possible to define additional role values. Vocabulary authors must define such additional role values in their own vocabulary. The URI associated with that vocabulary should resolve to a resource that allows for the machine and human discovery of the definition of the roles in the vocabulary.

A good example of such a resource is the default vocabulary document at [XHTML-VOCAB]. This document uses a format compatible with the requirements of [RDFA-CORE] section 9 for machine-discoverable RDFa Initial Contexts.

4. Using Role in conjunction with RDFa

If a Host Language contains the @role attribute, then an RDFa processor processing a document written in that Host Language according to the rules of that Host Language may generate additional triples for role attributes. If these additional triples are being generated, then they must be generated as follows:

Remember that @role values are defined using the datatype TERMorCURIEorAbsIRIs. An RDFa Processor will intepret these values using the rules for that that datatype as defined in [RDFA-CORE].

A. XHTML Role Attribute Module

A.1 DTD Implementation

The DTD implementation of XHTML Role Attribute Module conforms to the requirements defined in [XHTML-MODULARIZATION11-2e]. Consequently, it provides a Qualified Names declaration module.

A.1.1 Qualified Names Module

Note that this module defines the parameter entity %xhtml-role-attrs.qname;. This entity is intended to be used in the attribute lists of elements in any host language that permits the use of the role attribute on elements in its own namespace. If a host language does not permit role in its namespace, then the host language driver should set a parameter entity %XHTML-ROLE.prefixed; to INCLUDE and a parameter entity %XHTML-ROLE.prefix; to a value that is the prefix for the XHTML Role Attribute Module attribute.

A.2 Schema Implementation

The schema implementation of XHTML Role Attribute Module conforms to the requirements defined in [XHTML-MODULARIZATION11-2e]. It is included here as an example implementation.

A.2.1 Attributes Module

B. Acknowledgements

The following people contributed to the development of this document.

B.1 Participants in the PFWG at the time of publication

  1. David Bolter (Mozilla)
  2. Sally Cain (Royal National Institute of Blind People)
  3. Michael Cooper (W3C/MIT)
  4. James Craig (Apple Inc.)
  5. Steve Faulkner (Invited Expert, The Paciello Group)
  6. Geoff Freed (Invited Expert, NCAM)
  7. Jon Gunderson (Invited Expert, UIUC)
  8. Markus Gylling (DAISY Consortium)
  9. Sean Hayes (Microsoft Corporation)
  10. Kenny Johar (Vision Australia)
  11. Matthew King (IBM Corporation)
  12. Gez Lemon (International Webmasters Association / HTML Writers Guild (IWA-HWG))
  13. Thomas Logan (HiSoftware Inc.)
  14. William Loughborough (Invited Expert)
  15. Shane McCarron (Invited Expert, Aptest)
  16. Charles McCathieNevile (Opera Software)
  17. Mary Jo Mueller (IBM Corporation)
  18. James Nurthen (Oracle Corporation)
  19. Joshue O'Connor (Invited Expert)
  20. Artur Ortega (Yahoo!, Inc.)
  21. Sarah Pulis (Media Access Australia)
  22. Gregory Rosmaita (Invited Expert)
  23. Janina Sajka (Invited Expert, The Linux Foundation)
  24. Joseph Scheuhammer (Invited Expert, Inclusive Design Research Centre, OCAD University)
  25. Stefan Schnabel (SAP AG)
  26. Richard Schwerdtfeger (IBM Corporation)
  27. Lisa Seeman (Invited Expert, Aqueous)
  28. Cynthia Shelly (Microsoft Corporation)
  29. Andi Snow-Weaver (IBM Corporation)
  30. Gregg Vanderheiden (Invited Expert, Trace)
  31. Léonie Watson (Invited Expert, Nomensa)
  32. Gottfried Zimmermann (Invited Expert, Access Technologies Group)

B.2 Other previously active PFWG participants and contributors

Jim Allan (TSB), Simon Bates, Chris Blouch (AOL), Judy Brewer (W3C/MIT), Ben Caldwell (Trace), Charles Chen (Google, Inc.), Christian Cohrs, Dimitar Denev (Frauenhofer Gesellschaft), Donald Evans (AOL), Kentarou Fukuda (IBM Corporation), Becky Gibson (IBM), Alfred S. Gilman, Andres Gonzalez (Adobe Systems Inc.), Georgios Grigoriadis (SAP AG), Jeff Grimes (Oracle), Barbara Hartel, John Hrvatin (Microsoft Corporation), Masahiko Kaneko (Microsoft Corporation), Earl Johnson (Sun), Jael Kurz, Diego La Monica (International Webmasters Association / HTML Writers Guild (IWA-HWG)), Aaron Leventhal (IBM Corporation), Alex Li (SAP), Linda Mao (Microsoft), Anders Markussen (Opera Software), Matthew May (Adobe Systems Inc.), Lisa Pappas (Society for Technical Communication (STC)), Dave Pawson (RNIB), David Poehlman, Simon Pieters (Opera Software), T.V. Raman (Google, Inc.), Tony Ross (Microsoft Corporation), Martin Schaus (SAP AG), Marc Silbey (Microsoft Corporation), Henri Sivonen (Mozilla), Henny Swan (Opera Software), Vitaly Sourikov, Mike Squillace (IBM), Ryan Williams (Oracle), Tom Wlodkowski.

B.3 Enabling funders

This publication has been funded in part with Federal funds from the U.S. Department of Education, National Institute on Disability and Rehabilitation Research (NIDRR) under contract number ED-OSE-10-C-0067. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.

C. References

C.1 Normative references

Shane McCarron; et al. RDFa Core 1.1: Syntax and processing rules for embedding RDF through attributes. 7 June 2012. W3C Recommendation. URL: http://www.w3.org/TR/2012/REC-rdfa-core-20120607/
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Internet RFC 2119. URL: http://www.ietf.org/rfc/rfc2119.txt
Shane McCarron. XHTML™ Modularization 1.1 Second Edition. 29 July 2010. W3C Recommendation. URL: http://www.w3.org/TR/2010/REC-xhtml-modularization-20100729
XHTML 2 Working Group. XHTML Vocabulary. URL: http://www.w3.org/1999/xhtml/vocab
C. M. Sperberg-McQueen; et al. Extensible Markup Language (XML) 1.0 (Fourth Edition). 16 August 2006. W3C Recommendation. URL: http://www.w3.org/TR/2006/REC-xml-20060816/

C.2 Informative references

Lisa Pappas; et al. Accessible Rich Internet Applications (WAI-ARIA) 1.0. 24 February 2009. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2009/WD-wai-aria-20090224
Andrew Layman; et al. Namespaces in XML 1.1 (Second Edition). 16 August 2006. W3C Recommendation. URL: http://www.w3.org/TR/2006/REC-xml-names11-20060816