graphics-aria/index.html

<!--?xml version='1.0' encoding='UTF-8'?-->
<!doctype html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US">
  <head>
    <meta charset="UTF-8" />
    <title>WAI-ARIA Graphics Module</title>
    <script src="https://www.w3.org/Tools/respec/respec-w3c" class="remove" defer="defer"></script>
    <script src="../common/script/resolveReferences.js" class="remove"></script>
    <script src="../common/biblio.js" class="remove" defer="defer"></script>
    <link href="../common/css/common.css" rel="stylesheet" type="text/css" />
    <script class="remove" src="../common/script/ariaChild.js"></script>
    <script class="remove" src="../common/script/roleInfo.js"></script>
    <script class="remove">
      var respecConfig = {
        trace: true,
        github: "w3c/graphics-aria",
        doJsonLd: true,
        // specification status (e.g., WD, LC, NOTE, etc.). If in doubt use ED.
        specStatus: "ED",
        //crEnd:                "2012-04-30",
        //perEnd:               "2013-07-23",
        //publishDate:          "2016-08-18",

        // the specifications short name, as in https://www.w3.org/TR/short-name/
        shortName: "graphics-aria-1.0",

        // if you wish the publication date to be other than today, set this
        //publishDate:  "2014-12-11",
        copyrightStart: "2015",

        // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
        // and its maturity status
        previousPublishDate: "2015-12-03",
        previousMaturity: "WD",
        //prevRecURI: "https://www.w3.org/TR/2014/REC-wai-aria-20140320/",
        //previousDiffURI: "https://www.w3.org/TR/2014/REC-wai-aria-20140320/",

        // if there a publicly available Editors Draft, this is the link
        github: "https://github.com/w3c/graphics-aria/",
        //edDraftURI: "https://w3c.github.io/graphics-aria/",

        // if this is a LCWD, uncomment and set the end of its review period
        // lcEnd: "2012-02-21",

        // editors, add as many as you like
        // only "name" is required

        editors: [
          {
            name: "Amelia Bellamy-Royds",
            mailto: "amelia.bellamy.royds@gmail.com",
            w3cid: 75809,
          },
          {
            name: "James Nurthen",
            company: "Adobe",
            companyURL: "https://www.adobe.com/",
            w3cid: 37155,
          },
        ],
        formerEditors: [
          {
            name: "Joanmarie Diggs",
            company: "Igalia, S.L.",
            companyURL: "https://www.igalia.com",
            w3cid: 68182,
            note: "Editor until August 2023",
          },
          {
            name: "Michael Cooper",
            company: "w3c",
            companyURL: "http://www.w3.org",
            w3cid: 34017,
            note: "Editor until August 2023",
          },
          {
            name: "Fred Esch",
            mailto: "fesch@us.ibm.com",
            company: "IBM Corporation",
            companyURL: "https://www.ibm.com",
            w3cid: 73593,
            note: "until September 2016",
          },
          {
            name: "Rich Schwerdtfeger",
            mailto: "richschwer@gmail.com",
            company: "Knowbility",
            companyURL: "https://knowbility.org/",
            w3cid: 2460,
            note: "until August 2017",
          },
        ],

        // authors, add as many as you like.
        // This is optional, uncomment if you have authors as well as editors.
        // only "name" is required. Same format as editors.

        authors: [
          {
            name: "Amelia Bellamy-Royds",
            mailto: "amelia.bellamy.royds@gmail.com",
            w3cid: 75809,
          },
          {
            name: "Fred Esch",
            mailto: "fesch@us.ibm.com",
            company: "IBM Corporation",
            companyURL: "https://www.ibm.com/",
            w3cid: 73593,
          },
          {
            name: "Rich Schwerdtfeger",
            mailto: "richschwer@gmail.com",
            company: "Knowbility",
            companyURL: "https://knowbility.org/",
            w3cid: 2460,
          },
          {
            name: "Doug Schepers",
            mailto: "schepers@w3.org",
            company: "W3C",
            companyURL: "https://www.w3.org/",
            w3cid: 38635,
          },
        ],

        /*
		alternateFormats: [
			{ uri: 'aria-diff.html', label: "Diff from Previous Recommendation" } ,
			{ uri: 'aria.ps', label: "PostScript version" }, 
			{ uri: 'aria.pdf', label: "PDF version" }
		],
		*/

        // errata: 'https://www.w3.org/2010/02/rdfa/errata.html',

        //processVersion:  2015,
        // name of the WG
        group: "aria",
        maxTocLevel: 4,
        // Spec URLs
        ariaSpecURLs: {
          ED: "https://w3c.github.io/aria/",
          FPWD: "https://www.w3.org/TR/wai-aria-1.1/",
          WD: "https://www.w3.org/TR/wai-aria-1.1/",
          CR: "https://www.w3.org/TR/wai-aria-1.1/",
          PR: "https://www.w3.org/TR/wai-aria-1.1/",
          REC: "https://www.w3.org/TR/wai-aria-1.1/",
        },

        preProcess: [linkCrossReferences],
        postProcess: [ariaAttributeReferences],
        definitionMap: [],
        xref: ["core-aam", "accname", "wai-aria"],
      };
    </script>
    <style>
      /* Styles for embedded object examples */
      .example object,
      .example img {
        display: block;
        width: 35em;
        max-width: 100%;
        max-height: 100vh;
        background-color: white;
        border: solid 1px #999;
      }
      .example object[type="text/html"] {
        height: 20em;
        width: 60em;
      }
    </style>
  </head>
  <body>
    <section id="abstract">
      <p>
        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 <a href="" class="specref">WAI-ARIA 1.1</a> [[WAI-ARIA-1.1]] module of core <a data-lt="role">roles</a
        ><!-- , <a data-lt="state">states</a> and <a data-lt="property">properties</a> Note, if we do include any states & properties in this module, edit this sentence! -->
        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]].
      </p>
      <p>
        This document is part of the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> suite described in the
        <a href="https://www.w3.org/WAI/intro/aria.php"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Overview</a>.
      </p>
    </section>
    <section id="sotd">
      <p>
        This is an Editor's Draft of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Graphics Module 1.0 by the
        <a href="https://www.w3.org/WAI/PF/svg-a11y-tf/"><abbr title="Scalable Vector Graphics">SVG</abbr> Accessibility Taskforce</a>, a joint task force of the
        <a href="https://www.w3.org/WAI/ARIA/">Accessible Rich Internet Applications Working Group</a> and the <a href="https://www.w3.org/Graphics/SVG/WG/">SVG Working Group</a>.
      </p>
      <p>
        Feedback on any aspect of the specification is accepted. For this publication, the <abbr title="Scalable Vector Graphics">SVG</abbr> Accessibility Task Force particularly seeks feedback on the
        following questions:
      </p>
      <ul>
        <li>Are proposed roles clear and appropriate to the needs of interactive graphics?</li>
        <li>Is the relationship of this specification to <a href="" class="specref">WAI-ARIA 1.1</a> clear?</li>
      </ul>
      <p>
        To comment, <a href="https://github.com/w3c/graphics-aria/issues/new">file an issue in the W3C graphics-aria GitHub repository</a>. If this is not feasible, send email to
        <a href="mailto:public-aria@w3.org?subject=Graphics%20ARIA%20public%20comment">public-aria@w3.org</a> (<a href="https://lists.w3.org/Archives/Public/public-aria/">comment archive</a>).
        In-progress updates to the document may be viewed in the <a href="https://w3c.github.io/graphics-aria/">publicly visible editors' draft</a>.
      </p>
    </section>
    <section id="toc"></section>
    <section class="informative" id="introduction">
      <h1>Introduction</h1>
      <p>
        <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> 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.
      </p>
      <p>
        This specification is a modular extension of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> [[WAI-ARIA-1.1]] designed to support graphics. The goals of this specification
        include:
      </p>
      <ul>
        <li>
          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.
        </li>
        <li>Align with a new governance model for modularization and extensions to <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>.</li>
        <li>Provide structural semantics extensions that will support both assistive technologies and enable semantic navigation, alternative styling, and interactivity support.</li>
        <li>
          Work in harmony with SVG 2 and ARIA 1.1 to get consistent working accessibility infrastructure, on par with <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> and HTML 5.2,
          across all the major browsers.
        </li>
      </ul>
      <p>
        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.
      </p>
      <p>
        For a more detailed explanation of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> please refer to the
        <a href="https://www.w3.org/WAI/intro/aria">WAI-ARIA Introduction</a> and how it applies to Rich Internet Application Accessibility.
      </p>

      <section id="target-audience">
        <h2>Target Audience</h2>
        <p>
          This specification defines a module of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> for graphics, consisting of graphics-specific element <a data-lt="role">roles</a
          ><!-- , <a data-lt="state">states</a>, <a data-lt="property">properties</a> and values Again, edit as required re states/properties -->. It impacts several audiences:
        </p>
        <ul>
          <li>
            <a data-lt="user agent">User agents</a> that process content containing <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> and graphics
            <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> features;
          </li>
          <li><a>Assistive technologies</a> that provide specialized reading experiences to users with disabilities;</li>
          <li>Authors of web graphics;</li>
          <li>Authoring tools that help authors create conforming graphics; and</li>
          <li>
            Conformance checkers, that verify appropriate use of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> and this
            <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Graphics module.
          </li>
        </ul>
        <p>Each conformance requirement indicates the audience to which it applies.</p>
        <!--p>Although this specification is applicable to the above audiences, it is not specifically targeted to, nor is it intended to be the sole source of information for, any of these audiences. In the future, additional documents will be created to assist authors in applying these <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> semantics for graphics and to define how the information in this document is mapped to platform accessibility APIs.</p-->
      </section>

      <section id="ua-support">
        <h2>User Agent Support</h2>
        <p>
          This module follows the general <a href="https://www.w3.org/TR/wai-aria-1.1/#ua-support">User Agent support principles</a> 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 <a>accessibility API</a>. 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.
        </p>
      </section>

      <section id="co-evolution">
        <h2>Co-Evolution of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> and Host Languages</h2>
        <p>
          The <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Graphics module follows the model for
          <a href="https://www.w3.org/TR/wai-aria-1.1/#co-evolution">co-evolution of <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> and host languages</a> 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 <a>roles</a> 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.
        </p>
        <p>
          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
          <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> 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 <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> Graphics module
          could be adopted as a long-term approach to add semantic information.
        </p>
      </section>

      <section id="authoring_practices">
        <h2>Authoring Practices</h2>
        <section id="authoring_tools">
          <h3>Authoring Tools</h3>
          <p>
            Many of the requirements in the definitions of the <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> and Graphics
            <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> <a data-lt="role">roles</a>, <a data-lt="state">states</a> and <a data-lt="property">properties</a> 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 <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> roles from the <abbr title="Document Object Model">DOM</abbr> to that defined in this
            specification and notify the author of errors or simply create templates that enforce that structure.
          </p>
        </section>

        <section id="authoring_testing">
          <h3>Testing Practices and Tools</h3>
          <p>
            The accessibility of interactive content cannot be confirmed by static checks alone. Developers of interactive content should test for device-independent access to
            <a data-lt="widget">widgets</a> and applications, and should verify accessibility <abbr title="application programming interface">API</abbr> access to all content and changes during user
            interaction.
          </p>
        </section>
      </section>

      <section id="at_support">
        <h2>Assistive Technologies</h2>
        <p>
          Programmatic access to accessibility semantics is essential for assistive technologies. For more information, refer to the
          <a href="https://www.w3.org/TR/wai-aria-1.1/#at_support">Assistive Technologies</a> section in WAI-ARIA [[WAI-ARIA-1.1]].
        </p>
        <p>For the graphics roles in particular, two categories of assistive technology are particularly relevant, but have different needs:</p>
        <ul>
          <li>
            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.
          </li>
          <li>
            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.
          </li>
        </ul>
        <p>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.</p>
      </section>
    </section>
    <section class="normative" id="conformance">
      <h2>Conformance</h2>
      <p>
        The main content of this specification is <a class="termref">normative</a> and defines requirements that impact conformance claims. Introductory material, appendices, sections marked as
        "non-normative" and their subsections, diagrams, examples, and notes are <a class="termref">informative</a> (non-normative). Non-normative material provides advisory information to help
        interpret the guidelines but does not create requirements that impact a conformance claim.
      </p>
      <p>
        Normative sections provide requirements that <a class="termref">user agents</a> must follow for an implementation to conform to this specification. The keywords <em class="rfc2119">MUST</em>,
        <em class="rfc2119">MUST NOT</em>, <em class="rfc2119">REQUIRED</em>, <em class="rfc2119">SHALL</em>, <em class="rfc2119">SHALL NOT</em>, <em class="rfc2119">SHOULD</em>,
        <em class="rfc2119">RECOMMENDED</em>, <em class="rfc2119">MAY</em>, and <em class="rfc2119">OPTIONAL</em> in this document are to be interpreted as described in
        <cite><a href="http://www.rfc-editor.org/rfc/rfc2119.txt">Keywords for use in RFCs to indicate requirement levels</a></cite> [[!RFC2119]]. RFC-2119 keywords are formatted in uppercase and
        contained in an element with <code>class="rfc2119"</code>. 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.
      </p>
      <p>Normative sections provide requirements that authors, user agents and assistive technologies MUST follow for an implementation to conform to this specification.</p>
      <p>
        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.
      </p>
    </section>
    <section class="normative" id="roles">
      <h1>Graphics Roles</h1>
      <p>
        This section defines additions to the
        <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>
        <a class="termref">role</a> <a class="termref">taxonomy</a> and describes the characteristics and properties of all <a data-lt="role" class="termref">roles</a>. See
        <a href="#roles" class="specref">ARIA Roles</a> for descriptions of the fields provided by this module.
      </p>
      <p>
        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.
      </p>
      <p>
        Authors may mark elements for exclusion from the semantic representation of the document (the accessibility tree) by assigning the role <rref>none</rref> or <rref>presentation</rref>. 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 <rref>img</rref> or <rref>graphics-symbol</rref>, 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]].
      </p>
      <p>
        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 <code>none</code> or
        <code>presentation</code> will be ignored for interactive elements or those with WAI-ARIA states and properties.
      </p>
      <section id="role_definitions">
        <h2>Definition of Roles</h2>
        <p>
          Below is an alphabetical list of the
          <abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr>
          <a data-lt="role" class="termref">roles</a> 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]].
        </p>
        <!--  -->
        <p id="index_role">Placeholder for compact list of roles</p>

        <div class="role">
          <rdef>graphics-document</rdef>
          <div class="role-description">
            <p>A type of <rref>document</rref> in which the visual appearance or layout of content conveys meaning.</p>
            <p>
              Similar to other <rref>document</rref> types, the <code>graphics-document</code> 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.
            </p>
            <p>The <code>graphics-document</code> may be distinguished from similar roles as follows:</p>
            <ul>
              <li>
                <p>
                  Relative to other documents, a <code>graphics-document</code> 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 <code>graphics-document</code>
                  except in ways that are consistent with the semantic roles and relationships of its content.
                </p>
              </li>
              <li>
                <p>
                  Relative to an <rref>img</rref>, a <code>graphics-document</code>
                  is distinguished by the structured nature of its content. Its child elements may have semantic meaning, and may include links or other interactive widgets.
                </p>
              </li>
              <li>
                <p>
                  Relative to a <rref>graphics-object</rref>, a <code>graphics-document</code> is self-contained. Its meaning persists when separated from surrounding content. The element with the
                  <code>graphics-document</code> role defines the scope and context for interpretation of the child content.
                </p>
              </li>
            </ul>
            <p>
              In general, authors SHOULD use the <code>graphics-document</code> 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
              <code>graphics-document</code>. An alternative role (such as <rref>figure</rref>) may be used to group them together. One <code>graphics-document</code> 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 <code>graphics-document</code>. The nested document provides encapsulation;
              navigation between components of the inner and outer graphics should be explicit.
            </p>
            <div class="note">
              <p>
                To support user agents and assistive technologies based on the ARIA 1.0 specification, authors may wish to include the <rref>document</rref> role as a fallback value, in the form
                <code>role="graphics-document document"</code>.
              </p>
              <p>
                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
                <code>graphics-document</code>.
              </p>
            </div>
            <aside class="example">
              <p>An SVG diagram of an electrical circuit is a simple graphical document:</p>
              <object type="image/svg+xml" data="img/circuit-diagram.svg"></object>
              <pre class="highlight">
&lt;svg xmlns="https://www.w3.org/2000/svg" 
     width="400" height="200" viewBox="0 0 200 100"
     role="graphics-document document" &gt;
     &lt;title&gt;A simple circuit&lt;/title&gt;
     &lt;desc&gt;A circuit with one source, one switch, and one load&lt;/desc&gt;
     &lt;style type="text/css"&gt;
        /* omitted */
     &lt;/style&gt;
     &lt;g id="battery-1" role="graphics-symbol img"
        aria-roledescription="source" aria-label="battery"
        transform="translate(20,50)"&gt;
        &lt;path d="M-15,-5 h30 M-5,5 h10"/&gt;
     &lt;/g&gt;
     &lt;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"/&gt;
     &lt;!-- the switch, more wires, and a light bulb --&gt; 
&lt;/svg&gt;
</pre
              >
            </aside>
          </div>
          <table class="role-features">
            <caption>
              Characteristics:
            </caption>
            <thead>
              <tr>
                <th scope="col">Characteristic</th>
                <th scope="col">Value</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <th class="role-abstract-head" scope="row">Is Abstract:</th>
                <td class="role-abstract"> </td>
              </tr>
              <tr>
                <th class="role-parent-head" scope="row">Superclass Role:</th>
                <td class="role-parent"><rref>document</rref></td>
              </tr>
              <tr>
                <th class="role-children-head" scope="row">Subclass Roles:</th>
                <td class="role-children"> </td>
              </tr>
              <tr>
                <th class="role-base-head" scope="row">Base Concept:</th>
                <td class="role-base"> </td>
              </tr>
              <tr>
                <th class="role-related-head" scope="row">Related Concepts:</th>
                <td class="role-related">
                  <ul>
                    <li><rref>graphics-object</rref></li>
                    <li><rref>img</rref></li>
                    <li><rref>article</rref></li>
                  </ul>
                </td>
              </tr>
              <tr>
                <th class="role-scope-head" scope="row">Required Context Role:</th>
                <td class="role-scope"> </td>
              </tr>
              <tr>
                <th class="role-mustcontain-head" scope="row">Required Owned Elements:</th>
                <td class="role-mustcontain"></td>
              </tr>
              <tr>
                <th class="role-required-properties-head">Required States and Properties:</th>
                <td class="role-required-properties"> </td>
              </tr>
              <tr>
                <th class="role-properties-head" scope="row">Supported States and Properties:</th>
                <td class="role-properties"> </td>
              </tr>
              <tr>
                <th class="role-inherited-head" scope="row">Inherited States and Properties:</th>
                <td class="role-inherited"> </td>
              </tr>
              <tr>
                <th class="role-namefrom-head" scope="row">Name From:</th>
                <td class="role-namefrom">author</td>
              </tr>
              <tr>
                <th class="role-namerequired-head" scope="row">Accessible Name Required:</th>
                <td class="role-namerequired">True</td>
              </tr>
              <tr>
                <th class="role-namerequired-inherited-head" scope="row">Inherits Name Required:</th>
                <td class="role-namerequired-inherited"></td>
              </tr>
              <tr>
                <th class="role-childpresentational-head" scope="row">Children Presentational:</th>
                <td class="role-childpresentational">False</td>
              </tr>
              <tr>
                <th class="role-presentational-inherited-head" scope="row">Inherits Presentational:</th>
                <td class="role-presentational-inherited"> </td>
              </tr>
              <tr>
                <th class="implicit-values-head">Implicit Value for Role:</th>
                <td class="implicit-values"> </td>
              </tr>
            </tbody>
          </table>
        </div>

        <div class="role">
          <rdef>graphics-object</rdef>
          <div class="role-description">
            <p>
              A section of a <rref>graphics-document</rref>
              that represents a distinct object or sub-component with semantic meaning. A graphical object may itself have nested sub-components.
            </p>
            <p>
              Container elements that represent a collection of disconnected objects should be given the
              <rref>group</rref> or <rref>list</rref> roles, instead. Grouping elements that do not have semantic meaning and do not alter the semantic context provided by an ancestor (for example, a
              <code>div</code> or SVG <code>g</code> 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
              <rref>none</rref> or <rref>presentation</rref>.
            </p>
            <p>
              Unlike a <rref>graphics-document</rref>, a <code>graphics-object</code> 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.
            </p>
            <p class="note">
              To support user agents and assistive technologies based on the ARIA 1.0 specification, authors may wish to include the <rref>group</rref> role as a fallback value, in the form
              <code>role="graphics-object group"</code>.
            </p>

            <aside class="example">
              <p>The code that follows is a portion of the markup for a structured graphic. It includes SVG <code>g</code> grouping elements with various roles:</p>
              <ul>
                <li><code>graphics-object</code> for distinct objects, such as the house, its door, or roof.</li>
                <li><rref>group</rref> to group together the windows or the trees (multiple distinct objects) with a single label or description.</li>
                <li><rref>img</rref> for the background which is described as a whole.</li>
                <li><rref>none</rref> for elements that apply styles or transformations without having any semantic meaning.</li>
              </ul>
              <p>Where a graphical object has multiple sub-components, the group role is provided as an explicit fallback.</p>
              <object type="image/svg+xml" data="img/house-graphicsroles.svg"></object>
              <pre class="highlight">
&lt;svg xmlns="https://www.w3.org/2000/svg"
     width="600" height="400" viewBox="0 0 600 400"
     role="graphics-document document" xml:lang="en"&gt;
    &lt;title&gt;Home&lt;/title&gt;
    &lt;g role="img" aria-label="background"&gt;
        &lt;desc&gt;Blue sky, sunshine, and green grass&lt;/desc&gt;
        &lt;!-- The multiple parts of the background form a single image
             conveyed by that one description. --&gt;
        &lt;rect fill="lightSkyBlue" height="100%" width="100%" /&gt;
        &lt;circle fill="yellow" stroke="gold" stroke-width="4"
                cx="0" cy="0" r="50" /&gt;
        &lt;path fill="none" stroke="gold" stroke-width="3"
              d="..." /&gt;
        &lt;rect fill="#6a2" y="300" width="100%" height="100" /&gt;
    &lt;/g&gt;
    &lt;g role="graphics-object group"
       aria-labelledby="house-label"
       transform="translate(100,325)"&gt;
        &lt;desc&gt;A two-storey brick house, drawn with basic shapes.
        &lt;/desc&gt;
        &lt;!-- The house has a number of details worth calling out,
             so it is a graphical object --&gt;

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

        &lt;g role="graphics-object" aria-label="door"
           transform="translate(30,-90)"&gt;
            &lt;desc&gt;The brown door on the left side of the building
                has a window and a round doorknob&lt;/desc&gt;
            &lt;!-- 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. --&gt;
            &lt;rect fill="darkKhaki" stroke="#632"
                  width="50" height="90"/&gt;
            &lt;rect fill="lightSteelBlue" stroke="#632" stroke-width="4" 
                  x="5" y="5" width="40" height="30" /&gt;
            &lt;circle fill="gray" stroke="#444" stroke-width="0.7"
                    cx="10" cy="50" r="4" /&gt;
        &lt;/g&gt;

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

        &lt;text id="house-label"
              font-family="cursive" font-size="36px" 
              x="70" y="50"&gt;My House&lt;/text&gt;
    &lt;/g&gt;
    &lt;!-- more markup for the trees --&gt;
&lt;/svg&gt;
</pre
              >
            </aside>
            <!-- 
FRED: I've added more explanation to the house example,
which I think covers the factors you were trying to emphasize here.
OK to omit the second example?

<div class="example">
        <p>
            In the example below, the outer most group element has the role <code>graphics-object</code>. The outer group represents
            the set of labels for the months of the year.  The inner group elements exist for style purposes, do not have semantic
            meaning and thus are given the role none.           
       </p>
            
<pre class="highlight">
&lt;g  role='graphics-object' &gt;
   &lt;text x="376.01" y="248.66" &gt;Jan&lt;/text&gt;
   &lt;text x="325.32" y="336.46" &gt;Feb&lt;/text&gt;
   &lt;g role='none'&gt;
    &lt;text x="237.52" y="387.15" &gt;Mar&lt;/text&gt;
    &lt;g text-anchor="end" role='none'&gt;
     &lt;text x="136.14" y="387.15" &gt;Apr&lt;/text&gt;
     &lt;text x="48.34" y="336.46" &gt;May&lt;/text&gt;
     &lt;/g&gt;
    &lt;/g&gt;
   &lt;g text-anchor="end" role='none'&gt;
    &lt;text x="-2.346" y="248.66" &gt;Jun&lt;/text&gt;
    &lt;text x="-2.346" y="147.28" &gt;Jul&lt;/text&gt;
    &lt;g  role='none'&gt;
     &lt;text x="48.34" y="59.48" &gt;Aug&lt;/text&gt;
     &lt;text x="136.14" y="8.794" &gt;Sep&lt;/text&gt;
     &lt;/g&gt;
    &lt;/g&gt;
   &lt;g text-anchor="start"  role='none'&gt;
    &lt;text x="237.52" y="8.794" &gt;Oct&lt;/text&gt;
    &lt;text x="325.32" y="59.48" &gt;Nov&lt;/text&gt;
    &lt;text x="376.01" y="147.28" &gt;Dec&lt;/text&gt;
    &lt;/g&gt;
   &lt;/g&gt;
</pre>
   <object type="image/svg+xml" data="img/monthsCircle.svg"></object>
</div>
-->
          </div>
          <table class="role-features">
            <caption>
              Characteristics:
            </caption>
            <thead>
              <tr>
                <th scope="col">Characteristic</th>
                <th scope="col">Value</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <th class="role-abstract-head" scope="row">Is Abstract:</th>
                <td class="role-abstract"> </td>
              </tr>
              <tr>
                <th class="role-parent-head" scope="row">Superclass Role:</th>
                <td class="role-parent"><rref>group</rref></td>
              </tr>
              <tr>
                <th class="role-children-head" scope="row">Subclass Roles:</th>
                <td class="role-children"> </td>
              </tr>
              <tr>
                <th class="role-base-head" scope="row">Base Concept:</th>
                <td class="role-base"> </td>
              </tr>
              <tr>
                <th class="role-related-head" scope="row">Related Concepts:</th>
                <td class="role-related">
                  <ul>
                    <li><rref>graphics-document</rref></li>
                    <li><rref>group</rref></li>
                    <li><rref>img</rref></li>
                    <li><rref>graphics-symbol</rref></li>
                  </ul>
                </td>
              </tr>
              <tr>
                <th class="role-scope-head" scope="row">Required Context Role:</th>
                <td class="role-scope"> </td>
              </tr>
              <tr>
                <th class="role-mustcontain-head" scope="row">Required Owned Elements:</th>
                <td class="role-mustcontain"></td>
              </tr>
              <tr>
                <th class="role-required-properties-head">Required States and Properties:</th>
                <td class="role-required-properties"> </td>
              </tr>
              <tr>
                <th class="role-properties-head" scope="row">Supported States and Properties:</th>
                <td class="role-properties"> </td>
              </tr>
              <tr>
                <th class="role-inherited-head" scope="row">Inherited States and Properties:</th>
                <td class="role-inherited"> </td>
              </tr>
              <tr>
                <th class="role-namefrom-head" scope="row">Name From:</th>
                <td class="role-namefrom">
                  <ul>
                    <li>author</li>
                    <li>contents</li>
                  </ul>
                </td>
              </tr>
              <tr>
                <th class="role-namerequired-head" scope="row">Accessible Name Required:</th>
                <td class="role-namerequired">False</td>
              </tr>
              <tr>
                <th class="role-namerequired-inherited-head" scope="row">Inherits Name Required:</th>
                <td class="role-namerequired-inherited"></td>
              </tr>
              <tr>
                <th class="role-childpresentational-head" scope="row">Children Presentational:</th>
                <td class="role-childpresentational">False</td>
              </tr>
              <tr>
                <th class="role-presentational-inherited-head" scope="row">Inherits Presentational:</th>
                <td class="role-presentational-inherited"> </td>
              </tr>
              <tr>
                <th class="implicit-values-head">Implicit Value for Role:</th>
                <td class="implicit-values"> </td>
              </tr>
            </tbody>
          </table>
        </div>

        <div class="role">
          <rdef>graphics-symbol</rdef>
          <div class="role-description">
            <p>
              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.
            </p>
            <p>
              When used as part of a structured symbolic language, the <pref>aria-roledescription</pref> 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.
            </p>
            <p class="note">
              To support user agents and assistive technologies based on the ARIA 1.0 specification, authors may wish to include the <rref>img</rref> role as a fallback value, in the form
              <code>role="graphics-symbol img"</code>, if that is not already the default semantic role for the element.
            </p>
            <aside class="example">
              <p>Within an HTML document for a restaurant menu, an <code>img</code> element can represent a repeated symbol:</p>
              <pre class="highlight">
&lt;h2&gt;Appetizers&lt;/h2&gt;
&lt;ul&gt;
    &lt;li&gt; Spinach Salad with Strawberry &amp; Almonds
        &lt;img role="graphics-symbol" title="Vegetarian" src="../assets/leaf.svg" /&gt;
        &lt;img role="graphics-symbol" title="Contains Nuts" src="../assets/peanut.svg" /&gt;
    &lt;/li&gt;
    &lt;li&gt; Chicken Satay with Peanut Sauce
        &lt;img role="graphics-symbol" title="Contains Nuts" src="../assets/peanut.svg" /&gt;
    &lt;/li&gt;
    &lt;!-- &#8230; --&gt;
&lt;/ul&gt;
</pre
              >
            </aside>
            <aside class="example">
              <p>Within an SVG diagram of an electrical circuit, the graphics that represent batteries, switches, and loads like this lightbulb are each symbols:</p>
              <object type="image/svg+xml" data="img/circuit-diagram.svg"></object>
              <pre class="highlight">
&lt;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)"&gt;
    &lt;text id="lightbulb-1-label"
        x="-15" dy="0.5ex" text-anchor="end" &gt;10W&lt;/text&gt;
    &lt;circle r="10" /&gt;
    &lt;path d="M0,-10 C0,8 5,8 5,0 C5,-8 0,-8 0,10" /&gt;
&lt;/g&gt;
</pre
              >
              <p>
                Note that the visible text must be included in the label for its parent symbol, in this example. As the child of a <rref>graphics-symbol</rref>, it is treated as presentational
                content, and is therefore not accessible as a separate element of the graphic.
              </p>
            </aside>
            <aside class="example">
              <p>Within an architectural blueprint-style SVG diagram, each SVG <code>use</code> element that creates a copy of a simple SVG <code>symbol</code> is a <rref>graphics-symbol</rref>:</p>
              <object type="image/svg+xml" data="img/blueprint.svg"></object>
              <pre class="highlight">
&lt;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"&gt;
    &lt;title&gt;Room with 5 outlets&lt;/title&gt;
    &lt;desc&gt;Schematic showing the minimum number and position of 
        electrical outlets for a mid-sized room with one door.
    &lt;/desc&gt;
    &lt;defs&gt; 
        &lt;symbol id="outlet" viewBox="0 0 30 20"
                stroke="#000" stroke-width="1.5" pointer-events="all"&gt;
          &lt;desc&gt;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.&lt;/desc&gt;
          &lt;circle cx="15" cy="10" r="9" fill="none"/&gt;
          &lt;line x1="1" y1="7" x2="29" y2="7"/&gt;
          &lt;line x1="1" y1="13" x2="29" y2="13"/&gt;
          &lt;line x1="1" y1="1" x2="1" y2="19"/&gt;
        &lt;/symbol&gt;
    &lt;/defs&gt;
&lt;!-- &#8230; --&gt;
    &lt;g role="group"&gt;
        &lt;use xlink:href="#outlet" role="graphics-symbol img"
             x="100" y="15" width="45" height="30"&gt;
            &lt;title&gt;Electrical outlet&lt;/title&gt;
            &lt;desc&gt;on West side of North wall&lt;/desc&gt;
        &lt;/use&gt;
        &lt;use xlink:href="#outlet" role="graphics-symbol img"
             x="250" y="15" width="45" height="30"&gt;
            &lt;title&gt;Electrical outlet&lt;/title&gt;
            &lt;desc&gt;on East side of North wall&lt;/desc&gt;
        &lt;/use&gt;
&lt;!-- &#8230; --&gt;
    &lt;/g&gt;
&lt;/svg&gt;</pre
              >
            </aside>
          </div>
          <table class="role-features">
            <caption>
              Characteristics:
            </caption>
            <thead>
              <tr>
                <th scope="col">Characteristic</th>
                <th scope="col">Value</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <th class="role-abstract-head" scope="row">Is Abstract:</th>
                <td class="role-abstract"> </td>
              </tr>
              <tr>
                <th class="role-parent-head" scope="row">Superclass Role:</th>
                <td class="role-parent"><rref>img</rref></td>
              </tr>
              <tr>
                <th class="role-children-head" scope="row">Subclass Roles:</th>
                <td class="role-children"> </td>
              </tr>
              <tr>
                <th class="role-base-head" scope="row">Base Concept:</th>
                <td class="role-base"> </td>
              </tr>
              <tr>
                <th class="role-related-head" scope="row">Related Concepts:</th>
                <td class="role-related"><a href="https://en.wikipedia.org/wiki/Symbol">symbol</a></td>
              </tr>
              <tr>
                <th class="role-scope-head" scope="row">Required Context Role:</th>
                <td class="role-scope"> </td>
              </tr>
              <tr>
                <th class="role-mustcontain-head" scope="row">Required Owned Elements:</th>
                <td class="role-mustcontain"></td>
              </tr>
              <tr>
                <th class="role-required-properties-head">Required States and Properties:</th>
                <td class="role-required-properties"> </td>
              </tr>
              <tr>
                <th class="role-properties-head" scope="row">Supported States and Properties:</th>
                <td class="role-properties"> </td>
              </tr>
              <tr>
                <th class="role-inherited-head" scope="row">Inherited States and Properties:</th>
                <td class="role-inherited"> </td>
              </tr>
              <tr>
                <th class="role-namefrom-head" scope="row">Name From:</th>
                <td class="role-namefrom">author</td>
              </tr>
              <tr>
                <th class="role-namerequired-head" scope="row">Accessible Name Required:</th>
                <td class="role-namerequired">True</td>
              </tr>
              <tr>
                <th class="role-namerequired-inherited-head" scope="row">Inherits Name Required:</th>
                <td class="role-namerequired-inherited"></td>
              </tr>
              <tr>
                <th class="role-childpresentational-head" scope="row">Children Presentational:</th>
                <td class="role-childpresentational">True</td>
              </tr>
              <tr>
                <th class="role-presentational-inherited-head" scope="row">Inherits Presentational:</th>
                <td class="role-presentational-inherited"> </td>
              </tr>
              <tr>
                <th class="implicit-values-head">Implicit Value for Role:</th>
                <td class="implicit-values"> </td>
              </tr>
            </tbody>
          </table>
        </div>
      </section>
      <section id="role_other">
        <h2>Other Roles for Graphics</h2>
        <p>The following core ARIA roles, defined in ARIA 1.1 [[WAI-ARIA-1.1]], are also relevant for annotating graphics:</p>
        <ul>
          <li>
            <rref>img</rref> (image) defines a single graphic that is perceived as an indivisible whole. Unlike a <rref>graphics-document</rref>, an image cannot have navigable or interactive child
            content. Unlike a <rref>graphics-symbol</rref>, an image may require a detailed text description to fully convey its meaning to non-visual users.
          </li>
          <li>
            <rref>figure</rref> 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 <rref>img</rref> or <rref>graphics-document</rref> roles, but may also contain text captions, credits, or other related content.
          </li>
        </ul>
        <p>
          The following examples demonstrate appropriate use of
          <rref>img</rref>, <rref>figure</rref>, and <rref>graphics-document</rref>
          in a document.
        </p>

        <aside class="example">
          <p>
            Within an HTML 5 document, an inline SVG may sometimes represent an atomic <code>img</code>. If the graphics form part of the natural reading flow of the text, then this role is
            sufficient, as in the first example:
          </p>

          <object type="text/html" data="img/img-role-for-svg.html"></object>
          <pre class="highlight">
&lt;p&gt;A repeating SVG gradient is defined using the
    &lt;code&gt;spreadMethod&lt;/code&gt; attribute.  
    A value of &lt;code&gt;repeat&lt;/code&gt; causes the color stops
    to repeat in the same order, from beginning to end:&lt;/p&gt;
&lt;svg class="inline-example" role="img"&gt;
    &lt;title&gt;A repeating linear gradient&lt;/title&gt;
    &lt;desc&gt;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.
    &lt;/desc&gt;
    &lt;linearGradient id="repeat" x2="25%" spreadMethod="repeat"&gt;
        &lt;stop offset="0"     stop-color="black" /&gt;
        &lt;stop offset="0.8" stop-color="white" /&gt;
        &lt;stop offset="1"     stop-color="black" /&gt;
    &lt;/linearGradient&gt;
    &lt;rect width="100%" height="100%" fill="url(#repeat)" /&gt;
&lt;/svg&gt;
</pre
          >

          <p>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.</p>
          <object type="text/html" data="img/nested-figures.html"></object>
          <pre class="highlight">
&lt;figure id="fig1" role="figure region"&gt;
    &lt;svg id="fig1A" class="nested-figure" role="figure"
         aria-labelledby="fig1-caption, fig1A-caption"&gt;
        &lt;!-- markup omitted--&gt;
    &lt;/svg&gt;
    &lt;svg id="fig1B" class="nested-figure" role="figure"
         aria-labelledby="fig1-caption, fig1B-caption"&gt;
        &lt;linearGradient id="reflect" spreadMethod="reflect"
                        xlink:href="#repeat" /&gt;
        &lt;text id="fig1B-caption" class="caption" dy="1em"
              &gt;b) spreadMethod="reflect"&lt;/text&gt;
        &lt;rect role="img"
              y="25%" width="100%" height="75%" fill="url(#reflect)" &gt;
            &lt;title&gt;A reflecting linear gradient&lt;/title&gt;
            &lt;desc&gt;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.
            &lt;/desc&gt;
        &lt;/rect&gt;
    &lt;/svg&gt;
    &lt;figcaption id="fig1-caption"
                &gt;Figure 1: Repeating SVG gradients&lt;/figcaption&gt;
&lt;/figure&gt;
</pre
          >

          <p>
            Finally, the last version uses a <rref>graphics-document</rref> to include complex annotations on the graphic, which is still contained within a figure element. The two sections of the
            graphic are <rref>graphics-object</rref> elements, while the annotations have individual labels and descriptions.
          </p>
          <object type="text/html" data="img/figure-graphics-doc.html"></object>
          <pre class="highlight">
&lt;figure id="fig1" role="figure region"&gt;
    &lt;svg role="graphics-document"&gt;
        &lt;title&gt;Repeating versus reflecting linear gradients&lt;/title&gt;
        &lt;desc&gt;
            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.
        &lt;/desc&gt;
        &lt;defs&gt;
            &lt;!-- markup omitted --&gt;
        &lt;/defs&gt;
        &lt;g role="graphics-object" aria-labelledby="repeat-label"&gt;
            &lt;!-- markup omitted --&gt;
        &lt;/g&gt;            
        &lt;g role="graphics-object" aria-labelledby="reflect-label"&gt;
            &lt;desc&gt;
                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.
            &lt;/desc&gt;
            &lt;rect y="50%" width="100%" height="50%" fill="url(#reflect)" /&gt;
            &lt;/rect&gt;
            &lt;use y="70%" xlink:href="#gradient-vector" &gt;
                &lt;title&gt;1st cycle&lt;/title&gt;
                &lt;desc&gt;left-to-right arrow, starting from x="0"&lt;/desc&gt;
            &lt;/use&gt;
            &lt;use y="70%" x="-50%" transform="scale(-1,1)"
                 xlink:href="#gradient-vector" &gt;
                &lt;title&gt;2nd cycle, reflected&lt;/title&gt;
                &lt;desc&gt;right-to-left arrow, ending at x="25%"&lt;/desc&gt;
            &lt;/use&gt;
            &lt;use y="70%" x="50%" xlink:href="#gradient-vector" &gt;
                &lt;title&gt;3rd cycle&lt;/title&gt;
                &lt;desc&gt;left-to-right arrow, starting from x="50%"&lt;/desc&gt;
            &lt;/use&gt;
            &lt;use y="70%" x="-100%" transform="scale(-1,1)"
                 xlink:href="#gradient-vector" &gt;
                &lt;title&gt;4th cycle, reflected&lt;/title&gt;
                &lt;desc&gt;right-to-left arrow, ending at x="75%"&lt;/desc&gt;
            &lt;/use&gt;
            &lt;text id="reflect-label" class="overlay-text" 
                  aria-label="spreadMethod='reflect'"
                  dy="-0.2em" dx="-0.2em" x="100%" y="100%"
                  &gt;reflect&lt;/text&gt;
        &lt;/g&gt;
    &lt;/svg&gt;
    &lt;figcaption&gt;Figure 1: spreadMethod options for
        repeating SVG gradients&lt;/figcaption&gt;
&lt;/figure&gt;
    </pre
          >
        </aside>

        <aside class="example">
          <p>Within the fallback DOM dynamically constructed for an HTML 5 canvas game, elements may represent the different images that create the composite graphic:</p>
          <pre class="highlight">
&lt;canvas role="graphics-document"&gt;
    &lt;p id="scene-desc" role="img" 
       aria-label="The Dungeon"
       aria-describedby="scene-desc"&gt;
       The door opens into a long hallway.
       Every few steps on either side are barred doors.
       Moisture drips from the stone walls.
    &lt;/p&gt;
    &lt;p id="grue-1" role="img"
       aria-label="Grue"
       aria-describedby="grue-1"&gt;
       An amorphous and poorly defined, but unmistakably sinister,
       creature blocks the passage.
   &lt;/p&gt;
   &lt;!-- more DOM elements representing game controls --&gt;
&lt;/canvas&gt;
</pre
          >
        </aside>
      </section>
    </section>
    <section class="normative" id="state_prop">
      <h1>States and Properties</h1>
      <p>
        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.
      </p>
    </section>
    <section class="appendix" id="changelog">
      <h2>Change Log</h2>
      <p>The full <a href="https://github.com/w3c/graphics-aria/commits/master/index.html">commit history to WAI-ARIA Graphics Module 1.0</a> is available.</p>
      <section>
        <h2>Substantive changes since the <a href="https://www.w3.org/TR/2016/WD-graphics-aria-1.0-20160908/">last public working draft</a></h2>
        <ul>
          <li>2017-11-15: Change superclass for graphics-object to img and graphics-symbol to group.</li>
          <!-- EdNote: After each WD publish, move contents of this list into the next one below. -->
        </ul>
      </section>
      <section>
        <h2>Other substantive changes since the <a href="http://www.w3.org/TR/2015/WD-graphics-aria-1.0-20151203/">First Public Working Draft</a></h2>
        <ul>
          <li>2016-01-26: changed superclass of graphics-doc to structure.</li>
          <li>2016-04-28: removed reference to role="none" or "presentation".</li>
          <li>2016-05-02: Change graphics-doc to graphics-document.</li>
          <li>2016-05-07: clarify limitations of presentational role; mention SVG 2 next to HTML 5 in section on Schemata.</li>
          <!-- EdNote: After each WD publish, move previous list into this one. -->
        </ul>
      </section>
    </section>
    <section class="appendix informative section" id="acknowledgements">
      <h3>Acknowledgments</h3>
      <p>The following people contributed to the development of this document.</p>
      <section class="section" id="ack_svga11y">
        <h4>Participants active in the SVG accessibility task force at the time of publication</h4>
        <ul>
          <li>Amelia Bellamy-Royds (Invited expert)</li>
          <li>Fred Esch (IBM Corporation)</li>
          <li>Charles McCathieNevile (Yandex)</li>
          <li>Charu Pandhi (IBM Corporation)</li>
          <li>Doug Schepers (W3C Staff)</li>
          <li>Richard Schwerdtfeger (Knowbility)</li>
          <li>Léonie Watson (The Paciello Group)</li>
          <li>Jason White (Educational Testing Service)</li>
        </ul>
      </section>
      <section class="section" id="ack_group">
        <h4>Participants active in the ARIA WG at the time of publication</h4>
        <ul>
          <li>David Bolter (Mozilla Foundation)</li>
          <li>Michael Cooper (W3C/MIT)</li>
          <li>James Craig (Apple Inc.)</li>
          <li>Joanmarie Diggs (Igalia)</li>
          <li>John Foliot (Invited Expert)</li>
          <li>Christopher Gallelo (Microsoft Corporation)</li>
          <li>Bryan Garaventa (SSB BART Group)</li>
          <li>Jon Gunderson (University of Illinois at Urbana-Champaign)</li>
          <li>Matthew King (IBM Corporation)</li>
          <li>Dominic Mazzoni (Google, Inc.)</li>
          <li>Shane McCarron (Invited Expert, Aptest)</li>
          <li>James Nurthen (Oracle Corporation)</li>
          <li>Janina Sajka (Invited Expert, The Linux Foundation)</li>
          <li>Stefan Schnabel (SAP AG)</li>
          <li>Lisa Seeman (Invited Expert)</li>
          <li>Alexander Surkov (Mozilla Foundation)</li>
          <li>Jason White (Educational Testing Service)</li>
        </ul>
      </section>
      <div data-include="../common/acknowledgements/funders.html" data-include-replace="true"></div>
    </section>
  </body>
</html>