WAI-ARIA Graphics Module

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.

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:

Expanding WAI-ARIA to produce semantic extensions to support structured graphics such as charts, graphs, maps, technical drawings and scientific diagrams. It has applicability to both Scalable Vector Graphics as well as HTML 5 Canvas and graphics produced with CSS styling of HTML and other markup languages.
Align with a new governance model for modularization and extensions to WAI-ARIA.
Provide structural semantics extensions that will support both assistive technologies and enable semantic navigation, alternative styling, and interactivity support.
Work in harmony with SVG 2 and ARIA 1.1 to get consistent working accessibility infrastructure, on par with WAI-ARIA and HTML 5.2, across all the major browsers.

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:

User agents that process content containing WAI-ARIA and graphics WAI-ARIA features;
Assistive technologies that provide specialized reading experiences to users with disabilities;
Authors of web graphics;
Authoring tools that help authors create conforming graphics; and
Conformance checkers, that verify appropriate use of WAI-ARIA and this WAI-ARIA Graphics module.

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:

Text-based presentations, such as screen readers, braille displays, and text-only displays or printers. These technologies need to replace a complex graphic with semantic text descriptions, preserving any meaningful structure and relationships between components.
Alternative graphical presentations, such as colour-adjusted displays, screen magnifiers, large print documents, or embossing printers with graphic support. These technologies need to distinguish between graphical features which are primarily decorative and those which are essential for conveying the meaning of the content.

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.

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.

Example 1

An SVG diagram of an electrical circuit is a simple graphical document:

<svg xmlns="https://www.w3.org/2000/svg" 
     width="400" height="200" viewBox="0 0 200 100"
     role="graphics-document document" >
     <title>A simple circuit</title>
     <desc>A circuit with one source, one switch, and one load</desc>
     <style type="text/css">
        /* omitted */
     </style>
     <g id="battery-1" role="graphics-symbol img"
        aria-roledescription="source" aria-label="battery"
        transform="translate(20,50)">
        <path d="M-15,-5 h30 M-5,5 h10"/>
     </g>
     <path id="wire-1" role="graphics-symbol img"
          aria-label="wire connecting"
          aria-labelledby="wire-1 battery-1 switch-1"
          class="wire" d="M20,45 V20 H90"/>
     <!-- the switch, more wires, and a light bulb --> 
</svg>

Characteristics:
Characteristic	Value
Superclass Role:	`document`
Related Concepts:	`graphics-object` `img` `article`
Inherited States and Properties:	`aria-atomic` `aria-busy (state)` `aria-controls` `aria-current (state)` `aria-describedby` `aria-details` `aria-disabled (state)` `aria-dropeffect` `aria-errormessage` `aria-expanded (state)` `aria-flowto` `aria-grabbed (state)` `aria-haspopup` `aria-hidden (state)` `aria-invalid (state)` `aria-keyshortcuts` `aria-label` `aria-labelledby` `aria-live` `aria-owns` `aria-relevant` `aria-roledescription`
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".

Example 2

The code that follows is a portion of the markup for a structured graphic. It includes SVG g grouping elements with various roles:

graphics-object for distinct objects, such as the house, its door, or roof.
group to group together the windows or the trees (multiple distinct objects) with a single label or description.
img for the background which is described as a whole.
none for elements that apply styles or transformations without having any semantic meaning.

Where a graphical object has multiple sub-components, the group role is provided as an explicit fallback.

<svg xmlns="https://www.w3.org/2000/svg"
     width="600" height="400" viewBox="0 0 600 400"
     role="graphics-document document" xml:lang="en">
    <title>Home</title>
    <g role="img" aria-label="background">
        <desc>Blue sky, sunshine, and green grass</desc>
        <!-- The multiple parts of the background form a single image
             conveyed by that one description. -->
        <rect fill="lightSkyBlue" height="100%" width="100%" />
        <circle fill="yellow" stroke="gold" stroke-width="4"
                cx="0" cy="0" r="50" />
        <path fill="none" stroke="gold" stroke-width="3"
              d="..." />
        <rect fill="#6a2" y="300" width="100%" height="100" />
    </g>
    <g role="graphics-object group"
       aria-labelledby="house-label"
       transform="translate(100,325)">
        <desc>A two-storey brick house, drawn with basic shapes.
        </desc>
        <!-- The house has a number of details worth calling out,
             so it is a graphical object -->

        <rect fill="firebrick" stroke="darkRed"
              width="300" height="200" y="-200"
              role="none" /><!-- the walls of the house are 
                already described thoroughly,
                so no role is required -->

        <g role="graphics-object" aria-label="door"
           transform="translate(30,-90)">
            <desc>The brown door on the left side of the building
                has a window and a round doorknob</desc>
            <!-- The graphical object role allows for further
                 nested sub-components.
                 However, based on the default SVG API mappings,
                 these shapes, which have neither labels nor descriptions,
                 will be treated as presentation. -->
            <rect fill="darkKhaki" stroke="#632"
                  width="50" height="90"/>
            <rect fill="lightSteelBlue" stroke="#632" stroke-width="4" 
                  x="5" y="5" width="40" height="30" />
            <circle fill="gray" stroke="#444" stroke-width="0.7"
                    cx="10" cy="50" r="4" />
        </g>

        <g role="group" aria-label="windows"
           fill="lightSteelBlue" stroke="#632" stroke-width="6">
            <!-- The windows are distinct objects, 
                 grouped together with a common label -->
            <g role="none" transform="translate(0,-85)">
                <rect aria-label="first-floor window"
                      x="100" width="25" height="45">
                    <desc>A small window beside the door</desc>
                </rect>
                <path aria-label="first-floor living-room window"
                      d="M180,0h100v60h-100v-60z
                         m30,0v60 m40,0v-60">
                    <desc>A large three-pane window fills
                    the rest of the first floor</desc>
                </path>
            </g>
            <g role="none" transform="translate(0,-180)">
                <!-- more windows on the second floor -->
            </g>
        </g>
        <!-- more markup for the roof and chimney -->

        <text id="house-label"
              font-family="cursive" font-size="36px" 
              x="70" y="50">My House</text>
    </g>
    <!-- more markup for the trees -->
</svg>

Characteristics:
Characteristic	Value
Superclass Role:	`group`
Related Concepts:	`graphics-document` `group` `img` `graphics-symbol`
Inherited States and Properties:	`aria-activedescendant` `aria-atomic` `aria-busy (state)` `aria-controls` `aria-current (state)` `aria-describedby` `aria-details` `aria-disabled (state)` `aria-dropeffect` `aria-errormessage` `aria-expanded (state)` `aria-flowto` `aria-grabbed (state)` `aria-haspopup` `aria-hidden (state)` `aria-invalid (state)` `aria-keyshortcuts` `aria-label` `aria-labelledby` `aria-live` `aria-owns` `aria-relevant` `aria-roledescription`
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.

Example 3

Within an HTML document for a restaurant menu, an img element can represent a repeated symbol:

<h2>Appetizers</h2>
<ul>
    <li> Spinach Salad with Strawberry & Almonds
        <img role="graphics-symbol" title="Vegetarian" src="../assets/leaf.svg" />
        <img role="graphics-symbol" title="Contains Nuts" src="../assets/peanut.svg" />
    </li>
    <li> Chicken Satay with Peanut Sauce
        <img role="graphics-symbol" title="Contains Nuts" src="../assets/peanut.svg" />
    </li>
    <!-- … -->
</ul>

Example 4

Within an SVG diagram of an electrical circuit, the graphics that represent batteries, switches, and loads like this lightbulb are each symbols:

<g id="lightbulb-1" role="graphics-symbol img"
   aria-roledescription="load"
   aria-label="lightbulb"
   aria-labelledby="lightbulb-1 lightbulb-1-label"
   transform="translate(180,50)">
    <text id="lightbulb-1-label"
        x="-15" dy="0.5ex" text-anchor="end" >10W</text>
    <circle r="10" />
    <path d="M0,-10 C0,8 5,8 5,0 C5,-8 0,-8 0,10" />
</g>

Note that the visible text must be included in the label for its parent symbol, in this example. As the child of a graphics-symbol, it is treated as presentational content, and is therefore not accessible as a separate element of the graphic.

Example 5

Within an architectural blueprint-style SVG diagram, each SVG use element that creates a copy of a simple SVG symbol is a graphics-symbol:

<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     width="400" height="300" viewBox="0 0 400 300"
     role="graphics-document document" xml:lang="en">
    <title>Room with 5 outlets</title>
    <desc>Schematic showing the minimum number and position of 
        electrical outlets for a mid-sized room with one door.
    </desc>
    <defs> 
        <symbol id="outlet" viewBox="0 0 30 20"
                stroke="#000" stroke-width="1.5" pointer-events="all">
          <desc>The symbol for an electrical outlet is a circle with 
          a plug shape overlaid on top.  The plug consists of two horizontal 
          lines extending from a vertical line.</desc>
          <circle cx="15" cy="10" r="9" fill="none"/>
          <line x1="1" y1="7" x2="29" y2="7"/>
          <line x1="1" y1="13" x2="29" y2="13"/>
          <line x1="1" y1="1" x2="1" y2="19"/>
        </symbol>
    </defs>
<!-- … -->
    <g role="group">
        <use xlink:href="#outlet" role="graphics-symbol img"
             x="100" y="15" width="45" height="30">
            <title>Electrical outlet</title>
            <desc>on West side of North wall</desc>
        </use>
        <use xlink:href="#outlet" role="graphics-symbol img"
             x="250" y="15" width="45" height="30">
            <title>Electrical outlet</title>
            <desc>on East side of North wall</desc>
        </use>
<!-- … -->
    </g>
</svg>

Characteristics:
Characteristic	Value
Superclass Role:	`img`
Related Concepts:	symbol
Inherited States and Properties:	`aria-atomic` `aria-busy (state)` `aria-controls` `aria-current (state)` `aria-describedby` `aria-details` `aria-disabled (state)` `aria-dropeffect` `aria-errormessage` `aria-expanded (state)` `aria-flowto` `aria-grabbed (state)` `aria-haspopup` `aria-hidden (state)` `aria-invalid (state)` `aria-keyshortcuts` `aria-label` `aria-labelledby` `aria-live` `aria-owns` `aria-relevant` `aria-roledescription`
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:

img (image) defines a single graphic that is perceived as an indivisible whole. Unlike a graphics-document, an image cannot have navigable or interactive child content. Unlike a graphics-symbol, an image may require a detailed text description to fully convey its meaning to non-visual users.
figure defines a container element for content (including graphics) that is a key part of the containing document but is outside the normal reading stream. A figure will often contain one or more elements with the img or graphics-document roles, but may also contain text captions, credits, or other related content.

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

Example 6

Within an HTML 5 document, an inline SVG may sometimes represent an atomic img. If the graphics form part of the natural reading flow of the text, then this role is sufficient, as in the first example:

<p>A repeating SVG gradient is defined using the
    <code>spreadMethod</code> attribute.  
    A value of <code>repeat</code> causes the color stops
    to repeat in the same order, from beginning to end:</p>
<svg class="inline-example" role="img">
    <title>A repeating linear gradient</title>
    <desc>The gradient starts dark, slowly shifting to light, 
        then quickly dark again.  This pattern repeats four
        times left to right, each time brightening across a large
        region and then getting dark within a short space.
    </desc>
    <linearGradient id="repeat" x2="25%" spreadMethod="repeat">
        <stop offset="0"     stop-color="black" />
        <stop offset="0.8" stop-color="white" />
        <stop offset="1"     stop-color="black" />
    </linearGradient>
    <rect width="100%" height="100%" fill="url(#repeat)" />
</svg>

The following example provides the same content, but now structured as a figure that may be re-positioned separately from the flow of paragraph text.

<figure id="fig1" role="figure region">
    <svg id="fig1A" class="nested-figure" role="figure"
         aria-labelledby="fig1-caption, fig1A-caption">
        <!-- markup omitted-->
    </svg>
    <svg id="fig1B" class="nested-figure" role="figure"
         aria-labelledby="fig1-caption, fig1B-caption">
        <linearGradient id="reflect" spreadMethod="reflect"
                        xlink:href="#repeat" />
        <text id="fig1B-caption" class="caption" dy="1em"
              >b) spreadMethod="reflect"</text>
        <rect role="img"
              y="25%" width="100%" height="75%" fill="url(#reflect)" >
            <title>A reflecting linear gradient</title>
            <desc>The gradient again starts dark, slowly shifting to light, 
              then quickly dark again.  However, the next repeat shifts
              quickly to the light, then slowly back dark.  
              The original pattern is then repeated, followed by the reflected
              version again.
            </desc>
        </rect>
    </svg>
    <figcaption id="fig1-caption"
                >Figure 1: Repeating SVG gradients</figcaption>
</figure>

Finally, the last version uses a graphics-document to include complex annotations on the graphic, which is still contained within a figure element. The two sections of the graphic are graphics-object elements, while the annotations have individual labels and descriptions.

<figure id="fig1" role="figure region">
    <svg role="graphics-document">
        <title>Repeating versus reflecting linear gradients</title>
        <desc>
            The graphic shows two gradient patterns,
            annotated with text labels and arrows.
            Both gradients use the same series of color stops,
            starting dark, slowly shifting to light, 
            then quickly dark again.
            This cycle covers one-quarter of the width of the graphic,
            starting on the left.
            The two gradients differ in their repeat cycles.
        </desc>
        <defs>
            <!-- markup omitted -->
        </defs>
        <g role="graphics-object" aria-labelledby="repeat-label">
            <!-- markup omitted -->
        </g>            
        <g role="graphics-object" aria-labelledby="reflect-label">
            <desc>
                The gradient stretches across the bottom half of 
                the graphic.
                Each cycle of the gradient alternates direction,
                left-to-right then right-to-left,
                as do the arrows that emphasize the pattern.
            </desc>
            <rect y="50%" width="100%" height="50%" fill="url(#reflect)" />
            </rect>
            <use y="70%" xlink:href="#gradient-vector" >
                <title>1st cycle</title>
                <desc>left-to-right arrow, starting from x="0"</desc>
            </use>
            <use y="70%" x="-50%" transform="scale(-1,1)"
                 xlink:href="#gradient-vector" >
                <title>2nd cycle, reflected</title>
                <desc>right-to-left arrow, ending at x="25%"</desc>
            </use>
            <use y="70%" x="50%" xlink:href="#gradient-vector" >
                <title>3rd cycle</title>
                <desc>left-to-right arrow, starting from x="50%"</desc>
            </use>
            <use y="70%" x="-100%" transform="scale(-1,1)"
                 xlink:href="#gradient-vector" >
                <title>4th cycle, reflected</title>
                <desc>right-to-left arrow, ending at x="75%"</desc>
            </use>
            <text id="reflect-label" class="overlay-text" 
                  aria-label="spreadMethod='reflect'"
                  dy="-0.2em" dx="-0.2em" x="100%" y="100%"
                  >reflect</text>
        </g>
    </svg>
    <figcaption>Figure 1: spreadMethod options for
        repeating SVG gradients</figcaption>
</figure>

Example 7

Within the fallback DOM dynamically constructed for an HTML 5 canvas game, elements may represent the different images that create the composite graphic:

<canvas role="graphics-document">
    <p id="scene-desc" role="img" 
       aria-label="The Dungeon"
       aria-describedby="scene-desc">
       The door opens into a long hallway.
       Every few steps on either side are barred doors.
       Moisture drips from the stone walls.
    </p>
    <p id="grue-1" role="img"
       aria-label="Grue"
       aria-describedby="grue-1">
       An amorphous and poorly defined, but unmistakably sinister,
       creature blocks the passage.
   </p>
   <!-- more DOM elements representing game controls -->
</canvas>

WAI-ARIA Graphics Module

W3C Recommendation 02 October 2018

Abstract

Status of This Document

1. Introduction

1.1 Target Audience

1.2 User Agent Support

1.3 Co-Evolution of WAI-ARIA and Host Languages

1.4 Authoring Practices

1.4.1 Authoring Tools

1.4.2 Testing Practices and Tools

1.5 Assistive Technologies

2. Conformance

3. Important Terms

4. Graphics Roles

4.1 Definition of Roles

`graphics-document` (role)

`graphics-object` (role)

`graphics-symbol` (role)

4.2 Other Roles for Graphics

5. States and Properties

A. Change Log

A.1 Substantive changes since the last public working draft

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

B. Acknowledgments

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

C. References

C.1 Normative references

C.2 Informative references

WAI-ARIA Graphics Module

W3C Recommendation 02 October 2018

Abstract

Status of This Document

1. Introduction

1.1 Target Audience

1.2 User Agent Support

1.3 Co-Evolution of WAI-ARIA and Host Languages

1.4 Authoring Practices

1.4.1 Authoring Tools

1.4.2 Testing Practices and Tools

1.5 Assistive Technologies

2. Conformance

3. Important Terms

4. Graphics Roles

4.1 Definition of Roles

graphics-document (role)

graphics-object (role)

graphics-symbol (role)

4.2 Other Roles for Graphics

5. States and Properties

A. Change Log

A.1 Substantive changes since the last public working draft

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

B. Acknowledgments

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

C. References

C.1 Normative references

C.2 Informative references

`graphics-document` (role)

`graphics-object` (role)

`graphics-symbol` (role)