WAI-ARIA Graphics Module

W3C Editor's Draft

This version:
https://w3c.github.io/graphics-aria/
Latest published version:
https://www.w3.org/TR/graphics-aria-1.0/
Latest editor's draft:
https://w3c.github.io/graphics-aria/
Editors:
(Igalia, S.L.)
(W3C)
Former editors:
(IBM Corporation) (until September 2016)
(Knowbility) (until August 2017)
Authors:
(IBM Corporation)
(Knowbility)
(W3C)

Abstract

Assistive technologies need semantic information about the structures and expected behaviors of a document in order to convey appropriate information to persons with disabilities. This specification defines a WAI-ARIA 1.1 [WAI-ARIA-1.1] module of core roles specific to web graphics. These semantics allow an author to express the logical structure of the graphic to assistive technologies in order improve accessibility of graphics. Assistive technologies could then enable semantic navigation and adapt styling and interactive features, to provide an optimal experience for the audience. These features complement the graphics and document structure elements defined by HTML [HTML52] and SVG [SVG2].

This document is part of the WAI-ARIA suite described in the WAI-ARIA Overview.

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 https://www.w3.org/TR/.

This is an Editor's Draft of WAI-ARIA Graphics Module 1.0 by the SVG Accessibility Taskforce, a joint task force of the Accessible Rich Internet Applications Working Group and the SVG Working Group.

Feedback on any aspect of the specification is accepted. For this publication, the SVG Accessibility Task Force particularly seeks feedback on the following questions:

To comment, file an issue in the W3C ARIA GitHub repository, using the "graphics" label in the issue. If this is not feasible, send email to public-svg-a11y@w3.org (comment archive). Comments are requested by 30 September 2016. In-progress updates to the document may be viewed in the publicly visible editors' draft.

This document was published by the Accessible Rich Internet Applications Working Group as an Editor's Draft. Comments regarding this document are welcome. Please send them to public-aria@w3.org (subscribe, archives).

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

This document is governed by the 1 February 2018 W3C Process Document.

1. Introduction§

This section is non-normative.

WAI-ARIA is a technical specification that provides a framework to improve the accessibility and interoperability of web content and applications. It enables web browsers to map the accessibility semantics in web content to platform-specific accessibility APIs. This enables web content to be interoperable with platform assistive technologies, similar to native platform applications, without requiring authors to include platform dependencies.

This specification is a modular extension of WAI-ARIA [WAI-ARIA-1.1] designed to support graphics. The goals of this specification include:

This specification defines the core roles that would be used in all structured graphics or diagrams. It establishes the default roles that can be used to describe graphical markup elements such as shapes and canvases. In combination with WAI-ARIA attributes to provide alternative text and to indicate relationships between elements, this provides a framework for annotating many figures and diagrams. Future work will expand on this framework to enable more detailed annotation of data-rich graphics such as charts or maps.

For a more detailed explanation of WAI-ARIA please refer to the WAI-ARIA Introduction and how it applies to Rich Internet Application Accessibility.

1.1 Target Audience§

This specification defines a module of WAI-ARIA for graphics, consisting of graphics-specific element roles. It impacts several audiences:

Each conformance requirement indicates the audience to which it applies.

1.2 User Agent Support§

This module follows the general User Agent support principles defined in WAI-ARIA [WAI-ARIA-1.1]. The roles defined here do not require any change in behavior by user agents other than in the information exposed to the accessibility API. However, the semantics defined here provide the ability for user agents to enhance the general user interface presented to readers. For example, a user agent may provide alternative keyboard navigation suitable to a graphical environment, or may allow users to extract a copy of a graphic from a larger document.

1.3 Co-Evolution of WAI-ARIA and Host Languages§

The WAI-ARIA Graphics module follows the model for co-evolution of WAI-ARIA and host languages defined in WAI-ARIA [WAI-ARIA-1.1]. It is intended to augment semantics in supporting languages like HTML [HTML52], SVG [SVG2] and EPUB, or to be used as an accessibility enhancement technology in other markup-based languages that do not explicitly include support for ARIA. WAI-ARIA roles clarify semantics to assistive technologies when authors create new types of objects, via style and script, or use markup languages which describe the visual appearance of a document rather than its meaning.

Although markup languages may provide some of these semantics natively, it is expected that there will be a persistent need for the semantics provided by the WAI-ARIA Graphics module. Some host languages exist to create semantics for features other than the user interface. For example, SVG expresses the semantics behind production of graphical objects, not of user interface components that those objects may represent. Host languages such as these might, by design, not provide native semantics that map to all of this specification's features. In these host languages, the WAI-ARIA Graphics module could be adopted as a long-term approach to add semantic information.

1.4 Authoring Practices§

1.4.1 Authoring Tools§

Many of the requirements in the definitions of the WAI-ARIA and Graphics WAI-ARIA roles, states and properties can be checked automatically during the development process, similar to other quality control processes used for validating code. To assist authors who are creating graphics, these tools can compare the semantic structure of Graphics WAI-ARIA roles from the DOM to that defined in this specification and notify the author of errors or simply create templates that enforce that structure.

1.4.2 Testing Practices and Tools§

The accessibility of interactive content cannot be confirmed by static checks alone. Developers of interactive content should test for device-independent access to widgets and applications, and should verify accessibility API access to all content and changes during user interaction.

1.5 Assistive Technologies§

Programmatic access to accessibility semantics is essential for assistive technologies. For more information, refer to the Assistive Technologies section in WAI-ARIA [WAI-ARIA-1.1].

For the graphics roles in particular, two categories of assistive technology are particularly relevant, but have different needs:

The role descriptions suggest which features of an element with that role are considered semantically important and should be conveyed to the reader whenever possible.

2. Conformance§

The main content of this specification is normative and defines requirements that impact conformance claims. Introductory material, appendices, sections marked as "non-normative" and their subsections, diagrams, examples, and notes are informative (non-normative). Non-normative material provides advisory information to help interpret the guidelines but does not create requirements that impact a conformance claim.

Normative sections provide requirements that user agents must follow for an implementation to conform to this specification. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in Keywords for use in RFCs to indicate requirement levels [RFC2119]. RFC-2119 keywords are formatted in uppercase and contained in an element with class="rfc2119". When the keywords shown above are used, but do not share this format, they do not convey formal information in the RFC 2119 sense, and are merely explanatory, i.e., informative. As much as possible, such usages are avoided in this specification.

Normative sections provide requirements that authors, user agents and assistive technologies MUST follow for an implementation to conform to this specification.

Non-normative (informative) sections provide information useful to understanding the specification. Such sections may contain examples of recommended practice, but it is not required to follow such recommendations in order to conform to this specification.

3. Important Terms§

This section is non-normative.

While some terms are defined in place, the following definitions are used throughout this document.

Accessibility API

Operating systems and other platforms provide a set of interfaces that expose information about objects and events to assistive technologies. Assistive technologies use these interfaces to get information about and interact with those widgets. Examples of accessibility APIs are Microsoft Active Accessibility [MSAA], Microsoft User Interface Automation [UI-AUTOMATION], MSAA with UIA Express [UIA-EXPRESS], the Mac OS X Accessibility Protocol [AXAPI], the Linux/Unix Accessibility Toolkit [ATK] and Assistive Technology Service Provider Interface [AT-SPI], and IAccessible2 [IAccessible2].

Assistive Technologies

Hardware and/or software that:

  • relies on services provided by a user agent to retrieve and render Web content
  • works with a user agent or web content itself through the use of APIs, and
  • provides services beyond those offered by the user agent to facilitate user interaction with web content by people with disabilities

This definition may differ from that used in other documents.

Examples of assistive technologies that are important in the context of this document include the following:

  • screen magnifiers, which are used to enlarge and improve the visual readability of rendered text and images;
  • screen readers, which are most-often used to convey information through synthesized speech or a refreshable Braille display;
  • text-to-speech software, which is used to convert text into synthetic speech;
  • speech recognition software, which is used to allow spoken control and dictation;
  • alternate input technologies (including head pointers, on-screen keyboards, single switches, and sip/puff devices), which are used to simulate the keyboard;
  • alternate pointing devices, which are used to simulate mouse pointing and clicking.
Informative

Content provided for information purposes and not required for conformance. Content required for conformance is referred to as normative.

Normative

Required for conformance. By contrast, content identified as informative or "non-normative" is not required for conformance.

Property

Attributes that are essential to the nature of a given object, or that represent a data value associated with the object. A change of a property may significantly impact the meaning or presentation of an object. Certain properties (for example, aria-multiline) are less likely to change than states, but note that the frequency of change difference is not a rule. A few properties, such as aria-activedescendant, aria-valuenow, and aria-valuetext are expected to change often. See clarification of states versus properties.

Role

Main indicator of type. This semantic association allows tools to present and support interaction with the object in a manner that is consistent with user expectations about other objects of that type.

State

A state is a dynamic property expressing characteristics of an object that may change in response to user action or automated processes. States do not affect the essential nature of the object, but represent data associated with the object or user interaction possibilities. See clarification of states versus properties.

Taxonomy

A hierarchical definition of how the characteristics of various classes relate to each other, in which classes inherit the properties of superclasses in the hierarchy. A taxonomy can comprise part of the formal definition of an ontology.

User Agent

Any software that retrieves, renders and facilitates end user interaction with Web content. This definition may differ from that used in other documents.

Widget

Discrete user interface object with which the user can interact. Widgets range from simple objects that have one value or operation (e.g., check boxes and menu items), to complex objects that contain many managed sub-objects (e.g., trees and grids).

4. Graphics Roles§

This section defines additions to the WAI-ARIA role taxonomy and describes the characteristics and properties of all roles. See ARIA Roles for descriptions of the fields provided by this module.

Authors are given the ability to influence what is presented to assistive technologies and to influence navigation through the use of roles and properties. This includes the ability to mark elements as having no semantic importance. With graphics, there are many cases where presenting and navigating every element will make the graphic harder to understand and use.

Authors may mark elements for exclusion from the semantic representation of the document (the accessibility tree) by assigning the role none or presentation. The element with this role should be treated transparently by assistive technologies, as if its children or text content were directly contained by its parent element. In addition, certain roles, such as img or graphics-symbol, when assigned to a parent element, will cause all child DOM structure to be omitted from the accessibility tree. This is indicated by the "Children Presentational" value in the role characteristics table. Finally, the native semantics of the graphics language may also default to ignoring DOM structure that does not have semantic data attached; for SVG, this is defined in the SVG Accessibility API Mappings specification [SVG-AAM-1.0].

In all cases, to be considered presentational, an element must not be interactive and must not be assigned any accessible properties or alternative text. A role of none or presentation will be ignored for interactive elements or those with WAI-ARIA states and properties.

4.1 Definition of Roles§

Below is an alphabetical list of the WAI-ARIA roles defined in this specification. They would normally be used in combination with other roles defined in WAI-ARIA to annotate graphics within documents and rich internet applications [WAI-ARIA-1.1].

graphics-document
A type of document in which the visual appearance or layout of content conveys meaning.
graphics-object
A section of a graphics-document that represents a distinct object or sub-component with semantic meaning. A graphical object may itself have nested sub-components.
graphics-symbol
A graphical object used to convey a simple meaning or category, where the meaning is more important than the particular visual appearance. It may be a component of a larger structured graphic such as a chart or map. The symbol itself is an atomic object; children are presentational.

graphics-document (role)§

A type of document in which the visual appearance or layout of content conveys meaning.

Similar to other document types, the graphics-document role applies to the root element of a region of the page containing related information, where the user's primary interaction mode is expected to be browsing the document rather than controlling an application. The element with this role may be the root element of the document file, or of a nested structure within it.

The graphics-document may be distinguished from similar roles as follows:

  • Relative to other documents, a graphics-document is distinguished by the semantic importance of its visual (usually two-dimensional) representation. User agents and assistive technologies SHOULD take this into consideration when supporting navigation of the graphic. Accessibility technologies that re-format or re-style a document SHOULD NOT alter the layout of a graphics-document except in ways that are consistent with the semantic roles and relationships of its content.

  • Relative to an img, a graphics-document is distinguished by the structured nature of its content. Its child elements may have semantic meaning, and may include links or other interactive widgets.

  • Relative to a graphics-object, a graphics-document is self-contained. Its meaning persists when separated from surrounding content. The element with the graphics-document role defines the scope and context for interpretation of the child content.

In general, authors SHOULD use the graphics-document role for structured graphics such as charts, maps, diagrams, technical drawing, blue prints and instructional graphics. However, if a single large graphic has discrete regions that may be safely re-arranged without sacrificing meaning, each of those regions SHOULD be a distinct graphics-document. An alternative role (such as figure) may be used to group them together. One graphics-document may also be nested inside another, for example a bar chart that is embedded in a map or a matrix of chart panels should have a role of graphics-document. The nested document provides encapsulation; navigation between components of the inner and outer graphics should be explicit.

Note

To support user agents and assistive technologies based on the ARIA 1.0 specification, authors may wish to include the document role as a fallback value, in the form role="graphics-document document".

Future specifications may define more specific roles for particular types of graphical documents with special semantic structures. Those more specific roles would be subclasses of graphics-document.

Characteristics:
Characteristic Value
Superclass Role: document
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: True
Children Presentational: False

graphics-object (role)§

A section of a graphics-document that represents a distinct object or sub-component with semantic meaning. A graphical object may itself have nested sub-components.

Container elements that represent a collection of disconnected objects should be given the group or list roles, instead. Grouping elements that do not have semantic meaning and do not alter the semantic context provided by an ancestor (for example, a div or SVG g that is only used for styling or layout) SHOULD NOT be given a role. The lack of role may be explicitly indicated with the role none or presentation.

Unlike a graphics-document, a graphics-object need not be self-contained, and it does not establish a new context for navigation. However, user agents and assistive technologies SHOULD provide a way for users, particularly non-visual users, to navigate the nested structure of objects in a hierarchical manner, similar to nested lists.

Note

To support user agents and assistive technologies based on the ARIA 1.0 specification, authors may wish to include the group role as a fallback value, in the form role="graphics-object group".

Characteristics:
Characteristic Value
Superclass Role: group
Related Concepts:
Inherited States and Properties:
Name From:
  • author
  • contents
Accessible Name Required: False
Children Presentational: False

graphics-symbol (role)§

A graphical object used to convey a simple meaning or category, where the meaning is more important than the particular visual appearance. It may be a component of a larger structured graphic such as a chart or map. The symbol itself is an atomic object; children are presentational.

When used as part of a structured symbolic language, the aria-roledescription property (introduced in ARIA 1.1 [WAI-ARIA-1.1]) can be used to name the symbol type separately from the name and description for the particular instance of the symbol.

Note

To support user agents and assistive technologies based on the ARIA 1.0 specification, authors may wish to include the img role as a fallback value, in the form role="graphics-symbol img", if that is not already the default semantic role for the element.

Characteristics:
Characteristic Value
Superclass Role: img
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: True
Children Presentational: True

4.2 Other Roles for Graphics§

The following core ARIA roles, defined in ARIA 1.1 [WAI-ARIA-1.1], are also relevant for annotating graphics:

The following examples demonstrate appropriate use of img, figure, and graphics-document in a document.

5. States and Properties§

WAI-ARIA provides a collection of accessibility state and properties which are used to support platform accessibility APIs on various operating system platforms. Assistive technologies may access this information through an exposed user agent DOM or through a mapping to the platform accessibility API. When combined with roles, the user agent can supply the assistive technologies with user interface information to convey to the user at any time. Changes in states or properties will result in a notification to assistive technologies, which could alert the user that a change has occurred.

A. Change Log§

The full commit history to WAI-ARIA Graphics Module 1.0 is available.

A.1 Substantive changes since the last public working draft§

A.2 Other substantive changes since the First Public Working Draft§

B. Acknowledgments§

This section is non-normative.

The following people contributed to the development of this document.

B.1 Participants active in the SVG accessibility task force at the time of publication§

B.2 Participants active in the ARIA WG at the time of publication§

B.3 Enabling funders§

This publication has been funded in part with U.S. Federal funds from the Department of Education, National Institute on Disability, Independent Living, and Rehabilitation Research (NIDILRR), initially under contract number ED-OSE-10-C-0067 and currently under contract number HHSP23301500054C. 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§

[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[WAI-ARIA-1.1]
Accessible Rich Internet Applications (WAI-ARIA) 1.1. Joanmarie Diggs; Shane McCarron; Michael Cooper; Richard Schwerdtfeger; James Craig. W3C. 14 December 2017. W3C Recommendation. URL: https://www.w3.org/TR/wai-aria-1.1/

C.2 Informative references§

[AT-SPI]
Assistive Technology Service Provider Interface. The GNOME Project. URL: https://developer.gnome.org/libatspi/stable/
[ATK]
ATK - Accessibility Toolkit. The GNOME Project. URL: https://developer.gnome.org/atk/stable/
[AXAPI]
The NSAccessibility Protocol for macOS. Apple, Inc. URL: https://developer.apple.com/documentation/appkit/nsaccessibility
[CORE-AAM-1.1]
Core Accessibility API Mappings 1.1. Joanmarie Diggs; Joseph Scheuhammer; Richard Schwerdtfeger; Michael Cooper; Andi Snow-Weaver; Aaron Leventhal. W3C. 14 December 2017. W3C Recommendation. URL: https://www.w3.org/TR/core-aam-1.1/
[HTML52]
HTML 5.2. Steve Faulkner; Arron Eicholz; Travis Leithead; Alex Danilo; Sangwhan Moon. W3C. 14 December 2017. W3C Recommendation. URL: https://www.w3.org/TR/html52/
[IAccessible2]
IAccessible2. Linux Foundation. URL: https://www.linuxfoundation.org/collaborate/workgroups/accessibility/iaccessible2
[MSAA]
Microsoft Active Accessibility (MSAA) 2.0. Microsoft Corporation. URL: https://msdn.microsoft.com/en-us/library/ms697707.aspx
[SVG-AAM-1.0]
SVG Accessibility API Mappings. Amelia Bellamy-Royds; Ian Pouncey. W3C. 10 May 2018. W3C Working Draft. URL: https://www.w3.org/TR/svg-aam-1.0/
[SVG2]
Scalable Vector Graphics (SVG) 2. Nikos Andronikos; Rossen Atanassov; Tavmjong Bah; Amelia Bellamy-Royds; Brian Birtles; Bogdan Brinza; Cyril Concolato; Erik Dahlström; Chris Lilley; Cameron McCormack; Doug Schepers; Dirk Schulze; Richard Schwerdtfeger; Satoru Takagi; Jonathan Watt. W3C. 15 September 2016. W3C Candidate Recommendation. URL: https://www.w3.org/TR/SVG2/
[UI-AUTOMATION]
UI Automation. Microsoft Corporation. URL: https://msdn.microsoft.com/en-us/library/ee684009%28v=vs.85%29.aspx
[UIA-EXPRESS]
The IAccessibleEx Interface. Microsoft Corporation. URL: https://msdn.microsoft.com/en-us/library/windows/desktop/dd561898%28v=vs.85%29.aspx
[WCAG21]
Web Content Accessibility Guidelines (WCAG) 2.1. Andrew Kirkpatrick; Joshue O Connor; Alastair Campbell; Michael Cooper. W3C. 5 June 2018. W3C Recommendation. URL: https://www.w3.org/TR/WCAG21/