aria-practices.html

<!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 Authoring Practices 1.2</title>
  <script src="common/script/resolveReferences.js" class="remove"></script>
  <script src="respec-config.js" class="remove"></script>
  <script src="common/biblio.js" class="remove"></script>
  <script src="https://www.w3.org/Tools/respec/respec-w3c-common" class="remove"></script>
  <link href="common/css/common.css" rel="stylesheet" type="text/css" />
</head>
<body>
  <section id="abstract">
    <p>
      This document provides readers with an understanding of how to use <cite><a href="https://www.w3.org/TR/wai-aria-1.2/"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> 1.2</a></cite> [[WAI-ARIA]] to create accessible rich internet applications.
      It describes considerations that might not be evident to most authors from the WAI-ARIA specification alone and recommends approaches to make widgets, navigation, and behaviors accessible using WAI-ARIA roles, states, and properties.
      This document is directed primarily to Web application developers, but the guidance is also useful for user agent and assistive technology developers.
    </p>
    <p>This document is part of the WAI-ARIA suite described in the <a href="https://www.w3.org/WAI/intro/aria.php">WAI-ARIA Overview</a>.</p>
  </section>

  <section id="sotd">
    <p>
      This is an editor's draft by the
      <a href="https://www.w3.org/WAI/ARIA/">Accessible Rich Internet Applications Working Group</a>
      of the
      <a href="https://www.w3.org/WAI/">Web Accessibility Initiative</a>.
      It supports the
      [[[wai-aria-1.2]]] [[WAI-ARIA-1.2]]
      specification, providing detailed advice and examples beyond what would be appropriate to a technical specification but which are important to understand the specification.
    </p>
    <p> This draft includes only a portion of content planned for WAI-ARIA Authoring Practices 1.2. To see plans for the complete guide, review the <a href="https://github.com/w3c/aria-practices/milestones?direction=asc&amp;sort=due_date&amp;state=open">Authoring Practices Milestone Plan</a>. </p>
    <p>
      Feedback on the  information provided here is essential to the ultimate success of Rich Internet Applications that afford full access to their information and operations.
      The Accessible Rich Internet Applications Working Group asks in particular:
    </p>
    <ul>
      <li>Is it clear how to create accessible Rich Internet Applications?</li>
      <li>Is the usage of roles, states, and properties clear? </li>
      <li>Are the various types of rich Web content covered? </li>
      <li>Are considerations beyond the use of WAI-ARIA sufficiently explained? </li>
      <li>Is the relationship of this document to the WAI-ARIA specification clear? </li>
      <li>Are the <a href="#aria_ex">design patterns</a> clear?</li>
    </ul>
    <p>
      To comment,
      <a href="https://github.com/w3c/aria-practices/issues/">file an issue in the <abbr title="World Wide Web Consortium">W3C</abbr> ARIA Practices GitHub repository</a>,
      or if that is not possible, send email to
      <a href="mailto:public-aria@w3.org?subject=Comment%20on%20WAI-ARIA%20Practices%201.2">public-aria@w3.org</a>
      (<a href="http://lists.w3.org/Archives/Public/public-aria/">comment archive</a>).
    </p>
  </section>

  <section id="intro">
    <h2>Introduction</h2>
    <p>This section is <em>informative.</em></p>
    <p>
      WAI-ARIA Authoring Practices is a guide for understanding how to use
      <cite><a href="https://www.w3.org/TR/wai-aria-1.2/">WAI-ARIA 1.2</a></cite> to create an accessible Rich Internet Application.
      It provides guidance on the appropriate application of WAI-ARIA, describes recommended WAI-ARIA usage patterns, and explains concepts behind them.
    </p>
    <p>
      Languages used to create rich and dynamic web sites, e.g., HTML, JavaScript, CSS, and SVG, do not natively include all the features required to make sites usable by people who use assistive technologies (AT) or who rely on keyboard navigation.
      The W3C Web Accessibility Initiative's (WAI) Accessible Rich Internet Applications working group (ARIA WG) is addressing these deficiencies through several W3C standards efforts.
      The <a href="https://www.w3.org/WAI/intro/aria.php">WAI-ARIA Overview</a>
      provides additional background on WAI-ARIA, summarizes those efforts, and lists the other documents included in the WAI-ARIA suite.
    </p>
    <p>
      After a brief <q>Read Me First</q> section, the guide begins with ARIA implementation patterns for common widgets that both enumerate expected behaviors and demonstrate those behaviors with working code.
      The implementation patterns and examples refer to detailed explanations of supporting concepts in subsequent guidance sections.
      The guidance sections cover more general topics such as use of ARIA landmarks, practices for keyboard interfaces, grid and table properties, and the effects of role <code>presentation</code>.
    </p>
  </section>

  <section id="read_me_first">
    <h2>Read Me First</h2>
    <section id="no_aria_better_bad_aria">
      <h3>No ARIA is better than Bad ARIA</h3>
      <p>
        Functionally, ARIA roles, states, and properties are analogous to a CSS for assistive technologies.
        For screen reader users, ARIA controls the rendering of their non-visual experience.
        Incorrect ARIA misrepresents visual experiences, with potentially devastating effects on their corresponding non-visual experiences.
      </p>
      <p>Before using ARIA or any of the guidance in this document, please take time to understand the following two essential principles.</p>
      <h4>Principle 1: A role is a promise</h4>
      <p>This code:</p>
      <pre><code>
        &lt;div role=&quot;button&quot;&gt;Place Order&lt;/div&gt;
          </code> </pre>
      <p>
        Is a promise that the author of that <code>&lt;div&gt;</code> has also incorporated JavaScript that provides the keyboard interactions expected for a button.
        Unlike HTML input elements, ARIA roles do not cause browsers to provide keyboard behaviors or styling.
      </p>
      <p>Using a role without fulfilling the promise of that role is similar to making a &quot;Place Order&quot; button that abandons an order and empties the shopping cart.</p>
      <p>One of the objectives of this guide is to define expected behaviors for each ARIA role.</p>
      <h4>Principle 2: ARIA Can Both Cloak and Enhance, Creating Both Power and Danger</h4>
      <p>
        The information assistive technologies need about the meaning and purpose of user interface elements is called accessibility semantics.
        From the perspective of assistive technologies, ARIA gives authors the ability to dress up HTML and SVG elements with critical accessibility semantics that the assistive technologies would not otherwise be able to reliably derive.
      </p>
      <p>Some of ARIA is like a cloak; it covers up, or overrides, the original semantics or content.</p>
      <pre><code>
        &lt;a role=&quot;menuitem&quot;&gt;Assistive tech users perceive this element as an item in a menu, not a link.&lt;/a&gt;
        &lt;a aria-label=&quot;Assistive tech users can only perceive the contents of this aria-label, not the link text&quot;&gt;Link Text&lt;/a&gt;
</code></pre>
      <p>On the other hand, some uses of ARIA are more like suspenders or belts; they add meaning that provides essential support to the original content.</p>
      <pre><code>
        &lt;button aria-pressed=&quot;false&quot;&gt;Mute&lt;/button&gt;
      </code></pre>
      <p>
        This is the power of ARIA.
        It enables authors to describe nearly any user interface component in ways that assistive technologies can reliably interpret, thus making components accessible to assistive technology users.
      </p>
      <p>
        This is also the danger of ARIA.
        Authors can inadvertently override accessibility semantics.
      </p>
      <pre>
        <code>
          &lt;table role=&quot;log&quot;&gt;
            &lt;!--
              Table that assistive technology users will not perceive as a table.
              The log role tells browser this is a log, not a table.
            --&gt;
          &lt;/table&gt;
          &lt;ul role=&quot;navigation&quot;&gt;
            &lt;!-- This is a navigation region, not a list. --&gt;
            &lt;li&gt;&lt;a href=&quot;uri1&quot;&gt;nav link 1&lt;/li&gt;
            &lt;li&gt;&lt;a href=&quot;uri2&quot;&gt;nav link 2&lt;/li&gt;
            &lt;!-- ERROR! Previous list items are not in a list! --&gt;
          &lt;/ul&gt;
        </code>
      </pre>
    </section>
    <section id="browser_and_AT_support">
      <h3>Browser and Assistive Technology Support</h3>
      <p>
        <strong>Testing assistive technology interoperability is essential before using code from this guide in production.</strong>
        Because the purpose of this guide is to illustrate appropriate use of ARIA 1.2 as defined in the ARIA specification, the design patterns, reference examples, and sample code intentionally <strong>do not</strong> describe and implement coding techniques for working around problems caused by gaps in support for ARIA 1.2 in browsers and assistive technologies.
        It is thus advisable to test implementations thoroughly with each browser and assistive technology combination that is relevant within a target audience.
      </p>
      <p>
        Similarly, JavaScript and CSS in this guide is written to be compatible with the most recent version of Chrome, Firefox, and Safari at the time of writing.
Some JavaScript and CSS may not function correctly in Internet Explorer.
      </p>
      <p>
        Except in cases where the ARIA Working Group and other contributors have overlooked an error,
        examples in this guide that do not function well in a particular browser or with a specific assistive technology are demonstrating browser or assistive technology bugs.
        Browser and assistive technology developers can thus utilize code in this guide to help assess the quality of their support for ARIA 1.2.
      </p>
    </section>
    <section id="mobile_and_touch_support">
      <h3>Mobile and Touch Support</h3>
      <p>
        Currently, this guide does not indicate which examples are compatible with mobile browsers or touch interfaces.
        While some of the examples include specific features that enhance mobile and touch support, some ARIA features are not supported in any mobile browser.
        In addition, there is not yet a standardized approach for providing touch interactions that work across mobile browsers.
      </p>
      <p>More guidance about touch and mobile support is planned for future releases of the guide.</p>
    </section>
  </section>

  <section id="aria_ex">
    <h2>Design Patterns and Widgets</h2>
    <p>This section demonstrates how to make common rich internet application patterns and widgets accessible by applying WAI-ARIA roles, states, and properties and implementing keyboard support.</p>
    <section class="widget" id="accordion">
      <h3>Accordion (Sections With Show/Hide Functionality)</h3>
      <p>
        An accordion is a vertically stacked set of interactive headings that each contain a title, content snippet, or thumbnail representing a section of content.
        The headings function as controls that enable users to reveal or hide their associated sections of content.
        Accordions are commonly used to reduce the need to scroll when presenting multiple sections of content on a single page.
      </p>
      <p>Terms for understanding accordions include:</p>
      <dl>
        <dt>Accordion Header:</dt>
        <dd>Label for or thumbnail representing a section of content that also serves as a control for showing, and in some implementations, hiding  the section of content. </dd>
        <dt>Accordion Panel:</dt>
        <dd>Section of content associated with an accordion header.</dd>
      </dl>
      <p>
        In some accordions, there are additional elements that are always visible adjacent to the accordion header.
        For instance, a menubutton may accompany each accordion header to provide access to actions that apply to that section.
        And, in some cases, a snippet of the hidden content may also be visually persistent.
      </p>
      <section class="notoc">
        <h4>Example</h4>
        <p><a href="examples/accordion/accordion.html">Accordion Example</a>: demonstrates a form divided into three sections using an accordion to show one section at a time. </p>
      </section>
      <section class="notoc">
        <h4>Keyboard Interaction</h4>
        <ul>
          <li>
            <kbd>Enter</kbd> or <kbd>Space</kbd>:
            <ul>
              <li>
                When focus is on the accordion header for a collapsed panel, expands the associated panel.
                If the implementation allows only one panel to be expanded, and if another panel is expanded, collapses that panel.
              </li>
              <li>
                When focus is on the accordion header for an expanded panel, collapses the panel if the implementation supports collapsing.
                Some implementations require one panel to be expanded at all times and allow only one panel to be expanded; so, they do not support a collapse function.
              </li>
            </ul>
          </li>
          <li><kbd>Tab</kbd>: Moves focus to the next focusable element; all focusable elements in the accordion are included in the page <kbd>Tab</kbd> sequence.</li>
          <li><kbd>Shift + Tab</kbd>: Moves focus to the previous focusable element; all focusable elements in the accordion are included in the page <kbd>Tab</kbd> sequence.</li>
          <li>
            <kbd>Down Arrow</kbd> (Optional): If focus is on an accordion header, moves focus to the next accordion header.
            If focus is on the last accordion header, either does nothing or moves focus to the first accordion header.
          </li>
          <li>
            <kbd>Up Arrow</kbd> (Optional): If focus is on an accordion header, moves focus to the previous accordion header.
            If focus is on the first accordion header, either does nothing or moves focus to the last accordion header.
          </li>
          <li>
            <kbd>Home</kbd> (Optional): When focus is on an accordion header, moves focus to the first accordion header.
          </li>
          <li>
            <kbd>End</kbd> (Optional): When focus is on an accordion header, moves focus to the last accordion header.
          </li>
        </ul>
      </section>
      <section class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties:</h4>
        <ul>
          <li>
            The title of each accordion header is contained in an element with role <a href="#button" class="role-reference">button</a>.
          </li>
          <li>
            Each accordion header <code>button</code> is wrapped in an element with role <a href="#heading" class="role-reference">heading</a> that has a value set for <a href="#aria-level" class="property-reference">aria-level</a> that is appropriate for the information architecture of the page.
            <ul>
              <li>If the native host language has an element with an implicit <code>heading</code> and <code>aria-level</code>, such as an HTML heading tag, a native host language element may be used.</li>
              <li>
                The <code>button</code> element is the only element inside the <code>heading</code> element.
                That is, if there are other visually persistent elements, they are not included inside the <code>heading</code> element.
              </li>
            </ul>
          </li>
          <li>
            If the accordion panel associated with an accordion header is visible, the header <code>button</code> element has <a href="#aria-expanded" class="state-reference">aria-expanded</a> set to <code>true</code>.
            If the panel is not visible, <a href="#aria-expanded" class="state-reference">aria-expanded</a> is set to <code>false</code>.
          </li>
          <li>
            The accordion header <code>button</code> element has <a href="#aria-controls" class="property-reference">aria-controls</a> set to the ID of the element containing the accordion panel content.
          </li>
          <li>
            If the accordion panel associated with an accordion header is visible, and if the accordion does not permit the panel to be collapsed, the header <code>button</code> element has <a href="#aria-disabled" class="state-reference">aria-disabled</a> set to <code>true</code>.
          </li>
          <li>
            Optionally, each element that serves as a container for panel content has role
            <a href="#region" class="role-reference">region</a> and
            <a href="#aria-labelledby" class="property-reference">aria-labelledby</a>
            with a value that refers to the button that controls display of the panel.
            <ul>
              <li>
                Avoid using the <code>region</code> role in circumstances that create landmark region proliferation,
                e.g., in an accordion that contains more than approximately 6 panels that can be expanded at the same time.
              </li>
              <li>
                Role <code>region</code> is especially helpful to the perception of structure by screen reader users when panels contain heading elements or a nested accordion.
              </li>
            </ul>
          </li>
        </ul>
      </section>
    </section>

    <section class="widget" id="alert">
      <h3>Alert</h3>
      <p>
        An <a class="role-reference" href="#alert">alert</a> is an element that displays a brief, important message in a way that attracts the user's attention without interrupting the user's task.
        Dynamically rendered alerts are automatically announced by most screen readers, and in some operating systems, they may trigger an alert sound.
        It is important to note that, at this time, screen readers do not inform users of alerts that are present on the page before page load completes.
      </p>
      <p>
        Because alerts are intended to provide important and potentially time-sensitive information without interfering with the user's ability to continue working,
        it is crucial they do not affect keyboard focus.
        The <a href="#alertdialog">alert dialog</a> is designed for situations where interrupting work flow is necessary.
      </p>
      <p>
        It is also important to avoid designing alerts that disappear automatically.
        An alert that disappears too quickly can lead to failure to meet
        <a href="https://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-no-exceptions.html">WCAG 2.0 success criterion 2.2.3</a>.
        Another critical design consideration is the frequency of interruption caused by alerts.
        Frequent interruptions inhibit usability for people with visual and cognitive disabilities, which makes meeting the requirements of
        <a href="https://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-postponed.html">WCAG 2.0 success criterion 2.2.4</a>
        more difficult.
      </p>

      <section class="notoc">
        <h4>Example</h4>
        <p><a href="examples/alert/alert.html">Alert Example</a></p>
      </section>

      <section class="notoc">
        <h4>Keyboard Interaction</h4>
        <p>Not applicable.</p>
      </section>

      <section class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <p>The widget has a role of <a class="role-reference" href="#alert">alert</a>.</p>
      </section>
    </section>

    <section class="widget" id="alertdialog">
      <h3>Alert and Message Dialogs</h3>
      <p>
        An alert dialog  is a <a href="#dialog_modal">modal dialog</a> that interrupts the user's workflow to communicate an important message and acquire a response.
        Examples include action confirmation prompts and error message confirmations.
        The <a href="#alertdialog" class="role-reference">alertdialog</a> role
        enables assistive technologies and browsers to distinguish alert dialogs from other dialogs
        so they have the option of giving alert dialogs special treatment, such as playing a system alert sound.
      </p>

      <section class="notoc">
        <h4>Example</h4>
        <p><a href="examples/dialog-modal/alertdialog.html">Alert Dialog Example</a>: A confirmation prompt that demonstrates an alert dialog.</p>
      </section>

      <section class="notoc">
        <h4>Keyboard Interaction</h4>
        <p>See the keyboard interaction section for the <a href="#dialog_modal">modal dialog pattern</a>.</p>
      </section>
      <section class="notoc">
          <h4>WAI-ARIA Roles, States, and Properties</h4>
          <ul>
              <li>
                  The element that contains all elements of the dialog, including the alert
                  message and any dialog buttons, has role
                  <a class="role-reference" href="#alertdialog">alertdialog</a>.
              </li>
              <li>
                  The element with role <code>alertdialog</code> has either:
                  <ul>
                      <li>
                          A value for
                          <a href="#aria-labelledby" class="property-reference">aria-labelledby</a>
                          that refers to the element containing the title of the dialog if the
                          dialog has a visible label.
                      </li>
                      <li>
                          A value for
                          <a href="#aria-label" class="property-reference">aria-label</a>
                          if the dialog does not have a visible label.
                      </li>
                  </ul>
              </li>
              <li>
                  The element with role <code>alertdialog</code> has a value set for
                  <a href="#aria-describedby" class="property-reference">aria-describedby</a>
                  that refers to the element containing the alert message.
              </li>
          </ul>
      </section>
    </section>

    <section class="widget" id="breadcrumb">
      <h3 class="widget-name">Breadcrumb</h3>
      <p>
        A breadcrumb trail consists of a list of links to the parent pages of the current page in hierarchical order.
        It helps users find their place within a website or web application.
        Breadcrumbs are often placed horizontally before a page's main content.
      </p>

      <section class="notoc">
        <h4>Example</h4>
        <p><a href="examples/breadcrumb/index.html">Breadcrumb design pattern example</a></p>
      </section>

      <section class="notoc">
        <h4>Keyboard Interaction</h4>
        <p>Not applicable.</p>
      </section>

      <section class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <ul>
          <li>Breadcrumb trail is contained within a navigation landmark region.</li>
          <li>The landmark region is labelled via <a href="#aria-label" class="property-reference">aria-label</a> or <a href="#aria-labelledby" class="property-reference">aria-labelledby</a>.</li>
          <li>
            The link to the current page has <a href="#aria-current" class="property-reference">aria-current</a> set to <code>page</code>.
            If the element representing the current page is not a link, aria-current is optional.
          </li>
        </ul>
      </section>
    </section>

    <section class="widget" id="button">
      <h3>Button</h3>
      <p>
        A <a class="role-reference" href="#button">button</a> is a widget that enables users to trigger an action or event, such as submitting a form, opening a dialog, canceling an action, or performing a delete operation.
        A common convention for informing users that a button launches a dialog is to append &quot;&#8230;&quot; (ellipsis) to the button label, e.g., &quot;Save as&#8230;&quot;.
      </p>
      <p>In addition to the ordinary button widget, WAI-ARIA supports 2 other types of buttons:</p>
      <ul>
        <li>
          Toggle button: A two-state button that can be either off (not pressed) or on (pressed).
          To tell assistive technologies that a button is a toggle button, specify a value for the attribute <a href="#aria-pressed" class="state-reference">aria-pressed</a>.
          For example, a button labelled mute in an audio player could indicate that sound is muted by setting the pressed state true.
          <strong>Important:</strong> it is critical the label on a toggle does not change when its state changes.
          In this example, when the pressed state is true, the label remains &quot;Mute&quot; so a screen reader would say something like &quot;Mute toggle button pressed&quot;.
          Alternatively, if the design were to call for the button label to change from &quot;Mute&quot; to &quot;Unmute,&quot; the aria-pressed attribute would not be needed.
        </li>
        <li>Menu button: as described in the <a href="#menubutton">menu button pattern</a>, a button is revealed to assistive technologies as a menu button if it has the property <a href="#aria-haspopup" class="property-reference">aria-haspopup</a> set to either <code>menu</code> or <code>true</code>.</li>
      </ul>
      <p class="note">
        The types of actions performed by buttons are distinctly different from the function of a link (see <a href="#link">link pattern</a>).
        It is important that both the appearance and role of a widget match the function it provides.
        Nevertheless, elements occasionally have the visual style of a link but perform the action of a button.
        In such cases, giving the element role <code>button</code> helps assistive technology users understand the function of the element.
        However, a better solution is to adjust the visual design so it matches the function and ARIA role.
      </p>

      <section class="notoc">
        <h4>Examples</h4>
        <ul>
          <li><a href="examples/button/button.html">Button Examples</a>: Examples of clickable HTML <code>div</code> and <code>span</code> elements made into accessible command and toggle buttons.</li>
          <li><a href="examples/button/button_idl.html">Button Examples (IDL)</a>: Examples of clickable HTML <code>div</code> and <code>span</code> elements made into accessible command and toggle buttons. This example uses the <a class="specref" href="#idl-interface">IDL Interface</a>.</li>
        </ul>
      </section>

      <section class="notoc">
        <h4>Keyboard Interaction</h4>
        <p>When the button has focus:</p>
        <ul>
          <li>
            <kbd>Space</kbd>: Activates the button.
          </li>
          <li>
            <kbd>Enter</kbd>: Activates the button.
          </li>
          <li>
            Following button activation, focus is set depending on the type of action the button
            performs. For example:
            <ul>
              <li>
                If activating the button opens a dialog, the focus moves inside the dialog. (see
                <a href="#dialog_modal">dialog pattern</a>)
              </li>
              <li>If activating the button closes a dialog, focus typically returns to the
                button that opened the dialog unless the function performed in the dialog context
                logically leads to a different element. For example, activating a cancel button in a
                dialog returns focus to the button that opened the dialog. However, if
                the dialog were confirming the action of deleting the page from which it was
                opened, the focus would logically move to a new context.</li>
              <li>If activating the button does not dismiss the current context, then focus
                typically remains on the button after activation, e.g., an Apply or
                Recalculate button.</li>
              <li>If the button action indicates a context change, such as move to next step in
                a wizard or add another search criteria, then it is often appropriate to move focus to
                the starting point for that action.</li>
              <li>
                If the button is activated with a shortcut key, the focus usually remains in
                the context from which the shortcut key was activated. For example, if <kbd>Alt
                  + U</kbd> were assigned to an &quot;Up&quot; button that moves the currently focused
                item in a list one position higher in the list, pressing <kbd>Alt + U</kbd> when the
                focus is in the list would not move the focus from the list.
              </li>
            </ul>
          </li>
        </ul>
      </section>

      <section class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <ul>
          <li>The button has role of <a class="role-reference" href="#button">button</a>.</li>
          <li>
            The <code>button</code> has an accessible label.
            By default, the accessible name is computed from any text content inside the button element.
            However, it can also be provided with <a href="#aria-labelledby" class="property-reference">aria-labelledby</a> or <a href="#aria-label" class="property-reference">aria-label</a>.
          </li>
          <li>If a description of the button's function is present, the button element has <a href="#aria-describedby" class="property-reference">aria-describedby</a> set to the ID of the element containing the description.</li>
          <li>When the action associated with a button is unavailable, the button has <a class="state-reference" href="#aria-disabled">aria-disabled</a> set to <code>true</code>.</li>
          <li>
            If the button is a toggle button, it has an <a href="#aria-pressed" class="state-reference">aria-pressed</a> state.
            When the button is toggled on, the value of this state is <code>true</code>, and when toggled off, the state is <code>false</code>.
          </li>
        </ul>
      </section>
    </section>

    <section class="widget" id="carousel">
      <h3>Carousel (Slide Show or Image Rotator)</h3>
      <p>
        A carousel presents a set of items, referred to as slides, by sequentially displaying a subset of one or more slides.
        Typically, one slide is displayed at a time, and users can activate a next or previous slide control that hides the current slide and &quot;rotates&quot; the next or previous slide into view.
        In some implementations, rotation automatically starts when the page loads, and it may also automatically stop once all the slides have been displayed.
        While a slide may contain any type of content, image carousels where each slide contains nothing more than a single image are common.
      </p>
      <p>
        Ensuring all users can easily control and are not adversely effected by slide rotation is an essential aspect of making carousels accessible.
        For instance, the screen reader experience can be confusing and disorienting if slides that are not visible on screen are incorrectly hidden, e.g., displayed off-screen.
        Similarly, if slides rotate automatically and a screen reader user is not aware of the rotation, the user may read an element on slide one, execute the screen reader command for next element, and, instead of hearing the next element on slide one,  hear an element from slide 2 without any knowledge that the element just announced is from an entirely new context.
      </p>
      <p>Features needed to provide sufficient rotation control include:</p>
      <ul>
        <li>Buttons for displaying the previous and next slides.</li>
        <li>Optionally, a control, or group of controls, for choosing a specific slide to display. For example, slide picker controls can be marked up as tabs in a tablist with the slide represented by a tabpanel element.</li>
        <li>If the carousel can automatically rotate, it also:
          <ul>
            <li>Has a button for stopping and restarting rotation. This is particularly important for supporting assistive technologies operating in a mode that does not move either keyboard focus or the mouse.</li>
            <li>Stops rotating when keyboard focus enters the carousel. It does not restart unless the user explicitly requests it to do so.</li>
            <li>Stops rotating whenever the mouse is hovering over the carousel.</li>
          </ul>
        </li>
      </ul>

      <section class="notoc">
        <h4>Examples</h4>
        <ul>
          <li><a href="examples/carousel/carousel-1-prev-next.html">Auto-Rotating Image Carousel with Buttons for Slide Control:</a> A basic image carousel that demonstrates the accessibility features necessary for carousels that rotate automatically on page load and also enables users to choose which slide is displayed with buttons for previous and next slide.</li>
          <li><a href="examples/carousel/carousel-2-tablist.html">Auto-Rotating Image Carousel with Tabs for Slide Control:</a> An image carousel that demonstrates accessibility features necessary for carousels that rotate automatically on page load and also enables users to choose which slide is displayed with a set of tabs.</li>
        </ul>
      </section>

      <section class="notoc">
        <h4>Terms</h4>
        <p>The following terms are used to describe components of a carousel.</p>
        <dl>
          <dt>Slide</dt>
          <dd>A single content container within a set of content containers that hold the content to be presented by the carousel.</dd>
          <dt>Rotation Control</dt>
          <dd>An interactive element that stops and starts automatic slide rotation.</dd>
          <dt>Next Slide Control</dt>
          <dd>An interactive element, often styled as an arrow,  that displays the next slide in the rotation sequence.</dd>
          <dt>Previous Slide Control</dt>
          <dd>An interactive element, often styled as an arrow,  that displays the previous slide in the rotation sequence.</dd>
          <dt>Slide Picker Controls</dt>
          <dd>A group of elements, often styled as small dots, that enable the user to pick a specific slide in the rotation sequence to display.</dd>
        </dl>
      </section>

      <section class="notoc">
        <h4>Keyboard Interaction</h4>
        <ul>
          <li>
            If the carousel has an auto-rotate feature, automatic slide rotation stops when any element in the carousel receives keyboard focus.
            It does not resume unless the user activates the rotation control.
          </li>
          <li><kbd>Tab</kbd> and <kbd>Shift + Tab</kbd>: Move focus through the interactive elements of the carousel as specified by the page tab sequence -- scripting for <kbd>Tab</kbd> is not necessary.</li>
          <li>
            Button elements implement the keyboard interaction defined in the <a href="#button">button pattern</a>.
            Note: Activating the rotation control, next slide, and previous slide do not move focus, so users may easily repetitively activate them as many times as desired.
          </li>
          <li>If present, the rotation control is the first element in the <kbd>Tab</kbd> sequence inside the carousel. It is essential that it precede the rotating content so it can be easily located.</li>
          <li>If tab elements are used for slide picker controls, they implement the keyboard interaction defined in the <a href="#tabpanel">Tabs Pattern.</a></li>
        </ul>
      </section>

      <section class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <p>This section describes the element composition for three styles of carousels:</p>
        <ul>
          <li>Basic: Has rotation, previous slide, and next slide controls but no slide picker controls.</li>
          <li>Tabbed: Has basic controls plus a single tab stop for slide picker controls implemented using the <a href="#tabpanel">tabs pattern.</a></li>
          <li>Grouped: Has basic controls plus a series of tab stops in a group of slide picker controls where each control implements the <a href="#button">button pattern.</a> Because each slide selector button adds an element to the page tab sequence, this style is the least friendly for keyboard users.</li>
        </ul>
        <h5>Basic carousel elements</h5>
        <ul>
          <li>
            A carousel container element that encompasses all components of the carousel,  including both carousel controls and slides,
            has either role <a href="#region" class="role-reference">region</a>
            or role <a href="#group" class="role-reference">group.</a>
            The most appropriate role for the carousel container depends on the information architecture of the page.
            See the <a href="#aria_landmark">landmark regions guidance</a> to determine whether the carousel warrants being designated as a landmark region.
          </li>
          <li>The carousel container has the <a href="#aria-roledescription" class="property-reference">aria-roledescription</a> property set to <code>carousel</code>.</li>
          <li>
            If the carousel has a visible label, its accessible label is provided by the property
            <a href="#aria-labelledby" class="property-reference" >aria-labelledby</a> on the carousel container set to the ID of the element containing the visible label.
            Otherwise, an accessible label is provided by the property <a href="#aria-label" class="property-reference">aria-label</a> set on the carousel container.
            Note that since the <code>aria-roledescription</code> is set to &quot;carousel&quot;, the label does not contain the word &quot;carousel&quot;.
          </li>
          <li>The rotation control, next slide control, and previous slide control are either native button elements (recommended) or implement the <a href="#button">button pattern</a>.</li>
          <li>
            The rotation control has an accessible label provided by either its inner text or <a href="#aria-label" class="property-reference">aria-label</a>.
            The label changes to match the action the button will perform, e.g., &quot;Stop slide rotation&quot; or &quot;Start slide rotation&quot;.
            A label that changes when the button is activated clearly communicates both that slide content can change automatically and when it is doing so.
            Note that since the label changes, the rotation control does not have any states, e.g., <code>aria-pressed</code>, specified.
          </li>
          <li>Each slide container has role <a href="#group" class="role-reference">group</a> with the property <a href="#aria-roledescription" class="property-reference">aria-roledescription</a> set to <code>slide</code>.</li>
          <li>Each slide has an accessible name:
            <ul>
              <li>
                If a slide has a visible label, its accessible label is provided by the property
                <a href="#aria-labelledby" class="property-reference" >aria-labelledby</a>
                on the slide container set to the ID of the element containing the visible label.
              </li>
              <li>
                Otherwise, an accessible label is provided by the property
                <a href="#aria-label" class="property-reference">aria-label</a>
                set on the slide container.
              </li>
              <li>
                If unique names that identify the slide content are not available, a number and set size can serve as a meaningful alternative, e.g., &quot;3 of 10&quot;.
                Note: Normally, including set position and size information in an accessible name is not appropriate.
                An exception is helpful in this implementation because group elements do not support <a href="#aria-setsize" class="property-reference">aria-setsize</a> or <a href="#aria-posinset" class="property-reference">aria-posinset</a>.
                The tabbed carousel implementation pattern does not have this limitation.
              </li>
              <li>Note that since the <code>aria-roledescription</code> is set to &quot;slide&quot;, the label does not contain the word &quot;slide.&quot;</li>
            </ul>
          </li>
          <li>
            Optionally, an element wrapping the set of slide elements has <a href="#aria-atomic" class="property-reference">aria-atomic</a> set to <code>false</code>
            and <a href="#aria-live" class="property-reference">aria-live</a> set to:
            <ul>
              <li><code>off</code>: if the carousel is automatically rotating.</li>
              <li><code>polite</code>: if the carousel is <strong>NOT</strong> automatically rotating.</li>
            </ul>
          </li>
        </ul>
        <h5>Tabbed Carousel Elements</h5>
        <p>The structure of a tabbed carousel is the same as a basic carousel except that:</p>
        <ul>
          <li>
            Each slide container has role <a href="#tabpanel" class="role-reference">tabpanel</a> in lieu of <code>group</code>,
            and it does not have the <code>aria-roledescription</code> property.
          </li>
          <li>It has slide picker controls implemented using the <a href="#tabpanel">tabs pattern</a> where:
            <ul>
              <li>Each control is a <code>tab</code> element, so activating a tab displays the slide associated with that tab.</li>
              <li>The accessible name of each <code>tab</code> indicates which slide it will display by including the name or number of the slide, e.g., &quot;Slide 3&quot;. Slide names are preferable if each slide has a unique name.</li>
              <li>The set of controls is grouped in a <code>tablist</code> element with an accessible name provided by the value of <a href="#aria-label" class="property-reference">aria-label</a> that identifies the purpose of the tabs, e.g., &quot;Choose slide to display.&quot;</li>
              <li>The <code>tab</code>, <code>tablist</code>, and <code>tabpanel</code> implement the properties specified in the <a href="#tabpanel">tabs pattern</a>.</li>
            </ul>
          </li>
        </ul>
        <h5>Grouped Carousel Elements</h5>
        <p>A grouped carousel has the same structure as a basic carousel, but it also includes slide picker controls where:</p>
        <ul>
          <li>The set of slide picker controls is contained in an element with role <a href="#group" class="role-reference">group</a>.</li>
          <li>The group containing the picker controls has an accessible label provided by the value of <a href="#aria-label" class="property-reference">aria-label</a> that identifies the purpose of the controls, e.g., &quot;Choose slide to display.&quot;</li>
          <li>Each picker control is a native button element (recommended) or implements the <a href="#button">button pattern.</a></li>
          <li>
            The accessible name of each picker button matches the name of the slide it displays.
            One technique for accomplishing this is to set <a href="#aria-labelledby" class="property-reference">aria-labelledby</a> to a value that references the slide <code>group</code> element.
          </li>
          <li>
            The picker button representing the currently displayed slide has the property <a href="#aria-disabled" class="property-reference">aria-disabled</a> set to <code>true</code>.
            Note: <code>aria-disabled</code> is preferable to the HTML <code>disabled</code> attribute because this is a circumstance where screen reader users benefit from the disabled button being included in the page <kbd>Tab</kbd> sequence.
          </li>
        </ul>
      </section>
    </section>

    <section class="widget" id="checkbox">
      <h3>Checkbox</h3>
      <p>WAI-ARIA supports two types of <a href="#checkbox" class="role-reference">checkbox</a> widgets:</p>
      <ol>
        <li>Dual-state: The most common type of checkbox, it allows the user to toggle between two choices -- checked and not checked.</li>
        <li>Tri-state: This type of checkbox supports an additional third state known as partially checked.</li>
      </ol>
      <p>
        One common use of a tri-state checkbox can be found in software installers where a single tri-state checkbox is used to represent and control the state of an entire group of install options.
        And, each option in the group can be individually turned on or off with a dual state checkbox.
      </p>
      <ul>
        <li>If all options in the group are checked, the overall state is represented by the tri-state checkbox displaying as checked.</li>
        <li>If some of the options in the group are checked, the overall state is represented with the tri-state checkbox displaying as partially checked.</li>
        <li>If none of the options in the group are checked, the overall state of the group is represented with the tri-state checkbox displaying as not checked.</li>
      </ul>
      <p>The user can use the tri-state checkbox to change all options in the group with a single action:</p>
      <ul>
        <li>Checking the overall checkbox checks all options in the group.</li>
        <li>Unchecking the overall checkbox will uncheck all options in the group.</li>
        <li>
          And, In some implementations, the system may remember which options were checked the last time the overall status was partially checked.
          If this feature is provided, activating the overall checkbox a third time recreates that partially checked state where only some options in the group are checked.
        </li>
      </ul>

      <section class="notoc">
        <h4>Examples</h4>
        <ul>
          <li>
            <a href="examples/checkbox/checkbox-1/checkbox-1.html">Simple Two-State Checkbox Example</a>: Demonstrates a simple 2-state checkbox.
          </li>
          <li>
            <a href="examples/checkbox/checkbox-2/checkbox-2.html">Tri-State Checkbox Example</a>:
            Demonstrates how to make a widget that uses the <code>mixed</code> value for <code>aria-checked</code> and group collection of checkboxes with a field set.
          </li>
        </ul>
      </section>

      <section class="notoc">
        <h4>Keyboard Interaction</h4>
        <p>When the checkbox has focus, pressing the <kbd>Space</kbd> key changes the state of the checkbox.</p>
      </section>

      <section class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <ul>
          <li>The checkbox has role <a href="#checkbox" class="role-reference">checkbox</a>.</li>
          <li>
            The checkbox has an accessible label provided by one of the following:
            <ul>
              <li>Visible text content contained within the element with role <code>checkbox</code>.</li>
              <li>A visible label referenced by the value of <a href="#aria-labelledby" class="property-reference" >aria-labelledby</a> set on the element with role <code>checkbox</code>.</li>
              <li><a href="#aria-label" class="property-reference">aria-label</a> set on the element with role <code>checkbox</code>.</li>
            </ul>
          </li>
          <li>When checked, the checkbox element has state <a href="#aria-checked" class="state-reference" >aria-checked</a> set to <code>true</code>.</li>
          <li>When not checked, it has state <a href="#aria-checked" class="state-reference" >aria-checked</a> set to <code>false</code>.</li>
          <li>When partially checked, it has state <a href="#aria-checked" class="state-reference" >aria-checked</a> set to <code>mixed</code>.</li>
          <li>If a set of checkboxes is presented as a logical group with a visible label, the checkboxes are included in an element with role <a href="#group" class="role-reference" >group</a> that has the property <a href="#aria-labelledby" class="property-reference" >aria-labelledby</a> set to the ID of the element containing the label.</li>
          <li>If the presentation includes additional descriptive static text relevant to a checkbox or checkbox group, the checkbox or checkbox group has the property <a href="#aria-describedby" class="property-reference">aria-describedby</a> set to the ID of the element containing the description.</li>
        </ul>
      </section>
    </section>

    <section class="widget" id="combobox">
      <h3>Combobox</h3>
      <p>
        A <a href="#combobox" class="role-reference">combobox</a> is an input widget with an associated popup that enables users to select a value for the combobox from a collection of possible values.
        In some implementations, the popup presents allowed values, while in other implementations, the popup presents suggested values, and users may either select one of the suggestions or type a value.
        The popup may be a <a href="#Listbox">listbox</a>,
        <a href="#grid">grid</a>,
        <a href="#TreeView">tree</a>, or
        <a href="#dialog_modal">dialog.</a>
        Many implementations also include a third optional element -- a graphical <q>Open</q> button adjacent to the combobox, which indicates availability of the popup.
        Activating the <q>Open</q> button displays the popup if suggestions are available.
      </p>
      <p>
        The combobox pattern supports several optional behaviors.
        The one that most shapes interaction is text input.
        Some comboboxes allow users to type and edit text in the combobox and others do not.
        If a combobox does not support text input, it is referred to as select-only, meaning the only way users can set a value is by selecting a value in the popup.
        For example, in some browsers, an HTML <code>select</code> element with <code>size="1"</code> is presented to assistive technologies as a combobox.
        Alternatively, if a combobox supports text input, it is referred to as editable.
        An editable combobox may either allow users to input any arbitrary value, or it may restrict its value to a discrete set of allowed values, in which case typing input serves to filter suggestions presented in the popup.
      </p>
      <p>The popup is hidden by default, i.e., the default state is collapsed. The conditions that trigger expansion -- display of the popup --are specific to each implementation. Some possible conditions that trigger expansion include:</p>
      <ul>
        <li>It is displayed when the <kbd>Down Arrow</kbd> key is pressed or the <q>Open</q> button is activated. Optionally, if the combobox is editable and contains a string that does not match an allowed value, expansion does not occur.</li>
        <li>It is displayed when the combobox receives focus even if the combobox is editable and empty.</li>
        <li>If the combobox is editable, the popup is displayed only if a certain number of characters are typed in the combobox and those characters match some portion of one of the suggested values.</li>
      </ul>
      <p>Combobox widgets are useful for acquiring user input in either of two scenarios:</p>
      <ol>
        <li>
          The value must be one of a predefined set of allowed values, e.g., a location field must contain a valid location name.
          Note that the listbox and menu button patterns are also useful in this scenario; differences between combobox and alternative patterns are described below.
        </li>
        <li>
          An arbitrary value is allowed, but it is advantageous to suggest possible values to users.
          For example, a search field may suggest similar or previous searches to save the user time.
        </li>
      </ol>
      <p>
        The nature of possible values presented by a popup and the way they are presented is called the autocomplete behavior.
        Comboboxes can have one of four forms of autocomplete:
      </p>
      <ol>
        <li>
          <strong>No autocomplete:</strong> The combobox is editable, and  when the popup is triggered, the suggested values it contains are the same regardless of the characters typed in the combobox.
          For example, the popup suggests a set of recently entered values, and the suggestions  do not change as the user types.
        </li>
        <li>
          <strong>List autocomplete with manual selection:</strong> When the popup is triggered, it presents suggested values. If the combobox is editable,  the suggested values complete or logically correspond to the characters typed in the combobox.
          The character string the user has typed will become the value of the combobox unless the user selects a value in the popup.
        </li>
        <li>
          <strong>List autocomplete with automatic selection:</strong> The combobox is editable, and when the popup is triggered, it presents suggested values that complete or logically correspond to the characters typed in the combobox,
          and the first suggestion is automatically highlighted as selected.
          The automatically selected suggestion becomes the value of the combobox when the combobox loses focus unless the user chooses a different suggestion or changes the character string in the combobox.
        </li>
        <li>
          <strong>List with inline autocomplete:</strong> This is the same as list with automatic selection with one additional feature.
          The portion of the selected suggestion that has not been typed by the user, a completion string, appears inline after the input cursor in the combobox.
          The inline completion string is visually highlighted and has a selected state.
        </li>
      </ol>
      <p>
        If a combobox is editable and has any form of list autocomplete, the popup may appear and disappear as the user types.
        For example, if the user types a two character string that triggers five suggestions to be displayed but then types a third character that forms a string that does not have any matching suggestions,
        the popup may close and, if present, the inline completion string disappears.
      </p>
      <p>
        Two other widgets that are also visually compact and enable users to make a single choice from a set of discrete choices are <a href="#Listbox">listbox</a> and <a href="#menubutton">menu button</a>.
        One feature that distinguishes combobox from both listbox and menu button is that the user's choice can be presented as a value in an editable field, which gives users the ability to select some or all of the value for copying to the clipboard.
        Comboboxes and menu buttons can be implemented so users can explore the set of allowed choices without losing a previously made choice.
        That is, users can navigate the set of available choices in a combobox popup or menu and then press <kbd>escape</kbd>, which closes the popup or menu without changing previous input.
        In contrast, navigating among options in a single-select listbox immediately changes its value, and <kbd>Escape</kbd> does not provide an undo mechanism.
        Comboboxes and listboxes can be marked as required with <code>aria-required="true"</code>, and they have an accessible name that is distinct from their value.
        Thus, when assistive technology users focus either a combobox or listbox in its default state, they can perceive both a name and value for the widget.
        However, a menu button cannot be marked required, and while it has an accessible name, it does not have a value so is not suitable for conveying the user's choice in its collapsed state.
      </p>

      <section class="notoc">
        <h4>Examples</h4>
        <ul>
          <li><a href="examples/combobox/combobox-select-only.html">Select-Only Combobox</a>: A single-select combobox with no text input that is functionally similar to an HTML <code>select</code> element.</li>
          <li><a href="examples/combobox/combobox-autocomplete-both.html">Editable Combobox with Both List and Inline Autocomplete</a>: An editable combobox that demonstrates the autocomplete behavior known as <q>list with inline autocomplete</q>.</li>
          <li><a href="examples/combobox/combobox-autocomplete-list.html">Editable Combobox with List Autocomplete</a>: An editable combobox that demonstrates the autocomplete behavior known as <q>list with manual selection</q>.</li>
          <li><a href="examples/combobox/combobox-autocomplete-none.html">Editable Combobox Without Autocomplete</a>: An editable combobox that demonstrates the behavior associated with <code>aria-autocomplete=none</code>.</li>
          <li><a href="examples/combobox/grid-combo.html">Editable Combobox with Grid Popup</a>: An editable combobox that presents suggestions in a grid, enabling users to navigate descriptive information about each suggestion.</li>
          <li><a href="examples/combobox/combobox-datepicker.html">Date Picker Combobox</a>: An editable date input combobox that opens a dialog containing a calendar grid and buttons for navigating by month and year.</li>
        </ul>
      </section>

      <section class="notoc">
        <h4>Keyboard Interaction</h4>
        <ul>
          <li><kbd>Tab</kbd>: The combobox is in the page <kbd>Tab</kbd> sequence.</li>
          <li>Note: The popup indicator icon or button (if present), the popup, and the popup descendants are excluded from the page <kbd>Tab</kbd> sequence. </li>
        </ul>
        <h5>Combobox Keyboard Interaction</h5>
        <p>When focus is in the combobox:</p>
        <ul>
          <li><kbd>Down Arrow</kbd>: If the popup is available, moves focus into the popup:
            <ul>
              <li>If the autocomplete behavior automatically selected a suggestion before <kbd>Down Arrow</kbd> was pressed, focus is placed on the suggestion following the automatically selected suggestion.</li>
              <li>Otherwise, places focus on the first focusable element in the popup.</li>
            </ul>
          </li>
          <li><kbd>Up Arrow</kbd> (Optional): If the popup is available, places focus on the last focusable element in the popup.</li>
          <li><kbd>Escape</kbd>: Dismisses the popup if it is visible. Optionally, if the popup is hidden before <kbd>Escape</kbd> is pressed, clears the combobox.</li>
          <li>
            <kbd>Enter</kbd>: If the combobox is editable and an autocomplete suggestion is selected in the popup, accepts the suggestion either by placing the input cursor at the end of the accepted value in the combobox or by performing a default action on the value.
            For example, in a messaging application, the default action may be to add the accepted value to a list of message recipients and then clear the combobox so the user can add another recipient.
          </li>
          <li>Printable Characters:
            <ul>
              <li>If the combobox is editable, type characters in the combobox. Note that some implementations may regard certain characters as invalid and prevent their input.</li>
              <li>If the combobox is not editable, optionally moves focus to a value that starts with the typed characters.</li>
            </ul>
          </li>
          <li>If the combobox is editable, it supports standard single line text editing keys appropriate for the device platform (see note below).</li>
          <li><kbd>Alt + Down Arrow</kbd> (Optional): If the popup is available but not displayed, displays the popup without moving focus.</li>
          <li><kbd>Alt + Up Arrow</kbd> (Optional): If the popup is displayed:
            <ul>
              <li>If the popup contains focus, returns focus to the combobox.</li>
              <li>Closes the popup.</li>
            </ul>
          </li>
        </ul>
        <div class="note">
          <p>Standard single line text editing keys appropriate for the device platform:</p>
          <ol>
            <li>include keys for input, cursor movement, selection, and text manipulation.</li>
            <li>Standard key assignments for editing functions depend on the device operating system.</li>
            <li>The most robust approach for providing text editing functions is to rely on browsers, which  supply them for HTML inputs with type text and for elements with the <code>contenteditable</code> HTML attribute.</li>
            <li><strong>IMPORTANT:</strong> Ensure JavaScript does not interfere with browser-provided text editing functions by capturing key events for the keys used to perform them.</li>
          </ol>
        </div>
        <h5>Listbox Popup Keyboard Interaction</h5>
        <p>When focus is in a listbox popup:</p>
        <ul>
          <li><kbd>Enter</kbd>: Accepts the focused option in the listbox  by closing the popup, placing the accepted value in the combobox, and if the combobox is editable,  placing the input cursor at the end of the value.</li>
          <li><kbd>Escape</kbd>: Closes the popup and returns focus to the combobox. Optionally, if the combobox is editable, clears the contents of the combobox.</li>
          <li><kbd>Down Arrow</kbd>: Moves focus to and selects the next option. If focus is on the last option, either returns focus to the combobox or does nothing.</li>
          <li><kbd>Up Arrow</kbd>: Moves focus to and selects the previous option. If focus is on the first option, either returns focus to the combobox or does nothing.</li>
          <li>
            <kbd>Right Arrow</kbd>: If the combobox is editable, returns focus to the combobox without closing the popup and moves the input cursor one character to the right.
            If the input cursor is on the right-most character, the cursor does not move.
          </li>
          <li>
            <kbd>Left Arrow</kbd>: If the combobox is editable, returns focus to the combobox without closing the popup and moves the input cursor one character to the left.
            If the input cursor is on the left-most character, the cursor does not move.
          </li>
          <li><kbd>Home</kbd> (Optional): Either moves focus to and selects the first option or, if the combobox is editable,  returns focus to the combobox and places the cursor on the first character.</li>
          <li><kbd>End</kbd> (Optional): Either moves focus to the last option or, if the combobox is editable, returns focus to the combobox and places the cursor after the last character.</li>
          <li>Any printable character:
            <ul>
              <li>If the combobox is editable, returns the focus to the combobox without closing the popup and types the character.</li>
              <li>Otherwise, moves focus to the next option with a name that starts with the characters typed.</li>
            </ul>
          </li>
          <li><kbd>Backspace</kbd> (Optional): If the combobox is editable, returns focus to the combobox and deletes the character prior to the cursor.</li>
          <li><kbd>Delete</kbd> (Optional): If the combobox is editable, returns focus to the combobox, removes the selected state if a suggestion was selected, and removes the inline autocomplete string if present.</li>
        </ul>
        <ol class="note">
          <li>DOM Focus is maintained on the combobox and the assistive technology focus is moved within the listbox using <code>aria-activedescendant</code> as described in <a href="#kbd_focus_activedescendant">Managing Focus in Composites Using aria-activedescendant.</a></li>
          <li>Selection follows focus in the listbox; the listbox allows only one suggested value to be selected at a time for the combobox value.</li>
        </ol>
        <h5>Grid Popup Keyboard Interaction</h5>
        <p>
          In a grid popup, each suggested value may be represented by either a single cell or an entire row.
          See notes below for how this aspect of grid design effects the keyboard interaction design and the way that selection moves in response to focus movements.
        </p>
        <ul>
          <li><kbd>Enter</kbd>: Accepts the currently selected suggested value by closing the popup, placing the selected value in the combobox, and if the combobox is editable, placing the input cursor at the end of the value.</li>
          <li><kbd>Escape</kbd>: Closes the popup and returns focus to the combobox. Optionally, if the combobox is editable, clears the contents of the combobox.</li>
          <li>
            <kbd>Right Arrow</kbd>: Moves focus one cell to the right.
            Optionally, if focus is on the right-most cell in the row, focus may move to the first cell in the following row.
            If focus is on the last cell in the grid, either does nothing or returns focus to the combobox.
          </li>
          <li>
            <kbd>Left Arrow</kbd>: Moves focus one cell to the left.
            Optionally, if focus is on the left-most cell in the row, focus may move to the last cell in the previous row.
            If focus is on the first cell in the grid, either does nothing or returns focus to the combobox.
          </li>
          <li>
            <kbd>Down Arrow</kbd>: Moves focus one cell down.
            If focus is in the last row of the grid, either does nothing or returns focus to the combobox.
          </li>
          <li>
            <kbd>Up Arrow</kbd>: Moves focus one cell up.
            If focus is in the first row of the grid, either does nothing or returns focus to the combobox.
          </li>
          <li>
            <kbd>Page Down</kbd> (Optional): Moves focus down an author-determined number of rows, typically scrolling so the bottom row in the currently visible set of rows becomes one of the first visible rows.
            If focus is in the last row of the grid, focus does not move.
          </li>
          <li>
            <kbd>Page Up</kbd> (Optional): Moves focus up an author-determined number of rows, typically scrolling so the top row in the currently visible set of rows becomes one of the last visible rows.
            If focus is in the first row of the grid, focus does not move.
          </li>
          <li><kbd>Home</kbd> (Optional): <strong>Either:</strong>
            <ul>
              <li> Moves focus to the first cell in the row that contains focus. Or, if the grid has fewer than three cells per row or multiple suggested values per row, focus may move to the first cell in the grid.</li>
              <li>If the combobox is editable, returns focus to the combobox and places the cursor on the first character.</li>
            </ul>
          </li>
          <li><kbd>End</kbd> (Optional): <strong>Either:</strong>
            <ul>
              <li> Moves focus to the last cell in the row that contains focus. Or, if the grid has fewer than three cells per row or multiple suggested values per row, focus may move to the last cell in the grid.</li>
              <li>If the combobox is editable, returns focus to the combobox and places the cursor after the last character.</li>
            </ul>
          </li>
          <li><kbd>Control + Home</kbd> (optional): moves focus to the first row.</li>
          <li><kbd>Control + End</kbd> (Optional): moves focus to the last row.</li>
          <li>Any printable character: If the combobox is editable, returns the focus to the combobox without closing the popup and types the character.</li>
          <li><kbd>Backspace</kbd> (Optional): If the combobox is editable, returns focus to the combobox and deletes the character prior to the cursor.</li>
          <li><kbd>Delete</kbd> (Optional): If the combobox is editable, returns focus to the combobox, removes the selected state if a suggestion was selected, and removes the inline autocomplete string if present.</li>
        </ul>
        <ol class="note">
          <li>DOM Focus is maintained on the combobox and the assistive technology focus is moved within the grid using <code>aria-activedescendant</code> as described in <a href="#kbd_focus_activedescendant">Managing Focus in Composites Using aria-activedescendant.</a></li>
          <li>The grid allows only one suggested value to be selected at a time for the combobox value.</li>
          <li>In a grid popup, each suggested value may be represented by either a single cell or an entire row. This aspect of design effects focus and selection movement:
            <ol>
              <li>If every cell contains a different suggested value:
                <ul>
                  <li>Selection follows focus so that the cell containing focus is selected.</li>
                  <li>Horizontal arrow key navigation typically wraps from one row to another.</li>
                  <li>Vertical arrow key navigation typically wraps from one column to another.</li>
                </ul>
              </li>
              <li>If all cells in a row contain information about the same suggested value:
                <ul>
                  <li>Either the row containing focus is selected or a cell containing a suggested value is selected when any cell in the same row contains focus.</li>
                  <li>Horizontal key navigation may wrap from one row to another.</li>
                  <li>Vertical arrow key navigation <strong>does not</strong> wrap from one column to another.</li>
                </ul>
              </li>
            </ol>
          </li>
        </ol>
        <h5>Tree Popup Keyboard Interaction</h5>
        <p>
          In some implementations of tree popups, some or all parent nodes may serve as suggestion category labels so may not be selectable values.
          See notes below for how this aspect of the design effects the way selection moves in response to focus movements.
        </p>
        <p>When focus is in a vertically oriented tree popup:</p>
        <ul>
          <li><kbd>Enter</kbd>: Accepts the currently selected suggested value by closing the popup, placing the selected value in the combobox, and if the combobox is editable, placing the input cursor at the end of the value.</li>
          <li><kbd>Escape</kbd>: Closes the popup and returns focus to the combobox. Optionally, clears the contents of the combobox.</li>
          <li><kbd>Right arrow</kbd>:
            <ul>
              <li>When focus is on a closed node, opens the node; focus and selection do not move.</li>
              <li>When focus is on a open node, moves focus to the first child node and selects it if it is selectable.</li>
              <li>When focus is on an end node, does nothing.</li>
            </ul>
           </li>
          <li><kbd>Left arrow</kbd>:
            <ul>
              <li>When focus is on an open node, closes the node.</li>
              <li>When focus is on a child node that is also either an end node or a closed node, moves focus to its parent node and selects it if it is selectable.</li>
              <li>When focus is on a root node that is also either an end node or a closed node, does nothing.</li>
            </ul>
           </li>
          <li><kbd>Down Arrow</kbd>: Moves focus to the next node that is focusable without opening or closing a node and selects it if it is selectable.</li>
          <li><kbd>Up Arrow</kbd>: Moves focus to the previous node that is focusable without opening or closing a node and selects it if it is selectable.</li>
          <li><kbd>Home</kbd>: Moves focus to the first focusable node in the tree without opening or closing a node and selects it if it is selectable.</li>
          <li><kbd>End</kbd>: Moves focus to the last focusable node in the tree without opening or closing a node and selects it if it is selectable.</li>
          <li>Any printable character:
            <ul>
              <li>If the combobox is editable, returns the focus to the combobox without closing the popup and types the character.</li>
              <li>Otherwise, moves focus to the next suggested value with a name that starts with the characters typed.</li>
            </ul>
          </li>
        </ul>
        <ol class="note">
        <li>DOM Focus is maintained on the combobox and the assistive technology focus is moved within the tree using <code>aria-activedescendant</code> as described in <a href="#kbd_focus_activedescendant">Managing Focus in Composites Using aria-activedescendant.</a></li>
        <li>The tree allows only one suggested value to be selected at a time for the combobox value.</li>
          <li>
            In a tree popup, some or all parent nodes may not be selectable values; they may serve as category labels for suggested values.
            If focus moves to a node that is not a selectable value, either:
            <ul>
              <li>The previously selected node, if any, remains selected until focus moves to a node that is selectable.</li>
              <li>There is no selected value.</li>
              <li>In either case, focus is visually distinct from selection so users can readily see if a value is selected or not.</li>
            </ul>
        </li>
          <li>If nodes in the tree are arranged horizontally (<a href="#aria-orientation" class="property-reference">aria-orientation</a> is set to <code>horizontal</code>):
            <ol>
              <li><kbd>Down Arrow</kbd> performs as <kbd>Right Arrow</kbd> is described above, and vice versa.</li>
              <li><kbd>Up Arrow</kbd> performs as <kbd>Left Arrow</kbd> is described above, and vice versa.</li>
            </ol>
          </li>
        </ol>
        <h5>Dialog Popup Keyboard Interaction</h5>
        <p>When focus is in a dialog popup:</p>
        <ul>
          <li>There are two ways to close the popup and return focus to the combobox:
            <ol>
              <li>Perform an action in the dialog, such as activate a button, that specifies a value for the combobox.</li>
              <li>
                Cancel out of the dialog, e.g., press <kbd>Escape</kbd> or activate the cancel button in the dialog.
                Canceling either returns focus to the text box without changing the combobox value or returns focus to the combobox and clears the combobox.
              </li>
            </ol>
          </li>
          <li>The dialog implements the keyboard interaction defined in the <a href="#dialog_modal">modal dialog pattern.</a></li>
        </ul>
        <p class="note">
          Unlike other combobox popups, dialogs do not support <code>aria-activedescendant</code> so DOM focus moves into the dialog from the combobox.
        </p>
      </section>

      <section class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <ul>
          <li>The element that serves as an input and displays the combobox value has role <a href="#combobox" class="role-reference">combobox</a>.</li>
          <li>
            The combobox element has <a href="#aria-controls" class="property-reference">aria-controls</a> set to a value that refers to the element that serves as the popup.
            Note that <code>aria-controls</code> only needs to be set when the popup is visible. However, it is valid to reference an element that is not visible.
          </li>
          <li>The popup is an element that has role <a href="#listbox" class="role-reference">listbox</a>, <a href="#tree" class="role-reference">tree</a>, <a href="#grid" class="role-reference">grid</a>, or <a href="#dialog" class="role-reference">dialog</a>.</li>
          <li>
            If the popup has a role other than <code>listbox</code>, the element with role <code>combobox</code> has <a href="#aria-haspopup" class="property-reference">aria-haspopup</a> set to a value that corresponds to the popup type.
            That is, <code>aria-haspopup</code> is set to <code>grid</code>, <code>tree</code>, or <code>dialog</code>.
            Note that elements with role <code>combobox</code> have an implicit <code>aria-haspopup</code> value of <code>listbox</code>.
          </li>
          <li>
            When the combobox popup is not visible, the element with role <code>combobox</code> has <a href="#aria-expanded" class="state-reference">aria-expanded</a> set to <code>false</code>.
            When the popup element is visible, <code>aria-expanded</code> is set to <code>true</code>.
            Note that elements with role <code>combobox</code> have a default value for <code>aria-expanded</code> of <code>false</code>.
          </li>
          <li>When a combobox receives focus, DOM focus is placed on the combobox element.</li>
          <li>When a descendant of a listbox, grid, or tree popup is focused, DOM focus remains on the combobox and the combobox has <a href="#aria-activedescendant" class="property-reference">aria-activedescendant</a> set to a value that refers to the focused element within the popup.</li>
          <li>For a combobox that controls a listbox, grid, or tree popup, when a suggested value is visually indicated as the currently selected value, the <code>option</code>, <code>gridcell</code>, <code>row</code>, or <code>treeitem</code> containing that value has <a href="#aria-selected" class="state-reference">aria-selected</a> set to <code>true</code>.</li>
          <li>
            If the combobox has a visible label and the combobox element is an HTML element that can be labelled using the HTML <code>label</code> element (e.g., the <code>input</code> element), it is labeled using the <code>label</code> element.
            Otherwise, if it has a visible label, the combobox element has <a href="#aria-labelledby" class="property-reference">aria-labelledby</a> set to a value that refers to the labelling element.
            Otherwise, the combobox element has a label provided by <a href="#aria-label" class="property-reference">aria-label</a>.
          </li>
          <li>The combobox element has <a href="#aria-autocomplete" class="property-reference">aria-autocomplete</a> set to a value that corresponds to its autocomplete behavior:
            <ul>
              <li><code>none</code>: When the popup is displayed, the suggested values it contains are the same regardless of the characters typed in the combobox.</li>
              <li><code>list</code>: When the popup is triggered, it presents suggested values. If the combobox is editable, the values complete or logically correspond to the characters typed in the combobox.</li>
              <li>
                <code>both</code>: When the popup is triggered, it presents suggested values that complete or logically correspond to the characters typed in the combobox.
                In addition, the portion of the selected suggestion that has not been typed by the user, known as the <q>completion string</q>, appears inline after the input cursor in the combobox.
                The inline completion string is visually highlighted and has a selected state.
              </li>
            </ul>
          </li>
        </ul>
        <div class="note">
          <ol>
            <li>
              In ARIA 1.0, the combobox referenced its popup with <a href="#aria-owns" class="property-reference">aria-owns</a> instead of <a href="#aria-controls" class="property-reference">aria-controls</a>.
              While user agents might support comboboxes with <a href="#aria-owns" class="property-reference">aria-owns</a> for backwards compatibility with legacy content, it is strongly recommended that authors use <a href="#aria-controls" class="property-reference">aria-controls</a>.
            </li>
            <li>When referring to the roles, states, and properties documentation for the below list of patterns used for popups, keep in mind that a combobox is a single-select widget where selection follows focus in the popup.</li>
            <li>The roles, states, and properties for popup elements are defined in their respective design patterns:
              <ul>
                <li><a href="#listbox_roles_states_props">Listbox Roles, States, and Properties</a></li>
                <li><a href="#grid_roles_states_props">Grid Roles, States, and Properties</a></li>
                <li><a href="#tree_roles_states_props">Tree Roles, States, and Properties</a></li>
                <li><a href="#dialog_roles_states_props">Dialog Roles, States, and Properties</a></li>
              </ul>
            </li>
          </ol>
        </div>
      </section>
    </section>

    <section class="widget" id="dialog_modal">
      <h3>Dialog (Modal)</h3>
      <p>
        A <a href="#dialog" class="role-reference">dialog</a> is a window overlaid on either the primary window or another dialog window.
        Windows under a modal dialog are inert.
        That is, users cannot interact with content outside an active dialog window.
        Inert content outside an active dialog is typically visually obscured or dimmed so it is difficult to discern,
        and in some implementations, attempts to interact with the inert content cause the dialog to close.
      </p>
      <p>
        Like non-modal dialogs, modal dialogs contain their tab sequence.
        That is, <kbd>Tab</kbd> and <kbd>Shift + Tab</kbd> do not move focus outside the dialog.
        However, unlike most non-modal dialogs, modal dialogs do not provide means for moving keyboard focus outside the dialog window without closing the dialog.
      </p>
      <p>
        The <a href="#alertdialog" class="role-reference">alertdialog</a> role is a special-case dialog role
        designed specifically for dialogs that divert users' attention to a brief, important message.
        Its usage is described in the <a href="#alertdialog">alert dialog design pattern.</a>
      </p>

      <section class="notoc">
        <h4>Examples</h4>
        <ul>
          <li><a href="examples/dialog-modal/dialog.html">Modal Dialog Example</a>: Demonstrates multiple layers of modal dialogs with both small and large amounts of content.</li>
          <li><a href="examples/dialog-modal/datepicker-dialog.html">Date Picker Dialog Example</a>: Demonstrates a dialog containing a calendar grid for choosing a date.</li>
        </ul>
      </section>

      <section class="notoc">
        <h4>Keyboard Interaction</h4>
        <p>In the following description, the term <q>tabbable element</q> refers to any element with a <code>tabindex</code> value of zero or greater. Note that values greater than 0 are strongly discouraged.</p>
        <ul>
          <li>When a dialog opens, focus moves to an element inside the dialog. See notes below regarding initial focus placement.</li>
          <li><kbd>Tab</kbd>:
            <ul>
              <li>Moves focus to the next tabbable element inside the dialog.</li>
              <li>If focus is on the last tabbable element inside the dialog, moves focus to the first tabbable element inside the dialog. </li>
            </ul>
          </li>
          <li><kbd>Shift + Tab</kbd>:
            <ul>
              <li>Moves focus to the previous tabbable element inside the dialog.</li>
              <li>If focus is on the first tabbable element inside the dialog, moves focus to the last tabbable element inside the dialog.</li>
            </ul>
          </li>
        <li><kbd>Escape</kbd>: Closes the dialog.</li>
        </ul>
        <ol class="note">
          <li> When a dialog opens, focus placement depends on the nature and size of the content.
            <ul>
              <li>In all circumstances, focus moves to an element contained in the dialog.</li>
              <li>Unless a condition where doing otherwise is advisable, focus is initially set on the first focusable element.</li>
              <li>
                If content is large enough that focusing the first interactive element could cause the beginning of content to scroll out of view,
                it is advisable to add <code>tabindex=<q>-1</q></code> to a static element at the top of the dialog, such as the dialog title or first paragraph, and initially focus that element.
              </li>
              <li>
                If a dialog contains the final step in a process that is not easily reversible, such as deleting data or completing a financial transaction,
                it may be advisable to set focus on the least destructive action, especially if undoing the action is difficult or impossible.
                The <a href="#alertdialog">Alert Dialog Pattern</a> is often employed in such circumstances.
              </li>
              <li>
                If a dialog is limited to interactions that either provide additional information or continue processing,
                it may be advisable to set focus to the element that is likely to be most frequently used, such as an <q>OK</q> or <q>Continue</q> button.
              </li>
            </ul>
          </li>
          <li>
            When a dialog closes, focus returns to the element that invoked the dialog unless either:
            <ul>
              <li>The invoking element no longer exists. Then, focus is set on another element that provides logical work flow.</li>
              <li>The work flow design includes  the following conditions that can occasionally make focusing a different element a more logical choice:
                <ol>
                  <li>It is very unlikely users need to immediately re-invoke the dialog.</li>
                  <li>The task completed in the dialog is directly related to a subsequent step in the work flow.</li>
                </ol>
                For example, a grid has an associated toolbar with a button for adding rows.
                the Add Rows button opens a dialog that prompts for the number of rows.
                After the dialog closes, focus is placed in the first cell of the first new row.
              </li>
            </ul>
          </li>
          <li>It is strongly recommended that the tab sequence of all dialogs include a visible element with role <code>button</code> that closes the dialog, such as  a close icon or cancel button.</li>
        </ol>
      </section>

      <section id="dialog_roles_states_props" class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <ul>
          <li>The element that serves as the dialog container has a role of <a href="#dialog" class="role-reference">dialog</a>.</li>
          <li>All elements required to operate the dialog are descendants of the element that has role <code>dialog</code>.</li>
          <li>The dialog container element has <a href="#aria-modal" class="property-reference">aria-modal</a> set to <code>true</code>.</li>
          <li>The dialog has either:
            <ul>
              <li>A value set for the
              <a href="#aria-labelledby" class="property-reference">aria-labelledby</a>
              property that refers to a visible dialog title.</li>
              <li>A label specified by <a href="#aria-label" class="property-reference">aria-label</a>.</li>
            </ul>
          </li>
          <li>
            Optionally, the <a href="#aria-describedby" class="property-reference">aria-describedby</a> property
            is set on the element with the <code>dialog</code> role to indicate which element or elements in the dialog contain content that describes the primary purpose or message of the dialog.
            Specifying descriptive elements enables screen readers to announce the description along with the dialog title and initially focused element when the dialog opens.
          </li>
        </ul>
        <ul class="note">
          <li>
            Because marking a dialog modal by setting
            <a href="#aria-modal" class="property-reference">aria-modal</a>
            to <code>true</code> can prevent users of some assistive technologies from perceiving content outside the dialog,
            users of those technologies will experience severe negative ramifications if a dialog is marked modal but does not behave as a modal for other users.
            So, mark a dialog modal <strong>only when both:</strong>
            <ol>
              <li>Application code prevents all users from interacting in any way with content outside of it.</li>
              <li>Visual styling obscures the content outside of it.</li>
            </ol>
          </li>
          <li>
            The <code>aria-modal</code> property introduced by ARIA 1.1 replaces
            <a href="#aria-hidden" class="state-reference">aria-hidden</a>
            for informing assistive technologies that content outside a dialog is inert.
            However, in legacy dialog implementations where <code>aria-hidden</code> is used to make content outside a dialog inert for assistive technology users, it is important that:
            <ol>
              <li><code>aria-hidden</code> is set to <code>true</code> on each element containing a portion of the inert layer.</li>
              <li>The dialog element is not a descendant of any element that has <code>aria-hidden</code> set to <code>true</code>.</li>
            </ol>
          </li>
        </ul>
      </section>
    </section>

    <section class="widget" id="disclosure">
      <h3>Disclosure (Show/Hide)</h3>
      <p>
        A disclosure is a <a href="#button">button</a> that controls visibility of a section of content.
        When the controlled content is hidden, it is often styled as a typical push button with a right-pointing arrow or triangle to hint that activating the button will display additional content.
        When the content is visible, the arrow or triangle typically points down.
      </p>

      <section class="notoc">
        <h4>Examples</h4>
        <ul>
          <li><a href="examples/disclosure/disclosure-img-long-description.html">Disclosure (Show/Hide) of Image Description</a></li>
          <li><a href="examples/disclosure/disclosure-faq.html">Disclosure (Show/Hide) of Answers to Frequently Asked Questions</a></li>
          <li><a href="examples/disclosure/disclosure-navigation.html">Disclosure (Show/Hide) for Navigation Menus</a></li>
        </ul>
      </section>

      <section class="notoc">
        <h4>Keyboard Interaction</h4>
        <p>When the disclosure control has focus:</p>
        <ul>
          <li><kbd>Enter</kbd>: activates the disclosure control and toggles the visibility of the disclosure content.</li>
          <li><kbd>Space</kbd>: activates the disclosure control and toggles the visibility of the disclosure content.</li>
        </ul>
      </section>

      <section class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <ul>
          <li>The element that shows and hides the content has role <a href="#button" class="role-reference">button</a>.</li>
          <li>
            When the content is visible, the element with role <code>button</code> has
            <a href="#aria-expanded" class="state-reference">aria-expanded</a>
            set to <code>true</code>.
            When the content area is hidden, it is set to <code>false</code>.
          </li>
          <li>
            Optionally, the element with role <code>button</code> has a value specified for
            <a href="#aria-controls" class="property-reference">aria-controls</a>
            that refers to the element that contains all the content that is shown or hidden.
            </li>
        </ul>

      </section>
    </section>

    <section class="widget" id="feed">
      <h3>Feed</h3>
      <p>
        A <a href="#feed" class="role-reference">feed</a> is a section of a page that automatically loads new sections of content as the user scrolls.
        The sections of content in a feed are presented in <a href="#article" class="role-reference">article</a> elements.
        So, a feed can be thought of as a dynamic list of articles that often appears to scroll infinitely.
      </p>
      <p>
        The feature that most distinguishes feed from other ARIA patterns that support loading data as users scroll, e.g., a <a href="#grid">grid</a>, is that a feed is a structure, not a widget.
        Consequently, assistive technologies with a reading mode, such as screen readers, default to reading mode when interacting with feed content.
        However, unlike most other WAI-ARIA structures, a feed establishes an interoperability contract between the web page and assistive technologies.
        The contract governs scroll interactions so that assistive technology users can read articles, jump forward and backward by article, and reliably trigger new articles to load while in reading mode.
      </p>
      <p>
        For example, a product page on a shopping site may have a related products section that displays five products at a time.
        As the user scrolls,  more products are requested  and loaded into the DOM.
         While a static design might include a next button for loading five more products, a dynamic implementation that automatically loads more data as the user scrolls simplifies the user experience and reduces the inertia associated with viewing more than the first five product suggestions.
         But, unfortunately when web pages load content dynamically based on scroll events, it can cause usability and interoperability difficulties for users of assistive technologies.
      </p>
      <p>
        The feed pattern enables reliable assistive technology reading mode interaction by establishing the following interoperability agreement between the web page and assistive technologies:
      </p>
      <ol>
        <li>In the context of a feed, the web page code is responsible for:
        <ul>
          <li>
            Appropriate visual scrolling of the content based on which article contains DOM focus.
          </li>
          <li>Loading or removing feed articles based on which article contains DOM focus.</li>
        </ul>
      </li>
        <li>In the context of a feed, assistive technologies with a reading mode are responsible for:
          <ul>
            <li>Indicating which article contains the reading cursor by ensuring the article element or one of its descendants has DOM focus.</li>
            <li>providing reading mode keys that move DOM focus to the next and previous articles.</li>
            <li>Providing reading mode keys for moving the reading cursor and DOM focus past the end and before the start of the feed.</li>
          </ul>
        </li>
      </ol>
      <p>
        Thus, implementing the feed pattern allows a screen reader to reliably read and trigger the loading of feed content while staying in its reading mode.
      </p>
      <p>
        Another feature of the feed pattern is its ability to facilitate skim reading for assistive technology users.
        Web page authors may provide both an accessible name and description for each article.
        By identifying the elements inside of an article that provide the title and the primary content, assistive technologies can provide functions that enable users to jump from article to article and efficiently discern which articles may be worthy of more attention.
      </p>

      <section class="notoc">
        <h4>Example</h4>
        <p>
        <a href="examples/feed/feed.html">Example Implementation of Feed Pattern</a>
        </p>
      </section>

      <section class="notoc">
        <h4>Keyboard Interaction</h4>
        <p>
          The feed pattern is not based on a desktop GUI widget so the <code>feed</code> role is not associated with any well-established keyboard conventions.
          Supporting the following, or a similar,  interface is recommended.
        </p>
        <p>When focus is inside the feed:</p>
        <ul>
          <li><kbd>Page Down</kbd>: Move focus to next article.</li>
          <li><kbd>Page Up</kbd>: Move focus to previous article.</li>
          <li><kbd>Control + End</kbd>: Move focus to the first focusable element after the feed.</li>
          <li><kbd>Control + Home</kbd>: Move focus to the first focusable element before the feed.</li>
        </ul>
        <ol class="note">
          <li>Due to the lack of convention, providing easily discoverable keyboard interface documentation is especially important.</li>
          <li>
            In some cases, a feed may contain a nested feed.
            For example, an article in a social media feed may contain a feed of comments on that article.
            To navigate the nested feed, users first move focus inside the nested feed.
            Options for supporting nested feed navigation include:
            <ul>
              <li>
                Users move focus into the nested feed from the content of the containing article with <kbd>Tab</kbd>.
                This may be slow if the article contains a significant number of links, buttons, or other widgets.
               </li>
              <li>Provide a key for moving focus from the elements in the containing article to the first item in the nested feed, e.g., <kbd>Alt + Page Down</kbd>.</li>
              <li>To continue reading the outer feed, <kbd>Control + End</kbd> moves focus to the next article in the outer feed.</li>
            </ul>
          </li>
          <li>In the rare circumstance that a feed article contains a widget that uses the above suggested keys, the feed navigation key will operate the contained widget, and the user needs to move focus to an element that does not utilize the feed navigation keys in order to navigate the feed.</li>
        </ol>
      </section>

      <section class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <ul>
          <li>The element that contains the set of feed articles has role <a href="#feed" class="role-reference">feed</a>.</li>
          <li>
            If the feed has a visible label, the <code>feed</code> element has <a href="#aria-labelledby" class="property-reference">aria-labelledby</a> referring to the element containing the title.
            Otherwise, the <code>feed</code> element has a label specified with <a href="#aria-label" class="property-reference">aria-label</a>.
          </li>
          <li>
            Each unit of content in a feed is contained in an element with role <a href="#article" class="role-reference">article</a>.
            All content inside the feed is contained in an <code>article</code>  element.
          </li>
          <li>
            Each <code>article</code> element has
            <a href="#aria-labelledby" class="property-reference">aria-labelledby</a>
            referring to elements inside the article that can serve as a distinguishing label.
          </li>
          <li>
            It is optional but strongly recommended for each <code>article</code> element to have
            <a href="#aria-describedby" class="property-reference">aria-describedby</a>
            referring to one or more elements inside the article that serve as the primary content of the article.
          </li>
          <li>
            Each <code>article</code> element has
            <a href="#aria-posinset" class="property-reference">aria-posinset</a>
            set to a value that represents its position in the feed.
          </li>
          <li>
            Each <code>article</code> element has
            <a href="#aria-setsize" class="property-reference">aria-setsize</a>
            set to a value that represents either the total number of articles that have been loaded or the total number in the feed,
            depending on which value is deemed more helpful to users.
            If the total number in the feed is undetermined, it can be represented by a <code>aria-setsize</code> value of <code>-1</code>.
          </li>
          <li>
            When <code>article</code> elements are being added to or removed from the <code>feed</code> container,
            and if the operation requires multiple DOM operations,
            the <code>feed</code> element has
            <a href="#aria-busy" class="state-reference">aria-busy</a>
            set to <code>true</code> during the update operation.
            Note that it is extremely important that <code>aria-busy</code> is set to <code>false</code> when the operation is complete or the changes may not become visible to some assistive technology users.
          </li>
        </ul>
      </section>
    </section>

    <section class="widget" id="grid">
      <h3>Grids : Interactive Tabular Data and Layout Containers</h3>

      <p>
        A <a href="#grid" class="role-reference">grid</a> widget is a container that enables users to navigate the information or interactive elements it contains using directional navigation keys, such as arrow keys, <kbd>Home</kbd>, and <kbd>End</kbd>.
        As a generic container widget that offers flexible keyboard navigation, it can serve a wide variety of needs.
        It can be used for purposes as simple as grouping a collection of checkboxes or navigation links or as complex as creating a full-featured spreadsheet application.
        While the words &quot;row&quot; and &quot;column&quot; are used in the names of WAI-ARIA attributes and by assistive technologies when describing and presenting the logical structure of elements with the <code>grid</code> role, using the <code>grid</code> role on an element does not necessarily imply that its visual presentation is tabular.
      </p>

      <p>When presenting content that is tabular, consider the following factors when choosing between implementing this <code>grid</code> pattern or the <a href="#table">table</a> pattern.</p>

      <ul>
        <li>
          A <code>grid</code> is a composite widget so it:

          <ul>
            <li>Always contains multiple focusable elements. </li>
            <li>Only one of the focusable elements contained by the grid is included in the page tab sequence.</li>
            <li>Requires the author to provide code that <a href="#kbd_general_within">manages focus movement inside it</a>.</li>
          </ul>
        </li>

        <li>All focusable elements contained in a table are included in the page tab sequence. </li>
      </ul>

      <p>
        Uses of the <code>grid</code> pattern broadly fall into two categories: presenting tabular information (data grids) and grouping other widgets (layout grids).
        Even though both data grids and layout grids employ the same ARIA roles, states, and properties, differences in their content and purpose surface factors that are important to consider in keyboard interaction design.
        To address these factors, the following two sections describe separate keyboard interaction patterns for data and layout grids.
      </p>

      <section class="notoc">
        <h4>Examples</h4>
        <ul>
          <li><a href="examples/grid/LayoutGrids.html">Layout Grid Examples</a>: Three example implementations of grids that are used to lay out widgets, including a collection of navigation links, a message recipients list, and a set of search results.</li>
          <li><a href="examples/grid/dataGrids.html">Data Grid Examples</a>: Three example implementations of grid that include features relevant to presenting tabular information, such as content editing, sort, and column hiding.</li>
          <li><a href="examples/grid/advancedDataGrid.html">Advanced Data Grid Example</a>: Example of a grid with behaviors and features similar to a typical spreadsheet, including cell and row selection.</li>
        </ul>
      </section>

      <section id="dataGrid" class="notoc">
        <h4>Data Grids For Presenting Tabular Information</h4>
        <p>
          A <code>grid</code> can be used to present tabular information that has column titles, row titles, or both.
          The <code>grid</code> pattern is particularly useful if the tabular information is editable or interactive.
          For example, when data elements are links to more information, rather than presenting them in a static table and including the links in the tab sequence, implementing the <code>grid</code> pattern provides users with intuitive and efficient keyboard navigation of the grid contents as well as a shorter tab sequence for the page.
          A <code>grid</code> may also offer functions, such as cell content editing, selection, cut, copy, and paste.
        </p>
        <p>
          In a grid, every cell contains a focusable element or is itself focusable, regardless of whether the cell content is editable or interactive.
          There is one exception: if column or row header cells do not provide functions, such as sort or filter, they do not need to be focusable.
          One reason it is important for all cells to be able to receive or contain keyboard focus is that screen readers will typically be in their application reading mode, rather than their document reading mode, when users are interacting with the grid.
          While in application mode, a screen reader user hears only focusable elements and content that labels focusable elements.
          So, screen reader users may unknowingly overlook elements contained in a grid that are either not focusable or not used to label a column or row.
        </p>
        <section class="notoc">
          <h5>Keyboard Interaction For Data Grids</h5>
          <p>
            The following keys provide grid navigation by moving focus among cells of the grid.
            Implementations of grid make these key commands available when an element in the grid has received focus, e.g., after a user has moved focus to the grid with <kbd>Tab</kbd>.
          </p>
          <ul>
            <li>
              <kbd>Right Arrow</kbd>: Moves focus one cell to the right.
              If focus is on the right-most cell in the row, focus does not move.
            </li>
            <li><kbd>Left Arrow</kbd>: Moves focus one cell to the left. If focus is on the left-most cell in the row, focus does not move.</li>
            <li><kbd>Down Arrow</kbd>: Moves focus one cell down. If focus is on the bottom cell in the column, focus does not move.</li>
            <li><kbd>Up Arrow</kbd>: Moves focus one cell Up. If focus is on the top cell in the column, focus does not move.</li>
            <li><kbd>Page Down</kbd>: Moves focus down an author-determined number of rows, typically scrolling so the bottom row in the currently visible set of rows becomes one of the first visible rows. If focus is in the last row of the grid, focus does not move.</li>
            <li><kbd>Page Up</kbd>: Moves focus up an author-determined number of rows, typically scrolling so the top row in the currently visible set of rows becomes one of the last visible rows. If focus is in the first row of the grid, focus does not move.</li>
            <li><kbd>Home</kbd>: moves focus to the first cell in the row that contains focus.</li>
            <li><kbd>End</kbd>: moves focus to the last cell in the row that contains focus.</li>
            <li><kbd>Control + Home</kbd>: moves focus to the first cell in the first row.</li>
            <li><kbd>Control + End</kbd>: moves focus to the last cell in the last row.</li>
          </ul>
          <ul class="note">
            <li>
              When the above grid navigation keys move focus, whether the focus is set on an element inside the cell or the grid cell depends on cell content.
              See <a href="#gridNav_focus">Whether to Focus on a Cell or an Element Inside It</a>.
            </li>
            <li>
              While navigation keys, such as arrow keys, are moving focus from cell to cell, they are not available to do something like operate a combobox or move an editing caret inside of a cell.
              If this functionality is needed, see <a href="#gridNav_inside">Editing and Navigating Inside a Cell</a>.
            </li>
            <li>If navigation functions can dynamically add more rows or columns to the DOM, key events that move focus to the beginning or end of the grid, such as <kbd>control + End</kbd>, may move focus to the last row in the DOM rather than the last available row in the back-end data.</li>
          </ul>
          <p>If a grid supports selection of cells, rows, or columns, the following keys are commonly used for these functions.</p>
          <ul>
            <li><kbd>Control + Space</kbd>: selects the column that contains the focus.</li>
            <li><kbd>Shift + Space</kbd>: Selects the row that contains the focus. If the grid includes a column with checkboxes for selecting rows, this key can serve as a shortcut for checking the box when focus is not on the checkbox.</li>
            <li><kbd>Control + A</kbd>: Selects all cells.</li>
            <li><kbd>Shift + Right Arrow</kbd>: Extends selection one cell to the right.</li>
            <li><kbd>Shift + Left Arrow</kbd>: Extends selection one cell to the left.</li>
            <li><kbd>Shift + Down Arrow</kbd>: Extends selection one cell down.</li>
            <li><kbd>Shift + Up Arrow</kbd>: Extends selection one cell Up.</li>
          </ul>
          <p class="note">See <a href="#kbd_common_conventions"></a> for cut, copy, and paste key assignments.</p>
        </section>
      </section>

      <section id="layoutGrid" class="notoc">
        <h4>Layout Grids for Grouping Widgets</h4>

        <p>
          The <code>grid</code> pattern  can be used to group a set of interactive elements, such as links, buttons,  or checkboxes.
          Since only one element in the entire grid is included in the tab sequence, grouping with a grid can dramatically reduce the number of tab stops on a page.
          This is especially valuable if scrolling through a list of elements dynamically loads more of those elements from a large data set, such as in a continuous list of suggested products on a shopping site.
          If elements in a list like this were in the tab sequence, keyboard users are effectively trapped in the list.
          If any elements in the group also have associated elements that appear on hover, the <code>grid</code> pattern is also useful for providing keyboard access to those contextual elements of the user interface.
        </p>

        <p>
          Unlike grids used to present data, A <code>grid</code> used for layout does not necessarily have header cells for labelling rows or columns and might contain only a single row or a single column.
          Even if it has multiple rows and columns, it may present a single, logically homogenous set of elements.
          For example, a list of recipients for a message may be a grid where each cell contains a link that represents a recipient.
          The grid may initially have a single row but then wrap into multiple rows as recipients are added.
          In such circumstances, grid navigation keys may also wrap so the user can read the list from beginning to end by pressing either <kbd>Right Arrow</kbd> or <kbd>Down Arrow</kbd>.
          While This type of focus movement wrapping can be very helpful in a layout grid, it would be disorienting if used in a data grid, especially for users of assistive technologies.
        </p>

        <p> Because arrow keys are used to move focus inside of a <code>grid</code>, a <code>grid</code> is both easier to build and use if the components it contains do not require the arrow keys to operate. If a cell contains an element like a <a href="#Listbox">listbox</a>, then an extra key command to focus and activate the listbox is needed as well as a command for restoring the grid navigation functionality. Approaches to supporting this need are described in the section on <a href="#gridNav_inside">Editing and Navigating Inside a Cell</a>. </p>

        <section class="notoc">
          <h5>Keyboard Interaction For Layout Grids</h5>
          <p>
            The following keys provide grid navigation by moving focus among cells of the grid.
            Implementations of grid make these key commands available when an element in the grid has received focus, e.g., after a user has moved focus to the grid with <kbd>Tab</kbd>.
          </p>
          <ul>
            <li>
              <kbd>Right Arrow</kbd>: Moves focus one cell to the right.
              Optionally, if focus is on the right-most cell in the row, focus may move to the first cell in the following row.
              If focus is on the last cell in the grid, focus does not move.
            </li>
            <li>
              <kbd>Left Arrow</kbd>: Moves focus one cell to the left.
              Optionally, if focus is on the left-most cell in the row, focus may move to the last cell in the previous row.
              If focus is on the first cell in the grid, focus does not move.
            </li>
            <li>
              <kbd>Down Arrow</kbd>: Moves focus one cell down.
              Optionally, if focus is on the bottom cell in the column, focus may move to the top cell in the following column.
              If focus is on the last cell in the grid, focus does not move.
            </li>
            <li>
              <kbd>Up Arrow</kbd>: Moves focus one cell up.
              Optionally, if focus is on the top cell in the column, focus may move to the bottom cell in the previous column.
              If focus is on the first cell in the grid, focus does not move.
            </li>
            <li>
              <kbd>Page Down</kbd> (Optional): Moves focus down an author-determined number of rows, typically scrolling so the bottom row in the currently visible set of rows becomes one of the first visible rows.
              If focus is in the last row of the grid, focus does not move.
            </li>
            <li>
              <kbd>Page Up</kbd> (Optional): Moves focus up an author-determined number of rows, typically scrolling so the top row in the currently visible set of rows becomes one of the last visible rows.
              If focus is in the first row of the grid, focus does not move.
            </li>
            <li>
              <kbd>Home</kbd>: moves focus to the first cell in the row that contains focus.
              Optionally, if the grid has a single column or fewer than three cells per row, focus may instead move to the first cell in the grid.
            </li>
            <li>
              <kbd>End</kbd>: moves focus to the last cell in the row that contains focus.
              Optionally, if the grid has a single column or fewer than three cells per row, focus may instead move to the last cell in the grid.
            </li>
            <li><kbd>Control + Home</kbd> (optional): moves focus to the first cell in the first row.</li>
            <li><kbd>Control + End</kbd> (Optional): moves focus to the last cell in the last row.</li>
          </ul>
          <ul class="note">
            <li>
              When the above grid navigation keys move focus, whether the focus is set on an element inside the cell or the grid cell depends on cell content.
              See <a href="#gridNav_focus">Whether to Focus on a Cell or an Element Inside It</a>.
            </li>
            <li>
              While navigation keys, such as arrow keys, are moving focus from cell to cell, they are not available to do something like operate a combobox or move an editing caret inside of a cell.
              If this functionality is needed, see <a href="#gridNav_inside">Editing and Navigating Inside a Cell</a>.
            </li>
            <li>If navigation functions can dynamically add more rows or columns to the DOM, key events that move focus to the beginning or end of the grid, such as <kbd>control + End</kbd>, may move focus to the last row in the DOM rather than the last available row in the back-end data.</li>
          </ul>

          <p>It would be unusual for a layout grid to provide functions that require cell selection. If it did, though, the following keys are commonly used for these functions.</p>

          <ul>
            <li><kbd>Control + Space</kbd>: selects the column that contains the focus.</li>
            <li>
              <kbd>Shift + Space</kbd>: Selects the row that contains the focus.
              If the grid includes a column with checkboxes for selecting rows, this key can serve as a shortcut for checking the box when focus is not on the checkbox.
            </li>
            <li><kbd>Control + A</kbd>: Selects all cells.</li>
            <li><kbd>Shift + Right Arrow</kbd>: Extends selection one cell to the right.</li>
            <li><kbd>Shift + Left Arrow</kbd>: Extends selection one cell to the left.</li>
            <li><kbd>Shift + Down Arrow</kbd>: Extends selection one cell down.</li>
            <li><kbd>Shift + Up Arrow</kbd>: Extends selection one cell Up.</li>
          </ul>
          <p class="note">See <a href="#kbd_common_conventions"></a> for cut, copy, and paste key assignments.</p>
        </section>
      </section>

      <section id="gridNav" class="notoc">
        <h4>Keyboard Interaction - Setting Focus and Navigating Inside Cells</h4>
        <p>This section describes two important aspects of keyboard interaction design shared by both data and layout grid patterns:</p>

        <ol>
          <li>Choosing whether a cell or an element inside a cell receives focus in response to grid navigation key events.</li>
          <li>Enabling grid navigation keys to be used to interact with elements inside of a cell.</li>
        </ol>

        <section id="gridNav_focus" class="notoc">
          <h5>Whether to Focus on a Cell Or an Element Inside It</h5>

          <p>
            For assistive technology users, the quality of experience when navigating a grid heavily depends on both what a cell contains and on where keyboard focus is set.
            For example, if a cell contains a button and a grid navigation key places focus on the cell instead of the button, screen readers announce the button label but do not tell users a button is present.
          </p>

          <p>There are two optimal cell design and focus behavior combinations: </p>

          <ol>
            <li>
              A cell contains one widget whose operation does not require arrow keys and grid navigation keys set focus on that widget.
              Examples of such widgets include link, button, menubutton, toggle button, radio button (not radio group), switch, and checkbox.
            </li>
            <li>A cell contains text or a single graphic and grid navigation keys set focus on the cell.</li>
          </ol>

          <p>
            While any combination of widgets, text, and graphics may be included in a single cell, grids that do not follow one of these two cell design and focus movement patterns add complexity for authors or users or both.
            The reference implementations included in the example section below demonstrate some strategies for making other cell designs as accessible as possible, but the most widely accessible experiences are likely to come by applying the above two patterns.
          </p>
        </section>

        <section id="gridNav_inside" class="notoc">
          <h5>Editing and Navigating Inside a Cell</h5>

          <p>
            While navigation keys, such as arrow keys, are moving focus from cell to cell, they are not available to perform actions like operate a combobox or move an editing caret inside of a cell. The user may need keys that are used for grid navigation to operate
            elements inside a cell if a cell contains:
          </p>

          <ol>
            <li>Editable content.</li>
            <li>Multiple widgets.</li>
            <li>A widget that utilizes arrow keys in its interaction model, such as a radio group or slider.</li>
          </ol>

          <p>Following are common keyboard conventions for disabling and restoring grid navigation functions. </p>

          <ul>
            <li>
              <kbd>Enter</kbd>: Disables grid navigation and:
              <ul>
                <li>If the cell contains editable content, places focus in an input field, such as a <a href="#textbox" class="role-reference">textbox</a>. If the input is a single-line text field, a subsequent press of <kbd>Enter</kbd> may either restore grid navigation
                  functions or move focus to an input field in a neighboring cell.</li>
                <li>If the cell contains one or more widgets, places focus on the first widget. </li>
              </ul>
            </li>

            <li>
              <kbd>F2</kbd>:
              <ul>
                <li>If the cell contains editable content, places focus in an input field, such as a <a href="#textbox" class="role-reference">textbox</a>. A subsequent press of <kbd>F2</kbd> restores grid navigation functions. </li>
                <li>If the cell contains one or more widgets, places focus on the first widget. A subsequent press of <kbd>F2</kbd> restores grid navigation functions. </li>
              </ul>
            </li>

            <li>Alphanumeric keys: If the cell contains editable content, places focus in an input field, such as a <a href="#textbox" class="role-reference">textbox</a>. </li>
          </ul>

          <p>When grid navigation is disabled, conventional changes to navigation behaviors include: </p>

          <ul>
            <li><kbd>Escape</kbd>: restores grid navigation. If content was being edited, it may also undo edits.</li>
            <li>
              <kbd>Right Arrow</kbd> or <kbd>Down Arrow</kbd>: If the cell contains multiple widgets, moves focus to the next widget inside the cell, optionally wrapping to the first widget if focus is on the last widget.
              Otherwise, passes the key event to the focused widget.
            </li>
            <li>
              <kbd>Left Arrow</kbd> or <kbd>Up Arrow</kbd>: If the cell contains multiple widgets, moves focus to the previous widget inside the cell, optionally wrapping to the first widget if focus is on the last widget.
              Otherwise, passes the key event to the focused widget.
            </li>
            <li>
              <kbd>Tab</kbd>: moves focus to the next widget in the grid.
              Optionally, the focus movement may wrap inside a single cell or within the grid itself.
            </li>
            <li>
              <kbd>Shift + Tab</kbd>: moves focus to the previous widget in the grid.
              Optionally, the focus movement may wrap inside a single cell or within the grid itself.
            </li>
          </ul>
        </section>
      </section>

      <section id="grid_roles_states_props" class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <ul>
          <li>The grid container has role <a href="#grid" class="role-reference">grid</a>. </li>
          <li>Each row container has role <a href="#row" class="role-reference">row</a> and is either a DOM descendant of or owned by the <code>grid</code> element or an element with role <a href="#rowgroup" class="role-reference">rowgroup</a>. </li>
          <li>Each cell is either a DOM descendant of or owned by a <code>row</code> element and has one of the following roles:
            <ul>
              <li><a href="#columnheader"  class="role-reference">columnheader</a> if the cell contains a title or header information for the column.</li>
              <li><a href="#rowheader"  class="role-reference">rowheader</a> if the cell contains title or header information for the row.</li>
              <li><a href="#gridcell" class="role-reference">gridcell</a> if the cell does not contain column or row header information.</li>
            </ul>
          </li>
          <li>
            If there is an element in the user interface that serves as a label for the grid, <a href="#aria-labelledby" class="property-reference">aria-labelledby</a> is set on the grid element with a value that refers to the labelling element.
            Otherwise, a label is specified for the grid element using <a href="#aria-label" class="property-reference">aria-label</a>.
          </li>
          <li>If the grid has a caption or description, <a href="#aria-describedby" class="property-reference">aria-describedby</a> is set on the grid element with a value referring to the element containing the description.</li>
          <li>If the grid provides sort functions, <a href="#aria-sort" class="property-reference">aria-sort</a> is set to an appropriate value on the header cell element for the sorted column or row as described in the section on <a href="#gridAndTableProperties">grid and table properties</a>. </li>
          <li>
            If the grid supports selection, when a cell or row is selected, the selected element has <a href="#aria-selected" class="state-reference">aria-selected</a> set <code>true</code>.
            If the grid supports column selection and a column is selected, all cells in the column have <code>aria-selected</code> set to <code>true</code>.
          </li>
          <li>
            If the grid provides content editing functionality and contains cells that may have edit capabilities disabled in certain conditions, <a href="#aria-readonly" class="state-reference">aria-readonly</a> may be set <code>true</code> on cells where editing is disabled.
            If edit functions are disabled for all cells, <code>aria-readonly</code> may be set <code>true</code> on the grid element.
            Grids that do not provide editing functions do not include the <code>aria-readonly</code> attribute on any of their elements.
          </li>
          <li>
            If there are conditions where some rows or columns are hidden or not present in the DOM, e.g., data is dynamically loaded when scrolling or the grid provides functions for hiding rows or columns, the following properties are applied as described in the section on <a href="#gridAndTableProperties">grid and table properties</a>.
            <ul>
              <li><a href="#aria-colcount" class="property-reference">aria-colcount</a> or <a href="#aria-rowcount" class="property-reference">aria-rowcount</a> is set to the total number of columns or rows, respectively. </li>
              <li><a href="#aria-colindex" class="property-reference">aria-colindex</a> or <a href="#aria-rowindex" class="property-reference">aria-rowindex</a> is set to the position of a cell within a row or column, respectively. </li>
            </ul>
          </li>
          <li>If the grid includes cells that span multiple rows or multiple columns, and if the <code>grid</code> role is NOT applied to an HTML <code>table</code> element, then <a href="#aria-rowspan" class="property-reference">aria-rowspan</a> or <a href="#aria-colspan" class="property-reference">aria-colspan</a> is applied as described in <a href="#gridAndTableProperties">grid and table properties</a>.</li>
        </ul>

        <ul class="note">
          <li>
            If the element with the <code>grid</code> role is an HTML <code>table</code> element, then it is not necessary to use ARIA roles for rows and cells because the HTML elements have implied ARIA semantics.
            For example, an HTML <code>&lt;TR&gt;</code> has an implied ARIA role of <code>row</code>.
            A <code>grid</code> built from an HTML <code>table</code> that includes cells that span multiple rows or columns must use HTML <code>rowspan</code> and <code>colspan</code> and must not use <code>aria-rowspan</code> or <code>aria-colspan</code>.
          </li>
          <li>
            If rows or cells are included in a grid via <a href="#aria-owns" class="property-reference">aria-owns</a>,
            they will be presented to assistive technologies after the DOM descendants of the <code>grid</code> element unless the DOM descendants are also included in the <code>aria-owns</code> attribute.
          </li>
        </ul>
      </section>
    </section>

    <section class="widget" id="link">
      <h3>Link</h3>
      <p>
        A <a href="#link" class="role-reference">link</a> widget provides an interactive reference to a resource.
        The target resource can be either external or local, i.e., either outside or within the current page or application.
       </p>
      <p class="note">
        Authors are strongly encouraged to use a native host language link element, such as an HTML
        <code>&lt;A&gt;</code> element with an <code>href</code> attribute. As with other WAI-ARIA
        widget roles, applying the link role to an element will not cause browsers to enhance the
        element with standard link behaviors, such as navigation to the link target or context menu
        actions.
        When using the <code>link</code> role, providing these features of the element is the author's responsibility.
      </p>

      <section class="notoc">
        <h4>Examples</h4>
        <p><a href="examples/link/link.html">Link Examples</a>: Link widgets constructed from HTML <code>span</code> and <code>img</code> elements.</p>
      </section>

      <section class="notoc">
        <h4>Keyboard Interaction</h4>
        <ul>
          <li><kbd>Enter</kbd>: Executes the link and moves focus to the link target.</li>
          <li><kbd>Shift + F10</kbd> (Optional): Opens a context menu for the link.</li>
        </ul>
      </section>

      <section class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <p>
            The element containing the link text or graphic has role of <a href="#link" class="role-reference">link</a>.
        </p>
      </section>
    </section>

    <section class="widget" id="Listbox">
      <h3>Listbox</h3>
      <p>
        A <a href="#listbox" class="role-reference">listbox</a> widget presents a list of options and allows a user to select one or more of them.
        A listbox that allows a single option to be chosen is a single-select listbox; one that allows multiple options to be selected is a multi-select listbox.
      </p>
      <p>
        When screen readers present a listbox, they may render the name, state, and position of each option in the list.
        The name of an option is a string calculated by the browser, typically from the content of the option element.
        As a flat string, the name does not contain any semantic information.
        Thus, if an option contains a semantic element, such as a heading, screen reader users will not have access to the semantics.
        In addition, the interaction model conveyed by the listbox role to assistive technologies does not support interacting with elements inside of an option.
        Because of these traits of the listbox widget, it does not provide an accessible way to present a list of interactive elements, such as links, buttons, or checkboxes.
        To present a list of interactive elements, see the <a href="#grid">grid</a> pattern.
      </p>
      <p>
        Avoiding very long option names facilitates understandability and perceivability for screen reader users.
        The entire name of an option is spoken as a single unit of speech when the option is read.
        When too much information is spoken as the result of a single key press, it is difficult to understand.
        Long names inhibit perception by increasing the impact of interrupted speech because users typically have to re-read the entire option.
      And, if the user does not understand what is spoken, reading the name by character, word, or phrase may be a difficult operation for many screen reader users in the context of a listbox widget.
      </p>
      <p>
        Sets of options where each option name starts with the same word or phrase can also significantly degrade usability for keyboard and screen reader users.
        Scrolling through the list to find a specific option becomes inordinately time consuming for a screen reader user who must listen to that word or phrase repeated before hearing what is unique about each option.
        For example, if a listbox for choosing a city were to contain options where each city name were preceded by a country name, and if many cities were listed for each country, a screen reader user would have to listen to the country name before hearing each city name.
        In such a scenario, it would be better to have 2 list boxes, one for country and one for city.
      </p>

      <section class="notoc">
        <h4>Examples</h4>
        <ul>
          <li><a href="examples/listbox/listbox-scrollable.html">Scrollable Listbox Example</a>: Single-select listbox that scrolls to reveal more options, similar to HTML <code>select</code> with <code>size</code> attribute greater than one.</li>
          <li><a href="examples/listbox/listbox-collapsible.html">Collapsible Dropdown Listbox Example</a>: Single-select collapsible listbox that expands when activated, similar to HTML <code>select</code> with the attribute <code>size=&quot;1&quot;</code>.</li>
          <li><a href="examples/listbox/listbox-rearrangeable.html">Example Listboxes with Rearrangeable Options</a>: Examples of both single-select and multi-select listboxes with accompanying toolbars where options can be added, moved, and removed.</li>
          <li><a href="examples/listbox/listbox-grouped.html">Listbox Example with Grouped Options</a>: Single-select listbox with grouped options, similar to an HTML <code>select</code> with <code>optgroup</code> children.</li>
        </ul>
      </section>

      <section id="listbox_kbd_interaction" class="notoc">
        <h4>Keyboard Interaction</h4>
        <p>For a vertically oriented listbox:</p>
        <ul>
          <li> When a single-select listbox receives focus:
            <ul>
              <li>If none of the options are selected before the listbox receives focus, the first option receives focus. Optionally, the first option may be automatically selected.</li>
              <li>If an option is selected before the listbox receives focus, focus is set on the selected option. </li>
            </ul>
          </li>
          <li>When a multi-select listbox receives focus:
            <ul>
              <li>If none of the options are selected before the listbox receives focus, focus is set on the first option and there is no automatic change in the selection state.</li>
              <li>If one or more options are selected before the listbox receives focus, focus is set on the first option in the list that is selected.</li>
            </ul>
          </li>
          <li><kbd>Down Arrow</kbd>: Moves focus to the next option. Optionally, in a single-select listbox, selection may also move with focus.</li>
          <li><kbd>Up Arrow</kbd>: Moves focus to the previous option. Optionally, in a single-select listbox, selection may also move with focus.</li>
           <li><kbd>Home</kbd> (Optional): Moves focus to first option. Optionally, in a single-select listbox, selection may also move with focus. Supporting this key is strongly recommended for lists with more than five options.</li>
           <li><kbd>End</kbd> (Optional): Moves focus to last option. Optionally, in a single-select listbox, selection may also move with focus. Supporting this key is strongly recommended for lists with more than five options.</li>
          <li>Type-ahead is recommended for all listboxes, especially those with more than seven options:
            <ul>
              <li>Type a character: focus moves to the next item with a name that starts with the typed character.</li>
              <li>Type multiple characters in rapid succession: focus moves to the next item with a name that starts with the string of characters typed.</li>
            </ul>
          </li>
          <li><strong>Multiple Selection</strong>:
            Authors may implement either of two interaction models to support multiple selection:
            a recommended model that does not require the user to hold a modifier key, such as <kbd>Shift</kbd> or <kbd>Control</kbd>, while navigating the list
            or an alternative model that does require modifier keys to be held while navigating in order to avoid losing selection states.
            <ul>
              <li>Recommended selection model -- holding modifier keys is not necessary:
                <ul>
                  <li><kbd>Space</kbd>: changes the selection state of the focused option.</li>
                  <li><kbd>Shift + Down Arrow</kbd> (Optional): Moves focus to and toggles the selected state of the next option.</li>
                  <li><kbd>Shift + Up Arrow</kbd> (Optional): Moves focus to and toggles the selected state of the previous option.</li>
                  <li><kbd>Shift + Space</kbd> (Optional): Selects contiguous items from the most recently selected item to the focused item.</li>
                  <li><kbd>Control + Shift + Home</kbd> (Optional): Selects the focused option and all options up to the first option. Optionally, moves focus to the first option.</li>
                  <li><kbd>Control + Shift + End</kbd> (Optional): Selects the focused option and all options down to the last option. Optionally, moves focus to the last option.</li>
                  <li><kbd>Control + A</kbd> (Optional): Selects all options in the list. Optionally, if all options are selected, it may also unselect all options.</li>
                </ul>
              </li>
              <li>Alternative selection model -- moving focus without holding a <kbd>Shift</kbd> or <kbd>Control</kbd> modifier unselects all selected nodes except the focused node:
              <ul>
                  <li><kbd>Shift + Down Arrow</kbd>: Moves focus to and toggles the selection state of the next option.</li>
                  <li><kbd>Shift + Up Arrow</kbd>: Moves focus to and toggles the selection state of the previous option.</li>
                  <li><kbd>Control + Down Arrow</kbd>: Moves focus to the next option without changing its selection state.</li>
                  <li><kbd>Control + Up Arrow</kbd>: Moves focus to the previous option without changing its selection state.</li>
                  <li><kbd>Control + Space</kbd> Changes the selection state of the focused option. </li>
                  <li><kbd>Shift + Space</kbd> (Optional): Selects contiguous items from the most recently selected item to the focused item.</li>
                  <li><kbd>Control + Shift + Home</kbd> (Optional): Selects the focused option and all options up to the first option. Optionally, moves focus to the first option.</li>
                  <li><kbd>Control + Shift + End</kbd> (Optional): Selects the focused option and all options down to the last option. Optionally, moves focus to the last option.</li>
                  <li><kbd>Control + A</kbd> (Optional): Selects all options in the list. Optionally, if all options are selected, it may also unselect all options.</li>
                </ul>
              </li>
            </ul>
          </li>
        </ul>
        <ol class="note">
          <li>DOM focus (the active element) is functionally distinct from the selected state. For more details, see <a href="#kbd_focus_vs_selection">this description of differences between focus and selection.</a></li>
          <li>
            The <code>listbox</code> role supports the <a class="property-reference" href="#aria-activedescendant">aria-activedescendant</a> property,
            which provides an alternative to moving DOM focus among <code>option</code> elements when implementing keyboard navigation.
            For details, see <a href="#kbd_focus_activedescendant">Managing Focus in Composites Using aria-activedescendant</a>.
          </li>
          <li>
            In a single-select listbox, moving focus may optionally unselect the previously selected option and select the newly focused option.
            This model of selection is known as &quot;selection follows focus&quot;.
            Having selection follow focus can be very helpful in some circumstances and can severely degrade accessibility in others.
            For additional guidance, see <a href="#kbd_selection_follows_focus">Deciding When to Make Selection Automatically Follow Focus</a>.
          </li>
          <li>If selecting or unselecting all options is an important function, implementing separate controls for these actions, such as buttons for &quot;Select All&quot; and &quot;Unselect All&quot;, significantly improves accessibility.</li>
          <li>
            If the options in a listbox are arranged horizontally:
            <ol>
              <li><kbd>Down Arrow</kbd> performs as <kbd>Right Arrow</kbd> is described above, and vice versa.</li>
              <li><kbd>Up Arrow</kbd> performs as <kbd>Left Arrow</kbd> is described above, and vice versa.</li>
            </ol>
          </li>
        </ol>
      </section>

      <section id="listbox_roles_states_props" class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <ul>
          <li>An element that contains or owns all the listbox options has role <a href="#listbox" class="role-reference">listbox</a>.</li>
          <li>Each option in the listbox has role <a href="#option" class="role-reference">option</a> and is a DOM  descendant of the element with role <code>listbox</code> or is referenced by an <a href="#aria-owns" class="property-reference">aria-owns</a> property on the listbox element.</li>
          <li>If the listbox is not part of another widget, then it has a visible label referenced by <a href="#aria-labelledby" class="property-reference">aria-labelledby</a> on the element with role <code>listbox</code>.</li>
          <li>In a single-select listbox, the selected option has <a href="#aria-selected" class="property-reference">aria-selected</a> set to <code>true</code>. </li>
          <li>if the listbox supports multiple selection:
            <ul>
              <li> The element with role <code>listbox</code> has <a href="#aria-multiselectable" class="property-reference">aria-multiselectable</a> set to <code>true</code>. </li>
              <li>All selected options have <a href="#aria-selected" class="state-reference">aria-selected</a> set to <code>true</code>. </li>
              <li>All options that are not selected have <a href="#aria-selected" class="state-reference">aria-selected</a> set to <code>false</code>. </li>
            </ul>
          </li>
          <li>If the complete set of available options is not present in the DOM due to dynamic loading as the user scrolls, their <a href="#aria-setsize" class="property-reference">aria-setsize</a> and <a href="#aria-posinset" class="property-reference">aria-posinset</a> attributes are set appropriately. </li>
          <li>
            If options are arranged horizontally, the element with role <code>listbox</code> has <a href="#aria-orientation" class="property-reference">aria-orientation</a> set to <code>horizontal</code>.
            The default value of <code>aria-orientation</code> for <code>listbox</code> is <code>vertical</code>.
          </li>
        </ul>
      </section>
    </section>

    <section class="widget" id="menu">
      <h3>Menu or Menu bar</h3>
      <p>
        A <a href="#menu" class="role-reference">menu</a> is a widget that offers a list of choices to the user, such as a set of actions or functions.
        Menu widgets behave like native operating system menus, such as the menus that pull down from the menubars commonly found at the top of many desktop application windows.
        A menu is usually opened, or made visible, by activating a <a href="#menubutton">menu button</a>, choosing an item in a menu that opens a sub menu, or by invoking a command, such as <kbd>Shift + F10</kbd> in Windows, that opens a context specific menu.
        When a user activates a choice in a menu, the menu usually closes unless the choice opened a submenu.
      </p>

      <p>
        A menu that is visually persistent is a <a href="#menubar" class="role-reference">menubar</a>.
        A menubar is typically horizontal and is often used to create a menu bar similar to those found near the top of the window in many desktop applications, offering the user quick access to a consistent set of commands.
      </p>

      <p>A common convention for indicating that a menu item launches a dialog box is to append &quot;&#8230;&quot; (ellipsis) to the menu item label, e.g., &quot;Save as &#8230;&quot;.</p>

      <section class="notoc">
        <h4>Examples</h4>
        <ul>
          <li><a href="examples/menubar/menubar-navigation.html">Navigation Menubar Example</a>: Demonstrates a menubar that provides site navigation.</li>
          <li><a href="examples/menubar/menubar-editor.html">Editor Menubar Example</a>: Demonstrates menu radios and menu checkboxes in submenus of a menubar that provides text formatting commands for a text field.</li>
        </ul>
      </section>

      <section class="notoc">
        <h4>Keyboard Interaction</h4>
        <p>
          The following description of keyboard behaviors assumes:</p>
          <ol>
            <li>A horizontal <code>menubar</code> containing several <code>menuitem</code> elements.</li>
            <li>All items in the <code>menubar</code> have child submenus that contain multiple vertically arranged items.</li>
            <li>Some of the <code>menuitem</code> elements in the submenus have child submenus with items that are also vertically arranged.</li>
          </ol>
          <p>When reading the following descriptions, also keep in mind that:</p>
          <ol>
            <li>Focusable elements, which may have role <code>menuitem</code>, <code>menuitemradio</code>, or <code>menuitemcheckbox</code>, are referred to as items.</li>
            <li>If a behavior applies to only certain types of items, e.g., <code>menuitem</code> elements, the specific role name is used.</li>
            <li>Submenus, also known as popup menus,  are elements with role <code>menu</code>.</li>
            <li>Except where noted, menus opened from a menubutton behave the same as menus opened from a menubar.</li>
          </ol>
        <ul>
          <li>
            When a <code>menu</code> opens, or when a <code>menubar</code> receives focus,
            keyboard focus is placed on the first item.
            All items are focusable as described in <a href="#kbd_general_within"></a>.
          </li>
          <li><kbd>Enter</kbd>:
            <ul>
              <li>When focus is on a <code>menuitem</code> that has a submenu, opens the submenu and places focus on its first item.</li>
              <li>Otherwise, activates the item and closes the menu.</li>
            </ul>
          </li>
          <li><kbd>Space</kbd>:
            <ul>
              <li>(Optional): When focus is on a <code>menuitemcheckbox</code>, changes the state without closing the menu.</li>
              <li>(Optional): When focus is on a <code>menuitemradio</code> that is not checked, without closing the menu, checks the focused <code>menuitemradio</code> and unchecks any other checked <code>menuitemradio</code> element in the same group.</li>
              <li>(Optional): When focus is on a <code>menuitem</code> that has a submenu, opens the submenu and places focus on its first item.</li>
              <li>(Optional): When focus is on a <code>menuitem</code> that does not have a submenu, activates the <code>menuitem</code> and closes the menu.</li>
            </ul>
          </li>
          <li><kbd>Down Arrow</kbd>:
            <ul>
              <li>When focus is on a <code>menuitem</code> in a <code>menubar</code>, opens its submenu and places focus on the first item in the submenu.</li>
            <li>When focus is in a <code>menu</code>, moves focus to the next item, optionally wrapping from the last to the first.</li>
            </ul>
          </li>
          <li><kbd>Up Arrow</kbd>:
            <ul>
            <li>When focus is in a <code>menu</code>, moves focus to the previous item, optionally wrapping from the first to the last.</li>
            <li>(Optional): When focus is on a <code>menuitem</code> in a <code>menubar</code>, opens its submenu and places focus on the last item in the submenu.</li>
            </ul>
          </li>
          <li><kbd>Right Arrow</kbd>:
            <ul>
            <li>When focus is in a <code>menubar</code>, moves focus to the next item, optionally wrapping from the last to the first.</li>
              <li>When focus is in a <code>menu</code> and on a <code>menuitem</code> that has a submenu, opens the submenu and places focus on its first item.</li>
              <li>When focus is in a <code>menu</code> and on an item that does not have a submenu, performs the following 3 actions:
              <ol>
                  <li>Closes the submenu and any parent menus.</li>
                  <li>Moves focus to the next <code>menuitem</code> in the <code>menubar</code>.</li>
                  <li>
                    Either: (Recommended) opens the submenu of that <code>menuitem</code> without moving focus into the submenu,
                    or opens the submenu of that <code>menuitem</code> and places focus on the first item in the submenu.
                  </li>
                </ol>
                Note that if the <code>menubar</code> were not present, e.g., the menus were opened from a menubutton, <kbd>Right Arrow</kbd> would not do anything when focus is on an item that does not have a submenu.
              </li>
            </ul>
          </li>
          <li><kbd>Left Arrow</kbd>:
            <ul>
              <li>When focus is in a <code>menubar</code>, moves focus to the previous item, optionally wrapping from the first to the last.</li>
              <li>When focus is in a submenu of an item in a <code>menu</code>, closes the submenu and returns focus to the parent <code>menuitem</code>.</li>
              <li>When focus is in a submenu of an item in a <code>menubar</code>, performs the following 3 actions:
                <ol>
                  <li>Closes the submenu.</li>
                  <li>Moves focus to the previous <code>menuitem</code> in the <code>menubar</code>.</li>
                  <li>
                    Either: (Recommended) opens the submenu of that <code>menuitem</code> without moving focus into the submenu,
                    or opens the submenu of that <code>menuitem</code> and places focus on the first item in the submenu.
                  </li>
                </ol>
              </li>
            </ul>
          </li>
          <li><kbd>Home</kbd>: If arrow key wrapping is not supported, moves focus to the first item in the current <code>menu</code> or <code>menubar</code>.</li>
          <li><kbd>End</kbd>: If arrow key wrapping is not supported, moves focus to the last item in the current <code>menu</code> or <code>menubar</code>.</li>
          <li>Any key that corresponds to a printable character (Optional): Move focus to   the next menu item in the current menu whose label begins with that printable character.</li>
          <li><kbd>Escape</kbd>: Close the menu that contains focus and return focus to   the element or context, e.g., menu button or parent <code>menuitem</code>, from which the menu was opened. </li>
          <li><kbd>Tab</kbd>: Moves focus to the next element in the tab sequence, and if the item that had focus is not in a <code>menubar</code>, closes its <code>menu</code> and all open parent <code>menu</code> containers.</li>
          <li><kbd>Shift + Tab</kbd>: Moves focus to the previous element in the tab sequence, and if the item that had focus is not in a <code>menubar</code>, closes its <code>menu</code> and all open parent <code>menu</code> containers.</li>
        </ul>
        <ol class="note">
          <li>Disabled menu items are focusable but cannot be activated. </li>
          <li>A <a href="#separator" class="role-reference">separator</a> in a menu is not focusable or interactive.</li>
          <li>
            If a menu is opened or a menubar receives focus as a result of a context action, <kbd>Escape</kbd> or <kbd>Enter</kbd> may return focus to   the invoking context.
            For example, a rich text editor may have a menubar that receives focus when a shortcut key, e.g., <kbd>alt + F10</kbd>, is pressed while editing.
            In this case, pressing <kbd>Escape</kbd> or activating a command from the menu may return focus to the editor.
          </li>
          <li>
            Although it is recommended that authors avoid doing so, some implementations of navigation menubars may have <code>menuitem</code> elements that both perform a function and open a submenu.
            In such implementations, <kbd>enter</kbd> and <kbd>Space</kbd> perform a navigation function, e.g., load new content,
            while <kbd>Down Arrow</kbd>, in a horizontal menubar, opens the submenu associated with that same <code>menuitem</code>.
          </li>
          <li>
            When items in a <code>menubar</code> are arranged vertically and items in <code>menu</code> containers are arranged horizontally:
            <ol>
              <li><kbd>Down Arrow</kbd> performs as <kbd>Right Arrow</kbd> is described above, and vice versa.</li>
              <li><kbd>Up Arrow</kbd> performs as <kbd>Left Arrow</kbd> is described above, and vice versa.</li>
            </ol>
          </li>
        </ol>
      </section>

      <section class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <ul>
          <li>A menu is a container of items that represent choices. The element serving as the menu has a role of either <a href="#menu" class="role-reference">menu</a> or   <a href="#menubar" class="role-reference">menubar</a>. </li>
          <li>The items contained in a menu are child elements of the containing menu or menubar and have any of the following roles:
            <ul>
              <li><a href="#menuitem" class="role-reference">menuitem</a></li>
              <li><a href="#menuitemcheckbox" class="role-reference">menuitemcheckbox</a></li>
              <li><a href="#menuitemradio" class="role-reference">menuitemradio</a></li>
            </ul>
          </li>
          <li>
            If activating a <a href="#menuitem" class="role-reference">menuitem</a> opens a submenu, the menuitem is known as a parent menuitem.
            A submenu's <code>menu</code> element is:
            <ul>
              <li>Contained inside the same <code>menu</code> element as its parent <code>menuitem</code>.</li>
              <li>Is the sibling element immediately following its parent <code>menuitem</code>.</li>
            </ul>
          </li>
          <li>A parent menuitem has <a href="#aria-haspopup" class="property-reference">aria-haspopup</a> set to either <code>menu</code> or <code>true</code>.</li>
          <li>A parent menuitem has <a href="#aria-expanded" class="property-reference">aria-expanded</a> set to <code>false</code> when its child menu is not visible and set to <code>true</code> when the child menu is visible.</li>
          <li>One of the following approaches is used to enable scripts to move focus among items in a menu as described in <a href="#kbd_general_within"></a>:
            <ul>
              <li>The menu container has <code>tabindex</code> set to <code>-1</code> or <code>0</code> and <a href="#aria-activedescendant" class="property-reference">aria-activedescendant</a> set to the ID of the focused item. </li>
              <li>Each item in the menu has <code>tabindex</code> set to <code>-1</code>, except in a menubar, where the first item has <code>tabindex</code> set to <code>0</code>. </li>
            </ul>
          </li>
          <li>When a <a href="#menuitemcheckbox" class="role-reference">menuitemcheckbox</a> or <a href="#menuitemradio" class="role-reference">menuitemradio</a> is checked, <a href="#aria-checked" class="property-reference">aria-checked</a> is set to <code>true</code>. </li>
          <li>When a menu item is disabled, <a href="#aria-disabled" class="state-reference">aria-disabled</a> is set to <code>true</code>.</li>
          <li>Items in a menu may be divided into groups by placing an element with a role of <a href="#separator" class="role-reference">separator</a> between groups. For example, this technique should be used when a menu contains a set of <a href="#menuitemradio" class="role-reference">menuitemradio</a> items. </li>
          <li>All <a href="#separator" class="role-reference">separators</a> should have <a href="#aria-orientation" class="property-reference">aria-orientation</a> consistent with the separator's orientation. </li>
          <li>
            If a menubar has a visible label, the element with role <code>menubar</code> has <a href="#aria-labelledby" class="property-reference">aria-labelledby</a> set to a value that refers to the labelling element.
            Otherwise, the menubar element has a label provided by <a href="#aria-label" class="property-reference">aria-label</a>.
          </li>
          <li>
            If a menubar is vertically oriented, it has <a class="property-reference" href="#aria-orientation">aria-orientation</a> set to <code>vertical</code>.
            The default value of <code>aria-orientation</code> for a menubar is <code>horizontal</code>.
          </li>
          <li>
            An element with role <code>menu</code> either has:
            <ul>
              <li><a href="#aria-labelledby" class="property-reference">aria-labelledby</a> set to a value that refers to the menuitem or button that controls its display.</li>
              <li>A label provided by <a href="#aria-label" class="property-reference">aria-label</a>.</li>
            </ul>
          </li>
          <li>
            If a menu is horizontally oriented, it has <a class="property-reference" href="#aria-orientation">aria-orientation</a> set to <code>horizontal</code>.
            The default value of <code>aria-orientation</code> for a menu is <code>vertical</code>.
          </li>
        </ul>
        <p class="note">
          If <a href="#aria-owns" class="property-reference">aria-owns</a> is set on the menu container to include elements that are not DOM children of the container, those elements will appear in the reading order in the sequence they are referenced and after any items that are DOM children.
          Scripts that manage focus need to ensure the visual focus order matches this assistive technology reading order.
        </p>
      </section>
    </section>

    <section class="widget" id="menubutton"><h3>Menu Button</h3>
      <p>A menu button is a <a href="#button">button</a> that opens a <a href="#menu">menu</a>. It is often styled as a typical push button with a downward pointing arrow or triangle to hint that activating the button will display a menu.</p>

      <section class="notoc">
        <h4>Examples</h4>
        <ul>
          <li><a href="examples/menu-button/menu-button-links.html">Navigation Menu Button</a>: A menu button made from an HTML <code>a</code> element that opens a menu of items that behave as links.</li>
          <li><a href="examples/menu-button/menu-button-actions.html">Action Menu Button Example Using element.focus()</a>: A menu button made from an HTML <code>button</code> element that opens a menu of actions or commands where focus in the menu is managed using <code>element.focus()</code>.</li>
          <li><a href="examples/menu-button/menu-button-actions-active-descendant.html">Action Menu Button Example Using aria-activedescendant</a>: A button that opens a menu of actions or commands where focus in the menu is managed using aria-activedescendant.</li>
        </ul>
      </section>

      <section class="notoc">
        <h4>Keyboard Interaction</h4>
        <ul>
          <li>With focus on the button:
            <ul>
              <li><kbd>Enter</kbd>: opens the menu and places focus on the first menu item.</li>
              <li><kbd>Space</kbd>: Opens the menu and places focus on the first menu item.</li>
              <li>(Optional) <kbd>Down Arrow</kbd>: opens the menu and moves focus to the first menu item.</li>
              <li>(Optional) <kbd>Up Arrow</kbd>: opens the menu and moves focus to the last menu item.</li>
            </ul>
          </li>
          <li>The keyboard behaviors needed after the menu is open are described in <a href="#menu"></a>.</li>
        </ul>
      </section>

      <section class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <ul>
          <li>The element that opens the menu has role <a href="#button" class="role-reference">button</a>.</li>
          <li>The element with role <code>button</code> has <a href="#aria-haspopup" class="property-reference">aria-haspopup</a> set to either <code>menu</code> or <code>true</code>.</li>
          <li>
            When the menu is displayed, the element with role <code>button</code> has
            <a href="#aria-expanded" class="state-reference">aria-expanded</a>
            set to <code>true</code>.
            When the menu is hidden, it is recommended that <code>aria-expanded</code> is not present.
            If <code>aria-expanded</code> is specified when the menu is hidden, it is set to <code>false</code>.
          </li>
          <li>
            The element that contains the menu items displayed by activating the button has role
            <a href="#menu" class="role-reference">menu</a>.
          </li>
          <li>
            Optionally, the element with role <code>button</code> has a value specified for
            <a href="#aria-controls" class="property-reference">aria-controls</a>
            that refers to the element with role <code>menu</code>.
            </li>
            <li>Additional roles, states, and properties needed for the menu element are described in <a href="#menu"></a>.</li>
        </ul>
      </section>
    </section>

    <section class="widget" id="meter">
      <h3>Meter</h3>
      <p>
        A <a class="role-reference" href="#meter">meter</a> is a graphical display of a numeric value that varies within a defined range.
        For example, a meter could be used to depict a device's current battery percentage or a car's fuel level.
      </p>
      <ul class="note">
        <li>A <code>meter</code> should not be used to represent a value like the current world population since it does not have a meaningful maximum limit.</li>
        <li>
          The <code>meter</code> should not be used to indicate progress, such as loading or percent completion of a task.
          To communicate progress, use the <a href="#progressbar" class="role-reference">progressbar</a> role instead.
        </li>
      </ul>

      <section class="notoc">
        <h4>Example</h4>
        <p><a href="examples/meter/meter.html">Meter Example</a></p>
      </section>

      <section class="notoc">
        <h4>Keyboard Interaction</h4>
        <p>Not applicable.</p>
      </section>

      <section class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <ul>
          <li>The element serving as the meter has a role of <a class="role-reference" href="#meter">meter</a>.</li>
          <li>The meter has <a class="property-reference" href="#aria-valuenow">aria-valuenow</a> set to a decimal value between <code>aria-valuemin</code> and <code>aria-valuemax</code> representing the current value of the meter.</li>
          <li>The meter has <a class="property-reference" href="#aria-valuemin">aria-valuemin</a> set to a decimal value less than <code>aria-valuemax</code>.</li>
          <li>The meter has <a class="property-reference" href="#aria-valuemax">aria-valuemax</a> set to a decimal value greater than <code>aria-valuemin</code>.</li>
          <li>
            Assistive technologies often present <code>aria-valuenow</code> as a percentage.
            If conveying the value of the meter only in terms of a percentage would not be user friendly, the <a class="property-reference" href="#aria-valuetext">aria-valuetext</a> property is set to a string that makes the meter value understandable.
            For example, a battery meter value might be conveyed as <code>aria-valuetext="50% (6 hours) remaining"</code>.
          </li>
          <li>If the meter has a visible label, it is referenced by <a href="#aria-labelledby" class="property-reference">aria-labelledby</a> on the element with role <code>meter</code>. Otherwise, the element with role <code>meter</code> has a label provided by <a href="#aria-label" class="property-reference">aria-label</a>.</li>
        </ul>
      </section>
    </section>

    <section class="widget" id="radiobutton">
      <h3>Radio Group</h3>
      <p>
        A radio group is a set of checkable buttons, known as radio buttons, where no more than one of
        the buttons can be checked at a time.
        Some implementations may initialize the set with all buttons in the unchecked state in order to
        force the user to check one of the buttons before moving past a certain point in the workflow.
      </p>

      <section class="notoc">
        <h4>Examples</h4>
        <ul>
          <li><a href="examples/radio/radio.html">Radio Group Example Using Roving tabindex</a></li>
          <li><a href="examples/radio/radio-activedescendant.html">Radio Group Example Using aria-activedescendant</a></li>
        </ul>
      </section>

      <section class="notoc">
        <h4>Keyboard Interaction</h4>
        <section class="notoc">
          <h5>For Radio Groups Not Contained in a Toolbar</h5>
          <p>
            This section describes the keyboard interaction implemented for most radio groups.
            For the special case of a radio group nested inside a <a href="#toolbar">toolbar</a>, use the keyboard interaction described in the following section.
          </p>
          <ul>
            <li>
              <kbd>Tab</kbd> and <kbd>Shift + Tab</kbd>:
              Move focus into and out of the radio group.
              When focus moves into a radio group :
              <ul>
                <li>If a radio button is checked, focus is set on the checked button.</li>
                <li>If none of the radio buttons are checked, focus is set on the first radio
                  button in the group.</li>
              </ul>
            </li>
            <li><kbd>Space</kbd>: checks the focused radio button if it is not already checked.</li>
            <li>
              <kbd>Right Arrow</kbd> and <kbd>Down Arrow</kbd>: move focus to the next radio button in
              the group, uncheck the previously focused button, and check the newly focused button. If
              focus is on the last button, focus moves to the first button.
            </li>
            <li>
              <kbd>Left Arrow</kbd> and <kbd>Up Arrow</kbd>: move focus to the previous radio button
              in the group, uncheck the previously focused button, and check the newly focused button.
              If focus is on the first button, focus moves to the last button.
            </li>
          </ul>
          <p class="note">
            The initial focus behavior described above differs slightly from the behavior
            provided by some browsers for native HTML radio groups. In some browsers, if none of the
            radio buttons are selected, moving focus into the radio group with <kbd>Shift+Tab</kbd> will place focus on the last radio button
            instead of the first radio button.
          </p>
        </section>
        <section class="notoc">
          <h5>For Radio Group Contained in a Toolbar</h5>
          <p>
            Because arrow keys are used to navigate among elements of a toolbar and the <kbd>Tab</kbd> key moves focus in and out of a toolbar, when a radio group is nested inside a toolbar, the keyboard interaction of the radio group is slightly different from that of a radio group that is not inside of a toolbar.
            For instance, users need to be able to navigate among all toolbar elements, including the radio buttons, without changing which radio button is checked.
            So, when navigating through a radio group in a toolbar with arrow keys, the button that is checked does not change.
            The keyboard interaction of a radio group nested in a toolbar is as follows.
          </p>
          <ul>
            <li><kbd>Space</kbd>: If the focused radio button is not checked, unchecks the currently checked radio button and checks the focused radio button. Otherwise, does nothing.</li>
            <li><kbd>Enter</kbd> (optional): If the focused radio button is not checked, unchecks the currently checked radio button and checks the focused radio button. Otherwise, does nothing.</li>
            <li><kbd>Right Arrow</kbd>:
              <ul>
                <li>When focus is on a radio button and that radio button is <strong>not</strong> the last radio button in the radio group, moves focus to the next radio button.</li>
                <li>When focus is on the last radio button in the radio group and that radio button is <strong>not</strong> the last element in the toolbar, moves focus to the next element in the toolbar.</li>
                <li>When focus is on the last radio button in the radio group and that radio button is also the last element in the toolbar, moves focus to the first element in the toolbar.</li>
              </ul>
            </li>
            <li><kbd>Left Arrow</kbd>:
              <ul>
                <li>When focus is on a radio button and that radio button is <strong>not</strong> the first radio button in the radio group, moves focus to the previous radio button.</li>
                <li>When focus is on the first radio button in the radio group and that radio button is <strong>not</strong> the first element in the toolbar, moves focus to the previous element in the toolbar.</li>
                <li>When focus is on the first radio button in the radio group and that radio button is also the first element in the toolbar, moves focus to the last element in the toolbar.</li>
              </ul>
            </li>
            <li>
              <kbd>Down Arrow</kbd> (optional): Moves focus to the next radio button in the radio group.
              If focus is on the last radio button in the radio group, moves focus to the first radio button in the group.
            </li>
            <li>
              <kbd>Up Arrow</kbd> (optional): Moves focus to the previous radio button in the radio group.
              If focus is on the first radio button in the radio group, moves focus to the last radio button in the group.
            </li>
          </ul>
          <p class="note">
            Radio buttons in a toolbar are frequently styled in a manner that appears more like toggle buttons.
            For an example, See the <a href="examples/toolbar/toolbar.html">Simple Editor Toolbar Example</a>
          </p>
        </section>
      </section>

      <section class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <ul>
          <li>
            The radio buttons are contained in or owned by an element with role
            <a href="#radiogroup" class="role-reference">radiogroup</a>.
          </li>
          <li>
            Each radio button element has role
            <a href="#radio" class="role-reference">radio</a>.
          </li>
          <li>
            If a radio button is checked, the <code>radio</code> element has
            <a href="#aria-checked" class="state-reference">aria-checked</a>
            set to <code>true</code>. If it is not checked, it has
            <a href="#aria-checked" class="state-reference">aria-checked</a>
            set to <code>false</code>.
          </li>
          <li>
            Each <code>radio</code> element is labelled by its content, has a visible label
            referenced by
            <a href="#aria-labelledby" class="property-reference">aria-labelledby</a>,
            or has a label specified with
            <a href="#aria-label" class="property-reference">aria-label</a>.
          </li>
          <li>
            The <code>radiogroup</code> element has a visible label referenced by
            <a href="#aria-labelledby" class="property-reference">aria-labelledby</a>
            or has a label specified with
            <a href="#aria-label" class="property-reference">aria-label</a>.
          </li>
          <li>
            If elements providing additional information about either the radio group or each radio
            button are present, those elements are referenced by the <code>radiogroup</code> element
            or <code>radio</code> elements with the
            <a href="#aria-describedby" class="property-reference">aria-describedby</a>
            property.
          </li>
        </ul>
      </section>
    </section>

    <section class="widget" id="slider">
      <h3>Slider</h3>
      <p>
        A slider is an input where the user selects a value from within a given range.
        Sliders typically have a slider thumb that can be moved along a bar or track to change the value of the slider.
      </p>
      <p class="warning">
        Users of touch-based assistive technologies may not be able to fully operate widgets that implement this pattern because APIs for capturing the necessary gestures and commands from assistive technologies are not yet available.
        Authors should fully test widgets using this pattern with assistive technologies before considering incorporation into production systems.
      </p>
      <section class="notoc">
        <h4>Examples</h4>
        <ul>
          <li><a href="examples/slider/slider-1.html">Horizontal Slider Examples</a>: Demonstrates using three horizontally aligned sliders to make a color picker.</li>
          <li><a href="examples/slider/slider-2.html">Slider Examples with aria-orientation and aria-valuetext</a>: Three thermostat control sliders that demonstrate using aria-orientation and aria-valuetext.</li>
        </ul>
      </section>

      <section id="slider_kbd_interaction" class="notoc">
        <h4>Keyboard Interaction</h4>
        <ul>
          <li><kbd>Right Arrow</kbd>: Increase the value of the slider by one step.</li>
          <li><kbd>Up Arrow</kbd>: Increase the value of the slider by one step.</li>
          <li><kbd>Left Arrow</kbd>: Decrease the value of the slider by one step.</li>
          <li><kbd>Down Arrow</kbd>: Decrease the value of the slider by one step.</li>
          <li><kbd>Home</kbd>: Set the slider to the first allowed value in its range.</li>
          <li><kbd>End</kbd>: Set the slider to the last allowed value in its range.</li>
          <li><kbd>Page Up</kbd> (Optional): Increment the slider by an amount larger than the step change made by <kbd>Up Arrow</kbd>.</li>
          <li><kbd>Page Down</kbd> (Optional): Decrement the slider by an amount larger than the step change made by <kbd>Down Arrow</kbd>.</li>
        </ul>
        <ol class="note">
          <li>Focus is placed on the slider (the visual object that the mouse user would move, also known as the thumb.</li>
          <li>In some circumstances, reversing the direction of the value change for the keys specified above, e.g., having <kbd>Up Arrow</kbd> decrease the value, could create a more intuitive experience.</li>
        </ol>
      </section>
      <section id="slider_roles_states_props" class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <ul>
          <li>The element serving as the focusable slider control has role <a class="role-reference" href="#slider">slider</a>.</li>
          <li>The slider element has the <a class="property-reference" href="#aria-valuenow">aria-valuenow</a> property set to a decimal value representing the current value of the slider.</li>
          <li>The slider element has the <a class="property-reference" href="#aria-valuemin">aria-valuemin</a> property set to a decimal value representing the minimum allowed value of the slider.</li>
          <li>The slider element has the <a class="property-reference" href="#aria-valuemax">aria-valuemax</a> property set to a decimal value representing the maximum allowed value of the slider.</li>
          <li>
          If the value of <code>aria-valuenow</code> is not user-friendly, e.g., the day of the week is represented by a number, the
          <a class="property-reference" href="#aria-valuetext">aria-valuetext</a>
          property is set to a string that makes the slider value understandable, e.g., &quot;Monday&quot;.
          </li>
          <li>
            If the slider has a visible label, it is referenced by
            <a href="#aria-labelledby" class="property-reference">aria-labelledby</a> on the slider element.
            Otherwise, the slider element has a label provided by
            <a href="#aria-label" class="property-reference">aria-label</a>.
          </li>
          <li>
            If the slider is vertically oriented, it has <a class="property-reference" href="#aria-orientation">aria-orientation</a> set to <code>vertical</code>.
            The default value of <code>aria-orientation</code> for a slider is <code>horizontal</code>.
          </li>
        </ul>
      </section>
    </section>

    <section class="widget" id="slidertwothumb">
      <h3>Slider (Multi-Thumb)</h3>
      <p>
        A multi-thumb slider is a <a href="#slider">slider</a>
        with two or more thumbs that each set a value in a group of related values.
        For example, in a product search, a two-thumb slider could be used to enable users to set the minimum and maximum price limits for the search.
        In many two-thumb sliders, the thumbs are not allowed to pass one another, such as when the slider sets the minimum and maximum values for a range.
        For example, in a price range selector, the maximum value of the thumb that sets the lower end of the range is limited by the current value of the thumb that sets the upper end of the range.
        Conversely, the minimum value of the upper end thumb is limited by the current value of the lower end thumb.
        However, in some multi-thumb sliders, each thumb sets a value that does not depend on the other thumb values.
      </p>
      <p class="warning">
        Users of touch-based assistive technologies may not be able to fully operate widgets that implement this pattern because APIs for capturing the necessary gestures and commands from assistive technologies are not yet available.
        Authors should fully test widgets using this pattern with assistive technologies before considering incorporation into production systems.
      </p>

      <section class="notoc">
        <h4>Example</h4>
        <p><a href="examples/slider/multithumb-slider.html">Multi-Thumb Slider Examples</a>: Demonstrates two-thumb sliders for picking price ranges for an airline flight and hotel reservation.</p>
      </section>

      <section id="slidertwothumb_kbd_interaction" class="notoc">
        <h4>Keyboard Interaction</h4>
        <ul>
          <li>Each thumb is in the page tab sequence and has the same keyboard interaction as a <a href="#slider_kbd_interaction">single-thumb slider</a>.</li>
          <li>
            The tab order remains constant regardless of thumb value and visual position within the slider.
            For example, if the value of a thumb changes such that it moves past one of the other thumbs, the tab order does not change.
          </li>
        </ul>
      </section>

      <section class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <ul>
          <li>Each element serving as a focusable slider thumb has role <a class="role-reference" href="#slider">slider</a>.</li>
          <li>Each slider element has the <a class="property-reference" href="#aria-valuenow">aria-valuenow</a> property set to a decimal value representing the current value of the slider.</li>
          <li>Each slider element has the <a class="property-reference" href="#aria-valuemin">aria-valuemin</a> property set to a decimal value representing the minimum allowed value of the slider.</li>
          <li>Each slider element has the <a class="property-reference" href="#aria-valuemax">aria-valuemax</a> property set to a decimal value representing the maximum allowed value of the slider.</li>
          <li>When the range (e.g. minimum and/or maximum value) of another slider is dependent on the current value of a slider, the values of <a class="property-reference" href="#aria-valuemin">aria-valuemin</a> or <a class="property-reference" href="#aria-valuemax">aria-valuemax</a> of the dependent sliders are updated when the value changes.</li>
          <li>
          If a value of <code>aria-valuenow</code> is not user-friendly, e.g., the day of the week is represented by a number, the
          <a class="property-reference" href="#aria-valuetext">aria-valuetext</a>
          property is set to a string that makes the slider value understandable, e.g., &quot;Monday&quot;.
          </li>
          <li>
            If a slider has a visible label, it is referenced by
            <a href="#aria-labelledby" class="property-reference">aria-labelledby</a> on the slider element.
            Otherwise, the slider element has a label provided by
            <a href="#aria-label" class="property-reference">aria-label</a>.
          </li>
          <li>
            If a slider is vertically oriented, it has <a class="property-reference" href="#aria-orientation">aria-orientation</a> set to <code>vertical</code>.
            The default value of <code>aria-orientation</code> for a slider is <code>horizontal</code>.
          </li>
        </ul>
      </section>
    </section>

    <section class="widget" id="spinbutton">
      <h3>Spinbutton</h3>
      <p>
        A spinbutton is an input widget that restricts its value to a set or range of discrete values.
        For example, in a widget that enables users to set an alarm, a spinbutton could allow users to select a number from 0 to 59 for the minute of an hour.
      </p>
      <p>
        Spinbuttons often have three components, including a text field that displays the current value, an increment button, and a decrement button.
        The text field is usually the only focusable component because the increment and decrement functions are keyboard accessible via arrow keys.
        Typically, the text field also allows users to directly edit the value.
      </p>
      <p>
        If the range is large, a spinbutton may support changing the value in both small and large steps.
        For instance, in the alarm example, the user may be able to move by 1 minute with <kbd>Up Arrow</kbd> and <kbd>Down Arrow</kbd> and by 10 minutes with <kbd>Page Up</kbd> and <kbd>Page Down</kbd>.
      </p>

      <section class="notoc">
        <h4>Example</h4>
        <p><a href="examples/spinbutton/datepicker-spinbuttons.html">Date Picker Spin Button Example:</a> Illustrates a date picker made from three spin buttons for day, month, and year.</p>
      </section>

      <section class="notoc">
        <h4>Keyboard Interaction</h4>
        <ul>
          <li><kbd>Up Arrow</kbd>: Increases the value.</li>
          <li><kbd>Down Arrow</kbd>: Decreases the value.</li>
          <li><kbd>Home</kbd>: If the spinbutton has a minimum value, sets the value to its minimum.</li>
          <li><kbd>End</kbd>: If the spinbutton has a maximum value, sets the value to its maximum.</li>
          <li><kbd>Page Up</kbd> (Optional): Increases the value by a larger step than <kbd>Up Arrow</kbd>.</li>
          <li><kbd>Page Down</kbd> (Optional): Decreases the value by a larger step than <kbd>Down Arrow</kbd>.</li>
          <li>If the spinbutton text field allows directly editing the value, the following keys are supported:
            <ul>
              <li>Standard single line text editing keys appropriate for the device platform (see note below).</li>
              <li>
                Printable Characters: Type characters in the textbox. Note that many implementations allow only certain characters as part of the value and prevent input of any other characters.
                For example, an hour-and-minute spinner would allow only integer values from 0 to 59, the colon ':', and the letters 'AM' and 'PM'.
                Any other character input does not change the contents of the text field nor the value of the spinbutton.
              </li>
            </ul>
          </li>
        </ul>
        <ol class="note">
          <li>Focus remains on the text field during operation.</li>
          <li>Standard single line text editing keys appropriate for the device platform:
            <ol>
              <li>include keys for input, cursor movement, selection, and text manipulation.</li>
              <li>Standard key assignments for editing functions depend on the device operating system.</li>
              <li>The most robust approach for providing text editing functions is to rely on browsers, which  supply them for HTML inputs with type text and for elements with the <code>contenteditable</code> HTML attribute.</li>
              <li><strong>IMPORTANT:</strong> Be sure that JavaScript does not interfere with browser-provided text editing functions by capturing key events for the keys used to perform them.</li>
            </ol>
          </li>
        </ol>
      </section>

      <section class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <ul>
          <li>
            The focusable element serving as the spinbutton has role <a class="role-reference" href="#spinbutton">spinbutton</a>.
            This is typically an element that supports text input.
          </li>
          <li>The spinbutton element has the <a class="property-reference" href="#aria-valuenow">aria-valuenow</a> property set to a decimal value representing the current value of the spinbutton.</li>
          <li>The spinbutton element has the <a class="property-reference" href="#aria-valuemin">aria-valuemin</a> property set to a decimal value representing the minimum allowed value of the spinbutton if it has a known minimum value.</li>
          <li>The spinbutton element has the <a class="property-reference" href="#aria-valuemax">aria-valuemax</a> property set to a decimal value representing the maximum allowed value of the spinbutton if it has a known maximum value.</li>
          <li>
          If the value of <code>aria-valuenow</code> is not user-friendly, e.g., the day of the week is represented by a number, the
          <a class="property-reference" href="#aria-valuetext">aria-valuetext</a>
          property is set on the spinbutton element to a string that makes the spinbutton value understandable, e.g., &quot;Monday&quot;.
          </li>
          <li>
            If the spinbutton has a visible label, it is referenced by
            <a href="#aria-labelledby" class="property-reference">aria-labelledby</a> on the spinbutton element.
            Otherwise, the spinbutton element has a label provided by
            <a href="#aria-label" class="property-reference">aria-label</a>.
          </li>
          <li>
            The spinbutton element has
            <a href="#aria-invalid" class="state-reference">aria-invalid</a> set to <code>true</code>
            if the value is outside the allowed range.
            Note that most implementations prevent input of invalid values, but in some scenarios, blocking all invalid input may not be practical.
          </li>
        </ul>
      </section>
    </section>

    <section class="widget" id="table">
      <h3>Table</h3>
      <p>
        Like an HTML <code>table</code> element, a WAI-ARIA <a href="#table" class="role-reference">table</a> is a static tabular structure containing one or more rows that each contain one or more cells; it is not an interactive widget.
        Thus, its cells are not focusable or selectable.
        The <a href="#grid">grid pattern</a> is used to make an interactive widget that has a tabular structure.
      </p>
      <p>
        However, tables are often used to present a combination of information and interactive widgets.
        Since a table is not a widget, each widget contained in a table is a separate stop in the page tab sequence.
        If the number of widgets is large, replacing the table with a grid can dramatically reduce the length of the page tab sequence because a grid is a composite widget that can contain other widgets.
      </p>
      <p class="note">
        As with other WAI-ARIA roles that have a native host language equivalent,
        authors are strongly encouraged to use a native HTML <code>table</code> element whenever possible.
        This is especially important with role <code>table</code> because it is a new feature of WAI-ARIA 1.1.
        It is thus advisable to test implementations thoroughly with each browser and assistive technology combination that could be used by the target audience.
      </p>
      <section class="notoc">
        <h4>Examples</h4>
        <p><a href="examples/table/table.html">Table Example</a>: ARIA table made using HTML <code>div</code> and <code>span</code> elements.</p>
      </section>
      <section class="notoc">
        <h4>Keyboard Interaction</h4>
        <p>Not applicable.</p>
      </section>
      <section id="table_roles_states_props" class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <ul>
          <li>The table container has role <a href="#table" class="role-reference">table</a>. </li>
          <li>Each row container has role <a href="#row" class="role-reference">row</a> and is either a DOM descendant of or owned by the <code>table</code> element or an element with role <a href="#rowgroup" class="role-reference">rowgroup</a>. </li>
          <li>Each cell is either a DOM descendant of or owned by a <code>row</code> element and has one of the following roles:
            <ul>
              <li><a href="#columnheader"  class="role-reference">columnheader</a> if the cell contains a title or header information for the column.</li>
              <li><a href="#rowheader"  class="role-reference">rowheader</a> if the cell contains title or header information for the row.</li>
              <li><a href="#cell" class="role-reference">cell</a> if the cell does not contain column or row header information.</li>
            </ul>
          </li>
          <li>
            If there is an element in the user interface that serves as a label for the table, <a href="#aria-labelledby" class="property-reference">aria-labelledby</a> is set on the table element with a value that refers to the labelling element.
            Otherwise, a label is specified for the table element using <a href="#aria-label" class="property-reference">aria-label</a>.
          </li>
          <li>If the table has a caption or description, <a href="#aria-describedby" class="property-reference">aria-describedby</a> is set on the table element with a value referring to the element containing the description.</li>
          <li>If the table contains sortable columns or rows, <a href="#aria-sort" class="property-reference">aria-sort</a> is set to an appropriate value on the header cell element for the sorted column or row as described in the section on <a href="#gridAndTableProperties">grid and table properties</a>. </li>
          <li>
            If there are conditions where some rows or columns are hidden or not present in the DOM, e.g., there are widgets on the page for hiding rows or columns, the following properties are applied as described in the section on <a href="#gridAndTableProperties">grid and table properties</a>.
            <ul>
              <li><a href="#aria-colcount" class="property-reference">aria-colcount</a> or <a href="#aria-rowcount" class="property-reference">aria-rowcount</a> is set to the total number of columns or rows, respectively. </li>
              <li><a href="#aria-colindex" class="property-reference">aria-colindex</a> or <a href="#aria-rowindex" class="property-reference">aria-rowindex</a> is set to the position of a cell within a row or column, respectively. </li>
            </ul>
          </li>
          <li>If the table includes cells that span multiple rows or multiple columns, then <a href="#aria-rowspan" class="property-reference">aria-rowspan</a> or <a href="#aria-colspan" class="property-reference">aria-colspan</a> is applied as described in <a href="#gridAndTableProperties">grid and table properties</a>.</li>
        </ul>
        <p class="note">
          If rows or cells are included in a table via <a href="#aria-owns" class="property-reference">aria-owns</a>,
          they will be presented to assistive technologies after the DOM descendants of the <code>table</code> element unless the DOM descendants are also included in the <code>aria-owns</code> attribute.
        </p>
      </section>
    </section>

    <section class="widget" id="tabpanel">
      <h3>Tabs</h3>
      <p>
        Tabs are a set of layered sections of content, known as tab panels, that display one panel of content at a time.
        Each tab panel has an associated tab element, that when activated, displays the panel.
        The list of tab elements is arranged along one edge of the currently displayed panel, most commonly the top edge.
      </p>
      <p>Terms used to describe this design pattern include:</p>
      <dl>
        <dt>Tabs or Tabbed Interface</dt>
        <dd>A set of tab elements and their associated tab panels.</dd>
        <dt>Tab List</dt>
        <dd>A set of tab elements contained in a <a href="#tablist" class="role-reference">tablist</a> element.</dd>
        <dt><a href="#tab" class="role-reference">tab</a></dt>
        <dd>An element in the tab list that serves as a label for one of the tab panels and can be activated to display that panel. </dd>
        <dt><a href="#tabpanel" class="role-reference">tabpanel</a></dt>
        <dd>The element that contains the content associated with a tab.</dd>
      </dl>
      <p>
        When a tabbed interface is initialized, one tab panel is displayed and its associated tab is styled to indicate that it is active.
        When the user activates one of the other tab elements, the previously displayed tab panel is hidden, the tab panel associated with the activated tab becomes visible, and the tab is considered "active".
      </p>

      <section class="notoc">
        <h4>Examples</h4>
        <ul>
          <li><a href="examples/tabs/tabs-1/tabs.html">Tabs With Automatic Activation</a>: A tabs widget where tabs are automatically activated and their panel is displayed when they receive focus.</li>
          <li><a href="examples/tabs/tabs-2/tabs.html">Tabs With Manual Activation</a>: A tabs widget where users activate a tab and display its panel by pressing <kbd>Space</kbd> or <kbd>Enter</kbd>.</li>
        </ul>
      </section>

      <section class="notoc">
        <h4>Keyboard Interaction</h4>
        <p>For the tab list:</p>
        <ul>
          <li>
            <kbd>Tab</kbd>:
            <ul>
              <li>When focus moves into the tab list, places focus on the active <code>tab</code> element.</li>
              <li>When the tab list contains the focus, moves focus to the next element in the page tab sequence outside the tablist, which is the tabpanel unless the first element containing meaningful content inside the tabpanel is focusable.</li>
            </ul>
          </li>
          <li>When focus is on a tab element in a horizontal tab list:
            <ul>
              <li>
                <kbd>Left Arrow</kbd>: moves focus to the previous tab.
                If focus is on the first tab, moves focus to the last tab.
                Optionally, activates the newly focused tab (See note below).
              </li>
              <li>
                <kbd>Right Arrow</kbd>: Moves focus to the next tab.
                If focus is on the last tab element, moves focus to the first tab.
                Optionally, activates the newly focused tab (See note below).
              </li>
            </ul>
          </li>
          <li>When focus is on a tab in a tablist with either horizontal or vertical orientation:
            <ul>
              <li><kbd>Space or Enter</kbd>: Activates the tab if it was not activated automatically on focus.</li>
              <li><kbd>Home</kbd> (Optional): Moves focus to the first tab. Optionally, activates the newly focused tab (See note below).</li>
              <li><kbd>End</kbd> (Optional): Moves focus to the last tab. Optionally, activates the newly focused tab (See note below).</li>
              <li><kbd>Shift + F10</kbd>: If the tab has an associated popup menu, opens the menu. </li>
              <li>
                <kbd>Delete</kbd> (Optional): If deletion is allowed, deletes (closes) the current tab element and its associated tab panel,
                sets focus on the tab following the tab that was closed, and optionally activates the newly focused tab. If there is not a tab that followed the tab that was deleted,
                e.g., the deleted tab was the right-most tab in a left-to-right horizontal tab list,
                sets focus on and optionally activates the tab that preceded the deleted tab.
                 If the application allows all tabs to be deleted, and the user deletes the last remaining tab in the tab list,
                the application moves focus to another element that provides a logical work flow.
                As an alternative to <kbd>Delete</kbd>, or in addition to supporting <kbd>Delete</kbd>, the delete function is available in a context menu.
              </li>
            </ul>
          </li>
        </ul>
        <ol class="note">
          <li>
            It is recommended that tabs activate automatically when they receive focus as long as their associated tab panels are displayed without noticeable latency.
            This typically requires tab panel content to be preloaded.
            Otherwise, automatic activation slows focus movement, which significantly hampers users' ability to navigate efficiently across the tab list.
            For additional guidance, see <a href="#kbd_selection_follows_focus"></a>.
          </li>
          <li>
            When a tab list has its <a href="#aria-orientation" class="property-reference">aria-orientation</a> set to <code>vertical</code>:
            <ol>
              <li><kbd>Down Arrow</kbd> performs as <kbd>Right Arrow</kbd> is described above.</li>
              <li><kbd>Up Arrow</kbd> performs as <kbd>Left Arrow</kbd> is described above.</li>
            </ol>
          </li>
          <li>If the tab list is horizontal, it does not listen for <kbd>Down Arrow</kbd> or <kbd>Up Arrow</kbd> so those keys can provide their normal browser scrolling functions even when focus is inside the tab list.</li>
        </ol>
      </section>
      <section class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <ul>
        <li>The element that serves as the container for the set of tabs has role  <a class="role-reference" href="#tablist">tablist</a>. </li>
        <li>Each element that serves as a tab has role <a class="role-reference" href="#tab">tab</a> and is contained within the element with role <code>tablist</code>.</li>
          <li>Each element that contains the content panel for a <code>tab</code> has role <a class="role-reference" href="#tabpanel">tabpanel</a>.</li>
          <li>
            If the tab list has a visible label, the element with role <code>tablist</code> has <a href="#aria-labelledby" class="property-reference">aria-labelledby</a> set to a value that refers to the labelling element.
            Otherwise, the <code>tablist</code> element has a label provided by <a href="#aria-label" class="property-reference">aria-label</a>.
          </li>
          <li>Each element with role <code>tab</code> has the property <a href="#aria-controls" class="property-reference">aria-controls</a> referring to its associated <code>tabpanel</code> element.</li>
          <li>The active <code>tab</code> element has the state <a href="#aria-selected" class="state-reference">aria-selected</a> set to <code>true</code> and all other <code>tab</code> elements have it set to <code>false</code>.</li>
          <li>Each element with role <code>tabpanel</code> has the property <a href="#aria-labelledby" class="property-reference">aria-labelledby</a> referring to its associated <code>tab</code> element. </li>
          <li>If a <code>tab</code> element has a popup menu, it has the property <a href="#aria-haspopup" class="property-reference">aria-haspopup</a> set to either <code>menu</code> or <code>true</code>. </li>
          <li>
            If the <code>tablist</code> element is vertically oriented, it has the property <a href="#aria-orientation" class="property-reference">aria-orientation</a> set to <code>vertical</code>.
            The default value of <code>aria-orientation</code> for a <code>tablist</code> element is <code>horizontal</code>.
        </li>
        </ul>
      </section>
    </section>

    <section class="widget" id="toolbar">
      <h3>Toolbar</h3>
      <p>A <a class="role-reference" href="#toolbar">toolbar</a> is a container for grouping a set of controls, such as buttons, menubuttons, or checkboxes.</p>
      <p>
        When a set of controls is visually presented as a group, the <code>toolbar</code> role can be used to communicate the presence and purpose of the grouping to screen reader users.
        Grouping controls into toolbars can also be an effective way of reducing the number of tab stops in the keyboard interface.
      </p>
      <p>To optimize the benefit of toolbar widgets:</p>
      <ul>
        <li>
          Implement focus management so the keyboard tab sequence includes one stop for the toolbar and arrow keys move focus among the controls in the toolbar.
          <ul>
            <li>In horizontal toolbars, <kbd>Left Arrow</kbd> and <kbd>Right Arrow</kbd> navigate among controls. <kbd>Up Arrow</kbd> and <kbd>Down Arrow</kbd> can duplicate <kbd>Left Arrow</kbd> and <kbd>Right Arrow</kbd>, respectively, or can be reserved for operating controls, such as spin buttons that require vertical arrow keys to operate.</li>
            <li>In vertical toolbars, <kbd>Up Arrow</kbd> and <kbd>Down Arrow</kbd> navigate among controls. <kbd>Left Arrow</kbd> and <kbd>Right Arrow</kbd> can duplicate <kbd>Up Arrow</kbd> and <kbd>Down Arrow</kbd>, respectively, or can be reserved for operating controls, such as horizontal sliders that require horizontal arrow keys to operate.</li>
            <li>In toolbars with multiple rows of controls, <kbd>Left Arrow</kbd> and <kbd>Right Arrow</kbd> can provide navigation that wraps from row to row, leaving the option of reserving vertical arrow keys for operating controls.</li>
          </ul>
        </li>
        <li>Avoid including controls whose operation requires the pair of arrow keys used for toolbar navigation. If unavoidable, include only one such control and make it the last element in the toolbar. For example, in a horizontal toolbar, a textbox could be included as the last element.</li>
        <li>Use toolbar as a grouping element only if the group contains 3 or more controls.</li>
      </ul>
      <section class="notoc">
        <h4>Example</h4>
        <p>
          <a href="examples/toolbar/toolbar.html">Toolbar Example</a>:
          A toolbar that uses roving tabindex to manage focus and contains several types of controls, including toggle buttons, radio buttons, a menu button, a spin button, a checkbox, and a link.
        </p>
      </section>
      <section class="notoc">
        <h4>Keyboard Interaction</h4>
        <ul>
          <li><kbd>Tab</kbd> and <kbd>Shift + Tab</kbd>: Move focus into and out of the toolbar. When focus moves into a toolbar:
            <ul>
              <li>If focus is moving into the toolbar for the first time, focus is set on the first control that is not disabled.</li>
              <li>If the toolbar has previously contained focus, focus is optionally set on the control that last had focus. Otherwise, it is set on the first control that is not disabled.</li>
            </ul>
          </li>
          <li>For a horizontal toolbar (the default):
            <ul>
              <li><kbd>Left Arrow</kbd>: Moves focus to the previous control.  Optionally, focus movement may wrap from the first element to the last element. </li>
              <li><kbd>Right Arrow</kbd>: Moves focus to the next control.  Optionally, focus movement may wrap from the last element to the first element. </li>
            </ul>
          </li>
          <li><kbd>Home</kbd> (Optional): Moves focus to first element.</li>
          <li><kbd>End</kbd> (Optional): Moves focus to last element.</li>
        </ul>
        <ol class="note">
          <li>If the items in a toolbar are arranged vertically:
            <ol>
              <li><kbd>Down Arrow</kbd> performs as <kbd>Right Arrow</kbd> is described above. </li>
              <li><kbd>Up Arrow</kbd> performs as <kbd>Left Arrow</kbd> is described above. </li>
            </ol>
          </li>
          <li>
            Typically, disabled elements are not focusable when navigating with a keyboard.
            However, in circumstances where discoverability of a function is crucial, it may be helpful if disabled controls are focusable so screen reader users are more likely to be aware of their presence.
            For additional guidance, see <a href="#kbd_disabled_controls"></a>.
          </li>
          <li>In applications where quick access to a toolbar is important, such as accessing an editor's toolbar from its text area, a documented shortcut key for moving focus from the relevant context to its corresponding toolbar is recommended.</li>
        </ol>
      </section>
      <section class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <ul>
          <li>The element that serves as the toolbar container has role <a class="role-reference" href="#toolbar">toolbar</a>.  </li>
          <li>
            If the toolbar has a visible label, it is referenced by
            <a href="#aria-labelledby" class="property-reference">aria-labelledby</a> on the toolbar element.
            Otherwise, the toolbar element has a label provided by
            <a href="#aria-label" class="property-reference">aria-label</a>.
          </li>
          <li>If the controls are arranged vertically, the toolbar element has <a href="#aria-orientation" class="property-reference">aria-orientation</a> set to <code>vertical</code>. The default orientation is horizontal.</li>
        </ul>
      </section>
    </section>

    <section class="widget" id="tooltip">
      <h3>Tooltip Widget</h3>
      <p>
        <strong>NOTE:</strong> This design pattern is work in progress; it does not yet have task force consensus.
        Progress and discussions are captured in
        <a href="https://github.com/w3c/aria-practices/issues/128">issue 128.</a>
      </p>
      <p>
        A tooltip is a popup that displays information related to an element when the element receives keyboard focus or the mouse hovers over it.
        It typically appears after a small delay and disappears when <kbd>Escape</kbd> is pressed or on mouse out.
      </p>
      <p>
        Tooltip widgets do not receive focus.
        A hover that contains focusable elements can be made using a non-modal dialog.
      </p>
      <section class="notoc">
        <h4>Example</h4>
        <p>
          Work to develop a tooltip example is tracked by
          <a href="https://github.com/w3c/aria-practices/issues/127">issue 127.</a>
        </p>
      </section>
      <section class="notoc">
        <h4>Keyboard Interaction</h4>
        <p><kbd>Escape</kbd>: Dismisses the Tooltip.</p>
        <ol class="note">
          <li>Focus stays on the triggering element while the tooltip is displayed.</li>
          <li>
            If the tooltip is invoked when the trigger element   receives focus, then it is dismissed when it no longer has focus (onBlur).
            If   the tooltip is invoked with mouseIn, then it is dismissed with on mouseOut.
          </li>
        </ol>
      </section>
      <section class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <ul>
          <li>The element that serves as the tooltip container has role <a href="#tooltip" class="role-reference">tooltip</a>.</li>
          <li>The element that triggers the tooltip references the tooltip element with <a href="#aria-describedby" class="property-reference">aria-describedby</a>.</li>
        </ul>
      </section>
    </section>

    <section class="widget" id="TreeView">
      <h3>Tree View</h3>
      <p>
        A tree view widget presents a hierarchical list.
        Any item in the hierarchy may have child items, and items that have children may be expanded or collapsed to show or hide the children.
        For example, in a file system navigator that uses a tree view to display folders and files,
        an item representing a folder can be expanded to reveal the contents of the folder, which may be files, folders, or both.
      </p>
      <p>Terms for understanding tree views include:</p>
      <dl>
        <dt>Node</dt>
        <dd>An item in a tree. </dd>
        <dt>Root Node</dt>
        <dd>Node at the base of the tree; it may have one or more child nodes but does not have a parent node.</dd>
        <dt>Child Node</dt>
        <dd>Node that has a parent; any node that is not a root node is a child node.</dd>
        <dt>End Node</dt>
        <dd>Node that does not have any child nodes; an end node may be either a root node or a child node.</dd>
        <dt>Parent Node</dt>
        <dd>Node with one or more child nodes. It can be open (expanded) or closed (collapsed).</dd>
        <dt>Open Node</dt>
        <dd>Parent node that is expanded so its child nodes are visible.</dd>
        <dt>Closed Node</dt>
        <dd>Parent node that is collapsed so the child nodes are not visible.</dd>
      </dl>
      <p>
        When using a keyboard to navigate a tree, a visual keyboard indicator informs the user which node is focused.
        If the tree allows the user to choose just one item for an action, then it is known as a single-select tree.
        In some implementations of single-select tree, the focused item also has a selected state; this is known as selection follows focus.
        However, in multi-select trees, which enable the user to select more than one item for an action, the selected state is always independent of the focus.
        For example, in a typical file system navigator, the user can move focus to select any number of files for an action, such as copy or move.
        It is important that the visual design distinguish between items that are selected and the item that has focus.
        For more details, see <a href="#kbd_focus_vs_selection">this description of differences between focus and selection</a>
        and <a href="#kbd_selection_follows_focus">Deciding When to Make Selection Automatically Follow Focus</a>.
      </p>

      <section class="notoc">
        <h4>Examples</h4>
        <ul>
          <li>
            <a href="examples/treeview/treeview-1/treeview-1a.html">File Directory Treeview Example Using Computed Properties</a>:
            A file selector tree that demonstrates browser support for automatically computing <code>aria-level</code>, <code>aria-posinset</code> and <code>aria-setsize</code> based on DOM structure.
          </li>
          <li>
            <a href="examples/treeview/treeview-1/treeview-1b.html">File Directory Treeview Example Using Declared Properties</a>:
            A file selector tree that demonstrates how to explicitly define values for <code>aria-level</code>, <code>aria-posinset</code> and <code>aria-setsize</code>.
          </li>
          <li>
            <a href="examples/treeview/treeview-2/treeview-2a.html">Navigation Treeview Example Using Computed Properties</a>:
            A tree that provides navigation to a set of web pages and demonstrates browser support for automatically computing <code>aria-level</code>, <code>aria-posinset</code> and <code>aria-setsize</code> based on DOM structure.
          </li>
          <li>
            <a href="examples/treeview/treeview-2/treeview-2b.html">Navigation Treeview Example Using Declared Properties</a>:
      A tree that provides navigation to a set of web pages and demonstrates how to explicitly define values for <code>aria-level</code>, <code>aria-posinset</code> and <code>aria-setsize</code>.
          </li>
        </ul>
      </section>

      <section class="notoc">
        <h4>Keyboard Interaction</h4>
        <p>For a vertically oriented tree:</p>
        <ul>
          <li> When a single-select tree receives focus:
            <ul>
              <li>If none of the nodes are selected before the tree receives focus, focus is set on the first node.</li>
              <li>If a node is selected before the tree receives focus, focus is set on the selected node. </li>
            </ul>
          </li>
          <li>When a multi-select tree receives focus:
            <ul>
              <li>If none of the nodes are selected before the tree receives focus, focus is set on the first node.</li>
              <li>If one or more nodes are selected before the tree receives focus, focus is set on the first selected node.</li>
            </ul>
          </li>
          <li><kbd>Right arrow</kbd>:
            <ul>
              <li>When focus is on a closed node, opens the node; focus does not move.</li>
              <li>When focus is on a open node, moves focus to the first child node.</li>
              <li>When focus is on an end node, does nothing.</li>
            </ul>
           </li>
          <li><kbd>Left arrow</kbd>:
            <ul>
              <li>When focus is on an open node, closes the node.</li>
              <li>When focus is on a child node that is also either an end node or a closed node, moves focus to its parent node.</li>
              <li>When focus is on a root node that is also either an end node or a closed node, does nothing.</li>
            </ul>
           </li>
          <li><kbd>Down Arrow</kbd>: Moves focus to the next node that is focusable without opening or closing a node.</li>
          <li><kbd>Up Arrow</kbd>: Moves focus to the previous node that is focusable without opening or closing a node.</li>
          <li><kbd>Home</kbd>: Moves focus to the first node in the tree without opening or closing a node.</li>
          <li><kbd>End</kbd>: Moves focus to the last node in the tree that is focusable without opening a node.</li>
          <li><kbd>Enter</kbd>: activates a node, i.e., performs its default action. For parent nodes, one possible default action is to open or close the node. In single-select trees where selection does not follow focus (see note below), the default action is typically to select the focused node.</li>
          <li>Type-ahead is recommended for all trees, especially for trees with more than 7 root nodes:
            <ul>
              <li>Type a character: focus moves to the next node with a name that starts with the typed character.</li>
              <li>Type multiple characters in rapid succession: focus moves to the next node with a name that starts with the string of characters typed.</li>
            </ul>
          </li>
          <li><kbd>*</kbd> (Optional): Expands all siblings that are at the same level as the current node.</li>
          <li><strong>Selection in multi-select trees:</strong>
          Authors may implement either of two interaction models to support multiple selection: a recommended model that does not require the user to hold a modifier key, such as <kbd>Shift</kbd> or <kbd>Control</kbd>, while navigating the list
          or an alternative model that does require modifier keys to be held while navigating in order to avoid losing selection states.
            <ul>
              <li>Recommended selection model -- holding a modifier key while moving focus is not necessary:
                <ul>
                  <li><kbd>Space</kbd>: Toggles the selection state of the focused node.</li>
                  <li><kbd>Shift + Down Arrow</kbd> (Optional): Moves focus to and toggles the selection state of the next node.</li>
                  <li><kbd>Shift + Up Arrow</kbd> (Optional): Moves focus to and toggles the selection state of the previous node.</li>
                  <li><kbd>Shift + Space</kbd> (Optional): Selects contiguous nodes from the most recently selected node to the current node.</li>
                  <li><kbd>Control + Shift + Home</kbd> (Optional): Selects the node with focus and all nodes up to the first node. Optionally, moves focus to the first node.</li>
                  <li><kbd>Control + Shift + End</kbd> (Optional): Selects the node with focus and all nodes down to the last node. Optionally, moves focus to the last node.</li>
                  <li><kbd>Control + A</kbd> (Optional): Selects all nodes in the tree. Optionally, if all nodes are selected, it can also unselect all nodes.</li>
                </ul>
              </li>
              <li>Alternative selection model -- Moving focus without holding the <kbd>Shift</kbd> or <kbd>Control</kbd> modifier unselects all selected nodes except for the focused node:
                <ul>
                  <li><kbd>Shift + Down Arrow</kbd>: Moves focus to and toggles the selection state of the next node.</li>
                  <li><kbd>Shift + Up Arrow</kbd>: Moves focus to and toggles the selection state of the previous node.</li>
                  <li><kbd>Control + Down Arrow</kbd>: Without changing the selection state, moves focus to the next node.</li>
                  <li><kbd>Control + Up Arrow</kbd>: Without changing the selection state, moves focus to the previous node.</li>
                  <li><kbd>Control + Space</kbd>: Toggles the selection state of the focused node.</li>
                  <li><kbd>Shift + Space</kbd> (Optional): Selects contiguous nodes from the most recently selected node to the current node.</li>
                  <li><kbd>Control + Shift + Home</kbd> (Optional): Selects the node with focus and all nodes up to the first node. Optionally, moves focus to the first node.</li>
                  <li><kbd>Control + Shift + End</kbd> (Optional): Selects the node with focus and all nodes down to the last node. Optionally, moves focus to the last node.</li>
                  <li><kbd>Control + A</kbd> (Optional): Selects all nodes in the tree. Optionally, if all nodes are selected, it can also unselect all nodes.</li>
                </ul>
              </li>
            </ul>
          </li>
        </ul>
        <ol class="note">
          <li>DOM focus (the active element) is functionally distinct from the selected state. For more details, see <a href="#kbd_focus_vs_selection">this description of differences between focus and selection.</a></li>
          <li>
            The <code>tree</code> role supports the <a class="property-reference" href="#aria-activedescendant">aria-activedescendant</a> property,
            which provides an alternative to moving DOM focus among <code>treeitem</code> elements when implementing keyboard navigation.
            For details, see <a href="#kbd_focus_activedescendant">Managing Focus in Composites Using aria-activedescendant</a>.
          </li>
          <li>
            In a single-select tree, moving focus may optionally unselect the previously selected node and select the newly focused node.
            This model of selection is known as &quot;selection follows focus&quot;.
            Having selection follow focus can be very helpful in some circumstances and can severely degrade accessibility in others.
            For additional guidance, see <a href="#kbd_selection_follows_focus">Deciding When to Make Selection Automatically Follow Focus</a>.
          </li>
          <li>If selecting or unselecting all nodes is an important function, implementing separate controls for these actions, such as buttons for &quot;Select All&quot; and &quot;Unselect All&quot;, significantly improves accessibility.</li>
        <li>
            If the nodes in a tree are arranged horizontally:
            <ol>
              <li><kbd>Down Arrow</kbd> performs as <kbd>Right Arrow</kbd> is described above, and vice versa.</li>
              <li><kbd>Up Arrow</kbd> performs as <kbd>Left Arrow</kbd> is described above, and vice versa.</li>
            </ol>
          </li>
        </ol>
      </section>

      <section id="tree_roles_states_props" class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <ul>
          <li>All tree nodes are contained in or owned by an element with role <a class="role-reference" href="#tree">tree</a>.</li>
          <li>Each element serving as a tree node has role <a class="role-reference" href="#treeitem">treeitem</a>.</li>
          <li>Each root node is contained in the element with role <code>tree</code> or referenced by an <a href="#aria-owns" class="property-reference">aria-owns</a> property set on the <code>tree</code> element.</li>
          <li>Each parent node contains or owns an element with role <a class="role-reference" href="#group">group</a>.</li>
          <li>Each child node is contained in or owned by an element with role <a class="role-reference" href="#group">group</a> that is contained in or owned by the node that serves as the parent of that child.</li>
          <li>
            Each element with role <code>treeitem</code> that serves as a parent node has <a class="property-reference" href="#aria-expanded">aria-expanded</a>
            set to <code>false</code> when the node is in a closed state and set to <code>true</code> when the node is in an open state.
            End nodes do not have the <code>aria-expanded</code> attribute because, if they were to have it, they would be incorrectly described to assistive technologies as parent nodes.
          </li>
          <li>If the tree supports selection of more than one node, the element with role <code>tree</code> has <a class="property-reference" href="#aria-multiselectable">aria-multiselectable</a> set to <code>true</code>. Otherwise, <code>aria-multiselectable</code> is either set to <code>false</code> or the default value of <code>false</code> is implied.</li>
          <li>If the tree does not support multiple selection, <a href="#aria-selected" class="property-reference">aria-selected</a> is set to <code>true</code> for the selected node and it is not present on any other node in the tree.</li>
          <li>if the tree supports multiple selection:
          <ul>
          <li>All selected nodes have <a href="#aria-selected" class="state-reference">aria-selected</a> set to <code>true</code>.</li>
          <li>All nodes that are selectable but not selected have <a href="#aria-selected" class="state-reference">aria-selected</a> set to <code>false</code>.</li>
          <li>If the tree contains nodes that are not selectable, those nodes do not have the <code>aria-selected</code> state.</li>
          </ul>
          </li>
          <li>The element with role <code>tree</code> has either a visible label referenced by <a href="#aria-labelledby" class="property-reference">aria-labelledby</a> or a value specified for <a href="#aria-label" class="property-reference">aria-label</a>.</li>
          <li>If the complete set of available nodes is not present in the DOM due to dynamic loading as the user moves focus in or scrolls the tree, each node has <a href="#aria-level" class="property-reference">aria-level</a>, <a href="#aria-setsize" class="property-reference">aria-setsize</a>, and <a href="#aria-posinset" class="property-reference">aria-posinset</a> specified.</li>
          <li>
            If the <code>tree</code> element is horizontally oriented, it has <a href="#aria-orientation" class="property-reference">aria-orientation</a>
            set to <code>horizontal</code>.
            The default value of <code>aria-orientation</code> for a tree is <code>vertical</code>.
          </li>
        </ul>
        <p class="note">
          If <a href="#aria-owns" class="property-reference">aria-owns</a> is set on the tree container to include elements that are not DOM children of the container,
          those elements will appear in the reading order in the sequence they are referenced and after any items that are DOM children.
          Scripts that manage focus need to ensure the visual focus order matches this assistive technology reading order.
        </p>
      </section>
    </section>

    <section class="widget" id="treegrid">
      <h3>Treegrid</h3>
        <p>
          A <a href="#treegrid" class="role-reference">treegrid</a> widget presents a hierarchical data grid consisting of tabular information that is editable or interactive.
          Any row in the hierarchy may have child rows, and rows with children may be expanded or collapsed to show or hide the children.
          For example, in a <code>treegrid</code> used to display messages and message responses for a e-mail discussion list, messages with responses would be in rows that can be expanded to reveal the response messages.
        </p>
      <p>
        In a treegrid both rows and cells are focusable.  Every row and cell contains a focusable element or is itself focusable, regardless of whether individual cell content is editable or interactive.
        There is one exception: if column header cells do not provide functions, such as sort or filter, they do not need to be focusable.
        One reason it is important for all cells to be able to receive or contain keyboard focus is that screen readers will typically be in their application reading mode, rather than their document reading mode, when users are interacting with the grid.
        While in application mode, a screen reader user hears only focusable elements and content that labels focusable elements.
        So, screen reader users may unknowingly overlook elements contained in a <code>treegrid</code> that are either not focusable or not used to label a column or row.
      </p>
      <p>
        When using a keyboard to navigate a <code>treegrid</code>, a visual keyboard indicator informs the user which row or cell is focused.
        If the <code>treegrid</code> allows the user to choose just one item for an action, then it is known as a single-select <code>treegrid</code>, and the item with focus also has a selected state.
        However, in multi-select <code>treegrid</code>s, which enable the user to select more than one row or cell for an action, the selected state is independent of the focus.
        For example, in a hierarchical e-mail discussion grid, the user can move focus to select any number of rows for an action, such as delete or move.
        It is important that the visual design distinguish between items that are selected and the item that has focus.
        For more details, see <a href="#kbd_focus_vs_selection">this description of differences between focus and selection.</a>
      </p>

      <section class="notoc">
        <h4>Examples</h4>
        <ul>
          <li>
            <a href="examples/treegrid/treegrid-1.html">E-mail Inbox <code>treegrid</code> Example</a>: A treegrid for navigating an e-mail inbox that demonstrates three keyboard navigation models -- rows first, cells first, and cells only.
          </li>
        </ul>
      </section>

      <section class="notoc">
        <h4>Keyboard Interaction</h4>
        <p>
          The following keys provide <code>treegrid</code> navigation by moving focus among rows and cells of the grid.
          Implementations of <code>treegrid</code> make these key commands available when an element in the grid has received focus, e.g., after a user has moved focus to the grid with <kbd>Tab</kbd>.
          Moving focus into the grid may result in the first cell or the first row being focused.
          Whether focus goes to a cell or the row depends on author preferences and whether row focus is supported, since some <code>treegrid</code>s may not provide focus to rows.
        </p>
        <ul>
          <li> <kbd>Enter</kbd>: If cell-only focus is enabled and focus is on the first cell with the <code>aria-expanded</code> property, opens or closes the child rows.,Otherwise, performs the default action for the cell.</li>
          <li><kbd>Tab</kbd>: If the row containing focus contains focusable elements (e.g., inputs, buttons, links, etc.), moves focus to the next input in the row.  If focus is on the last focusable element in the row, moves focus out of the <code>treegrid</code> widget to the next focusable element.</li>
          <li>
            <kbd>Right Arrow</kbd>:
            <ul>
              <li>If focus is on a collapsed row, expands the row.</li>
              <li>If focus is on an expanded row or is on a row that does not have child rows, moves focus to the first cell in the row.</li>
              <li>If focus is on the right-most cell in a row, focus does not move.</li>
              <li>If focus is on any other cell, moves focus one cell to the right.</li>
            </ul>
          </li>
          <li><kbd>Left Arrow</kbd>:
            <ul>
              <li>If focus is on an expanded row, collapses the row.</li>
              <li>If focus is on a collapsed row or on a row that does not have child rows, focus does not move.</li>
              <li>If focus is on the first cell in a row and row focus is supported, moves focus to the row.</li>
              <li>If focus is on the first cell in a row and row focus is not supported, focus does not move.</li>
              <li>If focus is on any other cell, moves focus one cell to the left.</li>
            </ul>
          </li>
          <li>
            <kbd>Down Arrow</kbd>:
            <ul>
              <li>If focus is on a row, moves focus one row down.  If focus is on the last row, focus does not move.</li>
              <li>If focus is on a cell, moves focus one cell down.  If focus is on the bottom cell in the column, focus does not move.</li>
            </ul>
          </li>
          <li>
            <kbd>Up Arrow</kbd>:
            <ul>
              <li>If focus is on a row, moves focus one row up.  If focus is on the first row, focus does not move.</li>
              <li>If focus is on a cell, moves focus one cell up.  If focus is on the top cell in the column, focus does not move.</li>
            </ul>
          </li>
          <li>
            <kbd>Page Down</kbd>:
            <ul>
              <li>If focus is on a row, moves focus down an author-determined number of rows, typically scrolling so the bottom row in the currently visible set of rows becomes one of the first visible rows. If focus is in the last row, focus does not move.</li>
              <li>If focus is on a cell, moves focus down an author-determined number of cells, typically scrolling so the bottom row in the currently visible set of rows becomes one of the first visible rows. If focus is in the last row, focus does not move.</li>
            </ul>
          </li>
          <li>
            <kbd>Page Up</kbd>:
             <ul>
                <li>If focus is on a row, moves focus up an author-determined number of rows, typically scrolling so the top row in the currently visible set of rows becomes one of the last visible rows. If focus is in the first row, focus does not move.</li>
                <li>If focus is on a cell, moves focus up an author-determined number of cells, typically scrolling so the top row in the currently visible set of rows becomes one of the last visible rows. If focus is in the first row, focus does not move.</li>
              </ul>
          </li>
          <li>
            <kbd>Home</kbd>:
             <ul>
                <li>If focus is on a row, moves focus to the first row.  If focus is in the first row, focus does not move.</li>
                <li>If focus is on a cell, moves focus to the first cell in the row. If focus is in the first cell of the row, focus does not move.</li>
              </ul>
          </li>
          <li>
            <kbd>End</kbd>:
             <ul>
                <li>If focus is on a row, moves focus to the last row.  If focus is in the last row, focus does not move.</li>
                <li>If focus is on a cell, moves focus to the last cell in the row. If focus is in the last cell of the row, focus does not move.</li>
              </ul>
          </li>
          <li>
            <kbd>Control + Home</kbd>:
             <ul>
                <li>If focus is on a row, moves focus to the first row.  If focus is in the first row, focus does not move.</li>
                <li>If focus is on a cell, moves focus to the first cell in the column. If focus is in the first row, focus does not move.</li>
              </ul>
          </li>
          <li>
            <kbd>Control + End</kbd>:
             <ul>
                <li>If focus is on a row, moves focus to the last row.  If focus is in the last row, focus does not move.</li>
                <li>If focus is on a cell, moves focus to the last cell in the column. If focus is in the last row, focus does not move.</li>
              </ul>
          </li>
        </ul>
        <ul class="note">
          <li>
            When the above <code>treegrid</code> navigation keys move focus, whether the focus is set on an element inside the cell or on the cell depends on cell content.
            See <a href="#gridNav_focus">Whether to Focus on a Cell or an Element Inside It</a>.
          </li>
          <li>
            While navigation keys, such as arrow keys, are moving focus from cell to cell, they are not available to do something like operate a combobox or move an editing caret inside of a cell.
            If this functionality is needed, see <a href="#gridNav_inside">Editing and Navigating Inside a Cell</a>.
          </li>
          <li>If navigation functions can dynamically add more rows or columns to the DOM, key events that move focus to the beginning or end of the grid, such as <kbd>control + End</kbd>, may move focus to the last row in the DOM rather than the last available row in the back-end data.</li>
        </ul>
        <p>If a treegrid supports selection of cells, rows, or columns, the following keys are commonly used for these functions.</p>
        <ul>
          <li>
            <kbd>Control + Space</kbd>:
            <ul>
              <li>If focus is on a row, selects all cells.</li>
              <li>If focus is on a cell, selects the column that contains the focus.</li>
            </ul>
          </li>
          <li>
            <kbd>Shift + Space</kbd>:
            <ul>
              <li>If focus is on a row, selects the row.</li>
              <li>If focus is on a cell, selects the row that contains the focus. If the treegrid includes a column with checkboxes for selecting rows, this key can serve as a shortcut for checking the box when focus is not on the checkbox.</li>
            </ul>
          </li>
          <li><kbd>Control + A</kbd>: Selects all cells.</li>
          <li>
            <kbd>Shift + Right Arrow</kbd>:
            <ul>
              <li>If focus is on a row, does not change selection.</li>
              <li>if focus is on a cell, extends selection one cell to the right.</li>
            </ul>
          </li>
          <li>
            <kbd>Shift + Left Arrow</kbd>:
            <ul>
              <li>If focus is on a row, does not change selection.</li>
              <li>if focus is on a cell, extends selection one cell to the left.</li>
            </ul>
          </li>
          <li>
            <kbd>Shift + Down Arrow</kbd>:
            <ul>
              <li>If focus is on a row, extends selection to all the cells in the next row.</li>
              <li>If focus is on a cell, extends selection one cell down.</li>
            </ul>
          </li>
          <li>
            <kbd>Shift + Up Arrow</kbd>:
            <ul>
              <li>If focus is on a row, extends selection to all the cells in the previous row.</li>
              <li>If focus is on a cell, extends selection one cell up.</li>
            </ul>
          </li>
        </ul>
        <p class="note">See <a href="#kbd_common_conventions"></a> for cut, copy, and paste key assignments.</p>
      </section>

      <section id="treegrid_roles_states_props" class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <ul>
          <li>The treegrid container has role <a href="#treegrid" class="role-reference">treegrid</a>. </li>
          <li>Each row container has role <a href="#row" class="role-reference">row</a> and is either a DOM descendant of or owned by the <code>treegrid</code> element or an element with role <a href="#rowgroup" class="role-reference">rowgroup</a>. </li>
          <li>Each cell is either a DOM descendant of or owned by a <code>row</code> element and has one of the following roles:
            <ul>
              <li><a href="#columnheader"  class="role-reference">columnheader</a> if the cell contains a title or header information for the column.</li>
              <li><a href="#rowheader"  class="role-reference">rowheader</a> if the cell contains title or header information for the row.</li>
              <li><a href="#gridcell" class="role-reference">gridcell</a> if the cell does not contain column or row header information.</li>
            </ul>
          </li>
          <li>
            A <code>row</code> that can be expanded or collapsed to show or hide a set of child rows is a parent row.
            Each parent <code>row</code> has the <a class="property-reference" href="#aria-expanded">aria-expanded</a> state set on either the <code>row</code> element or on a cell contained in the<code>row</code>.
            The <code>aria-expanded</code> state is set to <code>false</code> when the child rows are not displayed and set to <code>true</code> when the child rows are displayed.
            Rows that do not control display of child rows do not have the <code>aria-expanded</code> attribute because, if they were to have it, they would be incorrectly described to assistive technologies as parent rows.
          </li>
          <li>If the treegrid supports selection of more than one row or cell, it is a multi-select treegrid and the element with role <code>treegrid</code> has <a class="property-reference" href="#aria-multiselectable">aria-multiselectable</a> set to <code>true</code>. Otherwise, it is a single-select treegrid, and <code>aria-multiselectable</code> is either set to <code>false</code> or the default value of <code>false</code> is implied.</li>
          <li>If the treegrid is a single-select treegrid, <a href="#aria-selected" class="property-reference">aria-selected</a> is set to <code>true</code> on the selected row or cell, and it is not present on any other row or cell in the treegrid.</li>
          <li>if the treegrid is a multi-select treegrid:
          <ul>
          <li>All selected rows or cells have <a href="#aria-selected" class="state-reference">aria-selected</a> set to <code>true</code>.</li>
          <li>All rows and cells that are not selected have <a href="#aria-selected" class="state-reference">aria-selected</a> set to <code>false</code>.</li>
          </ul>
          </li>
          <li>
            If there is an element in the user interface that serves as a label for the treegrid, <a href="#aria-labelledby" class="property-reference">aria-labelledby</a> is set on the grid element with a value that refers to the labelling element.
            Otherwise, a label is specified for the grid element using <a href="#aria-label" class="property-reference">aria-label</a>.
          </li>
          <li>If the treegrid has a caption or description, <a href="#aria-describedby" class="property-reference">aria-describedby</a> is set on the grid element with a value referring to the element containing the description.</li>
          <li>If the treegrid provides sort functions, <a href="#aria-sort" class="property-reference">aria-sort</a> is set to an appropriate value on the header cell element for the sorted column or row as described in the section on <a href="#gridAndTableProperties">grid and table properties</a>. </li>
          <li>
            If the treegrid provides content editing functionality and contains cells that may have edit capabilities disabled in certain conditions, <a href="#aria-readonly" class="state-reference">aria-readonly</a> is set to <code>true</code> on cells where editing is disabled.
            If edit functions are disabled for all cells, instead of setting <code>aria-readonly</code> to <code>true</code> on every cell, <code>aria-readonly</code> may be set to <code>true</code> on the <code>treegrid</code> element.
            Treegrids that do not provide cell content editing functions do not include the <code>aria-readonly</code> attribute on any of their elements.
          </li>
          <li>
            If there are conditions where some rows or columns are hidden or not present in the DOM, e.g., data is dynamically loaded when scrolling or the grid provides functions for hiding rows or columns, the following properties are applied as described in the section on <a href="#gridAndTableProperties">grid and table properties</a>.
            <ul>
              <li><a href="#aria-colcount" class="property-reference">aria-colcount</a> or <a href="#aria-rowcount" class="property-reference">aria-rowcount</a> is set to the total number of columns or rows, respectively. </li>
              <li><a href="#aria-colindex" class="property-reference">aria-colindex</a> or <a href="#aria-rowindex" class="property-reference">aria-rowindex</a> is set to the position of a cell within a row or column, respectively. </li>
            </ul>
          </li>
          <li>If the treegrid includes cells that span multiple rows or multiple columns, and if the <code>treegrid</code> role is NOT applied to an HTML <code>table</code> element, then <a href="#aria-rowspan" class="property-reference">aria-rowspan</a> or <a href="#aria-colspan" class="property-reference">aria-colspan</a> is applied as described in <a href="#gridAndTableProperties">grid and table properties</a>.</li>
        </ul>
        <ul class="note">
          <li>
            A <code>treegrid</code> built from an HTML <code>table</code> that includes cells that span multiple rows or columns must use HTML <code>rowspan</code> and <code>colspan</code> and must not use <code>aria-rowspan</code> or <code>aria-colspan</code>.
          </li>
          <li>
            If rows or cells are included in a treegrid via <a href="#aria-owns" class="property-reference">aria-owns</a>,
            they will be presented to assistive technologies after the DOM descendants of the <code>treegrid</code> element unless the DOM descendants are also included in the <code>aria-owns</code> attribute.
          </li>
        </ul>
      </section>
   </section>

    <section class="widget" id="windowsplitter">
      <h3>Window Splitter</h3>
      <p>
        <strong>NOTE:</strong> ARIA 1.1 introduced changes to the separator role so it behaves as a widget when focusable.
        While this pattern has been revised to match the ARIA 1.1 specification, the task force will not complete its review until a functional example that matches the ARIA 1.1 specification is complete.
        Progress on this pattern is tracked by
        <a href="https://github.com/w3c/aria-practices/issues/129">issue 129.</a>
      </p>
      <p>
        A window splitter is a moveable separator between two sections, or panes, of a window that enables users to change the relative size of the panes.
        A Window Splitter can be either variable or fixed.
        A fixed splitter toggles between two positions whereas a variable splitter can be adjusted to any position within an allowed range.
      </p>
      <p>
        A window splitter has a value that represents the size of one of the panes, which, in this pattern,  is called the primary pane.
        When the splitter has its minimum value, the primary pane has its smallest size and the secondary pane has its largest size.
        The splitter also has an accessible name that matches the name of the primary pane.
      </p>
      <p>
        For example, consider a book reading application with a primary pane for the table of contents and a secondary pane that displays content from a section of the book.
        The two panes are divided by a vertical splitter labelled &quot;Table of Contents&quot;.
        When the table of contents pane has its maximum size, the splitter has a value of <code>100</code>,
        and when the table of contents is completely collapsed, the splitter has a value of <code>0</code>.
      </p>
      <p>
        Note that the term &quot;primary pane&quot; does not describe the importance or purpose of content inside the pane.
      </p>
      <section class="notoc">
        <h4>Example</h4>
        <p>
          Work to develop an example window splitter widget is tracked by
          <a href="https://github.com/w3c/aria-practices/issues/130">issue 130.</a>
        </p>
      </section>
      <section class="notoc">
        <h4>Keyboard Interaction</h4>
        <ul>
          <li><kbd>Left Arrow</kbd>: Moves a vertical splitter to the left.</li>
          <li><kbd>Right Arrow</kbd>: Moves a vertical splitter to the right.</li>
          <li><kbd>Up Arrow</kbd>: Moves a horizontal splitter up.</li>
          <li><kbd>Down Arrow</kbd>: Moves a horizontal splitter down.</li>
          <li><kbd>Enter</kbd>: If the primary pane is not collapsed, collapses the pane. If the pane is collapsed, restores the splitter to its previous position.</li>
          <li><kbd>Home</kbd> (Optional): Moves splitter to the position that gives the primary pane its smallest allowed size. This may completely collapse the primary pane.</li>
          <li><kbd>End</kbd> (Optional): Moves splitter to the position that gives the primary pane its largest allowed size. This may completely collapse the secondary pane.</li>
          <li><kbd>F6</kbd> (Optional): Cycle through window   panes.</li>
        </ul>
        <p class="note">A fixed size splitter omits implementation of the arrow keys.</p>
      </section>
      <section class="notoc">
        <h4>WAI-ARIA Roles, States, and Properties</h4>
        <ul>
          <li>The element that serves as the focusable splitter has role <a href="#separator" class="role-reference">separator</a>.</li>
          <li>The separator element has the <a class="property-reference" href="#aria-valuenow">aria-valuenow</a> property set to a decimal value representing the current position of the separator.</li>
          <li>The separator element has the <a class="property-reference" href="#aria-valuemin">aria-valuemin</a> property set to a decimal value that represents the position where the primary pane has its minimum size. This is typically <code>0</code>.</li>
          <li>The separator element has the <a class="property-reference" href="#aria-valuemax">aria-valuemax</a> property set to a decimal value that represents the position where the primary pane has its maximum size. This is typically <code>100</code>.</li>
          <li>
            If the primary pane has a visible label, it is referenced by
            <a href="#aria-labelledby" class="property-reference">aria-labelledby</a> on the separator element.
            Otherwise, the separator element has a label provided by
            <a href="#aria-label" class="property-reference">aria-label</a>.
          </li>
          <li>The separator element has <a href="#aria-controls" class="property-reference">aria-controls</a> referring to the primary pane.</li>
        </ul>
      </section>
    </section>
  </section>

  <section class="widget" id="aria_landmark">
    <h2>Landmark Regions</h2>
    <p>
      ARIA landmark roles provide a powerful way to identify the organization and structure of a web page.
      By classifying and labelling sections of a page, they enable structural information that is conveyed visually through layout to be represented programmatically.
      Screen readers exploit landmark roles to provide keyboard navigation to important sections of a page.
      Landmark regions can also be used as targets for &quot;skip links&quot; and by browser extensions to enhanced keyboard navigation.
    </p>
    <p>
      This section explains how HTML sectioning elements and ARIA landmark roles
      are used to make it easy for assistive technology users to understand the meaning of the layout of a page.
    </p>
    <section>
      <h3>HTML Sectioning Elements</h3>
      <p>
        Several HTML sectioning elements automatically create ARIA landmark regions.
        So, in order to provide assistive technology users with a logical view of a page,
        it is important to understand the effects of using HTML sectioning elements.
        [[HTML-ARIA]] contains more information on HTML element role mapping.
      </p>
      <table class="widget-features">
        <caption>Default landmark roles for HTML sectioning elements</caption>
        <thead>
          <tr>
            <th>HTML Element</th>

            <th>Default Landmark Role</th>
          </tr>
        </thead>

        <tbody>
          <tr>
            <td><code>aside</code></td>

            <td><code>complementary</code></td>
          </tr>

          <tr>
            <td><code>footer</code></td>

            <td><code>contentinfo</code> when in context of the <code>body</code> element</td>
          </tr>

          <tr>
            <td><code>header</code></td>

            <td><code>banner</code> when in context of the <code>body</code> element</td>
          </tr>

          <tr>
            <td><code>main</code></td>

            <td><code>main</code></td>
          </tr>

          <tr>
            <td><code>nav</code></td>

            <td><code>navigation</code></td>
          </tr>

          <tr>
            <td><code>section</code></td>

            <td><code>region</code> when it has an accessible name using <code>aria-labelledby</code> or <code>aria-label</code></td>
          </tr>
        </tbody>
      </table>
    </section>
    <section>
      <h3>General Principles of Landmark Design</h3>
      <p>
        Including <strong>all perceivable content</strong> on a page in one of its landmark regions
        and giving each landmark region a semantically meaningful role
        is one of the most effective ways of ensuring assistive technology users will not overlook information that is relevant to their needs.
      </p>
      <p><strong>Step 1: Identify the logical structure</strong></p>

      <ul>
        <li>Break the page into perceivable areas of content which designers typically indicate visually using alignment and spacing.</li>

        <li>Areas can be further defined into logical sub-areas as needed.</li>

        <li>An example of a sub-area is a portlet in a portal application.</li>
      </ul>

      <p><strong>Step 2: Assign landmark roles to each area</strong></p>

      <ul>
        <li>Assign landmark roles based on the type of content in the area.</li>

        <li><code>banner</code>, <code>main</code>, <code>complementary</code> and <code>contentinfo</code> landmarks should be top level landmarks.</li>

        <li>Landmark roles can be nested to identify parent/child relationships of the information being presented.</li>
      </ul>

      <p id="aria_lh_step3"><strong>Step 3: Label areas</strong></p>

      <ul>
        <li>
          If a specific landmark role is used more than once on a page, provide each instance of that landmark with a unique label.
          There is one rare circumstance where providing the same label to multiple instances of a landmark can be beneficial: the content and purpose of each instance is identical.
          For example, a large search results table has two sets of identical pagination controls -- one above and one below the table, so each set is in a navigation region labelled <q>Search Results</q>.
          In this case, adding extra information to the label that distinguishes the two instances may be more distracting than helpful.
        </li>

        <li>If a landmark is only used once on the page it may not require a label. See Landmark Roles section below. </li>

        <li>If an area begins with a heading element (e.g. <code>h1-h6</code>) it can be used as the label for the area using the <code>aria-labelledby</code> attribute.</li>

        <li>If an area requires a label and does not have a heading element, provide a label using the <code>aria-label</code> attribute.</li>

        <li>
          Do not use the landmark role as part of the label.
          For example, a navigation landmark with a label &quot;Site Navigation&quot; will be announced by a screen reader as &quot;Site Navigation Navigation&quot;.
          The label should simply be &quot;Site&quot;.
        </li>
      </ul>
    </section>

    <section>
      <h3>Landmark Roles</h3>

      <section class="widget" id="aria_lh_banner">
        <h4 class="widget-name">Banner</h4>

        <p>
          A <a class="role-reference" href="#banner"><code>banner</code></a> landmark identifies site-oriented content at the beginning of each page within a website. Site-oriented content typically includes things such as the logo or identity
          of the site sponsor, and site-specific search tool. A banner usually appears at the top of the page and typically spans the full width.
        </p>

        <ul>
          <li>Each page may have one <code>banner</code> landmark.</li>

          <li>The <code>banner</code> landmark should be a top-level landmark.</li>

          <li>When a page contains nested <code>document</code> and/or <code>application</code> roles (e.g. typically through the use of <code>iframe</code> and <code>frame</code> elements), each <code>document</code> or <code>application</code> role may have
            one <code>banner</code> landmark.</li>

          <li>If a page includes more than one <code>banner</code> landmark, each should have a unique label (see <a href="#aria_lh_step3">Step 3</a> above).</li>
        </ul>

        <section class="notoc">
          <h5>HTML Techniques</h5>
          <ul>
            <li>The HTML <code>header</code> element defines a <code>banner</code> landmark when its context is the <code>body</code> element.</li>

            <li>
              The HTML <code>header</code> element is not considered a <code>banner</code> landmark when it is descendant of any of following elements (see <a href="" class="html-mapping">HTML Accessibility Mappings</a> [[HTML-AAM]]):
              <ul>
                <li><code>article</code></li>
                <li><code>aside</code></li>
                <li><code>main</code></li>
                <li><code>nav</code></li>
                <li><code>section</code></li>
              </ul>
            </li>
          </ul>

          <h5>ARIA Techniques</h5>

          <p>If the HTML <code>header</code> element technique is not being used, a <code>role=&quot;banner&quot;</code> attribute should be used to define a <code>banner</code> landmark.</p>
        </section>

        <section class="notoc">
          <h5>Examples</h5>

          <p><a href="examples/landmarks/banner.html">Banner Landmark Example</a></p>
        </section>

      </section>

      <section id="aria_lh_complementary">
        <h4 class="widget-name">Complementary</h4>

        <p>A <a class="role-reference" href="#complementary"><code>complementary</code></a> landmark is a supporting section of the document, designed to be complementary to the main content at a similar level in the DOM hierarchy, but remains meaningful
          when separated from the main content.</p>

        <ul>
          <li><code>complementary</code> landmarks should be top level landmarks (e.g. not contained within any other landmarks).</li>

          <li>If the complementary content is not related to the main content, a more general role should be assigned (e.g. <code>region</code>).</li>

          <li>If a page includes more than one <code>complementary</code> landmark, each should have a unique label (see <a href="#aria_lh_step3">Step 3</a> above).</li>
        </ul>

        <section class="notoc">
          <h5>HTML Technique</h5>

          <p>Use the HTML <code>aside</code> element to define a <code>complementary</code> landmark.</p>

          <h5>ARIA Technique</h5>

          <p>If the HTML <code>aside</code> element technique is not being used, use a <code>role=&quot;complementary&quot;</code> attribute to define a <code>complementary</code> landmark.</p>
        </section>

        <section class="notoc">
          <h5>Examples</h5>

          <p><a href="examples/landmarks/complementary.html">Complementary Landmark Example</a></p>
        </section>
      </section>

      <section id="aria_lh_contentinfo">
        <h4 class="widget-name">Contentinfo</h4>

        <p>A <a class="role-reference" href="#contentinfo"><code>contentinfo</code></a> landmark is a way to identify common information at the bottom of each page within a website, typically called the &quot;footer&quot; of the page, including information
          such as copyrights and links to privacy and accessibility statements.</p>

        <ul>
          <li>Each page may have one <code>contentinfo</code> landmark.</li>

          <li>The <code>contentinfo</code> landmark should be a top-level landmark.</li>

          <li>When a page contains nested <code>document</code> and/or <code>application</code> roles (e.g. typically through the use of <code>iframe</code> and <code>frame</code> elements), each <code>document</code> or <code>application</code> role may have
            one <code>contentinfo</code> landmark.</li>

          <li>If a page includes more than one <code>contentinfo</code> landmark, each should have a unique label (see <a href="#aria_lh_step3">Step 3</a> above).</li>
        </ul>

        <section class="notoc">

          <h5>HTML Techniques</h5>

          <ul>
            <li>The HTML <code>footer</code> element defines a <code>contentinfo</code> landmark when its context is the <code>body</code> element.</li>

            <li>
              The HTML <code>footer</code> element is not considered a <code>contentinfo</code> landmark when it is descendant of any of following elements (see <a href="" class="html-mapping">HTML Accessibility Mappings</a> [[HTML-AAM]]):
              <ul>
                <li><code>article</code></li>
                <li><code>aside</code></li>
                <li><code>main</code></li>
                <li><code>nav</code></li>
                <li><code>section</code></li>
              </ul>
            </li>
          </ul>

          <h5>ARIA Technique</h5>

          <p>If the HTML <code>footer</code> element technique is not being used, a <code>role=&quot;contentinfo&quot;</code> attribute should be used to define a <code>contentinfo</code> landmark.</p>
        </section>

        <section class="notoc">
          <h5>Examples</h5>
          <p><a href="examples/landmarks/contentinfo.html">Contentinfo Landmark Example</a></p>
        </section>
      </section>

      <section id="aria_lh_form">
        <h4 class="widget-name">Form</h4>

        <p>A <a class="role-reference" href="#form"><code>form</code></a> landmark identifies a region that contains a collection of items and objects that, as a whole, combine to create a form when no other named landmark is appropriate (e.g. main
          or search).</p>

        <ul>
          <li>Use the <code>search</code> landmark instead of the <code>form</code> landmark when the form is used for search functionality.</li>

          <li>A <code>form</code> landmark should have a label to help users understand the purpose of the form.</li>

          <li>A label for the <code>form</code> landmark should be visible to all users (e.g. an <code>h1-h6</code> element).</li>

          <li>If a page includes more than one <code>form</code> landmark, each should have a unique label (see <a href="#aria_lh_step3">Step 3</a> above).</li>

          <li>
            Whenever possible, controls contained in a <code>form</code> landmark in an HTML document should use native host semantics:
            <ul>
              <li><code>button</code></li>

              <li><code>input</code></li>

              <li><code>select</code></li>

              <li><code>textarea</code></li>
            </ul>
          </li>
        </ul>

        <section class="notoc">
          <h5>HTML Techniques</h5>

          <p>The HTML <code>form</code> element defines a <code>form</code> landmark when it has an accessible name (e.g. <code>aria-labelledby</code>, <code>aria-label</code> or <code>title</code>).</p>

          <h5>ARIA Technique</h5>

          <p>Use the <code>role=&quot;form&quot;</code> to identify a region of the page; do not use it to identify every form field.</p>
        </section>

        <section class="notoc">
          <h5>Examples</h5>

          <p><a href="examples/landmarks/form.html">Form Landmark Example</a></p>
        </section>
      </section>

      <section id="aria_lh_main">
        <h4 class="widget-name">Main</h4>

        <p>A <a class="role-reference" href="#main"><code>main</code></a> landmark identifies the primary content of the page.</p>

        <ul>
          <li>Each page should have one <code>main</code> landmark.</li>

          <li>The <code>main</code> landmark should be a top-level landmark.</li>

          <li>When a page contains nested <code>document</code> and/or <code>application</code> roles (e.g. typically through the use of <code>iframe</code> and <code>frame</code> elements), each <code>document</code> or <code>application</code> role may have
            one <code>main</code> landmark.</li>

          <li>If a page includes more than one <code>main</code> landmark, each should have a unique label (see <a href="#aria_lh_step3">Step 3</a> above).</li>
        </ul>

        <section class="notoc">
          <h5>HTML Technique</h5>

          <p>Use the HTML <code>main</code> element to define a <code>main</code> landmark.</p>

          <h5>ARIA Technique</h5>

          <p>If the HTML <code>main</code> element technique is not being used, use a <code>role=&quot;main&quot;</code> attribute to define a <code>main</code> landmark.</p>
        </section>

        <section class="notoc">
          <h5>Examples</h5>

          <p><a href="examples/landmarks/main.html">Main Landmark Example</a></p>
        </section>
      </section>

      <section id="aria_lh_navigation">
        <h4 class="widget-name">Navigation</h4>

        <p><a class="role-reference" href="#navigation"><code>Navigation</code></a> landmarks provide a way to identify groups (e.g. lists) of links that are intended to be used for website or page content navigation.</p>

        <ul>
          <li>If a page includes more than one <code>navigation</code> landmark, each should have a unique label (see <a href="#aria_lh_step3">Step 3</a> above).</li>

          <li>If a <code>navigation</code> landmark has an identical set of links as another <code>navigation</code> landmark on the page, use the same label for each <code>navigation</code> landmark.</li>
        </ul>

        <section class="notoc">
          <h5>HTML Technique</h5>

          <p>Use the HTML <code>nav</code> element to define a <code>navigation</code> landmark.</p>

          <h5>ARIA Technique</h5>

          <p>If the HTML <code>nav</code> element technique is not being used, use a <code>role=&quot;navigation&quot;</code> attribute to define a <code>navigation</code> landmark.</p>

        </section>

        <section class="notoc">
          <h5>Examples</h5>

          <p><a href="examples/landmarks/navigation.html">Navigation Landmark Example</a></p>
        </section>
      </section>

      <section id="aria_lh_region">
        <h4 class="widget-name">Region</h4>

        <p>A <a class="role-reference" href="#region"><code>region</code></a> landmark is a perceivable section of the page containing content that is sufficiently important for users to be able to navigate to the section.</p>

        <ul>
          <li>A <code>region</code> landmark must have a label.</li>

          <li>If a page includes more than one <code>region</code> landmark, each should have a unique label (see <a href="#aria_lh_step3">Step 3</a> above).</li>

          <li>The <code>region</code> landmark can be used identify content that named landmarks do not appropriately describe.</li>
        </ul>

        <section class="notoc">
          <h5>HTML Technique</h5>

          <p>The HTML <code>section</code> element defines a <code>region</code> landmark when it has an accessible name (e.g. <code>aria-labelledby</code>, <code>aria-label</code> or <code>title</code>).</p>

          <h5>ARIA Technique</h5>

          <p>If the HTML <code>section</code> element technique is not being used, use a <code>role=&quot;region&quot;</code> attribute to define a <code>region</code> landmark.</p>
        </section>

        <section class="notoc">
          <h5>Examples</h5>

          <p><a href="examples/landmarks/region.html">Region Landmark Example</a></p>
        </section>
      </section>

      <section id="aria_lh_search">
        <h4 class="widget-name">Search</h4>

        <p>A <a class="role-reference" href="#search"><code>search</code></a> landmark contains a collection of items and objects that, as a whole, combine to create search functionality.</p>

        <ul>
          <li>Use the <code>search</code> landmark instead of the <code>form</code> landmark when the form is used for search functionality.</li>

          <li>If a page includes more than one <code>search</code> landmark, each should have a unique label (see <a href="#aria_lh_step3">Step 3</a> above).</li>
        </ul>

        <section class="notoc">
          <h5>HTML Technique</h5>
          <p>There is no HTML element that defines a <code>search</code> landmark.</p>

          <h5>ARIA Technique</h5>

          <p>The <code>role=&quot;search&quot;</code> attribute defines a <code>search</code> landmark.</p>
        </section>

        <section class="notoc">
          <h5>Examples</h5>

          <p><a href="examples/landmarks/search.html">Search Landmark Example</a></p>
        </section>
      </section>
    </section>
  </section>

  <section id="names_and_descriptions">
    <h2>Providing Accessible Names and Descriptions</h2>
    <p>
      Providing elements with accessible names, and where appropriate, accessible descriptions is one of the most important responsibilities authors have when developing accessible web experiences.
      While doing so is straightforward for most elements, technical mistakes that can completely block users of assistive technologies are easy to make and unfortunately common.
      To help authors effectively provide accessible names and descriptions, this section explains their purpose, when authors need to provide them, how browsers assemble them, and rules for coding and composing them.
      It also guides authors in the use of the following naming and describing techniques and WAI-ARIA properties:
    </p>
    <ul>
      <li>Naming:
        <ul>
          <li>Naming with child content.</li>
          <li>Naming with a string attribute via <code>aria-label</code>.</li>
          <li>Naming by referencing content with <code>aria-labelledby</code>.</li>
          <li>Naming form controls with the label element.</li>
          <li>Naming fieldsets with the legend element.</li>
          <li>Naming tables and figures with captions.</li>
          <li>Fallback names derived from titles and placeholders.</li>
        </ul>
      </li>
      <li>Describing:
        <ul>
          <li>Describing by referencing content with <code>aria-describedby</code>.</li>
          <li>Describing tables and figures with captions.</li>
          <li>Descriptions derived from titles.</li>
        </ul>
      </li>
    </ul>

    <section id="names_and_descriptions_definition">
      <h3>What ARE Accessible Names and Descriptions?</h3>
      <p>
        An accessible name is a short string, typically 1 to 3 words,  that authors associate with an element to provide users of assistive technologies with a label for the element.
        For example, an input field might have an accessible name of &quot;User ID&quot; or a button might be named &quot;Submit&quot;.
      </p>
      <p>An accessible name serves two primary purposes for users of assistive technologies, such as screen readers:</p>
      <ol>
        <li>Convey the purpose or intent of the element.</li>
        <li>Distinguish the element from other elements on the page.</li>
      </ol>
      <p>
        Both the WAI-ARIA specification and WCAG require all focusable, interactive elements to have an accessible name.
        In addition dialogs and some structural containers, such as <a href="#table" class="role-reference">tables</a> and <a href="#region" class="role-reference">regions</a>, are required to have a name.
        Many other elements can be named, but whether a name will enhance the accessible experience is determined by various characteristics of the surrounding context.
        Finally, there are some elements where providing an accessible name is technically possible but not advisable.
        The <a href="#naming_role_guidance">Accessible Name Guidance by Role</a> section lists naming requirements and guidelines for every ARIA role.
      </p>
      <p>
        An accessible description is also an author-provided string that is rendered by assistive technologies.
        Authors supply a description when there is a need to associate additional information with an element, such as instructions or format requirements for an input field.
      </p>
      <p>
        Assistive technologies present names differently from descriptions.
        For instance, screen readers typically announce the name and role of an element first, e.g., a button named <q>Mute Conversation</q>could be spoken as <q>Mute Conversation button</q>.
        If an element has a state, it could be announced either before or after the name and role; after name and role is the typical default.
         For example, a switch button named <q>Mute Conversation</q> in the <q>off</q> state could be announced as <q>Mute Conversation switch button off</q>.
        Because descriptions are optional strings that are usually significantly longer than names, they are presented last, sometimes after a slight delay.
        For example, <q>Mute Conversation Switch button off, Silences alerts and notifications about activity in this conversation.</q>
        To reduce verbosity, some screen readers do not announce descriptions by default but instead inform users of their presence so that users can press a key that will announce the description.
      </p>
    </section>

    <section id="names_and_descriptions_derivation">
      <h3>How Are Name and Description Strings Derived?</h3>
      <p>
        Because there are several elements and attributes for specifying text to include in an accessible name or description string, and because authors can combine them in a practically endless number of ways, browsers implement fairly complex algorithms for assembling the strings.
The sections on <a href="#name_calculation">accessible name calculation</a> and <a href="#description_calculation">accessible description calculation</a> explain the algorithms and how they implement precedence.
However, most authors do not need such detailed understanding of the algorithms since nearly all circumstances where a name or description is useful are supported by the coding patterns described in the <a href="#naming_techniques">naming techniques</a> and <a href="#describing_techniques">describing techniques</a> sections.
      </p>
    </section>

    <section id="accessible_names">
      <h3>Accessible Names</h3>
      <section id="naming_cardinal_rules">
        <h4>Cardinal Rules of Naming</h4>

        <section id="naming_rule_heed_warnings">
          <h5>Rule 1: Heed Warnings and Test Thoroughly</h5>
          <p>
            Several of the <a href="#naming_techniques">naming techniques</a> below include notes that warn against specific coding patterns that are either prohibited by the ARIA specification or fall into gray space that is not yet fully specified.
            Some of these prohibited or ambiguous patterns may appear logical and even yield desired names in some browsers.
            However, it is unlikely they will provide consistent results across browsers, especially over time as work to improve the consistency of name calculation across browsers progresses.
          </p>
          <p>
            In addition to heeding the warnings provided in the naming techniques, it is difficult to over emphasize the importance of testing to ensure that names browsers calculate match expectations.
          </p>
        </section>

        <section id="naming_rule_visible_text">
          <h5>Rule 2: Prefer Visible Text</h5>
          <p>
            When a user interface includes visible text that could be used to provide an appropriate accessible name, using the visible text for the accessible name simplifies maintenance, prevents bugs, and reduces language translation requirements.
            When names are generated from text that exists only in markup and is never displayed visually, there is a greater likelihood that accessible names will not be updated when the user interface design or content are changed.
          </p>
          <p>
            If an interactive element, such as an input field or button, does not have a visually persistent text label, consider adjusting the design to include one.
            In addition to serving as a more robust source for an accessible name, visible text labels enhance accessibility for many people with disabilities who do not use assistive technologies that present invisible accessible names.
            In most circumstances, visible text labels also make the user interface easier to understand for all users.
          </p>
        </section>

        <section id="naming_rule_native_techniques">
          <h5>Rule 3: Prefer Native Techniques</h5>
          <p>
            In HTML documents, whenever possible, rely on HTML naming techniques, such as the HTML <code>label</code> element for form elements  and <code>caption</code> element for tables.
            While less flexible, their simplicity and reliance on visible text help ensure robust accessible experiences.
            Several of the <a href="#naming_techniques">naming techniques</a> highlight specific accessibility advantages of using HTML features instead of ARIA attributes.
          </p>
        </section>

        <section id="naming_rule_avoid_fallback">
          <h5>Rule 4: Avoid Browser Fallback</h5>
          <p>
            When authors do not specify an accessible name using an element or attribute that is intended for naming, browsers attempt to help assistive technology users by resorting to fallback methods for generating a name.
            For example, the HTML <code>title</code> and <code>placeholder</code> attributes are used as last resort sources of content for accessible names.
            Because the purpose of these attributes is not naming, their content typically yields low quality accessible names that are not effective.
          </p>
        </section>

        <section id="naming_rule_brief_names">
        <h5>Rule 5: Compose Brief, Useful Names</h5>
          <p>
            Similar to how visually crowded screens and ambiguous icons reduce usability, excessively long, insufficiently distinct, or unclear  accessible names can make a user interface very difficult, or even impossible, to use for someone who relies on a non-visual form of the user interface.
            In other words, for a web experience to be accessible, its accessible names must be effective.
            The section on <a href="#naming_effectively">Composing Effective and User-friendly Accessible Names</a> provides guidance for balancing brevity and clarity.
          </p>
        </section>
      </section>

      <section id="naming_techniques">
        <h4>Naming Techniques</h4>

        <section id="naming_with_child_content">
          <h5>Naming with Child Content</h5>
          <p>
            Certain elements get their name from the content they contain.
            For example, the following link is named &quot;Home&quot;.
          </p>

          <pre><code>&lt;a href="/">Home&lt;/a></code></pre>

          <p>
            When assistive technologies render an element that gets its accessible name from its content, such as a link or button, the accessible name is the only content the user can perceive for that element.
            This is in contrast to other elements, such as text fields or tables,  where the accessible name is a label that is presented in addition to the value or content of the element.
            For instance, the accessible name of a table can be derived from a caption element, and assistive technologies render both the caption and all other content contained inside the table.
          </p>
          <p>Elements having one of the following roles are, by default, named by a string calculated from their descendant content:</p>
          <ul>
            <li>button</li>
            <li>cell</li>
            <li>checkbox</li>
            <li>columnheader</li>
            <li>gridcell</li>
            <li>heading</li>
            <li>link</li>
            <li>menuitem (content contained in a child <code>menu</code> element is excluded.)</li>
            <li>menuitemcheckbox</li>
            <li>menuitemradio</li>
            <li>option</li>
            <li>radio</li>
            <li>row</li>
            <li>rowheader</li>
            <li>switch</li>
            <li>tab</li>
            <li>tooltip</li>
            <li>treeitem (content included in a child <code>group</code> element is excluded.)</li>
          </ul>
          <p>
            When calculating a name from content for an element, user agents recursively walk through each of its descendant elements, calculate a name string for each descendant, and concatenate the resulting strings.
            In two special cases, certain descendants are ignored: <code>group</code> descendants of <code>treeitem</code> elements and <code>menu</code> descendants of <code>menuitem</code> elements are omitted from the calculation.
            For example, in the following <code>tree</code>, the name of the first tree item is <q>Fruits</q>; <q>Apples</q>, <q>Bananas</q>, and <q>Oranges</q> are omitted.
          </p>
        <pre><code>&lt;ul role="tree">
  &lt;li role="treeitem">Fruits
    &lt;ul role="group">
      &lt;li role="treeitem">Apples&lt;/li>
      &lt;li role="treeitem">Bananas&lt;/li>
      &lt;li role="treeitem">Oranges&lt;/li>
    &lt;/ul>
  &lt;/li>
&lt;/ul></code></pre>
          <p class="warning">
            If an element with one of the above roles that supports naming from child content is named by using <code>aria-label</code> or <code>aria-labelledby</code>, content contained in the element and its descendants is hidden from assistive technology users unless the descendant content is referenced by <code>aria-labelledby</code>.
            It is strongly recommended to avoid using either of these attributes to override content of one of the above elements except in rare circumstances where hiding content from assistive technology users is beneficial.
            In addition, in situations where visible content is hidden from assistive technology users by use of one of these attributes, thorough testing with assistive technologies is particularly important.
          </p>
        </section>

        <section id="naming_with_aria-label">
          <h5>Naming with a String Attribute Via <code>aria-label</code></h5>
          <p>
            The <a href="#aria-label" class="property-reference">aria-label</a> property enables authors to name an element with a string that is not visually rendered.
            For example, the name of the following button is &quot;Close&quot;.
          </p>
          <pre><code>&lt;button type="button" aria-label="Close">X&lt;/button></code></pre>
          <p>
            The <code>aria-label</code> property is useful when there is no visible text content that will serve as an appropriate accessible name.
          </p>
          <p>
            The <code>aria-label</code> property affects assistive technology users in one of two different ways, depending on the role of the element to which it is applied.
            When applied to an element with one of the roles that supports <a href="#naming_with_child_content">naming from child content</a>, <code>aria-label</code> hides descendant content from assistive technology users and replaces it with the value of <code>aria-label</code>.
            However, when applied to nearly any other type of element, assistive technologies will render both the value of <code>aria-label</code> and the content of the element.
            For example, the name of the following navigation region is &quot;Product&quot;.
          </p>
          <pre><code>&lt;nav aria-label=&quot;Product&quot;&gt;
  &lt;!-- list of navigation links to product pages --&gt;
&lt;/nav&gt;</code></pre>
          <p>
            When encountering this navigation region, a screen reader user will hear the name and role of the element, e.g., &quot;Product navigation region&quot;, and then be able to read through the links contained in the region.
          </p>
          <ol class="warning">
            <li>
          If <code>aria-label</code> is applied to an element with one of the roles that supports <a href="#naming_with_child_content">naming from child content</a>, content contained in the element and its descendants is hidden from assistive technology users.
          It is strongly recommended to avoid using <code>aria-label</code> to override content of one of these elements except in rare circumstances where hiding content from assistive technology users is beneficial.
        </li>
        <li>There are certain types of elements, such as paragraphs and list items, that should not be named with <code>aria-label</code>. They are identified in the table in the <a href="#naming_role_guidance">Accessible Name Guidance by Role</a> section.</li>
            <li>Because the value of <code>aria-label</code> is not rendered visually, testing with assistive technologies to ensure the expected name is presented to users is particularly important.</li>
            <li>When a user interface is translated into multiple languages, ensure that <code>aria-label</code> values are translated.</li>
          </ol>
        </section>

        <section id="naming_with_aria-labelledby">
          <h5>Naming with Referenced Content Via <code>aria-labelledby</code></h5>
          <p>
            The <a href="#aria-labelledby" class="property-reference">aria-labelledby property</a> enables authors to reference other elements on the page to define an accessible name.
            For example, the following switch is named by the text content of a previous sibling element.
          </p>
          <pre><code>&lt;span id="night-mode-label">Night mode&lt;/span&gt;
&lt;span role="switch" aria-checked="false" tabindex="0" aria-labelledby="night-mode-label">&lt;/span&gt;</code></pre>
          <p>
            Note that while using <code>aria-labelledby</code> is similar in this situation to using an HTML <code>label</code> element with the <code>for</code> attribute, one significant difference is that browsers do not automatically make clicking on the labeling element activate the labeled element; that is an author responsibility.
            However, HTML <code>label</code> cannot be used to label a <code>span</code> element.
            Fortunately, an HTML <code>input</code> with <code>type="checkbox"</code> allows the ARIA <code>switch</code> role, so when feasible, using the following approach creates a more robust solution.
          </p>
          <pre><code>&lt;label for="night-mode">Night mode&lt;/label>
&lt;input type="checkbox" role="switch" id="night-mode"></code></pre>
  <p>The <code>aria-labelledby</code> property is useful in a wide variety of situations because:</p>
  <ul>
    <li><p>It has the highest precedence when browsers calculate accessible names, i.e., it overrides names from child content and all other naming attributes, including <code>aria-label</code>.</p></li>
    <li><p>It can concatenate content from multiple elements into a single name string.</p></li>
    <li>
      <p>It incorporates content from elements regardless of their visibility, i.e., it even includes content from elements with the HTML <code>hidden</code> attribute, CSS <code>display: none</code>, or CSS <code>visibility: hidden</code> in the calculated name string.</p>
    </li>
    <li><p>It incorporates the value of input elements, i.e., if it references a textbox, the value of the textbox is included in the calculated name string.</p></li>
  </ul>
  <p>An example of referencing a hidden element with <code>aria-labelledby</code> could be a label for a night switch control:</p>
      <pre><code>&lt;span id="night-mode-label" hidden>Night mode&lt;/span>
&lt;input type="checkbox" role="switch" aria-labelledby="night-mode-label"></code></pre>

          <p>
            In some cases, the most effective name for an element is its own content combined with the content of another element.
            Because <code>aria-labelledby</code> has highest precedence in name calculation, in those situations, it is possible to use <code>aria-labelledby</code> to reference both the element itself and the other element.
            In the following example, the &quot;Read more...&quot; link is named by the element itself and the article’s heading, resulting in a name for the link of &quot;Read more... 7 ways you can help save the bees&quot;.
          </p>
          <pre><code>&lt;h2 id="bees-heading"&gt;7 ways you can help save the bees&lt;/h2&gt;
&lt;p&gt;Bees are disappearing rapidly. Here are seven things you can do to help.&lt;/p&gt;
&lt;p&gt;&lt;a id="bees-read-more" aria-labelledby="bees-read-more bees-heading"&gt;Read more...&lt;/a&gt;&lt;/p&gt;</code></pre>
          <p>
            When multiple elements are referenced by <code>aria-labelledby</code>, text content from each referenced element is concatenated in the order specified in the <code>aria-labelledby</code> value.
            If an element is referenced more than one time, only the first reference is processed.
            When concatenating content from multiple elements, browsers trim leading and trailing white space and separate content from each element with a single space.
          </p>
          <pre><code>&lt;button id="download-button" aria-labelledby="download-button download-details">Download&lt;/button>
&lt;span id="download-details">PDF, 2.4 MB&lt;/span></code></pre>
          <p>In the above example, the accessible name of the button will be "Download PDF, 2.4 MB", with a space between "Download" and "PDF", and not "DownloadPDF, 2.4 MB".</p>
          <ol class="warning">
            <li>The <code>aria-labelledby</code> property cannot be chained, i.e., if an element with <code>aria-labelledby</code> references another element that also has <code>aria-labelledby</code>, the <code>aria-labelledby</code> attribute on the referenced element will be ignored.</li>
            <li>If an element is referenced by <code>aria-labelledby</code> more than one time during a name calculation, the second and any subsequent references will be ignored.</li>
            <li>There are certain types of elements, such as paragraphs and list items,  that should not be named with <code>aria-labelledby</code>. They are identified in the table in the <a href="#naming_role_guidance">Accessible Name Guidance by Role</a> section.</li>
            <li>
          If <code>aria-labelledby</code> is applied to an element with one of the roles that supports <a href="#naming_with_child_content">naming from child content</a>, content contained in the element and its descendants is hidden from assistive technology users unless it is also referenced by <code>aria-labelledby</code>.
          It is strongly recommended to avoid using this attribute to override content of one of these elements except in rare circumstances where hiding content from assistive technology users is beneficial.
        </li>
            <li>Because calculating the name of an element with <code>aria-labelledby</code> can be complex and reference hidden content, testing with assistive technologies to ensure the expected name is presented to users is particularly important.</li>
          </ol>
        </section>

        <section id="naming_with_labels">
          <h5>Naming Form Controls with the Label Element</h5>
          <p>
            The HTML <code>label</code> element enables authors to identify content that serves as a label and associate it with a form control.
            When a <code>label</code> element is associated with a form control, browsers calculate an accessible name for the form control from the <code>label</code> content.
          </p>
          <p>
            For example, text displayed adjacent to a checkbox may be visually associated with the checkbox, so it is understood as the checkbox label by users who can perceive that visual association.
            However, unless the text is programmatically associated with the checkbox, assistive technology users will experience a checkbox without a label.
            Wrapping the checkbox and the labeling text in a <code>label</code> element as follows gives the checkbox an accessible name.
          </p>
          <pre><code>&lt;label>
  &lt;input type="checkbox" name="subscribe">
  subscribe to our newsletter
&lt;/label></code></pre>
          <p>
            A form control can also be associated with a label by using the <code>for</code> attribute on the <code>label</code> element.
            This allows the label and the form control to be siblings or have different parents in the DOM, but requires adding an <code>id</code> attribute to the form control, which can be error-prone.
            When possible, use the above encapsulation technique for association instead of the following <code>for</code> attribute technique.
          </p>
          <pre><code>&lt;input type="checkbox" name="subscribe" id="subscribe_checkbox">
&lt;label for="subscribe_checkbox">subscribe to our newsletter&lt;/label></code></pre>
          <p>
            Using the <code>label</code> element is an effective technique for satisfying <a href="#naming_rule_visible_text">Rule 2: Prefer Visible Text</a>.
            It also satisfies <a href="#naming_rule_native_techniques">Rule 3: Prefer Native Techniques</a>.
            Native HTML labels offer an important usability and accessibility advantage over ARIA labeling techniques: browsers automatically make clicking the label equivalent to clicking the form control.
            This increases the hit area of the form control.
          </p>
        </section>

        <section id="naming_with_legends">
          <h5>Naming Fieldsets with the Legend Element</h5>
          <p>
            The HTML <code>fieldset</code> element can be used to group form controls, and the <code>legend</code> element can be used to give the group a name.
            For example, a group of radio buttons can be grouped together in a <code>fieldset</code>, where the <code>legend</code> element labels the group for the radio buttons.
          </p>
          <pre><code>&lt;fieldset>
  &lt;legend>Select your starter class&lt;/legend>
  &lt;label>&lt;input type="radio" name="starter-class" value="green"> Green&lt;/label>
  &lt;label>&lt;input type="radio" name="starter-class" value="red"> Red&lt;/label>
  &lt;label>&lt;input type="radio" name="starter-class" value="blue"> Blue&lt;/label>
&lt;/fieldset></code></pre>
          <p>
            This grouping technique is particularly useful for presenting multiple choice questions.
            It enables authors to associate a question with a group of answers.
            If a question is not programmatically associated with its answer options, assistive technology users may access the answers without being aware of the question.
          </p>
          <p>
            Similar benefits can be gained from grouping and naming other types of related form fields using <code>fieldset</code> and <code>legend</code>.
          </p>
          <pre><code>&lt;fieldset>
  &lt;legend>Shipping address&lt;/legend>
  &lt;p>&lt;label>Full name &lt;input name="name" required>&lt;/label>&lt;/p>
  &lt;p>&lt;label>Address line 1 &lt;input name="address-1" required>&lt;/label>&lt;/p>
  &lt;p>&lt;label>Address line 2 &lt;input name="address-2">&lt;/label>&lt;/p>
  ...
&lt;/fieldset>
&lt;fieldset>
  &lt;legend>Billing address&lt;/legend>
  ...
&lt;/fieldset></code></pre>
          <p>Using the <code>legend</code> element to name a <code>fieldset</code> element satisfies <a href="#naming_rule_visible_text">Rule 2: Prefer Visible Text</a> and <a href="#naming_rule_native_techniques">Rule 3: Prefer Native Techniques</a>.</p>
        </section>

        <section id="naming_with_captions">
          <h5>Naming Tables and Figures with Captions</h5>
          <p>
            The accessible name for HTML <code>table</code> and <code>figure</code> elements can be derived from a child <code>caption</code> or <code>figcaption</code> element, respectively.
            Tables and figures often have a caption to explain what they are about, how to read them, and sometimes giving them numbers used to refer to them in surrounding prose.
            Captions can help all users better understand content, but are especially helpful to users of assistive technologies.
          </p>
          <p>
            In HTML, the <code>table</code> element marks up a data table, and can be provided with a caption using the <code>caption</code> element.
            If the <code>table</code> element does not have <code>aria-label</code> or <code>aria-labelledby</code>, then the <code>caption</code> will be used as the accessible name.
            For example, the accessible name of the following table is <q>Special opening hours</q>.
          </p>
          <pre><code>&lt;table>
 &lt;caption>Special opening hours&lt;/caption>
 &lt;tr>&lt;td>30 May &lt;td>Closed
 &lt;tr>&lt;td>6 June &lt;td>11:00-16:00
&lt;/table></code></pre>
          <p>The following example gives the table a number (<q>Table 1</q>) so it can be referenced. </p>
          <pre><code>&lt;table>
 &lt;caption>Table 1. Traditional dietary intake of Okinawans and other Japanese circa 1950&lt;/caption>
 &lt;thead>
  &lt;tr>
   &lt;th>
   &lt;th>Okinawa, 1949
   &lt;th>Japan, 1950
 &lt;tbody>
  &lt;tr>
   &lt;th>Total calories
   &lt;td>1785
   &lt;td>2068

  [...]

&lt;/table></code></pre>
          <p>Note: Above table content is from <a href="https://www.ncbi.nlm.nih.gov/pubmed/17986602">Caloric restriction, the traditional Okinawan diet, and healthy aging: the diet of the world's longest-lived people and its potential impact on morbidity and life span</a>.</p>
          <p>
            If a <code>table</code> is named using <code>aria-label</code> or <code>aria-labelledby</code>, then a <code>caption</code> element, if present, will become an accessible description.
            For an example, see <a href="#describing_with_captions">Describing Tables and Figures with Captions</a>.
          </p>
          <p>
            Similarly, an HTML <code>figure</code> element can be given a caption using the <code>figcaption</code> element.
            The caption can appear before or after the figure, but it is more common for figures to have the caption after.
          </p>
          <pre><code>&lt;figure>
 &lt;img alt="Painting of a person walking in a desert." src="Hole_JesusalDesierto.jpg">
 &lt;figcaption>Jesus entering the desert as imagined by William Hole, 1908&lt;/figcaption>
&lt;/figure></code></pre>
          <p>
            Like with <code>table</code> elements, if a <code>figure</code> is not named using <code>aria-label</code> or <code>aria-labelledby</code>, the content of the <code>figcaption</code> element will be used as the accessible name.
            However unlike <code>table</code> elements, if the <code>figcaption</code> element is not used for the name, it does not become an accessible description unless it is referenced by <code>aria-describedby</code>.
            Nevertheless, assistive technologies will render the content of a <code>figcaption</code> regardless of whether it is used as a name, description, or neither.
          </p>
          <p>Using the <code>caption</code> element to name a <code>table</code> element, or a <code>figcaption</code> element to name a <code>figure</code> element, satisfies <a href="#naming_rule_visible_text">Rule 2: Prefer Visible Text</a> and <a href="#naming_rule_native_techniques">Rule 3: Prefer Native Techniques</a>.</p>
        </section>

        <section id="naming_with_fallback">
          <h5>Fallback Names Derived from Titles and Placeholders</h5>
          <p>
            When an accessible name is not provided using one of the primary techniques (e.g., the <code>aria-label</code> or <code>aria-labelledby</code> attributes), or native markup techniques (e.g., the HTML <code>label</code> element, or the <code>alt</code> attribute of the HTML <code>img</code> element), browsers calculate an accessible name from other attributes as a fallback mechanism.
            Because the attributes used in fallback name calculation are not intended for naming, they typically yield low quality accessible names that are not effective.
So, As advised by <a href="#naming_rule_avoid_fallback">Rule 4: Avoid Browser Fallback</a>, prefer the explicit labeling techniques described above over fallback techniques described in this section.
          </p>

          <p>
            Any HTML element can have a <code>title</code> attribute specified.
            The <code>title</code> attribute may be used as the element's fallback accessible name.
            The <code>title</code> attribute is commonly presented visually as a tooltip when the user hovers over the element with a pointing device, which is not particularly discoverable, and is also not accessible to visual users without a pointing device.
          </p>

          <p>For example, a <code>fieldset</code> element without a <code>legend</code> element child, but with a <code>title</code> attribute, gets its accessible name from the <code>title</code> attribute.</p>

          <pre><code>&lt;fieldset title="Select your starter class">
  &lt;label>&lt;input type="radio" name="starter-class" value="green"> Green&lt;/label>
  &lt;label>&lt;input type="radio" name="starter-class" value="red"> Red&lt;/label>
  &lt;label>&lt;input type="radio" name="starter-class" value="blue"> Blue&lt;/label>
&lt;/fieldset></code></pre>

          <p>
            For the HTML <code>input</code> and <code>textarea</code> elements, the <code>placeholder</code> attribute is used as a fallback labeling mechanism if nothing else (including the <code>title</code> attribute) results in a label.
            It is better to use a <code>label</code> element, since it does not disappear visually when the user focuses the form control.
          </p>

          <pre><code>&lt;!-- Using a &lt;label> is recommended -->
&lt;label>Search &lt;input type=search name=q>&lt;/label>

&lt;!-- A placeholder is used as fallback -->
&lt;input type=search name=q placeholder="Search"></code></pre>
        </section>
      </section>

      <section id="naming_effectively">
        <h4>Composing Effective and User-friendly Accessible Names</h4>
        <p>
          For assistive technology users, especially screen reader users, the quality of accessible names is one of the most  significant contributors to usability.
          Names that do not provide enough information reduce users' effectiveness while names that are too long reduce efficiency.
          And, names that are difficult to understand reduce effectiveness, efficiency, and enjoyment.
        </p>
        <p>The following guidelines provide a starting point for crafting user friendly names.</p>
        <ul>
          <li>
            Convey function or purpose, not form.
            For example, if an icon that looks like the letter <q>X</q> closes a dialog, name it <q>Close</q>, not <q>X</q>.
            Similarly, if a set of navigation links in the left side bar navigate among the product pages in a shopping site, name the navigation region <q>Product</q>, not <q>Left</q>.
          </li>
          <li>
            Put the most distinguishing and important words first.
            Often, for interactive elements that perform an action, this means a verb is the first word.
            For instance, if a list of contacts displays <q>Edit</q>, <q>Delete</q>, and <q>Actions</q> buttons for each contact,
            then <q>Edit John Doe</q>, <q>Delete John Doe</q>, and <q>Actions for John Doe</q> would be better accessible names than <q>John Doe edit</q>, <q>John Doe delete</q>, and <q>John Doe actions</q>.
            By placing the verb first in the name, screen reader users can more easily and quickly distinguish the buttons from one another as well as from the element that opens the contact card for John Doe.
          </li>
          <li>
            Be concise. For many elements, one to three words is sufficient.
            Only add more words when necessary.
          </li>
          <li>
            Do NOT include a WAI-ARIA role name in the accessible name.
            For example, do not include the word <q>button</q> in the name of a button, the word <q>image</q> in the name of an image, or the word <q>navigation</q> in the name of a navigation region.
            Doing so would create duplicate screen reader output since screen readers convey the role of an element in addition to its name.
          </li>
          <li>
            Create unique names for elements with the same role unless the elements are actually identical.
            For example, ensure every link on a page has a different name except in cases where multiple links reference the same location.
            Similarly, give every navigation region on a page a different name unless there are regions with identical content that performs identical navigation functions.
          </li>
          <li>
            Start names with a capital letter; it helps some screen readers speak them with appropriate inflection.
            Do not end names with a period; they are not sentences.
          </li>
        </ul>
      </section>

      <section id="naming_role_guidance">
        <h4><span id="naming_role_guidance_heading">Accessible Name Guidance by Role</span></h4>
        <p>
          Certain elements always require a name, others may usually or sometimes require a name, and still others should never be named.
          The table below lists all ARIA roles and provides the following information for each :
        </p>
        <dl>
          <dt>Necessity of Naming</dt>
          <dd>
            Indicates how necessary it is for authors to add a naming attribute or element to supplement or override the content of an element with the specified role.
            This column may include one of the following values:
            <ul>
              <li>
                Required <strong>Only If</strong> Content Insufficient: An element with this role is named by its descendant content.
                If <code>aria-label</code> or <code>aria-labelledby</code> is applied, content contained in the element and its descendants is hidden from assistive technology users unless it is also referenced by <code>aria-labelledby</code>.
                Avoid hiding descendant content except in the rare circumstances where doing so benefits assistive technology users.
              </li>
              <li>Required: The ARIA specification requires authors to provide a name; a missing name causes accessibility validators to report an error.</li>
              <li>Recommended: Providing a name is strongly recommended.</li>
              <li>Discretionary: Naming is either optional or, in the circumstances described in the guidance column, is discouraged.</li>
              <li>Do Not Name: Naming is strongly discouraged even if it is technically permitted; often assistive technologies do not render a name even if provided.</li>
              <li>Prohibited: The ARIA specification does not permit the element to be named; If a name is specified, accessibility validators will report an error.</li>
            </ul>
          </dd>
          <dt>Guidance:</dt>
          <dd>
            Provides information to help determine if providing a name is beneficial, and if so, describes any recommended techniques.
          </dd>
        </dl>
        <table aria-labelledby="naming_role_guidance_heading">
          <thead>
            <tr>
              <th>role</th>
              <th>Necessity of Naming</th>
              <th>Guidance</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td><a href="#alert" class="role-reference"><code>alert</code></a></td>
              <td>Discretionary</td>
              <td>
                Some screen readers announce the name of an alert before announcing the content of the alert.
                Thus, <code>aria-label</code> provides a method for prefacing the visible content of an alert with text that is not displayed as part of the alert.
                Using <code>aria-label</code> is functionally equivalent to providing off-screen text in the contents of the alert, except off-screen text would be announced by screen readers that do not support <code>aria-label</code> on <code>alert</code> elements.
              </td>
            </tr>
            <tr>
              <td><a href="#alertdialog" class="role-reference"><code>alertdialog</code></a></td>
              <td>Required</td>
              <td>Use <code>aria-labelledby</code> if a visible label is present, otherwise use <code>aria-label</code>.</td>
          </tr>
            <tr>
              <td><a href="#application" class="role-reference"><code>application</code></a></td>
              <td>Required</td>
              <td>Use <code>aria-labelledby</code> if a visible label is present, otherwise use <code>aria-label</code>.</td>
            </tr>
            <tr>
              <td><a href="#article" class="role-reference"><code>article</code></a></td>
              <td>Recommended</td>
              <td>
                <ul>
                  <li>Recommended to distinguish articles from one another; helps users when navigating among articles.</li>
                  <li>Use <code>aria-labelledby</code> if a visible label is present, otherwise use <code>aria-label</code>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#banner" class="role-reference"><code>banner</code></a></td>
              <td>Discretionary</td>
              <td>
                <ul>
                  <li>Necessary in the uncommon circumstance where two banner landmark regions are present on the same page. It is otherwise optional.</li>
                  <li>Named using <code>aria-labelledby</code> if a visible label is present, otherwise with <code>aria-label</code>.</li>
                  <li>See the <a href="#aria_lh_banner">Banner Landmark</a> section.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#blockquote" class="role-reference"><code>blockquote</code></a></td>
              <td>Discretionary</td>
              <td>
                If a visible label is present, associating it with the blockquote by using <code>aria-labelledby</code> could benefit some assistive technology users.
              </td>
            </tr>
            <tr>
              <td><a href="#button" class="role-reference"><code>button</code></a></td>
              <td>Required <strong>Only If</strong> Content Insufficient</td>
              <td>
                <ul>
                  <li>Warning! Using <code>aria-label</code> or <code>aria-labelledby</code> will hide descendant content from assistive technologies.</li>
                  <li>Ideally named by visible, descendant content.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#caption" class="role-reference"><code>caption</code></a></td>
              <td>Prohibited</td>
              <td></td>
            </tr>
            <tr>
              <td><a href="#cell" class="role-reference"><code>cell</code></a></td>
              <td>Required <strong>Only If</strong> Content Insufficient</td>
              <td>
                <ul>
                  <li>Warning! Using <code>aria-label</code> or <code>aria-labelledby</code> will hide descendant content from assistive technologies.</li>
                  <li>Ideally named by visible, descendant content.</li>
                  <li>Note that a name is not required; assistive technologies expect an empty cell in a table to be represented by an empty name.</li>
                  <li>Note that associated row or column headers do not name a <code>cell</code>; the name of a cell in a table is its content. Headers are complementary information.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#checkbox" class="role-reference"><code>checkbox</code></a></td>
              <td>Required <strong>Only If</strong> Content Insufficient</td>
              <td>
                <ul>
                  <li>Warning! Using <code>aria-label</code> or <code>aria-labelledby</code> will hide any descendant content from assistive technologies.</li>
                  <li>If based on HTML <code>type="checkbox"</code>, use a <code>label</code> element.</li>
                  <li>Otherwise, reference visible content via <code>aria-labelledby</code>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#code" class="role-reference"><code>code</code></a></td>
              <td>Prohibited</td>
              <td></td>
            </tr>
            <tr>
              <td><a href="#columnheader" class="role-reference"><code>columnheader</code></a></td>
              <td>Required <strong>Only If</strong> Content Insufficient</td>
              <td>
                <ul>
                  <li>Warning! Using <code>aria-label</code> or <code>aria-labelledby</code> will hide descendant content from assistive technologies.</li>
                  <li>Ideally named by visible, descendant content.</li>
                  <li>If the <code>columnheader</code> role is implied from an HTML <code>th</code>, the HTML <code>abbr</code> attribute can be used to specify an abbreviated version of the name that is only announced when screen readers are reading an associated <code>cell</code> within the <code>table</code>, <code>grid</code>, or <code>treegrid</code>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#combobox" class="role-reference"><code>combobox</code></a></td>
              <td>Required</td>
              <td>
                <ul>
                  <li>If the <code>combobox</code> role is applied to an HTML <code>select</code> or <code>input</code> element, can be named with an HTML <code>label</code> element.</li>
                  <li>Otherwise use <code>aria-labelledby</code> if a visible label is present.</li>
                  <li>Use <code>aria-label</code> if a visible label is not present.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#complementary" class="role-reference"><code>complementary</code></a></td>
              <td>Recommended</td>
              <td>
                <ul>
                  <li>Naming is necessary when two complementary landmark regions are present on the same page.</li>
                  <li>Naming is recommended even when one complementary region is present to help users understand the purpose of the region's content when navigating among landmark regions.</li>
                  <li>Use <code>aria-labelledby</code> if a visible label is present, otherwise use <code>aria-label</code>.</li>
                  <li>See the <a href="#aria_lh_complementary">Complementary Landmark</a> section.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#contentinfo" class="role-reference"><code>contentinfo</code></a></td>
              <td>Discretionary</td>
              <td>
                <ul>
                  <li>Necessary in the uncommon circumstance where two contentinfo landmark regions are present on the same page. It is otherwise optional.</li>
                  <li>Named using <code>aria-labelledby</code> if a visible label is present, otherwise with <code>aria-label</code>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#definition" class="role-reference"><code>definition</code></a></td>
              <td>Recommended</td>
              <td>Reference the term being defined with <code>role="term"</code>, using <code>aria-labelledby</code>.</td>
            </tr>
            <tr>
              <td><a href="#deletion" class="role-reference"><code>deletion</code></a></td>
              <td>Prohibited</td>
              <td></td>
            </tr>
            <tr>
              <td><a href="#dialog" class="role-reference"><code>dialog</code></a></td>
              <td>Required</td>
              <td>Use <code>aria-labelledby</code> if a visible label is present, otherwise use <code>aria-label</code>.</td>
            </tr>
            <tr>
              <td><a href="#directory" class="role-reference"><code>directory</code></a></td>
              <td>Discretionary</td>
              <td>
                <ul>
                  <li>Naming can help users understand the purpose of the directory.</li>
                  <li>Use <code>aria-labelledby</code> if a visible label is present, otherwise use <code>aria-label</code>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#document" class="role-reference"><code>document</code></a></td>
              <td>Discretionary</td>
              <td>
                Elements with the <code>document</code> role are contained within an element with the <code>application</code> role, which is required to have a name.
                Typically, the name of the <code>application</code> element will provide sufficient context and identity for the <code>document</code> element.
                Because the <code>application</code> element is used only to create unusual, custom widgets, careful assessment is necessary to determine whether or not adding an accessible name is beneficial.
              </td>
            </tr>
            <tr>
              <td><a href="#emphasis" class="role-reference"><code>emphasis</code></a></td>
              <td>Prohibited</td>
              <td></td>
            </tr>
            <tr>
              <td><a href="#feed" class="role-reference"><code>feed</code></a></td>
              <td>Recommended</td>
              <td>
                <ul>
                  <li>Helps screen reader users understand the context and purpose of the feed.</li>
                  <li>Use <code>aria-labelledby</code> if a visible label is present, otherwise use <code>aria-label</code>.</li>
                  <li>See the <a href="#feed">Feed Design Pattern</a>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#figure" class="role-reference"><code>figure</code></a></td>
              <td>Recommended</td>
              <td>
                <ul>
                  <li>For HTML, use the <code>figure</code> and <code>figcaption</code> elements. The <code>figcaption</code> will serve as the accessible name for the <code>figure</code>. See the <a href="#naming_with_captions">Naming Tables and Figures with Captions</a> section.</li>
                  <li>When not using HTML, or when retrofitting legacy HTML, use the <code>aria-labelledby</code> on the figure, pointing to the figure's caption.</li>
                  <li>If there is no visible caption, <code>aria-label</code> can be used.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#form" class="role-reference"><code>form</code></a></td>
              <td>Recommended</td>
              <td>
                <ul>
                  <li>Helps screen reader users understand the context and purpose of the form landmark.</li>
                  <li>Use <code>aria-labelledby</code> if a visible label is present, otherwise use <code>aria-label</code>.</li>
                  <li>See the <a href="#aria_lh_form">Form Landmark</a> section.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#generic" class="role-reference"><code>generic</code></a></td>
              <td>Prohibited</td>
              <td></td>
            </tr>
            <tr>
              <td><a href="#grid" class="role-reference"><code>grid</code></a></td>
              <td>Required</td>
              <td>
                <ul>
                  <li>If the <code>grid</code> is applied to an HTML <code>table</code> element, then the accessible name can be derived from the table's <code>caption</code> element.</li>
                  <li>Otherwise, use <code>aria-labelledby</code> if a visible label is present, otherwise use <code>aria-label</code>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#gridcell" class="role-reference"><code>gridcell</code></a></td>
              <td>Required <strong>Only If</strong> Content Insufficient</td>
              <td>
                <ul>
                  <li>Warning! Using <code>aria-label</code> or <code>aria-labelledby</code> will hide descendant content from assistive technologies.</li>
                  <li>Ideally named by visible, descendant content.</li>
                  <li>Note that a name is not required; assistive technologies expect an empty cell in a grid to be represented by an empty name.</li>
                  <li>Note that associated row or column headers do not name a <code>gridcell</code>; the name of a cell in a grid is its content. Headers are complementary information.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#group" class="role-reference"><code>group</code></a></td>
              <td>Discretionary</td>
              <td>
                <ul>
                  <li>When using the HTML <code>fieldset</code> element, the accessible name can be derived from the <code>legend</code> element.</li>
                  <li>When using the HTML <code>details</code> element, do not provide an accessible name for this element. The user interacts with the <code>summary</code> element, and that can derive its accessible name from its contents.</li>
                  <li>When using the HTML <code>optgroup</code> element, use the <code>label</code> attribute.</li>
                  <li>Otherwise, use <code>aria-labelledby</code> if a visible label is present, otherwise use <code>aria-label</code>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#heading" class="role-reference"><code>heading</code></a></td>
              <td>Required <strong>Only If</strong> Content Insufficient</td>
              <td>
                <ul>
                  <li>Warning! Using <code>aria-label</code> or <code>aria-labelledby</code> will hide descendant content from assistive technologies.</li>
                  <li>Ideally named by visible, descendant content.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#insertion" class="role-reference"><code>insertion</code></a></td>
              <td>Prohibited</td>
              <td></td>
            </tr>
            <tr>
              <td><a href="#img" class="role-reference"><code>img</code></a></td>
              <td>Required</td>
              <td>For the HTML <code>img</code> element, use the <code>alt</code> attribute. For other elements with the <code>img</code> role, use <code>aria-labelledby</code> or <code>aria-label</code>.</td>
            </tr>
            <tr>
              <td><a href="#link" class="role-reference"><code>link</code></a></td>
              <td>Required <strong>Only If</strong> Content Insufficient</td>
              <td>
                <ul>
                  <li>Warning! Using <code>aria-label</code> or <code>aria-labelledby</code> will hide descendant content from assistive technologies.</li>
                  <li>Ideally named by visible, descendant content.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#list" class="role-reference"><code>list</code></a></td>
              <td>Discretionary</td>
              <td>
                <ul>
                  <li>Potentially beneficial for users of screen readers that support both list names and navigation among lists on a page.</li>
                  <li>Potentially a source of distracting or undesirable screen reader verbosity, especially if nested within a named container, such as a navigation region.</li>
                  <li>Can be named using <code>aria-labelledby</code> if a visible label is present, otherwise with <code>aria-label</code>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#listbox" class="role-reference"><code>listbox</code></a></td>
              <td>Required</td>
              <td>
                <ul>
                  <li>If the <code>listbox</code> role is applied to an HTML <code>select</code> element (with the <code>multiple</code> attribute or a <code>size</code> attribute having a value greater than 1), can be named with an HTML <code>label</code> element.</li>
                  <li>Otherwise use <code>aria-labelledby</code> if a visible label is present.</li>
                  <li>Use <code>aria-label</code> if a visible label is not present.</li>
                  <li>See the <a href="#Listbox">Listbox Design Pattern</a>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#listitem" class="role-reference"><code>listitem</code></a></td>
              <td>Do Not Name</td>
              <td>Naming is not supported by assistive technologies; it is necessary to include relevant content within the list item.</td>
            </tr>
            <tr>
              <td><a href="#log" class="role-reference"><code>log</code></a></td>
              <td>Discretionary</td>
              <td>
                Some screen readers announce the name of a log element before announcing the content of the log element.
                Thus, <code>aria-label</code> provides a method for prefacing the visible content of a log element with text that is not displayed as part of the log element.
                Using <code>aria-label</code> is functionally equivalent to providing off-screen text in the contents of the log element, except off-screen text would be announced by screen readers that do not support <code>aria-label</code> on <code>log</code> elements.
              </td>
            </tr>
            <tr>
              <td><a href="#main" class="role-reference"><code>main</code></a></td>
              <td>Discretionary</td>
              <td>
                <ul>
                  <li>Potentially helpful for orienting assistive technology users, especially in single-page applications where main content changes happen without generating a page load event.</li>
                  <li>Can be named using <code>aria-labelledby</code> if a visible label is present, otherwise with <code>aria-label</code>.</li>
                  <li>See the <a href="#aria_lh_main">Main Landmark</a> section.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#marquee" class="role-reference"><code>marquee</code></a></td>
              <td>Discretionary</td>
              <td>Use <code>aria-labelledby</code> if a visible label is present, otherwise use <code>aria-label</code>.</td>
            </tr>
            <tr>
              <td><a href="#math" class="role-reference"><code>math</code></a></td>
              <td>Recommended</td>
              <td>
                <ul>
                  <li>If the <code>math</code> element has only presentational children and the accessible name is intended to convey the mathematical expression, use <code>aria-label</code> to provide a string that represents the expression.</li>
                  <li>If the <code>math</code> element contains navigable content that conveys the mathematical expression and a visible label for the expression is present, use <code>aria-labelledby</code>.</li>
                  <li>Otherwise, use a<code>aria-label</code> to name the expression, e.g., <code>aria-label="Pythagorean Theorem"</code>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#menu" class="role-reference"><code>menu</code></a></td>
              <td>Recommended</td>
              <td>
                <ul>
                  <li>Use <code>aria-labelledby</code> to refer to the menuitem or button that controls this element's display.</li>
                  <li>Otherwise, use <code>aria-label</code>.</li>
                  <li>See the <a href="#menu">Menu or Menu bar Design Pattern</a>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#menubar" class="role-reference"><code>menubar</code></a></td>
              <td>Recommended</td>
              <td>
                <ul>
                  <li>
                    Helps screen reader users understand the context and purpose of <code>menuitem</code> elements in a <code>menubar</code>.
                    Naming a <code>menubar</code> is comparable to naming a menu button.
                    The name of a <code>button</code> that opens a <code>menu</code> conveys the purpose of the menu it opens.
                    Since a <code>menubar</code> element is displayed persistently, a name on the <code>menubar</code> can serve that same purpose.
                  </li>
                  <li>Use <code>aria-labelledby</code> if a visible label is present, otherwise use <code>aria-label</code>.</li>
                  <li>See the <a href="#menu">Menu or Menu bar Design Pattern</a>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#menuitem" class="role-reference"><code>menuitem</code></a></td>
              <td>Required <strong>Only If</strong> Content Insufficient</td>
              <td>
                <ul>
                  <li>Warning! Using <code>aria-label</code> or <code>aria-labelledby</code> will hide any descendant content from assistive technologies.</li>
                  <li>Ideally named by visible, descendant content.</li>
                  <li>Note: content contained within a child <code>menu</code> is automatically excluded from the accessible name calculation.</li>
                  <li>See the <a href="#menu">Menu or Menu bar Design Pattern</a>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#menuitemcheckbox" class="role-reference"><code>menuitemcheckbox</code></a></td>
              <td>Required <strong>Only If</strong> Content Insufficient</td>
              <td>
                <ul>
                  <li>Warning! Using <code>aria-label</code> or <code>aria-labelledby</code> will hide any descendant content from assistive technologies.</li>
                  <li>Ideally named by visible, descendant content.</li>
                  <li>See the <a href="#menu">Menu or Menu bar Design Pattern</a>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#menuitemradio" class="role-reference"><code>menuitemradio</code></a></td>
              <td>Required <strong>Only If</strong> Content Insufficient</td>
              <td>
                <ul>
                  <li>Warning! Using <code>aria-label</code> or <code>aria-labelledby</code> will hide any descendant content from assistive technologies.</li>
                  <li>Ideally named by visible, descendant content.</li>
                  <li>See the <a href="#menu">Menu or Menu bar Design Pattern</a>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#meter" class="role-reference"><code>meter</code></a></td>
              <td>Required</td>
              <td>
                <ul>
                  <li>If based on an HTML <code>meter</code> element, can be named with an HTML <code>label</code> element.</li>
                  <li>Otherwise use <code>aria-labelledby</code> if a visible label is present.</li>
                  <li>Use <code>aria-label</code> if a visible label is not present.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#navigation" class="role-reference"><code>navigation</code></a></td>
              <td>Recommended</td>
              <td>
                <ul>
                  <li>Helps screen reader users understand the context and purpose of the navigation landmark.</li>
                  <li>Use <code>aria-labelledby</code> if a visible label is present, otherwise use <code>aria-label</code>.</li>
                  <li>See the <a href="#aria_lh_navigation">Navigation Landmark</a> section.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#none" class="role-reference"><code>none</code></a></td>
              <td>Prohibited</td>
              <td>An element with <code>role="none"</code> is not part of the accessibility tree (except in error cases). Do not use <code>aria-labelledby</code> or <code>aria-label</code>.</td>
            </tr>
            <tr>
              <td><a href="#note" class="role-reference"><code>note</code></a></td>
              <td>Discretionary</td>
              <td>
                <ul>
                  <li>Naming is optional, but can help screen reader users understand the context and purpose of the note.</li>
                  <li>Named using <code>aria-labelledby</code> if a visible label is present, otherwise with <code>aria-label</code>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#option" class="role-reference"><code>option</code></a></td>
              <td>Required <strong>Only If</strong> Content Insufficient</td>
              <td>
                <ul>
                  <li>Warning! Using <code>aria-label</code> or <code>aria-labelledby</code> will hide any descendant content from assistive technologies.</li>
                  <li>Ideally named by visible, descendant content.</li>
                  <li>See the <a href="#combobox">Combobox Design Pattern</a>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#paragraph" class="role-reference"><code>paragraph</code></a></td>
              <td>Prohibited</td>
              <td></td>
            </tr>
            <tr>
              <td><a href="#presentation" class="role-reference"><code>presentation</code></a></td>
              <td>Prohibited</td>
              <td>An element with <code>role="presentation"</code> is not part of the accessibility tree (except in error cases). Do not use <code>aria-labelledby</code> or <code>aria-label</code>.</td>
            </tr>
            <tr>
              <td><a href="#progressbar" class="role-reference"><code>progressbar</code></a></td>
              <td>Required</td>
              <td>
                <ul>
                  <li>If the <code>progressbar</code> role is applied to an HTML <code>progress</code> element, can be named with an HTML <code>label</code> element.</li>
                  <li>Otherwise use <code>aria-labelledby</code> if a visible label is present.</li>
                  <li>Use <code>aria-label</code> if a visible label is not present.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#radio" class="role-reference"><code>radio</code></a></td>
              <td>Required <strong>Only If</strong> Content Insufficient</td>
              <td>
                <ul>
                  <li>Warning! Using <code>aria-label</code> or <code>aria-labelledby</code> will hide any descendant content from assistive technologies.</li>
                  <li>If based on HTML <code>type="checkbox"</code>, use a <code>label</code> element.</li>
                  <li>Otherwise, reference visible content via <code>aria-labelledby</code>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#radiogroup" class="role-reference"><code>radiogroup</code></a></td>
              <td>Required</td>
              <td>
                <ul>
                  <li>Recommended to help assistive technology users understand the purpose of the group of <code>radio</code> buttons.</li>
                  <li>Use <code>aria-labelledby</code> if a visible label is present, otherwise use <code>aria-label</code>.</li>
                  <li>See the <a href="#radiobutton">Radio Group Design Pattern</a>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#region" class="role-reference"><code>region</code></a></td>
              <td>Required</td>
              <td>
                <ul>
                  <li>Helps screen reader users understand the context and purpose of the landmark.</li>
                  <li>Use <code>aria-labelledby</code> if a visible label is present, otherwise use <code>aria-label</code>.</li>
                  <li>See the <a href="#aria_lh_region">Region Landmark</a> section.</li>
                </ul>
            </td>
            </tr>
            <tr>
              <td><a href="#row" class="role-reference"><code>row</code></a></td>
              <td>
                Required <strong>Only If</strong> Content Insufficient
                <strong>AND</strong> descendant of a <code>treegrid</code>
                <strong>AND</strong> the row is focusable
              </td>
              <td>
                When <code>row</code> elements are focusable in a <a href="#treegrid">treegrid</a>, screen readers announce the entire contents of a row when navigating by row.
                This is typically the most appropriate behavior.
                However, in some circumstances, it could be beneficial to change the order in which cells are announced or exclude announcement of certain cells by using <code>aria-labelledby</code> to specify which cells to announce.
              </td>
            </tr>
            <tr>
              <td><a href="#rowgroup" class="role-reference"><code>rowgroup</code></a></td>
              <td>Do Not Name</td>
              <td>Naming is not supported by assistive technologies.</td>
            </tr>
            <tr>
              <td><a href="#rowheader" class="role-reference"><code>rowheader</code></a></td>
              <td>Required <strong>Only If</strong> Content Insufficient</td>
              <td>
                <ul>
                  <li>Warning! Using <code>aria-label</code> or <code>aria-labelledby</code> will hide descendant content from assistive technologies.</li>
                  <li>Ideally named by visible, descendant content.</li>
                  <li>If the <code>rowheader</code> role is implied from an HTML <code>th</code>, the HTML <code>abbr</code> attribute can be used to specify an abbreviated version of the name that is only announced when screen readers are reading an associated <code>cell</code> within the <code>table</code>, <code>grid</code>, or <code>treegrid</code>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#scrollbar" class="role-reference"><code>scrollbar</code></a></td>
              <td>Discretionary</td>
              <td>
                <ul>
                  <li>Naming is optional, but can potentially help screen reader users understand the purpose of the scrollbar. The purpose is also conveyed using the <code>aria-controls</code> attribute, which is required for <code>scrollbar</code>.</li>
                  <li>Named using <code>aria-labelledby</code> if a visible label is present, otherwise with <code>aria-label</code>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#search" class="role-reference"><code>search</code></a></td>
              <td>Recommended</td>
              <td>
                <ul>
                  <li>Helps screen reader users understand the context and purpose of the search landmark.</li>
                  <li>Named using <code>aria-labelledby</code> if a visible label is present, otherwise with <code>aria-label</code>.</li>
                  <li>See the <a href="#aria_lh_search">Search Landmark</a> section.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#searchbox" class="role-reference"><code>searchbox</code></a></td>
              <td>Required</td>
              <td>
                <ul>
                  <li>If the <code>searchbox</code> role is applied to an HTML <code>input</code> element, can be named with an HTML <code>label</code> element.</li>
                  <li>Otherwise use <code>aria-labelledby</code> if a visible label is present.</li>
                  <li>Use <code>aria-label</code> if a visible label is not present.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#separator" class="role-reference"><code>separator</code></a></td>
              <td>Discretionary</td>
              <td>
                <ul>
                  <li>Recommended if there is more than one focusable <code>separator</code> element on the page.</li>
                  <li>Can help assistive technology users understand the purpose of the separator.</li>
                  <li>Named using <code>aria-labelledby</code> if a visible label is present, otherwise with <code>aria-label</code>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#slider" class="role-reference"><code>slider</code></a></td>
              <td>Required</td>
              <td>
                <ul>
                  <li>If the <code>slider</code> role is applied to an HTML <code>input</code> element, can be named with an HTML <code>label</code> element.</li>
                  <li>Otherwise use <code>aria-labelledby</code> if a visible label is present.</li>
                  <li>Use <code>aria-label</code> if a visible label is not present.</li>
                  <li>See the <a href="#slider">Slider Design Pattern</a> and the <a href="#slidertwothumb">Slider (Multi-Thumb) Design Pattern</a>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#spinbutton" class="role-reference"><code>spinbutton</code></a></td>
              <td>Required</td>
              <td>
                <ul>
                  <li>If the <code>textbox</code> role is applied to an HTML <code>input</code> element, can be named with an HTML <code>label</code> element.</li>
                  <li>Otherwise use <code>aria-labelledby</code> if a visible label is present.</li>
                  <li>Use <code>aria-label</code> if a visible label is not present.</li>
                  <li>See the <a href="#spinbutton">Spinbutton Design Pattern</a>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#status" class="role-reference"><code>status</code></a></td>
              <td>Discretionary</td>
              <td>
                Some screen readers announce the name of a status element before announcing the content of the status element.
                Thus, <code>aria-label</code> provides a method for prefacing the visible content of a status element with text that is not displayed as part of the status element.
                Using <code>aria-label</code> is functionally equivalent to providing off-screen text in the contents of the status element, except off-screen text would be announced by screen readers that do not support <code>aria-label</code> on <code>status</code> elements.
              </td>
            </tr>
            <tr>
              <td><a href="#strong" class="role-reference"><code>strong</code></a></td>
              <td>Prohibited</td>
              <td></td>
            </tr>
            <tr>
              <td><a href="#subscript" class="role-reference"><code>subscript</code></a></td>
              <td>Prohibited</td>
              <td></td>
            </tr>
            <tr>
              <td><a href="#superscript" class="role-reference"><code>superscript</code></a></td>
              <td>Prohibited</td>
              <td></td>
            </tr>
            <tr>
              <td><a href="#switch" class="role-reference"><code>switch</code></a></td>
              <td>Required <strong>Only If</strong> Content Insufficient</td>
              <td>
                <ul>
                  <li>Warning! Using <code>aria-label</code> or <code>aria-labelledby</code> will hide any descendant content from assistive technologies.</li>
                  <li>If based on HTML <code>type="checkbox"</code>, use a <code>label</code> element.</li>
                  <li>Otherwise, reference visible content via <code>aria-labelledby</code>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#tab" class="role-reference"><code>tab</code></a></td>
              <td>Required <strong>Only If</strong> Content Insufficient</td>
              <td>
                <ul>
                  <li>Warning! Using <code>aria-label</code> or <code>aria-labelledby</code> will hide descendant content from assistive technologies.</li>
                  <li>Ideally named by visible, descendant content.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#table" class="role-reference"><code>table</code></a></td>
              <td>Required</td>
              <td>
                <ul>
                  <li>If using HTML <code>table</code> element, use the <code>caption</code> element.</li>
                  <li>Otherwise use <code>aria-labelledby</code> if a visible label is present.</li>
                  <li>Use <code>aria-label</code> if a visible label is not present.</li>
                  <li>See the <a href="#table">Table Design Pattern</a>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#tablist" class="role-reference"><code>tablist</code></a></td>
              <td>Recommended</td>
              <td>
                <ul>
                  <li>Helps screen reader users understand the context and purpose of the tablist.</li>
                  <li>Use <code>aria-labelledby</code> if a visible label is present, otherwise use <code>aria-label</code>.</li>
                  <li>See the <a href="#carousel">Carousel Design Pattern</a> and <a href="#tabpanel">Tabs Design Pattern</a>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#tabpanel" class="role-reference"><code>tabpanel</code></a></td>
              <td>Required</td>
              <td>
                <ul>
                  <li>Use <code>aria-labelledby</code> pointing to the <code>tab</code> element that controls the <code>tabpanel</code>.</li>
                  <li>See the <a href="#carousel">Carousel Design Pattern</a> and <a href="#tabpanel">Tabs Design Pattern</a>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#term" class="role-reference"><code>term</code></a></td>
              <td>Do Not Name</td>
              <td>Since a term is usually the name for the <code>role="definition"</code> element, it could be confusing if the term itself also has a name.</td>
            </tr>
            <tr>
              <td><a href="#textbox" class="role-reference"><code>textbox</code></a></td>
              <td>Required</td>
              <td>
                <ul>
                  <li>If the <code>textbox</code> role is applied to an HTML <code>input</code> or <code>textarea</code> element, can be named with an HTML <code>label</code> element.</li>
                  <li>Otherwise use <code>aria-labelledby</code> if a visible label is present.</li>
                  <li>Use <code>aria-label</code> if a visible label is not present.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#time" class="role-reference"><code>time</code></a></td>
              <td>Do Not Name</td>
              <td>Naming is not supported by assistive technologies.</td>
            </tr>
            <tr>
              <td><a href="#timer" class="role-reference"><code>timer</code></a></td>
              <td>Discretionary</td>
              <td>
                Some screen readers announce the name of a timer element before announcing the content of the timer element.
                Thus, <code>aria-label</code> provides a method for prefacing the visible content of a timer element with text that is not displayed as part of the timer element.
                Using <code>aria-label</code> is functionally equivalent to providing off-screen text in the contents of the timer element, except off-screen text would be announced by screen readers that do not support <code>aria-label</code> on <code>timer</code> elements.
              </td>
            </tr>
            <tr>
              <td><a href="#toolbar" class="role-reference"><code>toolbar</code></a></td>
              <td>Recommended</td>
              <td>
                <ul>
                  <li>If there is more than one <code>toolbar</code> element on the page, naming is required.</li>
                  <li>Helps assistive technology users to understand the purpose of the toolbar, even when there is only one toolbar on the page.</li>
                  <li>Use <code>aria-labelledby</code> if a visible label is present, otherwise use <code>aria-label</code>.</li>
                  <li>See the <a href="#toolbar">Toolbar Pattern</a>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#tooltip" class="role-reference"><code>tooltip</code></a></td>
              <td>Required <strong>Only If</strong> Content Insufficient</td>
              <td>
                <ul>
                  <li>Warning! Using <code>aria-label</code> or <code>aria-labelledby</code> will hide descendant content from assistive technologies.</li>
                  <li>Ideally named by visible, descendant content.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#tree" class="role-reference"><code>tree</code></a></td>
              <td>Required</td>
              <td>
                <ul>
                  <li>Use <code>aria-labelledby</code> if a visible label is present, otherwise use <code>aria-label</code>.</li>
                  <li>See the <a href="#TreeView">Tree View Design Pattern</a>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#treegrid" class="role-reference"><code>treegrid</code></a></td>
              <td>Required</td>
              <td>
                <ul>
                  <li>If the <code>treegrid</code> is applied to an HTML <code>table</code> element, then the accessible name can be derived from the table's <code>caption</code> element.</li>
                  <li>Otherwise, use <code>aria-labelledby</code> if a visible label is present, otherwise use <code>aria-label</code>.</li>
                  <li>See the <a href="#treegrid">Treegrid Design Pattern</a>.</li>
                </ul>
              </td>
            </tr>
            <tr>
              <td><a href="#treeitem" class="role-reference"><code>treeitem</code></a></td>
              <td>Required <strong>Only If</strong> Content Insufficient</td>
              <td>
                <ul>
                  <li>Warning! Using <code>aria-label</code> or <code>aria-labelledby</code> will hide any descendant content from assistive technologies.</li>
                  <li>Ideally named by visible, descendant content.</li>
                  <li>Note: content contained within a child <code>group</code> is automatically excluded from the accessible name calculation.</li>
                  <li>See the <a href="#TreeView">Tree View Design Pattern</a>.</li>
                </ul>
              </td>
            </tr>
          </tbody>
        </table>
      </section>

      <section id="name_calculation">
        <h4>Accessible name calculation</h4>
        <p>
          User agents construct an accessible name string for an element by walking through a list of potential naming methods and using the first that generates a name.
          The algorithm they follow is defined in the <a href="" class="accname">accessible name specification</a>.
          It is roughly like the following:
        </p>
        <ol>
          <li><p>The <code>aria-labelledby</code> property is used if present.</p></li>
          <li><p>If the name is still empty, the <code>aria-label</code> property is used if present.</p></li>
          <li>
            <p>If the name is still empty, then host-language-specific attributes or elements are used if present. For HTML, these are, depending on the element:</p>
            <dl class="switch">
              <dt><code>input</code> whose <code>type</code> attribute is in the Button, Submit Button, or Reset Button state</dt>
              <dd>The <code>value</code> attribute.</dd>

              <dt><code>input</code> whose <code>type</code> attribute is in the Image Button state</dt>
              <dt><code>img</code></dt>
              <dt><code>area</code></dt>
              <dd>The <code>alt</code> attribute. </dd>

              <dt><code>fieldset</code></dt>
              <dd>The first child <code>legend</code> element.</dd>

              <dt>Other form elements</dt>
              <dd>The associated <code>label</code> element(s).</dd>

              <dt><code>figure</code></dt>
              <dd>The first child <code>figcaption</code> element.</dd>

              <dt><code>table</code></dt>
              <dd>The first child <code>caption</code> element.</dd>
            </dl>
          </li>
          <li><p>If the name is still empty, then for elements with a role that supports naming from child content, the content of the element is used.</p></li>
          <li>
            <p>Finally, if the name is still empty, then other fallback host-language-specific attributes or elements are used if present. For HTML, these are, depending on the element:</p>
            <dl class="switch">
              <dt><code>input</code> whose <code>type</code> attribute is in the Text, Password, Search, Telephone, or URL states</dt>
              <dt><code>textarea</code></dt>
              <dd>The <code>title</code> attribute. Otherwise, the <code>placeholder</code> attribute.</dd>

              <dt><code>input</code> whose <code>type</code> attribute is in the Submit Button state</dt>
              <dd>A localized string of the word "submit".</dd>

              <dt><code>input</code> whose <code>type</code> attribute is in the Reset Button state</dt>
              <dd>A localized string of the word "reset".</dd>

              <dt><code>input</code> whose <code>type</code> attribute is in the Image Button state</dt>
              <dd>The <code>title</code> attribute. Otherwise, a localized string of the phrase "Submit Query".</dd>

              <dt><code>summary</code></dt>
              <dd>The word "Details".</dd>

              <dt>Other elements</dt>
              <dd>The <code>title</code> attribute.</dd>
            </dl>
          </li>
        </ol>
        <p>
          The final step is a fallback mechanism. Generally when labeling an element, use one of the non-fallback mechanisms.
        </p>
        <p>
          When calculating a name from content, the user agent walks through all descendant nodes except in the cases of <code>treeitem</code> and <code>menuitem</code> as described below.
          And, when following references in an <code>aria-labelledby</code> attribute, it similarly walks the tree of each referenced element.
          Thus, the naming algorithm is recursive.
          The following two sections explain non-recursive and recursive examples of how the algorithm works.
        </p>
        <p>
          When calculating a name from content for the <code>treeitem</code> role, descendant content of child <code>group</code> elements are not included.
          For example, in the following <code>tree</code>, the name of the first tree item is <q>Fruits</q>; <q>Apples</q>, <q>Bananas</q>, and <q>Oranges</q> are automatically omitted.
        </p>
        <pre><code>&lt;ul role="tree">
  &lt;li role="treeitem">Fruits
    &lt;ul role="group">
      &lt;li role="treeitem">Apples&lt;/li>
      &lt;li role="treeitem">Bananas&lt;/li>
      &lt;li role="treeitem">Oranges&lt;/li>
    &lt;/ul>
  &lt;/li>
&lt;/ul></code></pre>
        <p>
          Similarly, when calculating a name from content for the <code>menuitem</code> role, descendant content of child <code>menu</code> elements are not included.
          So, the name of the first parent <code>menuitem</code> in the following <code>menu</code> is <q>Fruits</q>.
        </p>
        <pre><code>&lt;ul role="menu">
  &lt;li role="menuitem">Fruits
    &lt;ul role="menu">
      &lt;li role="menuitem">Apples&lt;/li>
      &lt;li role="menuitem">Bananas&lt;/li>
      &lt;li role="menuitem">Oranges&lt;/li>
    &lt;/ul>
  &lt;/li>
&lt;/ul></code></pre>

        <section id="name_calculation_non-recursive_ex">
          <h5>Examples of non-recursive accessible name calculation</h5>
          <p>Consider an <code>input</code> element that has no associated <code>label</code> element and only a <code>name</code> attribute and so does not have an accessible name (do not do this):</p>
          <pre><code>&lt;input name="code"></code></pre>
          <p>If there is a <code>placeholder</code> attribute, then it serves as a naming fallback mechanism (avoid doing this):</p>

          <pre><code>&lt;input name="code"
       placeholder="One-time code"></code></pre>

          <p>If there is also a <code>title</code> attribute, then it is used as the accessible name instead of <code>placeholder</code>, but it is still a fallback (avoid doing this):</p>

          <pre><code>&lt;input name="code"
       placeholder="123456"
       title="One-time code"></code></pre>

          <p>If there is also a <code>label</code> element (recommended), then that is used as the accessible name, and the <code>title</code> attribute is instead used as the accessible description:</p>

          <pre><code>&lt;label>One-time code
 &lt;input name="code"
        placeholder="123456"
        title="Get your code from the app.">
&lt;/label></code></pre>

          <p>If there is also an <code>aria-label</code> attribute (not recommended unless it adds clarity for assistive technology users), then that becomes the accessible name, overriding the <code>label</code> element:</p>

          <pre><code>&lt;label>Code
 &lt;input name="code"
        aria-label="One-time code"
        placeholder="123456"
        title="Get your code from the app.">
&lt;/label></code></pre>

          <p>If there is also an <code>aria-labelledby</code> attribute, that wins over the other elements and attributes (the <code>aria-label</code> attribute ought to be removed if it is not used):</p>

          <pre><code>&lt;p>Please fill in your &lt;span id="code-label">one-time code&lt;/span> to log in.&lt;/p>
&lt;p>
 &lt;label>Code
  &lt;input name="code"
         aria-labelledby="code-label"
         aria-label="This is ignored"
         placeholder="123456"
         title="Get your code from the app.">
 &lt;/label>
&lt;/p></code></pre>
          </section>

          <section id="name_calculation_recursive_ex">
            <h5>Examples of recursive accessible name calculation</h5>
            <p>The accessible name calculation algorithm will be invoked recursively when necessary. An <code>aria-labelledby</code> reference causes the algorithm to be invoked recursively, and when computing an accessible name from content the algorithm is invoked recursively for each child node.</p>

            <p>In this example, the label for the button is computed by recursing into each child node, resulting in <q>Move to trash</q>.</p>

            <pre><code>&lt;button>Move to &lt;img src="bin.svg" alt="trash">&lt;/button></code></pre>

            <p>When following an <code>aria-labelledby</code> reference, the algorithm avoids following the same reference twice to avoid infinite loops.</p>

            <p>In this example, the label for the button is computed by first following the <code>aria-labelledby</code> reference to the parent element, and then computing the label for that element from the child nodes, first visiting the <code>button</code> element again but ignoring the <code>aria-labelledby</code> reference and instead using the <code>aria-label</code>, and then visiting the next child (the text node). The resulting label is <q>Remove meeting: Daily status report</q>.</p>

            <pre><code>&lt;div id="meeting-1">
  &lt;button aria-labelledby="meeting-1" aria-label="Remove meeting:">X&lt;/button>
  Daily status report
&lt;/div></code></pre>
        </section>
      </section>
    </section>

    <section id="accessible_descriptions">
      <h3>Accessible Descriptions</h3>
      <section id="describing_techniques">
        <h4>Describing Techniques</h4>
        <section id="describing_with_aria-describedby">
          <h5>Describing by referencing content with <code>aria-describedby</code></h5>
          <p>
            The <code>aria-describedby</code> property works similarly to the <code>aria-labelledby</code> property.
            For example, a button could be described by a sibling paragraph.
          </p>

          <pre><code>&lt;button aria-describedby="trash-desc">Move to trash&lt;/button>
...
&lt;p id="trash-desc">Items in the trash will be permanently removed after 30 days.&lt;/p></code></pre>

          <p>Descriptions are reduced to text strings. For example, if the description contains an HTML <code>img</code> element, a text equivalent of the image is computed.</p>

          <pre><code>&lt;button aria-describedby="trash-desc"> Move to &lt;img src="bin.svg" alt="trash">&lt;/button>
...
&lt;p id="trash-desc">Items in &lt;img src="bin.svg" alt="the trash"> will be permanently removed after 30 days.&lt;/p></code></pre>

          <p>
            As with <code>aria-labelledby</code>, it is possible to reference an element using <code>aria-describedby</code> even if that element is hidden.
            For example, a text field in a form could have a description that is hidden by default, but can be revealed on request using a disclosure widget.
            The description could also be referenced from the text field directly with <code>aria-describedby</code>.
            In the following example, the accessible description for the <code>input</code> element is <q>Your username is the name that you use to log in to this service.</q>
          </p>

          <pre><code>&lt;label for="username">Username&lt;/label>
&lt;input id="username" name="username" aria-describedby="username-desc">
&lt;button aria-expanded="false" aria-controls="username-desc" aria-label="Help about username">?&lt;/button>
&lt;p id="username-desc" hidden>
  Your username is the name that you use to log in to this service.
&lt;/p></code></pre>
        </section>

        <section id="describing_with_captions">
          <h5>Describing Tables and Figures with Captions</h5>
          <p>
            In HTML, if the <code>table</code> is named using <code>aria-label</code> or <code>aria-labelledby</code>, a child <code>caption</code> element becomes an accessible description.
            For example, a preceding heading might serve as an appropriate accessible name, and the <code>caption</code> element might contain a longer description.
            In such a situation, <code>aria-labelledby</code> could be used on the <code>table</code> to set the accessible name to the heading content and the <code>caption</code> would become the accessible description.
          </p>
          <pre><code>&lt;h2 id="events-heading">Upcoming events&lt;/h2>
&lt;table aria-labelledby="events-heading">
 &lt;caption>
  Calendar of upcoming events, weeks 27 through 31, with each week starting with
  Monday. The first column is the week number.
 &lt;/caption>
 &lt;tr>&lt;th>Week&lt;th>Monday&lt;th>Tuesday&lt;th>Wednesday&lt;th>Thursday&lt;th>Friday&lt;th>Saturday&lt;th>Sunday
 &lt;tr>&lt;td>27&lt;td>&lt;td>&lt;td>&lt;td>&lt;td>&lt;td>&lt;td>
 &lt;tr>&lt;td>28&lt;td>&lt;td>&lt;td>&lt;td>&lt;td>&lt;td>&lt;td>&lt;a href="/events/9856">Crown Princess's birthday&lt;/a>
 &lt;tr>&lt;td>29&lt;td>&lt;td>&lt;td>&lt;td>&lt;td>&lt;td>&lt;td>
 &lt;tr>&lt;td>30&lt;td>&lt;td>&lt;td>&lt;td>&lt;td>&lt;td>&lt;td>
 &lt;tr>&lt;td>31&lt;td>&lt;td>&lt;td>&lt;td>&lt;td>&lt;td>&lt;td>
&lt;/table></code></pre>
          <p>The HTML <code>figure</code> element can get its accessible <em>name</em> from its <code>figcaption</code> element, but it will not be used as the accessible <em>description</em>, even if it was not used as the accessible name. If the <code>figcaption</code> element is appropriate as an accessible description, and the accessible name is set using <code>aria-labelledby</code> or <code>aria-label</code>, then the <code>figcaption</code> can be explicitly set as the accessible description using the <code>aria-describedby</code> attribute.</p>
          <pre><code>&lt;h2 id="neutron">Neutron&lt;/h2>
&lt;figure aria-labelledby="neutron" aria-describedby="neutron-caption">
 &lt;img src="neutron.svg" alt="Within the neutron are three quarks (blue 'u',
 red 'd', green 'd') that are interconnected.">
 &lt;figcaption id="neutron-caption">
  The quark content of the neutron. The color assignment of individual quarks is
  arbitrary, but all three colors must be present. Forces between quarks are
  mediated by gluons.
 &lt;/figcaption>
&lt;/figure></code></pre>
         </section>

        <section id="describing_with_title">
          <h5>Descriptions Derived from Titles</h5>
          <p>If an accessible description was not provided using the <code>aria-describedby</code> attribute or one of the primary host-language-specific attributes or elements (e.g., the <code>caption</code> element for <code>table</code>), then, for HTML, if the element has a <code>title</code> attribute, that is used as the accessible description.</p>
          <p>A visible description together with <code>aria-describedby</code> is generally recommended. If a description that is not visible is desired, then the <code>title</code> attribute can be used, for any HTML element that can have an accessible description.</p>
          <p>Note that the <code>title</code> attribute might not be accessible to some users, in particular sighted users not using a screen reader and not using a pointing device that supports hover (e.g., a mouse).</p>
          <p>For example, an <code>input</code> element with input constrained using the <code>pattern</code> attribute can use the <code>title</code> attribute to describe what the expected input is.</p>
          <pre><code>&lt;label> Part number:
 &lt;input pattern="[0-9][A-Z]{3}" name="part"
        title="A part number is a digit followed by three uppercase letters."/>
&lt;/label></code></pre>
          <p>The <code>title</code> attribute in this case can be shown to the user as a tooltip when the user hovers or focuses the control, but also as part of the error message when the user agent validates the form, if the <code>input</code> element's value doesn't match the <code>pattern</code>.</p>
          <p>As another example, a link can use the <code>title</code> attribute to describe the link in more detail.</p>
          <pre><code>&lt;a href="http://twitter.com/W3C"
   title="Follow W3C on Twitter">
   &lt;img src="/2008/site/images/Twitter_bird_logo_2012.svg"
        alt="Twitter" class="social-icon" height="40" />
&lt;/a></code></pre>
        </section>
      </section>

      <section id="description_calculation">
        <h4>Accessible description calculation</h4>
        <p>
          Like the <a href="#name_calculation">accessible name calculation</a>, the accessible description calculation produces a text string.
        </p>
        <p>
          The accessible description calculation algorithm is the same as the accessible name calculation algorithm except for a few branch points that depend on whether a name or description is being calculated.
          In particular, when accumulating text for an accessible description, the algorithm uses <code>aria-describedby</code> instead of <code>aria-labelledby</code>.
        </p>
        <p>
          User agents construct an accessible description string for an element by walking through a list of potential description methods and using the first that generates a description.
          The algorithm they follow is defined in the <a href="" class="accname">accessible name specification</a>.
          It is roughly like the following:
        </p>
        <ol>
          <li><p>The <code>aria-describedby</code> property is used if present.</p></li>
          <li>
            <p>If the description is still empty, then host-language-specific attributes or elements are used if present, if it wasn't already used as the accessible name. For HTML, these are, depending on the element:</p>
            <dl class="switch">
              <dt><code>input</code> whose <code>type</code> attribute is in the Button, Submit Button, or Reset Button state</dt>
              <dd>The <code>value</code> attribute.</dd>

              <dt><code>summary</code></dt>
              <dd>The element's subtree.</dd>

              <dt><code>table</code></dt>
              <dd>The first child <code>caption</code> element.</dd>
            </dl>
          </li>
          <li>
            <p>Finally, if the description is still empty, then other host-language-specific attributes or elements are used if present, if it wasn't already used for the accessible name. For HTML, this is the <code>title</code> attribute.</p>
          </li>
        </ol>
      </section>
    </section>
  </section>

  <section id="keyboard">
    <h2>Developing a Keyboard Interface</h2>
    <p>
      Unlike native HTML form elements, browsers do not provide keyboard support for graphical user interface (GUI) components that are made accessible with ARIA; authors have to provide the keyboard support in their code.
      This section describes the principles and methods for making the functionality of a web page that includes ARIA widgets, such as menus and grids, as well as interactive components, such as toolbars and dialogs, operable with a keyboard.
      Along with the basics of focus management, this section offers guidance toward the objective of providing experiences to people who rely on a keyboard that are as efficient and enjoyable as the experiences available to others.
    </p>
      <p>This section covers: </p>
    <ol>
      <li>Understanding fundamental principles of focus movement conventions used in ARIA design patterns.</li>
      <li>Maintaining visible focus, predictable focus movement, and distinguishing between keyboard focus and the selected state.</li>
      <li>Managing movement of keyboard focus between components, e.g., how the focus moves when the <kbd>Tab</kbd> and <kbd>Shift+Tab</kbd> keys are pressed.</li>
      <li>Managing movement of keyboard focus inside components that contain multiple focusable elements, e.g., two different methods for programmatically exposing focus inside widgets like radio groups, menus, listboxes, trees, and grids.</li>
      <li>Determining when to make disabled interactive elements focusable.</li>
      <li>Assigning and revealing keyboard shortcuts, including guidance on how to avoid problematic conflicts with keyboard commands of assistive technologies, browsers, and operating systems.</li>
    </ol>
    <section id="kbd_generalnav">
      <h3>Fundamental Keyboard Navigation Conventions</h3>

      <p>
        ARIA roles, states, and properties model accessibility behaviors and features shared among GUI components of popular desktop GUIs, including Microsoft Windows, macOS, and GNOME.
        Similarly, ARIA design patterns borrow user expectations and keyboard conventions from those platforms, consistently incorporating common conventions with the aim of facilitating easy learning and efficient operation of keyboard interfaces across the web.
      </p>

      <p>
        For a web page to be accessible, all interactive elements must be operable via the keyboard.
        In addition, consistent application of the common GUI keyboard interface conventions described in the <a href="#aria_ex">ARIA design patterns</a> is important, especially for assistive technology users.
        Consider, for example, a screen reader user operating a tree.
        Just as familiar visual styling helps users discover how to expand a tree branch with a mouse, ARIA attributes give the tree the sound and feel of a tree in a desktop application.
        So, screen reader users will commonly expect that pressing the right arrow key will expand a collapsed node.
        Because the screen reader knows the element is a tree, it also has the ability to instruct a novice user how to operate it.
        Similarly, voice recognition software can implement commands for expanding and collapsing branches because it recognizes the element as a tree and can execute appropriate keyboard commands.
        All this is only possible if the tree implements the GUI keyboard conventions as described in the <a href="#TreeView">ARIA tree pattern</a>.
      </p>

      <p>
        A primary keyboard navigation convention common across all platforms is that the <kbd>tab</kbd> and <kbd>shift+tab</kbd> keys move focus from one UI component to another while other keys, primarily the arrow keys, move focus inside of components that include multiple focusable elements.
        The path that the focus follows when pressing the <kbd>tab</kbd> key is known as the tab sequence or tab ring.
      </p>

      <p>
        Common examples of UI components that contain multiple focusable elements are radio groups, tablists, menus, and grids.
        A radio group, for example, contains multiple radio buttons, each of which is focusable.
        However, only one of the radio buttons is included in the tab sequence.
        After pressing the <kbd>Tab</kbd> key moves focus to a radio button in the group, pressing arrow keys moves focus among the radio buttons in the group, and pressing the <kbd>Tab</kbd> key moves focus out of the radio group to the next element in the tab sequence.
      </p>

      <p>
        The ARIA specification refers to a discrete UI component that contains multiple
        focusable elements as a <a href="#composite" class="role-reference">composite</a>
        widget. The process of controlling focus movement inside a composite is called
        managing focus. Following are some ARIA design patterns with example implementations
        that demonstrate focus management:
      </p>

      <ul>
        <li><a href="#combobox">Combobox</a></li>
        <li><a href="#grid">Grid</a></li>
        <li><a href="#Listbox">Listbox</a></li>
        <li><a href="#menu">Menu or menu bar</a></li>
        <li><a href="#radiobutton">Radiogroup</a></li>
        <li><a href="#tabpanel">Tabs</a></li>
        <li><a href="#toolbar">Toolbar</a></li>
        <li>Tree Grid</li>
        <li><a href="#TreeView">Tree View</a></li>
      </ul>
    </section>

    <section id="kbd_focus_discernable_predictable">
      <h3>Discernible and Predictable Keyboard Focus</h3>
      <p>Work to complete this section is tracked by <a href="https://github.com/w3c/aria-practices/issues/217">issue 217.</a></p>
      <p>
        When operating with a keyboard, two essentials of a good experience are the abilities to easily discern the location of the keyboard focus and to discover where focus landed after a navigation key has been pressed.
        The following factors affect to what extent a web page affords users these capabilities.
      </p>

      <ol>
        <li>Visibility of the focus indicator: Users need to be able to easily distinguish the keyboard focus indicator from other features of the visual design. Just as a mouse user may move the mouse to help find the mouse pointer, a keyboard user may press a navigation key to watch for movement. If visual changes in response to focus movement are subtle, many users will lose track of focus and be unable to operate. Authors are advised to rely on the default focus indicators provided by browsers. If overriding the default, consider:
          <ul>
            <li>something about ... Colors and gradients can disappear in high contrast modes.</li>
            <li>Users need to be able to easily distinguish between focus and selection as described in <a href="#kbd_focus_vs_selection"></a>, especially when a component that contains selected elements does not contain the focus.</li>
            <li>... other considerations to be added ...</li>
          </ul>
        </li>

        <li> Persistence of focus: It is essential that there is always a component within the user interface that is active (document.activeElement is not null or is not the body element) and that the active element has a visual focus indicator. Authors need to manage events that effect the currently active element so focus remains visible and moves logically. For example, if the user closes a dialog or performs a destructive operation like deleting an item from a list, the active element may be hidden or removed from the DOM. If such events are not managed to set focus on the button that triggered the dialog or on the list item following the deleted item, browsers move focus to the body element, effectively causing a loss of focus within the user interface. </li>

        <li>
          Predictability of movement: Usability of a keyboard interface is heavily influenced by how readily users can guess where focus will land after a navigation key is pressed.
          Some possible approaches to optimizing predictability include:

          <ul>
            <li>
              Move focus in a pattern that matches the reading order of the page's language. In left to right languages, for example, create a tab sequence that moves focus left to right and then top to bottom.
            </li>

            <li>
              Incorporate all elements of a section of the page in the tab sequence before moving focus to another section. For instance, in a page
              with multiple columns that has content in a left side bar, center region, and right side bar, build a tab sequence that covers all elements in the left sidebar before focus moves to the first focusable element in the center column.
            </li>

            <li>
              When the distance between two consecutive elements in the tab sequence is significant, avoid movement that would be perceived as backward.
              For example, on a page with a left to right language, a jump from the last element in the bottom right of the main content to the top element in a left-hand sidebar is likely to be less predictable and more difficult to follow, especially for users with a narrow field of view.
            </li>

            <li>
              Follow consistent patterns across a site.
              The keyboard experience is more predictable when similar pages have similar focus movement patterns.
            </li>

            <li>Do not set initial focus when the page loads except in cases where:
              <ul>
                <li>The page offers a single, primary function that nearly all users employ immediately after page load.</li>
                <li>Any given user is likely to use the page often.</li>
              </ul>
            </li>
          </ul>
        </li>
      </ol>
    </section>

    <section id="kbd_focus_vs_selection">
      <h3>Focus VS Selection and the Perception of Dual Focus</h3>

      <p>
        Occasionally, it may appear as if two elements on the page have focus at the same time.
        For example, in a multi-select list box, when an option is selected it may be greyed.
        Yet, the focus indicator can still be moved to other options, which may also be selected.
        Similarly, when a user activates a tab in a tablist, the selected state is set on the tab and its visual appearance changes.
        However, the user can still navigate, moving the focus indicator elsewhere on the page while the tab retains its selected appearance and state.
      </p>

      <p>
        Focus and selection are quite different.
        From the keyboard user's perspective, focus is a pointer, like a mouse pointer; it tracks the path of navigation.
        There is only one point of focus at any time and all operations take place at the point of focus.
        On the other hand, selection is an operation that can be performed in some widgets, such as list boxes, trees, and tablists.
        If a widget supports only single selection, then only one item can be selected and very often the selected state will simply follow the focus when focus is moved inside of the widget.
        That is, in some widgets, moving focus may also perform the select operation.
        However, if the widget supports multiple selection, then more than one item can be in a selected state, and keys for moving focus do not perform selection.
        Some multi-select widgets do support key commands that both move focus and change selection, but those keys are different from the normal navigation keys.
        Finally, when focus leaves a widget that includes a selected element, the selected state persists.
      </p>

      <p>
        From the developer's perspective, the difference is simple -- the focused element is the active element (document.activeElement).
        Selected elements are elements that have <code>aria-selected="true"</code>.
      </p>

      <p>With respect to focus and the selected state, the most important considerations for designers and developers are:</p>

      <ul>
        <li>The visual focus indicator must always be visible.</li>
        <li>The selected state must be visually distinct from the focus indicator.</li>
      </ul>
    </section>

    <section id="kbd_selection_follows_focus">
      <h3>Deciding When to Make Selection Automatically Follow Focus</h3>
      <p> in composite widgets where only one element may be selected, such as a tablist or single-select listbox, moving the focus may also cause the focused element to become the selected element. This is called having selection follow focus. Having selection follow focus is often beneficial to users, but in some circumstances, it is extremely detrimental to accessibility. </p>
      <p>
        For example, in a tablist, the selected state is used to indicate which panel is displayed.
        So, when selection follows focus in a tablist, moving focus from one tab to another automatically changes  which panel is displayed.
        If the content of panels is present in the DOM, then displaying a new panel is nearly instantaneous.
        A keyboard user who wishes to display the fourth of six tabs can do so with 3 quick presses of the right arrow.
        And, a screen reader user who perceives the labels on tabs by navigating through them may efficiently read through the complete list without any latency.
      </p>
      <p> However, if displaying a new panel causes a network request and possibly a page refresh, the effect of having selection automatically focus can be devastating to the experience for keyboard and screen reader users. In this case, displaying the fourth tab or reading through the list becomes a tedious and time-consuming task as the user experiences significant latency with each movement of focus. Further, if displaying a new tab refreshes the page, then the user not only has to wait for the new page to load but also return focus to the tab list. </p>
      <p>
        When selection does not follow focus, the user changes which element is selected by pressing the <kbd>Enter</kbd> or <kbd>Space</kbd> key.
      </p>
    </section>

    <section id="kbd_general_between">
      <h3>Keyboard Navigation Between Components (The Tab Sequence)</h3>

      <p> As explained in section <a href="#kbd_generalnav"></a>, all interactive UI components need to be reachable via the keyboard. This is best achieved by either including them in the tab sequence or by making them accessible from a component that is in the tab sequence, e.g., as part of a composite component. This section addresses building and managing the tab sequence, and subsequent sections cover making focusable elements that are contained within components keyboard accessible. </p>

      <p>
        The [[HTML]] <a href="https://html.spec.whatwg.org/multipage/interaction.html#the-tabindex-attribute">tabindex</a> and [[SVG2]] <a href="https://www.w3.org/TR/SVG2/struct.html#tabindexattribute">tabindex</a> attributes can be used to add and remove elements from the tab sequence.
        The value of tabindex can also influence the order of the tab sequence, although authors are strongly advised not to use tabindex for that purpose.
      </p>

      <p>
        In HTML, the default tab sequence of a web page includes only links and HTML form elements, except In macOS, where it includes only form elements.
        macOS system preferences include a keyboard setting that enables the tab key to move focus to all focusable elements.
      </p>

      <p>
        The default order of elements in the tab sequence is the order of elements in the DOM.
        The DOM order also determines screen reader reading order.
        It is important to keep the keyboard tab sequence and the screen reader reading order aligned, logical, and predictable as described in <a href="#kbd_focus_discernable_predictable"></a>.
        The most robust method of manipulating the order of the tab sequence while also maintaining alignment with the reading order that is currently available in all browsers is rearranging elements in the DOM.
      </p>

      <p>The values of the tabindex attribute have the following effects.</p>

      <dl>
        <dt>tabindex is not present or does not have a valid value</dt>
        <dd>
          The element has its default focus behavior.
          In HTML, only form controls and anchors with an HREF attribute are included in the tab sequence.
        </dd>
        <dt>tabindex="0"</dt>
        <dd>The element is included in the tab sequence based on its position in the DOM.</dd>
        <dt>tabindex="-1"</dt>
        <dd>The element is not included in the tab sequence but is focusable with element.focus().</dd>
        <dt>tabindex="X" where X is an integer in the range 1 &lt;= X &lt;= 32767</dt>
        <dd>
          Authors are strongly advised NOT to use these values.
          The element is placed in the tab sequence based on the value of tabindex.
          Elements with a tabindex value of 0 and elements that are focusable by default will be in the sequence after elements with a tabindex value of 1 or greater.
        </dd>
      </dl>
    </section>

    <section id="kbd_general_within">
      <h3> Keyboard Navigation Inside Components</h3>

      <p>
        As described in section <a href="#kbd_generalnav"></a>, the tab sequence should include only one focusable element of a composite UI component.
        Once a composite contains focus, keys other than <kbd>Tab</kbd> and <kbd>Shift + Tab</kbd> enable the user to move focus among its focusable elements.
        Authors are free to choose which keys move focus inside of a composite, but they are strongly advised to use the same key bindings as similar components in common GUI operating systems as demonstrated in <a href="#aria_ex"></a>.
      </p>

      <p> The convention for where focus lands in a composite when it receives focus as a result of a <kbd>Tab</kbd> key event depends on the type of composite. It is typically one of the following. </p>

      <ul>
        <li>
          The element that had focus the last time the composite contained focus.
          Or, if the composite has not yet contained the focus, the first element.
          Widgets that usually employ this pattern include grid and tree grid.
        </li>

        <li>
          The selected element. Or, if there is no selected element, the first element.
          Widgets where this pattern is commonly implemented include radio groups, tabs, list boxes, and trees.
          Note: For radio groups, this pattern is referring to the checked radio button; the selected state is not supported for radio buttons.
        </li>

        <li>
          The first element.
          Components that typically follow this pattern include menubars and toolbars.
        </li>
      </ul>

      <p>
        The following sections explain two strategies for managing focus inside composite elements: creating a roving tabindex and using the aria-activedescendant property.
      </p>

      <section id="kbd_roving_tabindex">
        <h4>Managing Focus Within Components Using a Roving tabindex</h4>

        <p>
          When using roving tabindex to manage focus in a composite UI component, the element that is to be included in the tab sequence has tabindex of "0" and all other focusable elements contained in the composite have tabindex of "-1".
          The algorithm for the roving tabindex strategy is as follows.
        </p>

        <ul>
          <li>When the component container is loaded or created, set <code>tabindex="0"</code> on the element that will initially be included in the tab sequence and set <code>tabindex="-1"</code> on all other focusable elements it contains.</li>
          <li>
            When the component contains focus and the user presses a navigation key that moves focus within the component, such as an arrow key:

            <ul>
              <li>set <code>tabindex="-1"</code> on the element that has <code>tabindex="0"</code>.</li>
              <li>Set <code>tabindex="0"</code> on the element that will become focused as a result of the key event.</li>
              <li>Set focus, <code>element.focus()</code>, on the element that has <code>tabindex="0"</code>.</li>
            </ul>
          </li>

          <li>
            If the design calls for a specific element to be focused the next time the user moves focus into the composite with <kbd>Tab</kbd> or <kbd>Shift+Tab</kbd>, check if that target element has <code>tabindex="0"</code> when the composite loses focus.
            If it does not, set <code>tabindex="0"</code> on the target element and set <code>tabindex="-1"</code> on the element that previously had <code>tabindex="0"</code>.
          </li>
        </ul>

        <p>
          One benefit of using roving tabindex rather than aria-activedescendant to manage focus is that the user agent will scroll the newly focused element into view.
        </p>
      </section>

      <section id="kbd_focus_activedescendant">
        <h4>Managing Focus in Composites Using aria-activedescendant</h4>

        <p>
          If a component container has an ARIA role that supports the <a class="property-reference" href="#aria-activedescendant">aria-activedescendant</a> property, it is not necessary to manipulate the tabindex attribute and move DOM focus among focusable elements within the container.
          Instead, only the container element needs to be included in the tab sequence. When the container has DOM focus, the value of aria-activedescendant on the container tells assistive technologies which element is active within the widget.
          Assistive technologies will consider the element referred to as active to be the focused element even though DOM focus is on the element that has the aria-activedescendant property.
          And, when the value of aria-activedescendant is changed, assistive technologies will receive focus change events equivalent to those received when DOM focus actually moves.
        </p>

        <p>The steps for using the aria-activedescendant method of managing focus are as follows.</p>

        <ul>
          <li>When the container element that has a role that supports aria-activedescendant is loaded or created, ensure that:
            <ul>
              <li>The container element is included in the tab sequence as described in <a href="#kbd_general_between"></a> or is a focusable element of a composite that implements <a href="#kbd_roving_tabindex">a roving tabindex</a>.</li>
              <li>
                It has <code>aria-activedescendant="IDREF"</code> where IDREF is the ID of the element within the container that should be identified as active when the widget receives focus.
                The referenced element needs to meet the DOM relationship requirements described below.
              </li>
            </ul>
          </li>
          <li>When the container element receives DOM focus, draw a visual focus indicator on the active element and ensure the active element is scrolled into view.</li>
          <li>When the composite widget contains focus and the user presses a navigation key that moves focus within the widget, such as an arrow key:
            <ul>
              <li>Change the value of aria-activedescendant on the container to refer to the element that should be reported to assistive technologies as active.</li>
              <li>Move the visual focus indicator and, if necessary,  scrolled the active element into view.</li>
            </ul>
          </li>
          <li>
            If the design calls for a specific element to be focused the next time a user moves focus into the composite with <kbd>Tab</kbd> or <kbd>Shift+Tab</kbd>, check if aria-activedescendant is referring to that target element when the container loses focus.
            If it is not, set aria-activedescendant to refer to the target element.
          </li>
        </ul>

        <p>
          The <a href="#aria-activedescendant" class="property-reference">specification for aria-activedescendant</a> places important restrictions on the DOM relationship between the focused element that has the aria-activedescendant attribute and the element referenced as active by the value of the attribute.
          One of the following three conditions must be met.
        </p>
        <ol>
          <li>The element referenced as active is a DOM descendant of the focused referencing element.</li>
          <li>The focused referencing element has a value specified for the <a href="#aria-owns" class="property-reference">aria-owns</a> property that includes the ID of the element referenced as active.</li>
          <li>The focused referencing element has role of <a href="#textbox" class="role-reference">textbox</a> and has <a href="#aria-controls" class="property-reference">aria-controls</a> property referring to an element with a role that supports aria-activedescendant and either:
            <ol>
              <li>The element referenced as active is a descendant of the controlled element.</li>
              <li>The controlled element has a value specified for the <a href="#aria-owns" class="property-reference">aria-owns</a> property that includes the ID of the element referenced as active.</li>
            </ol>
          </li>
        </ol>
      </section>
    </section>
    <section id="kbd_disabled_controls">
      <h3>Focusability of disabled controls</h3>
      <p>
        By default, disabled HTML input elements are removed from the tab sequence.
        In most contexts, the normal expectation is that disabled interactive elements are not focusable.
        However, there are some contexts where it is common for disabled elements to be focusable, especially inside of composite widgets.
        For example, as demonstrated in the <a href="#menu"></a> pattern, disabled items are focusable when navigating through a menu with the arrow keys.
      </p>

      <p>
        Removing focusability from disabled elements can offer users both advantages and disadvantages.
        Allowing keyboard users to skip disabled elements usually reduces the number of key presses required to complete a task.
        However, preventing focus from moving to disabled elements can hide their presence from screen reader users who "see" by moving the focus.
      </p>

      <p>
        Authors are encouraged to adopt a consistent set of conventions for the focusability of disabled elements.
        The examples in this guide adopt the following conventions, which both reflect common practice and attempt to balance competing concerns.
      </p>

      <ol>
        <li>For elements that are in the tab sequence when enabled, remove them from the tab sequence when disabled.</li>

        <li>
          For the following composite widget elements, keep them focusable when disabled:

          <ul>
            <li>Options in a <a href="#Listbox">Listbox</a></li>
            <li>Menu items in a <a href="#menu">Menu or menu bar</a></li>
            <li>Tab elements in a set of <a href="#tabpanel">Tabs</a></li>
            <li>Tree items in a <a href="#TreeView">Tree View</a></li>
          </ul>
        </li>

        <li>
          For elements contained in a toolbar, make them focusable if discoverability is a concern. Here are two examples to aid with this judgment.

          <ol>
            <li>
              A toolbar with buttons for moving, removing, and adding items in a list includes buttons for &quot;Up&quot;, &quot;Down&quot;, &quot;Add&quot;, and &quot;Remove&quot;.
              The &quot;Up&quot; button is disabled and its focusability is removed when the first item in the list is selected.
              Given the  presence of the &quot;Down&quot; button, discoverability of the &quot;Up&quot; button is not a concern.
            </li>

            <li>
              A toolbar in an editor contains a set of special smart paste functions that are disabled when the clipboard is empty or when the function is not applicable to the current content of the clipboard.
              It could be helpful to keep the disabled buttons focusable if the ability to discover their functionality is primarily via their presence on the toolbar.
            </li>
          </ol>
        </li>
      </ol>

      <p>One design technique for mitigating the impact of including disabled elements in the path of keyboard focus is employing appropriate keyboard shortcuts as described in <a href="#kbd_shortcuts"></a>.</p>
    </section>
    <section id="kbd_common_conventions">
      <h3>Key Assignment Conventions for Common Functions</h3>
      <p>
        The following key assignments can be used in any context where their conventionally associated functions are appropriate.
        While the assignments associated with Windows and Linux platforms can be implemented and used in browsers running in macOS,
        replacing them with macOS assignments in browsers running on a macOS device can make the keyboard interface more discoverable and intuitive for those users.
        In some cases, it may also help avoid system or browser keyboard conflicts.
      </p>
      <table class="widget-features">
        <thead>
          <tr>
            <th>Function</th>
            <th>Windows/Linux Key</th>
            <th>macOS Key</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <th scope="row">open context menu</th>
            <td><kbd>Shift + F10</kbd></td>
            <td></td>
          </tr>
          <tr>
            <th scope="row">Copy to clipboard</th>
            <td><kbd>Control + C</kbd></td>
            <td><kbd>Command + C</kbd></td>
          </tr>
          <tr>
            <th scope="row">Paste from clipboard</th>
            <td><kbd>Control + V</kbd></td>
            <td><kbd>Command + V</kbd></td>
          </tr>
          <tr>
            <th scope="row">Cut to clipboard</th>
            <td><kbd>Control + X</kbd></td>
            <td><kbd>Command + X</kbd></td>
          </tr>
          <tr>
            <th scope="row">undo last action</th>
            <td><kbd>Control + Z</kbd></td>
            <td><kbd>Command + Z</kbd></td>
          </tr>
          <tr>
            <th scope="row">Redo action</th>
            <td><kbd>Control + Y</kbd></td>
            <td>Command + Shift + Z</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section id="kbd_shortcuts">
      <h3>Keyboard Shortcuts</h3>
      <p>
        When effectively designed, keyboard shortcuts that focus an element, activate a widget, or both can dramatically enhance usability of frequently used features of a page or site.
        This section addresses some of the keyboard shortcut design and implementation factors that most impact their effectiveness, including:
      </p>
      <ol>
        <li>Understanding how keyboard shortcuts augment a keyboard interface and whether to make a particular shortcut move focus, perform a function, or both. </li>
        <li>Making key assignments and avoiding assignment conflicts with assistive technologies, browsers, and operating systems. </li>
        <li>Exposing and documenting key assignments. </li>
      </ol>
      <section id="kbd_shortcuts_behavior_design">
        <h4>Designing the Scope and Behavior of Keyboard Shortcuts</h4>

        <p>This section explains the following factors when determining which elements and features to assign keyboard shortcuts and what behavior to give each shortcut:</p>

        <ol>
          <li>Ensuring discovery through navigation; keyboard shortcuts enhance, not replace, standard keyboard access.</li>

          <li>
            Effectively choosing from among the following behaviors:

            <ol>
              <li>Navigation: Moving focus to an element. </li>
              <li>Activation: Performing an operation associated with an element that does not have focus and might not be visible.</li>
              <li>Navigation and activation: Both moving focus to an element and activating it.</li>
            </ol>
          </li>

          <li>Balancing efficiency and cognitive load: lack of a shortcut can reduce efficiency while too many shortcuts can increase cognitive load and clutter the experience.</li>
        </ol>

        <section id="kbd_shortcuts_design_basic">
          <h5>Ensure Basic Access Via Navigation </h5>

          <p>
            Before assigning keyboard shortcuts, it is essential to ensure the features and functions to which shortcuts may be assigned are keyboard accessible without a keyboard shortcut.
            In other words, all elements that could be targets for keyboard shortcuts need to be focusable via the keyboard using the methods described in:
          </p>

          <ul>
            <li><a href="#kbd_general_between"></a> </li>
            <li><a href="#kbd_general_within"></a> </li>
          </ul>

          <p>
            Do not use keyboard shortcuts as a substitute for access via navigation.
            This is essential to full keyboard access because:
          </p>

          <ol>
            <li>The primary means of making functions and their shortcuts discoverable is by making the target elements focusable and revealing key assignments on the element itself.</li>
            <li>If people who rely on the keyboard have to read documentation to learn which keys are required to use an interface, the interface may technically meet some accessibility standards but in practice is only accessible to the small subset of them who have the knowledge that such documentation exists, have the extra time available, and the ability to retain the necessary information.</li>
            <li>Not all devices that depend on keyboard interfaces can support keyboard shortcuts.</li>
          </ol>
        </section>

        <section id="kbd_shortcuts_design_choose_behavior">
          <h5>Choose Appropriate Shortcut Behavior</h5>

          <p>The following conventions may help identify the most advantageous behavior for a keyboard shortcut.</p>

          <ul>
            <li>
              Move focus when the primary objective is to make navigation more efficient, e.g., reduce the number of times the user must press <kbd>Tab</kbd> or the arrow keys.
              This behavior is commonly expected when assigning a shortcut to a text box, toolbar, or composite, such as a listbox, tree, grid, or menubar.
              This behavior is also useful for moving focus to a section of a page, such as the main content or a complementary landmark section.
            </li>

            <li> Activate an element without moving focus when the target context of the function is the context that contains the focus. This behavior is most common for command buttons and for functions associated with elements that are not visible, such as a "Save" option that is accessible via a menu. For example, if the focus is on an option in a listbox and a toolbar contains buttons for moving and removing options, it is most beneficial to keep focus in the listbox when the user presses a key shortcut for one of the buttons in the toolbar. This behavior can be particularly important for screen reader users because it provides confirmation of the action performed and makes performing multiple commands more efficient. For instance, when a screen reader user presses the shortcut for the "Up" button, the user will be able to hear the new position of the option in the list since it still has the focus. Similarly, when the user presses the shortcut for deleting an option, the user can
								hear the next option in the list and immediately decide whether to press the delete shortcut again. </li>

            <li>
              Move focus and activate when the target of the shortcut has a single function and the context of that function is the same as the target.
              This behavior is typical when a shortcut is assigned to a button that opens a menu or dialog, to a checkbox, or to a navigation link or button.
            </li>
          </ul>
        </section>

        <section id="kbd_shortcuts_design_where">
          <h5>Choose Where to Add Shortcuts </h5>
          <p>Work to draft content for this section is tracked in <a href="https://github.com/w3c/aria-practices/issues/219">issue 219.</a></p>
          <p>The first goal when designing a keyboard interface is simple, efficient, and intuitive operation with only basic keyboard navigation support. If basic operation of a keyboard interface is inefficient, attempting to compensate for fundamental design issues, such as suboptimal layout or command structure, by implementing keyboard shortcuts will not likely reduce user frustration. The practical implication of this is that, in most well-designed user interfaces, the percentage of functionality that needs to be accessible via a keyboard shortcut in order to create optimal usability is not very high. In many simple user interfaces, keyboard shortcuts can be entirely superfluous. And, in user interfaces with too many keyboard shortcuts, the excess shortcuts create cognitive load that make the most useful ones more difficult to remember. </p>
          <p>Consider the following when deciding where to assign keyboard shortcuts: </p>

          <ol>
            <li>To be written.</li>
          </ol>
        </section>
      </section>
      <section id="kbd_shortcuts_assigning">
        <h4>Assigning Keyboard Shortcuts</h4>
        <p>When choosing the keys to assign to a shortcut, there are many factors to consider.</p>
        <ul>
          <li>Making the shortcut easy to learn and remember by using a mnemonic (e.g., <kbd>Control + S</kbd> for "Save") or following a logical or spacial pattern.</li>
          <li> Localizing the interface, including for differences in which keys are available and how they behave and for language considerations that could impact mnemonics. </li>
          <li>Avoiding and managing conflicts with key assignments used by an assistive technology, the browser, or the operating system.</li>
        </ul>
        <p>
          Methods for designing a key shortcut scheme that supports learning and memory is beyond the scope of this guide.
          Unless the key shortcut scheme is extensive, it is likely sufficient to mimic concepts that are familiar from common desktop software, such as browsers.
          Similarly, while localization is important, describing how to address it is left to other resources that specialize in that topic.
        </p>
        <p>
          The remainder of this section provides guidance balancing requirements and concerns related to key assignment conflicts.
          It is typically ideal if key assignments do not conflict with keys that are assigned to functions in the user's operating system, browser, or assistive technology.
          Conflicts can block efficient access to functions that are essential to the user, and a perfect storm of conflicts can trap a user.
          At the same time, there are some circumstances where intentional conflicts are useful.
          And, given the vast array of operating system, browser, and assistive technology keys, it is almost impossible to be certain conflicts do not exist.
          So it is also important to employ strategies that mitigate the impact of conflicts whether they are intentional or unknown.
        </p>
        <p class="note">
          In the following sections, <kbd>meta</kbd> key refers to the <kbd>Windows</kbd> key on Windows-compatible keyboards and the <kbd>Command</kbd> key on MacOS-compatible keyboards.
        </p>
        <section id="kbd_shortcuts_assignments_opsys_conflicts">
          <h5>Operating System Key Conflicts</h5>

          <p> It is essential to avoid conflicts with keys that perform system level functions, such as application and window management and display and sound control. In general, this can be achieved by refraining from the following types of assignments. </p>

          <ol>
            <li>Any modifier keys + any of <kbd>Tab</kbd>, <kbd>Enter</kbd>, <kbd>Space</kbd>, or <kbd>Escape</kbd>.</li>

            <li><kbd>Meta</kbd> key + any other single key (there are exceptions, but they can be risky as these keys can change across versions of operating systems). </li>

            <li><kbd>Alt</kbd> + a function key.</li>
          </ol>

          <p>
            In addition, there are some important application level features that most applications, including browsers, generally support.
            These include:
          </p>

          <ol>
            <li>Zoom</li>
            <li>Copy/Paste</li>
            <li> ... to be continued ... </li>
          </ol>
        </section>

        <section id="kbd_shortcuts_assignments_assistivetech_conflicts">
          <h5>Assistive Technology Key Conflicts</h5>

          <p>
            Even though assistive technologies have collectively taken thousands of key assignments, avoiding conflicts is relatively easy.
            This is because assistive technologies have had to develop key assignment schemes that avoid conflicts with both operating systems and applications.
            They do this by hijacking specific keys as modifiers that uniquely define their key commands.
            For example, many assistive technologies use the <kbd>Caps Lock</kbd> key as a modifier.
          </p>

          <p>Deflect assistive technology key conflicts by steering clear of the following types of assignments. </p>

          <ol>
            <li><kbd>Caps Lock</kbd> + any other combination of keys.</li>
            <li><kbd>Insert</kbd> + any combination of other keys.</li>
            <li><kbd>Scroll Lock</kbd> + any combination of other keys.</li>
            <li>macOS only: <kbd>Control+Option</kbd> + any combination of other keys.</li>
          </ol>
        </section>

        <section id="kbd_shortcuts_assignments_browser_conflicts">
          <h5>Browser Key Conflicts</h5>

          <p> While there is considerable similarity among browser keyboard schemes, the patterns within the schemes are less homogenous. Consequently, it is more difficult to avoid conflicts with browser key assignments. While the impact of conflicts is sometimes mitigated by the availability of two paths to nearly every function -- keyboard accessible menus and keyboard shortcuts, avoiding conflicts with shortcuts to heavily used functions is nonetheless important. Pay special attention to avoiding conflicts with shortcuts to: </p>

          <ol>
            <li>Address or location bar</li>
            <li>Notification bar</li>
            <li>Page refresh</li>
            <li>Bookmark and history functions</li>
            <li>Find functions</li>
          </ol>
        </section>
        <section id="kbd_shortcuts_assignments_intentional_conflicts">
          <h5>Intentional Key Conflicts</h5>

          <p>
            While avoiding key conflicts is usually desirable, there are circumstances where intentionally conflicting with a browser function is acceptable or even desirable.
            This can occur when the following combination of conditions arises:
          </p>

          <ul>
            <li>A web application has a frequently used function that is similar to a browser function.</li>
            <li>Users will often want to execute the web application function.</li>
            <li>Users will rarely execute the browser function.</li>
            <li>There is an efficient, alternative path to the browser function.</li>
          </ul>

          <p>For example, consider a save function that is available when the focus is in an editor. Most browsers use ... to be continued ...</p>
        </section>
      </section>
    </section>
  </section>

  <section id="gridAndTableProperties">
    <h2>Grid and Table Properties</h2>
    <p>
      To fully present and describe a grid or table, in addition to parsing the headers, rows, and cells using the roles described in the
      <a href="#grid">grid pattern</a> or <a href="#table">table pattern</a>,
      assistive technologies need to be able to determine:
    </p>
    <ul>
      <li>The number of rows and columns.</li>
      <li>Whether any columns or rows are hidden, e.g., columns 1 through 3 and  5 through 8 are visible but column 4 is hidden.</li>
      <li>Whether a cell spans multiple rows or columns.</li>
      <li>Whether and how data is sorted.</li>
    </ul>
    <p>
      Browsers automatically populate their accessibility tree with the number of rows and columns in a grid or table based on the rendered DOM.
      However, there are many situations where the DOM does not contain the whole grid or table, such as when the data set is too large to fully render.
      Additionally, some of this information, like skipped columns or rows and how data is sorted, cannot be derived from the DOM structure.
    </p>
    <p>The below sections explain how to use the following properties that ARIA provides for grid and table accessibility.</p>
    <table class="widget-features">
      <caption>Grid and Table Property Definitions</caption>
      <thead>
        <tr>
          <th>Property</th>
          <th>Definition</th>
        </tr>
      </thead>
      <tbody>
        <tr>
          <th><code>aria-colcount</code></th>
          <td>Defines the total number of columns in a <code>table</code>, <code>grid</code>, or <code>treegrid</code>.</td>
        </tr>
        <tr>
          <th><code>aria-rowcount</code></th>
          <td>Defines the total number of rows in a <code>table</code>, <code>grid</code>, or <code>treegrid</code>.</td>
        </tr>
        <tr>
          <th><code>aria-colindex</code></th>
          <td>
            <ul>
              <li>Defines a cell's position with respect to the total number of columns within a <code>table</code>, <code>grid</code>, or <code>treegrid</code>.</li>
              <li><strong>Note:</strong> Numbering starts with 1, not 0.</li>
            </ul>
          </td>
        </tr>
        <tr>
          <th><code>aria-rowindex</code></th>
          <td>
            <ul>
              <li>Defines a cell's position with respect to the total number of rows within a <code>table</code>, <code>grid</code>, or <code>treegrid</code>.</li>
              <li><strong>Note:</strong> Numbering starts with 1, not 0.</li>
            </ul>
          </td>
        </tr>
        <tr>
          <th><code>aria-colspan</code></th>
          <td>Defines the number of columns spanned by a cell or gridcell within a <code>table</code>, <code>grid</code>, or <code>treegrid</code>.</td>
        </tr>
        <tr>
          <th><code>aria-rowspan</code></th>
          <td>Defines the number of rows spanned by a cell or gridcell within a <code>table</code>, <code>grid</code>, or <code>treegrid</code>.</td>
        </tr>
        <tr>
          <th><code>aria-sort</code></th>
          <td>Indicates if items in a row or column are sorted in ascending or descending order.</td>
        </tr>
      </tbody>
    </table>
    <section id="gridAndTableProperties_rows">
      <h3>Using <code>aria-rowcount</code> and <code>aria-rowindex</code></h3>
      <p>
        When the number of rows represented by the DOM structure is not the total number of rows available for a table, grid, or treegrid,
        the  <code>aria-rowcount</code>  property is used to communicate the total number of rows available,
        and it is accompanied by the <code>aria-rowindex</code> property to identify the row indices of the rows that are present in the DOM.
      </p>
      <p>
        The <code>aria-rowcount</code> is specified on the element with the <code>table</code>, <code>grid</code>, or <code>treegrid</code> role.
        Its value is an integer equal to the total number of rows available, including header rows.
        If the total number of rows is unknown, a value of <code>-1</code> may be specified.
        Using a value of <code>-1</code> indicates that more rows are available to include in the DOM without specifying the size of the available supply.
      </p>
      <p>
        When <code>aria-rowcount</code> is used on a <code>table</code>, <code>grid</code>, or <code>treegrid</code>,
        a value for <code>aria-rowindex</code> property is specified on each of its descendant rows, including any header rows.
        The value of <code>aria-rowindex</code> is an integer that is:
      </p>
      <ol>
        <li>Greater than or equal to 1.</li>
        <li>Greater than the value of <code>aria-rowindex</code> on any previous rows.</li>
        <li>Set to the index of the first row in the span if cells span multiple rows.</li>
        <li>Less than or equal to the total number of rows.</li>
      </ol>
      <p>
        <strong>WARNING!</strong> Missing or inconsistent values of <code>aria-rowindex</code> could have devastating effects on assistive technology behavior.
        For example, specifying an invalid value for <code>aria-rowindex</code> or setting it on some but not all rows in a table, could cause screen reader table reading functions to skip rows or simply stop functioning.
      </p>
      <p>
        The following code demonstrates the use of <code>aria-rowcount</code> and <code>aria-rowindex</code> properties on a table containing a hypothetical class list.
      </p>
      <pre>
        <code>
          &lt;!--
            aria-rowcount tells assistive technologies the actual size of the grid
            is 463 rows even though only 4 rows are present in the markup.
          --&gt;
          &lt;table role=&quot;grid&quot; aria-rowcount=&quot;463&quot;&gt;
            aria-label=&quot;Student roster for history 101&quot;
            &lt;thead&gt;
              &lt;tr aria-rowindex=&quot;1&quot;&gt;
                &lt;th&gt;Last Name&lt;/th&gt;
                &lt;th&gt;First Name&lt;/th&gt;
                &lt;th&gt;E-mail&lt;/th&gt;
                &lt;th&gt;Major&lt;/th&gt;
                &lt;th&gt;Minor&lt;/th&gt;
                &lt;th&gt;Standing&lt;/th&gt;
              &lt;/tr&gt;
            &lt;/thead&gt;
            &lt;tbody&gt;
                &lt;!--
                  aria-rowindex tells assistive technologies that this
                  row is row 51 in the grid of 463 rows.
                --&gt;
              &lt;tr aria-rowindex=&quot;51&quot;&gt;
                &lt;td&gt;Henderson&lt;/td&gt;
                &lt;td&gt;Alan&lt;/td&gt;
                &lt;td&gt;ahederson56@myuniveristy.edu&lt;/td&gt;
                &lt;td&gt;Business&lt;/td&gt;
                &lt;td&gt;Spanish&lt;/td&gt;
                &lt;td&gt;Junior&lt;/td&gt;
              &lt;/tr&gt;
                &lt;!--
                  aria-rowindex tells assistive technologies that this
                  row is row 52 in the grid of 463 rows.
                --&gt;
              &lt;tr aria-rowindex=&quot;52&quot;&gt;
                &lt;td&gt;Henderson&lt;/td&gt;
                &lt;td&gt;Alice&lt;/td&gt;
                &lt;td&gt;ahederson345@myuniveristy.edu&lt;/td&gt;
                &lt;td&gt;Engineering&lt;/td&gt;
                &lt;td&gt;none&lt;/td&gt;
                &lt;td&gt;Sophomore&lt;/td&gt;
              &lt;/tr&gt;
                &lt;!--
                  aria-rowindex tells assistive technologies that this
                  row is row 53 in the grid of 463 rows.
                --&gt;
              &lt;tr aria-rowindex=&quot;53&quot;&gt;
                &lt;td&gt;Henderson&lt;/td&gt;
                &lt;td&gt;Andrew&lt;/td&gt;
                &lt;td&gt;ahederson75@myuniveristy.edu&lt;/td&gt;
                &lt;td&gt;General Studies&lt;/td&gt;
                &lt;td&gt;none&lt;/td&gt;
                &lt;td&gt;Freshman&lt;/td&gt;
              &lt;/tr&gt;
            &lt;/tbody&gt;
          &lt;/table&gt;
        </code>
      </pre>
    </section>
    <section id="gridAndTableProperties_cols">
      <h3>Using <code>aria-colcount</code> and <code>aria-colindex</code></h3>
      <p>
        When the number of columns represented by the DOM structure is not the total number of columns available for a table, grid, or treegrid,
        the  <code>aria-colcount</code>  property is used to communicate the total number of columns available,
        and it is accompanied by the <code>aria-colindex</code> property to identify the column indices of the columns that are present in the DOM.
      </p>
      <p>
        The <code>aria-colcount</code> is specified on the element with the <code>table</code>, <code>grid</code>, or <code>treegrid</code> role.
        Its value is an integer equal to the total number of columns available.
        If the total number of columns is unknown, a value of <code>-1</code> may be specified.
        Using a value of <code>-1</code> indicates that more columns are available to include in the DOM without specifying the size of the available supply.
      </p>
      <p>
        When <code>aria-colcount</code> is used on a <code>table</code>, <code>grid</code>, or <code>treegrid</code>,
        a value for <code>aria-colindex</code> property is either specified on each of its descendant rows or on every cell in each descendant row, depending on whether the columns are contiguous as described below.
        The value of <code>aria-colindex</code> is an integer that is:
      </p>
      <ol>
        <li>Greater than or equal to 1.</li>
        <li>When set on a cell, greater than the value set on any previous cell within the same row.</li>
        <li>Set to the index of the first column in the span if a cell spans multiple columns.</li>
        <li>Less than or equal to the total number of columns.</li>
      </ol>
      <p>
        <strong>WARNING!</strong> Missing or inconsistent values of <code>aria-colindex</code> could have devastating effects on assistive technology behavior.
        For example, specifying an invalid value for <code>aria-colindex</code> or setting it on some but not all cells in a row, could cause screen reader table reading functions to skip cells or simply stop functioning.
      </p>
      <section id="gridAndTableProperties_cols_contiguous">
        <h4>Using <code>aria-colindex</code> When Column Indices Are Contiguous</h4>
        <p>
          When all the cells in a row have column index numbers that are consecutive integers,
          <code>aria-colindex</code> can be set on the row element with a value equal to the index number of the first column in the set.
          Browsers will then compute a column number for each cell in the row.
        </p>
        <p>
          The following code shows a grid with 16 columns, of which columns 2 through 5 are displayed to the user.
          Because the set of columns is contiguous, <code>aria-colindex</code> can be placed on each row.
        </p>
        <pre>
        <code>
&lt;div role="grid" aria-colcount="16"&gt;
  &lt;div role="rowgroup"&gt;
    &lt;div role="row" <strong>aria-colindex="2"</strong>&gt;
      &lt;span role="columnheader"&gt;First Name&lt;/span&gt;
      &lt;span role="columnheader"&gt;Last Name&lt;/span&gt;
      &lt;span role="columnheader"&gt;Company&lt;/span&gt;
      &lt;span role="columnheader"&gt;Address&lt;/span&gt;
    &lt;/div&gt;
  &lt;/div&gt;
  &lt;div role="rowgroup"&gt;
    &lt;div role="row" <strong>aria-colindex="2"</strong>&gt;
      &lt;span role="gridcell"&gt;Fred&lt;/span&gt;
      &lt;span role="gridcell"&gt;Jackson&lt;/span&gt;
      &lt;span role="gridcell"&gt;Acme, Inc.&lt;/span&gt;
      &lt;span role="gridcell"&gt;123 Broad St.&lt;/span&gt;
    &lt;/div&gt;
    &lt;div role="row" <strong>aria-colindex="2"</strong>&gt;
      &lt;span role="gridcell"&gt;Sara&lt;/span&gt;
      &lt;span role="gridcell"&gt;James&lt;/span&gt;
      &lt;span role="gridcell"&gt;Acme, Inc.&lt;/span&gt;
      &lt;span role="gridcell"&gt;123 Broad St.&lt;/span&gt;
    &lt;/div&gt;
   &#8230;
  &lt;/div&gt;
&lt;/div&gt;
</code>
</pre>
      </section>
      <section id="gridAndTableProperties_cols_noncontiguous">
        <h4>Using <code>aria-colindex</code> When Column Indices Are Not Contiguous</h4>
        <p>
          When the cells in a row have column index numbers that are not consecutive integers, <code>aria-colindex</code> needs to be set on each cell in the row.
          The following example shows a grid for an online grade book where the first two columns contain a student name and subsequent columns contain scores.
          In this example, the first two columns with the student name are shown, but the score columns have been scrolled to show columns 10 through 13.
          Columns 3 through 9 are not visible so are not in the DOM.
        </p>
        <pre>
          <code>
            &lt;table role=&quot;grid&quot; aria-rowcount=&quot;463&quot; aria-colcount=&quot;13&quot;&gt;
              aria-label=&quot;Student grades for history 101&quot;
              &lt;!--
                aria-rowcount and aria-colcount tell assistive technologies
                the actual size of the grid is 463 rows by 13 columns,
                which is not the number rows and columns found in the markup.
              --&gt;
              &lt;thead&gt;
                &lt;tr aria-rowindex=&quot;1&quot;&gt;
                  &lt;!--
                    aria-colindex tells assistive technologies that the
                    following columns represent columns 1 and 2 of the total data set.
                  --&gt;
                  &lt;th aria-colindex=&quot;1&quot;&gt;Last Name&lt;/th&gt;
                  &lt;th aria-colindex=&quot;2&quot;&gt;First Name&lt;/th&gt;
                  &lt;!--
                    aria-colindex tells users of assistive technologies that the
                    following columns represent columns 10, 11, 12, and 13 of
                    the overall data set of grades.
                  --&gt;
                  &lt;th aria-colindex=&quot;10&quot;&gt;Homework 4&lt;/th&gt;
                  &lt;th aria-colindex=&quot;11&quot;&gt;Quiz 2&lt;/th&gt;
                  &lt;th aria-colindex=&quot;12&quot;&gt;Homework 5&lt;/th&gt;
                  &lt;th aria-colindex=&quot;13&quot;&gt;Homework 6&lt;/th&gt;
                &lt;/tr&gt;
              &lt;/thead&gt;
              &lt;tbody&gt;
                &lt;tr aria-rowindex=&quot;50&quot;&gt;
                  &lt;!--
                    every cell needs to define the aria-colindex attribute
                  --&gt;
                  &lt;td aria-colindex=&quot;1&quot;&gt;Henderson&lt;/td&gt;
                  &lt;td aria-colindex=&quot;2&quot;&gt;Alan&lt;/td&gt;
                  &lt;td aria-colindex=&quot;10&quot;&gt;8&lt;/td&gt;
                  &lt;td aria-colindex=&quot;11&quot;&gt;25&lt;/td&gt;
                  &lt;td aria-colindex=&quot;12&quot;&gt;9&lt;/td&gt;
                  &lt;td aria-colindex=&quot;13&quot;&gt;9&lt;/td&gt;
                &lt;/tr&gt;
                &lt;tr aria-rowindex=&quot;51&quot;&gt;
                  &lt;td aria-colindex=&quot;1&quot;&gt;Henderson&lt;/td&gt;
                  &lt;td aria-colindex=&quot;2&quot;&gt;Alice&lt;/td&gt;
                  &lt;td aria-colindex=&quot;10&quot;&gt;10&lt;/td&gt;
                  &lt;td aria-colindex=&quot;11&quot;&gt;27&lt;/td&gt;
                  &lt;td aria-colindex=&quot;12&quot;&gt;10&lt;/td&gt;
                  &lt;td aria-colindex=&quot;13&quot;&gt;8&lt;/td&gt;
                &lt;/tr&gt;
                &lt;tr aria-rowindex=&quot;52&quot;&gt;
                  &lt;td aria-colindex=&quot;1&quot;&gt;Henderson&lt;/td&gt;
                  &lt;td aria-colindex=&quot;2&quot;&gt;Andrew&lt;/td&gt;
                  &lt;td aria-colindex=&quot;10&quot;&gt;9&lt;/td&gt;
                  &lt;td aria-colindex=&quot;11&quot;&gt;0&lt;/td&gt;
                  &lt;td aria-colindex=&quot;12&quot;&gt;29&lt;/td&gt;
                  &lt;td aria-colindex=&quot;13&quot;&gt;8&lt;/td&gt;
                &lt;/tr&gt;
              &lt;/tbody&gt;
            &lt;/table&gt;
          </code>
        </pre>
      </section>
    </section>
    <section id="gridAndTableProperties_spans">
      <h3>Defining cell spans using <code>aria-colspan</code> and <code>aria-rowspan</code></h3>
      <p>
        For tables, grids, and treegrids  created using elements other than HTML <code>table</code> elements,
        row and column spans are defined with the <code>aria-rowspan</code> and <code>aria-colspan</code> properties.
      </p>
      <p>The value of <code>aria-colspan</code> is an integer that is:</p>
      <ol>
        <li>Greater than or equal to 1.</li>
        <li>less than the value that would cause the cell to overlap the next cell in the same row.</li>
      </ol>
      <p>The value of <code>aria-rowspan</code> is an integer that is:</p>
      <ol>
        <li>Greater than or equal to 0.</li>
        <li>0 means the cell spans all the remaining rows in its row group.</li>
        <li>less than the value that would cause the cell to overlap the next cell in the same column.</li>
      </ol>
      <p>
        The following example grid has a two row header.
        The first two columns have headers that span both rows of the header.
        The subsequent 6 columns are grouped into 3 pairs with headers in the first row that each span two columns.
      </p>
      <pre>
        <code>
          &lt;div role=&quot;grid&quot; aria-rowcount=&quot;463&quot;&gt;
            aria-label=&quot;Student grades for history 101&quot;
            &lt;div role=&quot;rowgroup&quot;&gt;
              &lt;div role=&quot;row&quot; aria-rowindex=&quot;1&quot;&gt;
                  &lt;!--
                    aria-rowspan and aria-colspan provide
                    assistive technologies with the correct data cell header information
                    when header cells span more than one row or column.
                  --&gt;
                  &lt;span role="columnheader" aria-rowspan=&quot;2&quot;&gt;Last Name&lt;/span&gt;
                  &lt;span role="columnheader" aria-rowspan=&quot;2&quot;&gt;First Name&lt;/span&gt;
                  &lt;span role="columnheader" aria-colspan=&quot;2&quot;&gt;Test 1&lt;/span&gt;
                  &lt;span role="columnheader" aria-colspan=&quot;2&quot;&gt;Test 2&lt;/span&gt;
                  &lt;span role="columnheader" aria-colspan=&quot;2&quot;&gt;Final&lt;/span&gt;
              &lt;/div&gt;
              &lt;div role=&quot;row&quot; aria-rowindex=&quot;2&quot;&gt;
                  &lt;span role="columnheader"&gt;Score&lt;/span&gt;
                  &lt;span role="columnheader"&gt;Grade&lt;/span&gt;
                  &lt;span role="columnheader"&gt;Score&lt;/span&gt;
                  &lt;span role="columnheader"&gt;Grade&lt;/span&gt;
                  &lt;span role="columnheader"&gt;Total&lt;/span&gt;
                  &lt;span role="columnheader"&gt;Grade&lt;/span&gt;
              &lt;/div&gt;
            &lt;/div&gt;
            &lt;div role=&quot;rowgroup&quot;&gt;
              &lt;div role=&quot;row&quot; aria-rowindex=&quot;50&quot;&gt;
                &lt;span role=&quot;cell&quot;&gt;Henderson&lt;/span&gt;
                &lt;span role=&quot;cell&quot;&gt;Alan&lt;/span&gt;
                &lt;span role=&quot;cell&quot;&gt;89&lt;/span&gt;
                &lt;span role=&quot;cell&quot;&gt;B+&lt;/span&gt;
                &lt;span role=&quot;cell&quot;&gt;72&lt;/span&gt;
                &lt;span role=&quot;cell&quot;&gt;C&lt;/span&gt;
                &lt;span role=&quot;cell&quot;&gt;161&lt;/span&gt;
                &lt;span role=&quot;cell&quot;&gt;B-&lt;/span&gt;
              &lt;/div&gt;
              &lt;div role=&quot;row&quot;  aria-rowindex=&quot;51&quot;&gt;
                &lt;span role=&quot;cell&quot;&gt;Henderson&lt;/span&gt;
                &lt;span role=&quot;cell&quot;&gt;Alice&lt;/span&gt;
                &lt;span role=&quot;cell&quot;&gt;94&lt;/span&gt;
                &lt;span role=&quot;cell&quot;&gt;A&lt;/span&gt;
                &lt;span role=&quot;cell&quot;&gt;86&lt;/span&gt;
                &lt;span role=&quot;cell&quot;&gt;B&lt;/span&gt;
                &lt;span role=&quot;cell&quot;&gt;180&lt;/span&gt;
                &lt;span role=&quot;cell&quot;&gt;A-&lt;/span&gt;
              &lt;/div&gt;
              &lt;div role=&quot;row&quot;  aria-rowindex=&quot;52&quot;&gt;
                &lt;span role=&quot;cell&quot;&gt;Henderson&lt;/span&gt;
                &lt;span role=&quot;cell&quot;&gt;Andrew&lt;/span&gt;
                &lt;span role=&quot;cell&quot;&gt;82&lt;/span&gt;
                &lt;span role=&quot;cell&quot;&gt;B-&lt;/span&gt;
                &lt;span role=&quot;cell&quot;&gt;95&lt;/span&gt;
                &lt;span role=&quot;cell&quot;&gt;A&lt;/span&gt;
                &lt;span role=&quot;cell&quot;&gt;177&lt;/span&gt;
                &lt;span role=&quot;cell&quot;&gt;B+&lt;/span&gt;
              &lt;/div&gt;
            &lt;/div&gt;
          &lt;/div&gt;
        </code>
      </pre>
      <p>
        <strong>Note:</strong> When using HTML <code>table</code> elements,
        use the native semantics of the <code>th</code> and <code>td</code> elements to define row and column spans
        by using the <code>rowspan</code> and <code>colspan</code> attributes.
      </p>
    </section>
    <section id="gridAndTableProperties_sort">
      <h3>Indicating sort order with <code>aria-sort</code></h3>
      <p>
        When rows or columns are sorted, the <code>aria-sort</code> property can be applied to a column or row header to indicate the sorting method.
        The following table describes allowed values for <code>aria-sort</code>.
      </p>
      <table class="widget-features">
        <caption>
          Description of values for <code>aria-sort</code>
        </caption>
        <thead>
          <tr>
            <th>Value</th>
            <th>Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <th><code>ascending</code></th>
            <td>Data are sorted in ascending order.</td>
          </tr>
          <tr>
            <th><code>descending</code></th>
            <td>Data are sorted in descending order.</td>
          </tr>
          <tr>
            <th><code>other</code></th>
            <td>Data are sorted by an algorithm other than ascending or descending.</td>
          </tr>
          <tr>
            <th><code>none</code></th>
            <td>Default (no sort applied).</td>
          </tr>
        </tbody>
      </table>
      <p>
        It is important to note that ARIA does not provide a way to indicate levels of sort for data sets that have multiple sort keys.
        Thus, there is limited value to applying <code>aria-sort</code> with a value other than <code>none</code> to more than one column or row.
      </p>
      <p>The following example grid uses <code>aria-sort</code> to indicate the rows are sorted from the highest "Quiz 2" score to the lowest "Quiz 2" score.</p>
      <pre>
        <code>
          &lt;table role=&quot;grid&quot; aria-rowcount=&quot;463&quot; aria-colcount=&quot;13&quot;
            aria-label=&quot;Student grades for history 101&quot;&gt;
            &lt;thead&gt;
              &lt;tr aria-colindex=&quot;10&quot; aria-rowindex=&quot;1&quot;&gt;
                &lt;th&gt;Homework 4&lt;/th&gt;
                &lt;!--
                  aria-sort indicates the column with the heading
                  "Quiz 2" has been used to sort the rows of the grid.
                --&gt;
                &lt;th aria-sort=&quot;descending&quot;&gt;Quiz 2&lt;/th&gt;
                &lt;th&gt;Homework 5&lt;/th&gt;
                &lt;th&gt;Homework 6&lt;/th&gt;
              &lt;/tr&gt;
            &lt;/thead&gt;
            &lt;tbody&gt;
              &lt;tr aria-colindex=&quot;10&quot; aria-rowindex=&quot;50&quot;&gt;
                &lt;td&gt;8&lt;/td&gt;
                &lt;td&gt;30&lt;/td&gt;
                &lt;td&gt;9&lt;/td&gt;
                &lt;td&gt;9&lt;/td&gt;
              &lt;/tr&gt;
              &lt;tr aria-colindex=&quot;10&quot;  aria-rowindex=&quot;51&quot;&gt;
                &lt;td&gt;10&lt;/td&gt;
                &lt;td&gt;29&lt;/td&gt;
                &lt;td&gt;10&lt;/td&gt;
                &lt;td&gt;8&lt;/td&gt;
              &lt;/tr&gt;
              &lt;tr aria-colindex=&quot;10&quot;  aria-rowindex=&quot;52&quot;&gt;
                &lt;td&gt;9&lt;/td&gt;
                &lt;td&gt;9&lt;/td&gt;
                &lt;td&gt;27&lt;/td&gt;
                &lt;td&gt;6&lt;/td&gt;
              &lt;/tr&gt;
              &lt;tr aria-colindex=&quot;10&quot;  aria-rowindex=&quot;53&quot;&gt;
                &lt;td&gt;9&lt;/td&gt;
                &lt;td&gt;10&lt;/td&gt;
                &lt;td&gt;26&lt;/td&gt;
                &lt;td&gt;8&lt;/td&gt;
              &lt;/tr&gt;
              &lt;tr aria-colindex=&quot;10&quot;  aria-rowindex=&quot;54&quot;&gt;
                &lt;td&gt;9&lt;/td&gt;
                &lt;td&gt;7&lt;/td&gt;
                &lt;td&gt;24&lt;/td&gt;
                &lt;td&gt;6&lt;/td&gt;
              &lt;/tr&gt;
            &lt;/tbody&gt;
          &lt;/table&gt;
        </code>
      </pre>


    </section>

  </section>

  <section id="range_related_properties">
    <h2>Communicating Value and Limits for Range Widgets</h2>
    <p>
      ARIA defines the following roles as range widgets, which means they communicate a value that is typically numeric and constrained to defined limits.
    </p>
    <ul>
      <li><code>meter</code></li>
      <li><code>progressbar</code></li>
      <li><code>scrollbar</code></li>
      <li><code>separator</code> (if focusable)</li>
      <li><code>slider</code></li>
      <li><code>spinbutton</code></li>
    </ul>
    <p>
      For example, a spin button for choosing a day within the month of January would allow integer values that range from 1 to 31.
      In some cases, the value is represented numerically, but is not presented as a number to users.
      For instance, a spin button for choosing a day of the week could support values from 1 to 7 but they could be presented to the user as day names, e.g., "Monday", "Tuesday", etc.
    </p>
    <p>
      This section describes considerations for using the following four properties that communicate characteristics of a range widget:
    </p>
    <table>
      <thead>
        <tr>
          <th>Property</th>
          <th>Definition</th>
        </tr>
      </thead>
      <tbody>
        <tr>
          <th><code>aria-valuemin</code></th>
          <td>Defines the minimum value allowed by a range widget.</td>
        </tr>
        <tr>
          <th><code>aria-valuemax</code></th>
          <td>Defines the maximum value allowed by a range widget.</td>
        </tr>
        <tr>
          <th><code>aria-valuenow</code></th>
          <td>Defines the current value of a range widget. This value is a number greater than or equal to <code>aria-valuemin</code> and less than or equal to <code>aria-valuemax</code> (if they are specified).</td>
        </tr>
        <tr>
          <th><code>aria-valuetext</code></th>
          <td>If a numeric value is not sufficiently descriptive, this property can define a text description of the current value of a range widget.</td>
        </tr>
      </tbody>
    </table>

    <section id="range_related_properties_using_aria-valuemin_aria-valuemax_and_aria-valuenow">
      <h3>Using <code>aria-valuemin</code>, <code>aria-valuemax</code> and <code>aria-valuenow</code></h3>
      <p>
        When the value of a range widget is constrained to known limits, the <code>aria-valuemin</code> and <code>aria-valuemax</code> properties are used to inform assistive technologies of the minimum and maximum values of the range.
        For some widgets, assistive technologies use this information to present the current value as a percentage.
        When using these properties, set <code>aria-valuemin</code> to the lowest value allowed for the widget and <code>aria-valuemax</code> to the highest allowed value.
        If values for <code>aria-valuemin</code> and <code>aria-valuemax</code> are not set, default values are exposed to assistive technologies unless the widget is a <code>spinbutton</code>, which is the only range widget that does not have default limits.
      </p>
      <p>
        The <code>aria-valuenow</code> property is used to inform assistive technologies of the current value of a range widget.
        Set <code>aria-valuenow</code> to the current value of the widget, ensuring the value of <code>aria-valuenow</code> falls within the range defined by <code>aria-valuemin</code> and <code>aria-valuemax</code>.
        If the current value of a <code>progressbar</code> or <code>spinbutton</code> is indeterminate or unknown, omit the <code>aria-valuenow</code> property.
        The <code>aria-valuenow</code> property is required for the <code>meter</code>, <code>scrollbar</code>, <code>separator</code> (if the element is focusable), and <code>slider</code> roles.
      </p>
      <p>
        The range widget roles have the following default values and requirements for <code>aria-valuemin</code>, <code>aria-valuemax</code> and <code>aria-valuenow</code>.
      </p>
      <table>
        <thead>

          <tr>
            <th scope="col">Role</th>
            <th scope="col"><code>aria-valuemin</code><br>(default)</th>
            <th scope="col"><code>aria-valuemax</code><br>(default)</th>
            <th scope="col"><code>aria-valuemin</code><br>(required)</th>
            <th scope="col"><code>aria-valuemax</code><br>(required)</th>
            <th scope="col"><code>aria-valuenow</code><br>(required)</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <th scope="row"><code>meter</code></th>
            <td>0</td>
            <td>100</td>
            <td>No</td>
            <td>No</td>
            <td>Yes</td>
          </tr>
          <tr>
            <th scope="row"><code>progressbar</code></th>
            <td>0</td>
            <td>100</td>
            <td>No</td>
            <td>No</td>
            <td>No</td>
          </tr>
          <tr>
            <th scope="row"><code>scrollbar</code></th>
            <td>0</td>
            <td>100</td>
            <td>No</td>
            <td>No</td>
            <td>Yes</td>
          </tr>
          <tr>
            <th scope="row"><code>separator</code> <small>(if focusable)</small></th>
            <td>0</td>
            <td>100</td>
            <td>No</td>
            <td>No</td>
            <td>Yes</td>
          </tr>
          <tr>
            <th scope="row"><code>slider</code></th>
            <td>0</td>
            <td>100</td>
            <td>No</td>
            <td>No</td>
            <td>Yes</td>
          </tr>
          <tr>
            <th scope="row"><code>spinbutton</code></th>
            <td>None</td>
            <td>None</td>
            <td>No</td>
            <td>No</td>
            <td>No</td>
          </tr>
        </tbody>
      </table>
    </section>

    <section id="range_related_properties_using_aria-valuetext">
      <h3>Using <code>aria-valuetext</code></h3>

      <p>
        When the element's values are contained within a range but those values are not numeric (such as "small", "medium" and "large"),
        or they are numeric but there is value in communicating more information than just a number,
        <code>aria-valuetext</code> is used to surface the text value to assistive technologies.
        Only use <code>aria-valuetext</code> when <code>aria-valuenow</code> is not sufficiently meaningful for users because using <code>aria-valuetext</code> will prevent assistive technologies from communicating <code>aria-valuenow</code>.
      </p>

      <div class="example">
        <p>
          For example, for a battery indicator, it would be useful to know how many minutes are remaining, in addition to the percentage of charge remaining.
        </p>

        <pre><code>
  &lt;span id="battery-label">Battery&lt;/span>
  &lt;span role="meter" aria-labelledby="battery-label"
    aria-valuenow="5"
    aria-valuetext="5%, 18 minutes remaining.">
  &lt;/span>
        </code></pre>
      </div>
    </section>

    <section id="range_related_properties_meter_role">
      <h3>Range properties with meter</h3>
      <p>
        The <code>aria-valuemin</code> and <code>aria-valuemax</code> properties only need to be set for elements with role <code>meter</code> if the meter's minimum value is not 0 or its maximum value is not 100.
        It is necessary, however, to always specify a value for <code>aria-valuenow</code> and to ensure the value is greater than or equal to the minimum allowed value and less than or equal to the maximum allowed value.
        A detailed description of the <code>meter</code> role is in the <a href="#meter">meter design pattern</a>.</p>

      <p>This example of a meter shows the current Central Processing Unit (CPU) usage. </p>

      <pre><code>&lt;span id="cpu_usage_label">CPU usage&lt;/span>
&lt;!-- The CPU usage uses the default values of 0 and 100 for aria-valuemin and aria-valuemax --&gt;
&lt;div role="meter"
      aria-valuenow="90"
      aria-labelledby="cpu_usage_label"&gt;
&lt;/div&gt;</code></pre>

      <p>
        The <code>aria-valuetext</code> property can be set to a string that makes the meter value understandable. For example, a CPU usage meter value might be conveyed as <code>aria-valuetext="90% of CPU is being used"</code>.
      </p>
      <p>Here is another example of a meter that has a range different from the default of 0 for <code>aria-valuemin</code> and 100 for <code>aria-valuemax</code>.</p>

      <pre><code>&lt;span id="ph_alkaline_meter_label">Alkaline pH(Power of Hydrogen) Level&lt;/span>
&lt;div role="meter"
        aria-valuenow="9"
        aria-valuemin="7"
        aria-valuemax="14"
        aria-labelledby="ph_alkaline_meter_label"&gt;
&lt;/div&gt;</code></pre>
    </section>
    <section id="range_related_properties_progressbar_role">
      <h3>Range properties with progress bars</h3>

      <p>
        The <code>aria-valuemin</code> and <code>aria-valuemax</code> properties only need to be set for the <code>progressbar</code> role when the progress bar's minimum is not 0 or the maximum value is not 100.
        The aria-valuenow property needs to be set for a <code>progressbar</code> if its value is known (e.g. not indeterminate).
        If the <code>aria-valuenow</code> property is set, the author needs to make sure it is within the minimum and maximum values.
      </p>
      <p>Following is an example of a progress bar represented by an SVG.</p>

      <pre><code>&lt;div&gt;&lt;span id="loadlabel"&gt;Loading:&lt;/span&gt;
  &lt;!-- The progress bar uses the default values of 0 and 100 for aria-valuemin and aria-valuemax --&gt;
  &lt;span role="progressbar"
        aria-labelledby="loadlabel"
        aria-valuenow="33" &gt;
    &lt;svg width="100" height="10"&gt;
      &lt;rect x="0" y="0" height="10" width="100" stroke="black" fill="none"/&gt;
      &lt;rect x="0" y="0" height="10" width="33" fill="green" /&gt;
    &lt;/svg&gt;
  &lt;/span&gt;
&lt;/div&gt;</code></pre>
      <p>This progress bar can also be made using the native HTML <code>progress</code> element.</p>

      <pre><code>&lt;label for="loadstatus"&gt;Loading:&lt;/label&gt;
&lt;progress id="loadstatus" max="100" value="33"&gt;&lt;/progress&gt;
      </code></pre>

      <p>To represent an indeterminate progress bar where the value range is unknown, omit the <code>aria-valuenow</code> attribute.</p>

      <pre><code>&lt;img role="progressbar" src="spinner.gif" alt="Loading..."&gt;</code></pre>
    </section>

    <section id="range_related_properties_scrollbar_role">
      <h3>Range properties with scrollbars</h3>

      <p>
        The <code>aria-valuemin</code> and <code>aria-valuemax</code> properties only need to be set for the <code>scrollbar</code> role when it's minimum value is not 0 or the maximum value is not 100.   The <code>aria-valuenow</code> property is required for <code>scrollbar</code> and the author needs to make sure it is within the minimum and maximum values.
      </p>
      <p>
        <code>aria-valuenow</code> will generally be exposed as a percentage between <code>aria-valuemin</code> and <code>aria-valuemax</code> calculated by assistive technologies.
      </p>

      <pre><code>&lt;span id="pi-label"&gt;Pi&lt;/div&gt;
&lt;div id="pi"&gt;
3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679
&lt;/div&gt;
&lt;div class="rail"&gt;
&lt;!-- The scrollbar uses the default values of 0 and 100 for aria-valuemin and aria-valuemax --&gt;
  &lt;div
    class="thumb"
    role="scrollbar"
    aria-labelledby="pi-label"
    aria-controls="pi"
    aria-orientation="horizontal"
    aria-valuenow="25"&gt;
  &lt;/div&gt;
&lt;/div&gt;</code></pre>


    </section>

    <section id="range_related_properties_slider_role">
      <h3>Range properties with sliders</h3>
      <p>
        The <code>aria-valuemin</code> and <code>aria-valuemax</code> properties only need to be set for the <code>slider</code> role when the slider's minimum is not 0 or the maximum value is not 100.
        The <code>aria-valuenow</code> property is required for <code>slider</code> role and the author needs to make sure it is within the minimum and maximum values.
        A detailed description of the <code>slider</code> role can be found in the <a href="#slider">slider design pattern</a> and <a href="#slidertwothumb">slider (multi-thumb) design pattern</a>.
      </p>
      <p>
        The following example shows a temperature controller.
        In this example, <code>aria-valuenow</code> is meaningful to the user, and so <code>aria-valuetext</code> is not used.
      </p>
      <pre><code>&lt;div class="rail"&gt;
  &lt;div id="thumb" role="slider" aria-valuemin="50" aria-valuenow="68" aria-valuemax="100"
       aria-label="Temperature (F)" tabindex="0"&gt;
  &lt;/div&gt;
&lt;/div&gt;</code></pre>
      <p>The slider example above can be made using the HTML <code>&lt;input type="range"></code> element.</p>
      <pre><code>&lt;input type="range" min="50" value="68" max="100" aria-label="Temperature (F)"&gt;
      </code></pre><p>The following example is a fan control. The <code>aria-valuenow</code> value is "1", which is not meaningful to the user. The <code>aria-valuetext</code> property is used so that assistive technology will surface its value ("low") instead.</p>
      <pre><code>&lt;div class="rail"&gt;
  &lt;div id="thumb" role="slider" aria-valuemin="0" aria-valuenow="1" aria-valuemax="3"
       aria-valuetext="low" aria-label="Fan speed" tabindex="0" &gt;
  &lt;/div&gt;
  &lt;div class="value"&gt; Off &lt;/div&gt;
  &lt;div class="value"&gt; Low &lt;/div&gt;
  &lt;div class="value"&gt; Medium &lt;/div&gt;
  &lt;div class="value"&gt; High &lt;/div&gt;
&lt;/div&gt;</code></pre>
    </section>

    <section id="range_related_properties_spinbutton_role">
      <h3>Range properties with spin buttons</h3>

      <p>
        The <code>aria-valuemin</code> and <code>aria-valuemax</code> properties are used only when a <code>spinbutton</code> has a defined range.
        They do not have default values, so if they are not specified, range limits will not be exposed to assistive technologies.
        Similarly, the <code>aria-valuenow</code> property is set only when a <code>spinbutton</code> has a value.
        If it is not set, a value is not exposed to assistive technologies for the <code>spinbutton</code>.
        <code>aria-valuetext</code> can be used when appropriate.
        A detailed description of the <code>spinbutton</code> role can be found in the <a href="#spinbutton">spinbutton design pattern</a>.
      </p>

      <p>The following example sets the price of paperclips in cents.</p>

      <pre><code>&lt;div role="spinbutton" aria-labelledby="price-label" aria-valuenow="50" tabindex="0"&gt;
  &lt;button id="lower-price"&gt;Lower&lt;/button&gt;
  &lt;button id="raise-price"&gt;Raise&lt;/button&gt;
  &lt;span id="price-label"&gt;Price per paperclip: $&lt;/span&gt;&lt;span id="price"&gt;0.50&lt;/span&gt;
&lt;/div&gt;</code></pre>

      <p>If there are minimum and maximum allowed values, set the <code>aria-valuemin</code> and <code>aria-valuemax</code> properties.</p>

      <pre><code>&lt;div role="spinbutton" aria-labelledby="price-label"
      aria-valuemin="1" aria-valuenow="50" aria-valuemax="200" tabindex="0"&gt;
  &lt;button id="lower-price"&gt;Lower&lt;/button&gt;
  &lt;button id="raise-price"&gt;Raise&lt;/button&gt;
  &lt;span id="price-label"&gt;Price per paperclip: $&lt;/span&gt;&lt;span id="price"&gt;0.50&lt;/span&gt;
&lt;/div&gt;</code></pre>

      <p>The spin button example above can be made using the native HTML <code>&lt;input type="number"></code> element.</p>

      <pre><code>&lt;label&gt;Price per paperclip: $&lt;input type="number" min="0.01" value="0.5" max="2" step="0.01"&gt;&lt;/label&gt;</code></pre>
    </section>
  </section>

  <section id="presentation_role">
    <h2>Intentionally Hiding Semantics with the <code>presentation</code> Role</h2>
    <p>
      While ARIA is primarily used to express semantics, there are some situations where hiding an
      element’s semantics from assistive technologies is helpful. This is done with the
      <a href="#presentation" class="role-reference">presentation</a>
      role, which declares that an element is being used only for presentation and therefore does
      not have any accessibility semantics. The ARIA 1.1 specification also includes role
      <a href="#none" class="role-reference">none</a>,
      which serves as a synonym for <code>presentation</code>.
    </p>
    <p>
      For example, consider a tabs widget built using an HTML <code>ul</code> element.
    </p>
    <pre>
    &lt;ul role=&quot;tablist&quot;&gt;
      &lt;li role=&quot;presentation&quot;&gt;
        &lt;a role=&quot;tab&quot; href=&quot;#&quot;&gt;Tab 1&lt;/a&gt;
      &lt;/li&gt;
      &lt;li role=&quot;presentation&quot;&gt;
        &lt;a role=&quot;tab&quot; href=&quot;#&quot;&gt;Tab 2&lt;/a&gt;
      &lt;/li&gt;
      &lt;li role=&quot;presentation&quot;&gt;
        &lt;a role=&quot;tab&quot; href=&quot;#&quot;&gt;Tab 3&lt;/a&gt;
      &lt;/li&gt;
    &lt;/ul&gt;
    </pre>
    <p>
      Because the list is declared to be a tablist, the list items are not in a list context. It
      could confuse users if an assistive technology were to render those list items. Applying role
      <code>presentation</code> to the <code>li</code> elements tells browsers to leave those
      elements out of their accessibility tree. Assistive technologies will thus be unaware of the
      list item elements and see the tab elements as immediate children of the tablist.
    </p>
    <p>
      Three common uses of role <code>presentation</code> are:
    </p>
    <ol>
      <li>Hiding a decorative image; it is equivalent to giving the image null alt text. </li>
      <li>Suppressing table semantics of tables used for layout in circumstances where the table semantics do not convey meaningful relationships.</li>
      <li>Eliminating semantics of intervening orphan elements in the structure of a composite
        widget, such as a tablist, menu, or tree as demonstrated in the example above.</li>
    </ol>
    <section id="presentation_role_effects">
      <h3>
        Effects of Role <code>presentation</code>
      </h3>
      <p>
        When <code>role=&quot;presentation&quot;</code> is specified on an element, if a
        <a href="#presentation_role_ignored">condition that requires a browser to ignore the <code>presentation</code> role</a>
        does not exist, it has the following three effects.
      </p>
      <ol>
        <li>The element’s implied ARIA role and any ARIA states and properties associated with
          that role are hidden from assistive technologies.</li>
        <li>
          Text contained by the element, i.e., inner text, as well as inner text of all its
          descendant elements remains visible to assistive technologies except, of course, when the
          text is explicitly hidden, e.g., styled with <code>display: none</code> or has <code>aria-hidden=&quot;true&quot;</code>.
        </li>
        <li>
          The roles, states, and properties of each descendant element remain visible to assistive
          technologies unless the descendant requires the context of the presentational
          element. For example:
          <ul>
            <li> If <code>presentation</code> is applied to a <code>ul</code> or <code>ol</code> element, each child <code>li</code> element inherits the <code>presentation</code> role because ARIA requires the <code>listitem</code> elements to have the parent <code>list</code> element. So, the <code>li</code> elements are not exposed to assistive technologies, but elements contained inside of those <code>li</code> elements, including nested lists, are visible to assistive technologies. </li>
            <li>
              Similarly, if <code>presentation</code> is applied to a <code>table</code> element,
              the descendant <code>caption</code>, <code>thead</code>, <code>tbody</code>, <code>tfoot</code>,
              <code>tr</code>, <code>th</code>, and <code>td</code>
              elements inherit role <code>presentation</code> and are thus not exposed to assistive technologies.
              But, elements inside of the <code>th</code> and <code>td</code> elements, including nested tables,  are exposed to assistive technologies.
            </li>
          </ul>
        </li>
      </ol>
    </section>
    <section id="presentation_role_ignored">
      <h3>
        Conditions That Cause Role <code>presentation</code> to be Ignored
      </h3>
      <p>
         Browsers ignore <code>role=&quot;presentation&quot;</code>, and it therefore has no effect, if either of the following are true about the element to which it is applied:</p>
          <ul>
            <li>The element is focusable, e.g. it is natively focusable like an HTML link or input, or it has a <code>tabindex</code> attribute.</li>
            <li>
              The element has any of the
              <a href="#global_states" class="specref">twenty-one global ARIA states and properties</a>,
              e.g., <code>aria-label</code>.
            </li>
          </ul>
    </section>
    <section id="presentation_role_examples">
      <h3>
        Example Demonstrating Effects of the <code>presentation</code> Role
      </h3>
      <p>This code:</p>
      <pre>
        &lt;ul role=&quot;presentation&quot;&gt;
          &lt;li&gt;Date of birth:&lt;/li&gt;
          &lt;li&gt;January 1, 3456&lt;/li&gt;
        &lt;/ul&gt;
      </pre>
      <p>when parsed by a browser, is equivalent to the following from the perspective of a screen reader or other assistive technology that relies on the browser's accessibility tree:
      </p>
      <pre>
        &lt;div&gt;Date of birth:&lt;/div&gt;
          &lt;div&gt;January 1, 3456&lt;/div&gt;
      </pre>
    </section>
  </section>

  <section id="children_presentational">
    <h2>Roles That Automatically Hide Semantics by Making Their Descendants Presentational</h2>
    <p>
      There are some types of user interface components that, when represented in a platform
      accessibility API, can only contain text. For example, accessibility APIs do not have a way of
      representing semantic elements contained in a button. To deal with this limitation, WAI-ARIA
      requires browsers to automatically apply role <code>presentation</code> to all descendant
      elements of any element with a role that cannot support semantic children.
    </p>
    <p>The roles that require all children to be presentational are:</p>
    <ul>
      <li>button</li>
      <li>checkbox</li>
      <li>img</li>
      <li>meter</li>
      <li>menuitemcheckbox</li>
      <li>menuitemradio</li>
      <li>option</li>
      <li>progressbar</li>
      <li>radio</li>
      <li>scrollbar</li>
      <li>separator</li>
      <li>slider</li>
      <li>switch</li>
      <li>tab</li>
    </ul>
    <p>For instance, consider the following tab element, which contains a heading.</p>
    <pre>
      &lt;li role=&quot;tab&quot;&gt;&lt;h3&gt;Title of My Tab&lt;/h3&gt;&lt;/li&gt;
    </pre>
    <p>
      Because WAI-ARIA requires descendants of tab to be presentational,
      the following code is equivalent.
    </p>
    <pre>
      &lt;li role=&quot;tab&quot;&gt;&lt;h3 role=&quot;presentation&quot;&gt;Title of My Tab&lt;/h3&gt;&lt;/li&gt;
    </pre>
    <p>
      And, from the perspective of anyone using a technology that relies on an accessibility API, such as a screen reader,
      the heading does not exist since the previous code is equivalent to the following.
    </p>
    <pre>
      &lt;li role=&quot;tab&quot;&gt;Title of My Tab&lt;/li&gt;
    </pre>
    <p>
      See the
      <a href="#presentation_role">
        section about role <code>presentation</code>
      </a>
      for a detailed explanation of what it does.
    </p>
  </section>

  <section id="structural_roles">
    <h2>Structural Roles</h2>
    <p>
      ARIA provides a set of roles that convey the accessibility semantics of structures on a page.
      These roles express the meaning that is conveyed by the layout and appearance of elements that organize and structure content, such as headings, lists, and tables.
    </p>
    <p>
      some host languages, such as HTML, include elements that express the same semantics as an ARIA role.
      For instance, the HTML <code>&lt;p&gt;</code> element is mapped to accessibility APIs in exactly the same way as <code>&lt;div role="paragraph"&gt;</code>.
      The ARIA and HTML specifications refer to this mapping of HTML elements to ARIA attributes as implied semantics, i.e., the implied ARIA role of the HTML <code>&lt;p&gt;</code> element is <code>paragraph</code>.
    </p>
    <p>
      When developing HTML, it is important to use native HTML elements where ever possible.
      Do not use an ARIA role or property if it is possible to use an HTML element that has equivalent semantics.
      Circumstances where it is appropriate to use ARIA attributes instead of equivalent HTML are:
    </p>
    <ol>
      <li>When the HTML element cannot be styled in a way that meets visual design requirements.</li>
      <li>When testing reveals that browsers or assistive technologies provide better support for the ARIA equivalent.</li>
      <li>When remediating or retrofitting legacy content and altering the underlying DOM to use the HTML would be cost prohibitive.</li>
      <li>When building a web component to compose a <a href="https://html.spec.whatwg.org/multipage/#custom-elements">custom element</a> and the element being extended  does not convey the appropriate or sufficient accessibility semantics.</li>
    </ol>
    <p>The following table lists all structural roles defined in ARIA 1.2.</p>
    <table class="widget-features">
      <caption>ARIA structural roles</caption>
      <thead>
        <tr>
          <th>ARIA Role</th>
          <th>HTML Equivalent</th>
        </tr>
      </thead>
      <tbody>
        <tr><th>application</th><td>No equivalent element</td></tr>
        <tr><th>article</th><td>article</td></tr>
        <tr><th>blockquote</th><td>blockquote</td></tr>
        <tr><th>caption</th><td>caption</td></tr>
        <tr><th>cell</th><td>td</td></tr>
        <tr><th>code</th><td>code</td></tr>
        <tr><th>columnheader</th><td>th</td></tr>
        <tr><th>definition</th><td>dd</td></tr>
        <tr><th>deletion</th><td>del</td></tr>
        <tr><th>directory</th><td>No equivalent element</td></tr>
        <tr><th>document</th><td>No equivalent element</td></tr>
        <tr><th>emphasis</th><td>em</td></tr>
        <tr><th>feed</th><td>No equivalent element</td></tr>
        <tr><th>figure</th><td>figure</td></tr>
        <tr><th>generic</th><td>div, span</td></tr>
        <tr><th>group</th><td>No equivalent element</td></tr>
        <tr><th>heading with aria-level="N" where N is 1, 2, 3, 4, 5, or 6</th><td>h1, h2, h3, h4, h5, h6</td></tr>
        <tr><th>insertion</th><td>ins</td></tr>
        <tr><th>img</th><td>img</td></tr>
        <tr><th>list</th><td>ul, ol</td></tr>
        <tr><th>listitem</th><td>li</td></tr>
        <tr><th>math</th><td>No equivalent element</td></tr>
        <tr><th>none</th><td>No equivalent element</td></tr>
        <tr><th>note</th><td>No equivalent element</td></tr>
        <tr><th>presentation</th><td>No equivalent element</td></tr>
        <tr><th>paragraph</th><td>p</td></tr>
        <tr><th>row</th><td>tr</td></tr>
        <tr><th>rowgroup</th><td>tbody, thead, tfoot</td></tr>
        <tr><th>rowheader</th><td>th</td></tr>
        <tr><th>separator (when not focusable)</th><td>hr</td></tr>
        <tr><th>strong</th><td>strong</td></tr>
        <tr><th>subscript</th><td>sub</td></tr>
        <tr><th>superscript</th><td>sup</td></tr>
        <tr><th>table</th><td>table</td></tr>
        <tr><th>term</th><td>dfn</td></tr>
        <tr><th>time</th><td>time</td></tr>
        <tr><th>toolbar</th><td>No equivalent element</td></tr>
        <tr><th>tooltip</th><td>No equivalent element</td></tr>
      </tbody>
    </table>
  </section>

  <section id="indexes" class="appendix">
    <h2>Indexes</h2>
    <ul>
      <li><a href="examples/#examples_by_role_label">Design Pattern Examples by Role</a></li>
      <li><a href="examples/#examples_by_props_label">Design Pattern Examples by Properties and States</a> </li>
    </ul>
  </section>

  <section id="change_log" class="appendix">
    <h2>Change History</h2>
    <p>Change history is maintained in a separate version-specific branch.</p>
  </section>

  <section id="acknowledgements" class="appendix">
    <h2>Acknowledgements</h2>
    <section>
      <h3>Major Contributors to Version 1.1</h3>
      <p>
        While WAI-ARIA Authoring Practices 1.1 is the work of the entire Authoring Practices Task Force and also benefits from many people throughout the open source community who both contribute significant work and provide valuable feedback,
        special thanks goes to the following people who provided distinctly large portions of the content and code in version 1.1.
      </p>
      <ul>
        <li>Jon Gunderson and Nicholas Hoyt  of the Division of Disability Resources and Education Services at the University of Illinois Urbana/Champaign and the students Max Foltz,  Sulaiman Sanaullah, Mark McCarthy, and Jinyuan Zhou for their contributions to the development of many of the design pattern examples.</li>
        <li>Valerie Young of Bocoup and her sponsor, Facebook, for development of the example test framework and regressions tests for more than 50 examples.</li>
        <li>Simon Pieters of Bocoup and his sponsor, Facebook, for authoring of significant guidance sections, including comprehensive treatment of the topic of accessible names and descriptions.</li>
      </ul>
    </section>
  	<section>
  		<h3>Participants active in the ARIA Authoring Practices Task Force</h3>
  		<ul>
  			<li>Ann Abbott (Invited Expert)</li>
  			<li>Shirisha Balusani (Microsoft Corporation)</li>
        <li>Dorothy Bass (Wells Fargo Bank N.A.)</li>
  			<li>Curt Bellew (Oracle)</li>
  			<li>Zoë Bijl (Invited Expert)</li>
  			<li>Michael Cooper (W3C)</li>
  			<li>Bryan Garaventa (Level Access)</li>
  			<li>Jon Gunderson (University of Illinois at Urbana-Champaign)</li>
        <li>Jesse Hausler(Salesforce)</li>
        <li>Sarah Higley (Microsoft Corporation)</li>
  			<li>Hans Hillen (The Paciello Group, LLC)</li>
  			<li>Matt King (Facebook)</li>
  			<li>Jaeun Ku (University of Illinois at Urbana-Champaign)</li>
  			<li>Aaron Leventhal (Google)</li>
        <li>Carolyn MacLeod (IBM Corporation)</li>
  			<li>Mark McCarthy (University of Illinois at Urbana-Champaign)</li>
  			<li>James Nurthen (Adobe)</li>
        <li>Scott O'Hara (The Paciello Group, LLC)</li>
        <li>Simon Pieters (Bocoup)</li>
        <li>Scott Vinkle (Shopify)</li>
  			<li>Evan Yamanishi (W. W. Norton)</li>
  			<li>Valerie Young (Bocoup)</li>
  		</ul>
  	</section>
  	<section>
  		<h3>Other commenters and contributors to Version 1.1</h3>
  		<ul>
  			<li>Vyacheslav Aristov</li>
  			<li>J. Renée Beach</li>
  			<li>Kasper Christensen</li>
  			<li>Gerard K. Cohen</li>
  			<li>Anne-Gaelle Colom</li>
  			<li>Kevin Coughlin</li>
  			<li>Cameron Cundiff</li>
  			<li>Manish Dahamiwal</li>
  			<li>Gilmore Davidson</li>
  			<li>Boris Dušek</li>
  			<li>Michael Fairchild</li>
  			<li>Jeremy Felt</li>
  			<li>Rob Fentress</li>
  			<li>Geppy</li>
  			<li>Tatiana Iskandar</li>
  			<li>Patrick Lauke</li>
  			<li>Marek Lewandowski</li>
  			<li>Dan Matthew</li>
  			<li>Shane McCarron</li>
  			<li>Victor Meyer</li>
  			<li>Jonathan Neal</li>
  			<li>Philipp Rudloff</li>
  			<li>Joseph Scheuhammer</li>
  			<li>Nick Schonning</li>
  			<li>thomascorthals</li>
  			<li>Christopher Tryens</li>
  		</ul>
  	</section>

  	<div data-include='common/acknowledgements/funders.html' data-include-replace='true'></div>

  </section>
</body>
</html>