From 8d8a9e63479345367027a6df82cb61186663b4dc Mon Sep 17 00:00:00 2001 From: Matt King Date: Sun, 15 Sep 2024 16:25:12 -0700 Subject: [PATCH 01/10] Start drafting listview and listviewitem --- index.html | 1641 ++++++++++++++++++++++++++++++---------------------- 1 file changed, 965 insertions(+), 676 deletions(-) diff --git a/index.html b/index.html index b887e641d..77a82fa3c 100644 --- a/index.html +++ b/index.html @@ -120,35 +120,35 @@ group: "aria", maxTocLevel: 4, - // Spec URLs - ariaSpecURLs: { - "ED": "https://w3c.github.io/aria/", - "FPWD": "https://www.w3.org/TR/wai-aria-1.3/", - "WD": "https://www.w3.org/TR/wai-aria-1.3/", - "CR": "https://www.w3.org/TR/wai-aria-1.3/", - "REC": "https://www.w3.org/TR/wai-aria-1.3/", - }, - accNameURLs: { - "ED": "https://w3c.github.io/accname/", - "WD" : "https://www.w3.org/TR/accname-1.2/", - "FPWD": "https://www.w3.org/TR/accname-1.2/", - "CR" : "https://www.w3.org/TR/accname-1.2/", - "REC": "https://www.w3.org/TR/accname-1.2/" - }, - coreMappingURLs: { - "ED": "https://w3c.github.io/core-aam/", - "WD" : "https://www.w3.org/TR/core-aam-1.2/", - "FPWD": "https://www.w3.org/TR/core-aam-1.2/", - "CR": "https://www.w3.org/TR/core-aam-1.2/", - "REC": "https://www.w3.org/TR/core-aam-1.2/" - }, - practicesURLs: { - "ED": "https://www.w3.org/WAI/ARIA/apg/", - "WD" : "https://www.w3.org/WAI/ARIA/apg/", - "FPWD": "https://www.w3.org/WAI/ARIA/apg/", - "CR": "https://www.w3.org/WAI/ARIA/apg/", - "REC": "https://www.w3.org/WAI/ARIA/apg/" - }, + // Spec URLs + ariaSpecURLs: { + "ED": "https://w3c.github.io/aria/", + "FPWD": "https://www.w3.org/TR/wai-aria-1.3/", + "WD": "https://www.w3.org/TR/wai-aria-1.3/", + "CR": "https://www.w3.org/TR/wai-aria-1.3/", + "REC": "https://www.w3.org/TR/wai-aria-1.3/", + }, + accNameURLs: { + "ED": "https://w3c.github.io/accname/", + "WD" : "https://www.w3.org/TR/accname-1.2/", + "FPWD": "https://www.w3.org/TR/accname-1.2/", + "CR" : "https://www.w3.org/TR/accname-1.2/", + "REC": "https://www.w3.org/TR/accname-1.2/" + }, + coreMappingURLs: { + "ED": "https://w3c.github.io/core-aam/", + "WD" : "https://www.w3.org/TR/core-aam-1.2/", + "FPWD": "https://www.w3.org/TR/core-aam-1.2/", + "CR": "https://www.w3.org/TR/core-aam-1.2/", + "REC": "https://www.w3.org/TR/core-aam-1.2/" + }, + practicesURLs: { + "ED": "https://www.w3.org/WAI/ARIA/apg/", + "WD" : "https://www.w3.org/WAI/ARIA/apg/", + "FPWD": "https://www.w3.org/WAI/ARIA/apg/", + "CR": "https://www.w3.org/WAI/ARIA/apg/", + "REC": "https://www.w3.org/WAI/ARIA/apg/" + }, preProcess: [ linkCrossReferences ], postProcess: [ ariaAttributeReferences ], @@ -274,12 +274,12 @@

Important Terms

Accessibility API
-

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

+

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

Accessible object
-

A [=nodes|node=] in the accessibility tree of a platform accessibility API. Accessible objects expose various states, [=ARIA/properties=], and events for use by assistive technologies. In the context of markup languages (e.g., HTML and SVG) in general, and of WAI-ARIA in particular, markup [=elements=] and their [=attributes=] are represented as accessible objects.

+

A [=nodes|node=] in the accessibility tree of a platform accessibility API. Accessible objects expose various states, [=ARIA/properties=], and events for use by assistive technologies. In the context of markup languages (e.g., HTML and SVG) in general, and of WAI-ARIA in particular, markup [=elements=] and their [=attributes=] are represented as accessible objects.

Assistive Technologies

Hardware and/or software that:

@@ -288,61 +288,61 @@

Important Terms

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

    This definition might differ from that used in other documents.

    +

    This definition might differ from that used in other documents.

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

    + of this document include the following:

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

    A deprecated role, state, or property is one which has been outdated by newer constructs or changed circumstances, and which might be removed in future versions of the WAI-ARIA specification. [=user agents=] are encouraged to continue to support items identified as deprecated for backward compatibility. For more information, see Deprecated Requirements in the Conformance section.

    +

    A deprecated role, state, or property is one which has been outdated by newer constructs or changed circumstances, and which might be removed in future versions of the WAI-ARIA specification. [=user agents=] are encouraged to continue to support items identified as deprecated for backward compatibility. For more information, see Deprecated Requirements in the Conformance section.

    Defines
    -

    Used in an attribute description to denote that the value type is an integer, number, or string.

    -

    Related Terms: Identifies, Indicates

    +

    Used in an attribute description to denote that the value type is an integer, number, or string.

    +

    Related Terms: Identifies, Indicates

    Desktop focus event
    -

    Event from/to the host operating system via the accessibility API, notifying of a change of input focus.

    +

    Event from/to the host operating system via the accessibility API, notifying of a change of input focus.

    Event
    -

    A programmatic message used to communicate discrete changes in the state of an object to other objects in a computational system. User input to a web page is commonly mediated through abstract events that describe the interaction and can provide notice of changes to the state of a document object. In some programming languages, events are more commonly known as notifications.

    +

    A programmatic message used to communicate discrete changes in the state of an object to other objects in a computational system. User input to a web page is commonly mediated through abstract events that describe the interaction and can provide notice of changes to the state of a document object. In some programming languages, events are more commonly known as notifications.

    Expose
    -

    Translated to platform-specific accessibility APIs as defined in the Core Accessibility API Mappings.

    +

    Translated to platform-specific accessibility APIs as defined in the Core Accessibility API Mappings.

    Graphical Document
    -

    A document containing graphic representations with user-navigable parts. Charts, maps, diagrams, blueprints, and dashboards are examples of graphical documents. A graphical document is composed using any combination of symbols, images, text, and graphic primitives (shapes such as circles, points, lines, paths, rectangles, etc).

    +

    A document containing graphic representations with user-navigable parts. Charts, maps, diagrams, blueprints, and dashboards are examples of graphical documents. A graphical document is composed using any combination of symbols, images, text, and graphic primitives (shapes such as circles, points, lines, paths, rectangles, etc).

    Hidden
    -

    Indicates that the element is excluded from the accessibility tree and therefore not exposed to accessibility APIs.

    -

    Related: Excluding Elements in the Accessibility Tree, [=element/hidden from all users=], aria-hidden.

    +

    Indicates that the element is excluded from the accessibility tree and therefore not exposed to accessibility APIs.

    +

    Related: Excluding Elements in the Accessibility Tree, [=element/hidden from all users=], aria-hidden.

    Hidden From All Users
    -

    Indicates that the element is not visible, perceivable, or interactive for any user. Note that an element can be [=element/hidden=] but not [=element/hidden from all users=] by using aria-hidden.

    -

    Related: Excluding Elements in the Accessibility Tree, [=element/hidden=], aria-hidden.

    +

    Indicates that the element is not visible, perceivable, or interactive for any user. Note that an element can be [=element/hidden=] but not [=element/hidden from all users=] by using aria-hidden.

    +

    Related: Excluding Elements in the Accessibility Tree, [=element/hidden=], aria-hidden.

    Identifies
    -

    Used in an attribute description to denote that the value type is an ID reference (identifying a single element) or ID reference list (identifying one or more elements).

    -

    Related Terms: Defines, Indicates

    +

    Used in an attribute description to denote that the value type is an ID reference (identifying a single element) or ID reference list (identifying one or more elements).

    +

    Related Terms: Defines, Indicates

    Indicates
    -

    Used in an attribute description to denote that the value type is a named token or otherwise token-like, including the Boolean-like true/false, true/false/undefined, tristate (true/false/mixed), a single named token, or a token list.

    -

    Related Terms: Defines, Identifies

    +

    Used in an attribute description to denote that the value type is a named token or otherwise token-like, including the Boolean-like true/false, true/false/undefined, tristate (true/false/mixed), a single named token, or a token list.

    +

    Related Terms: Defines, Identifies

    Keyboard Accessible
    @@ -350,15 +350,15 @@

    Important Terms

    Landmark
    -

    A type of region on a page to which the user might want quick access. Content in such a region is different from that of other regions on the page and relevant to a specific user purpose, such as navigating, searching, perusing the primary content, etc.

    +

    A type of region on a page to which the user might want quick access. Content in such a region is different from that of other regions on the page and relevant to a specific user purpose, such as navigating, searching, perusing the primary content, etc.

    Live Region
    -

    Live regions are perceivable regions of a web page that are typically updated as a result of an external event. These regions are not always updated as a result of a user interaction and can receive these updates even when they do not have focus. Examples of live regions include a chat log, stock ticker, or a sport scoring section that updates periodically to reflect game statistics. Since these asynchronous areas are expected to update outside the user's area of focus, assistive technologies such as screen readers have either been unaware of their existence or unable to process them for the user. WAI-ARIA has provided a collection of properties that allow the author to identify these live regions and process them: aria-live, aria-relevant, aria-atomic, and aria-busy.

    +

    Live regions are perceivable regions of a web page that are typically updated as a result of an external event. These regions are not always updated as a result of a user interaction and can receive these updates even when they do not have focus. Examples of live regions include a chat log, stock ticker, or a sport scoring section that updates periodically to reflect game statistics. Since these asynchronous areas are expected to update outside the user's area of focus, assistive technologies such as screen readers have either been unaware of their existence or unable to process them for the user. WAI-ARIA has provided a collection of properties that allow the author to identify these live regions and process them: aria-live, aria-relevant, aria-atomic, and aria-busy.

    Managed State
    -

    Accessibility API state that is controlled by the user agent, such as focus and selection. These are contrasted with "unmanaged states" that are typically controlled by the author. Nevertheless, authors can override some managed states, such as aria-posinset and aria-setsize. Many managed states have corresponding CSS pseudo-classes, such as :focus, and pseudo-elements, such as ::selection, that are also updated by the user agent.

    +

    Accessibility API state that is controlled by the user agent, such as focus and selection. These are contrasted with "unmanaged states" that are typically controlled by the author. Nevertheless, authors can override some managed states, such as aria-posinset and aria-setsize. Many managed states have corresponding CSS pseudo-classes, such as :focus, and pseudo-elements, such as ::selection, that are also updated by the user agent.

    Nemeth Braille
    @@ -366,43 +366,43 @@

    Important Terms

    Object
    -

    In the context of user interfaces, an item in the perceptual user experience, represented in markup languages by one or more [=elements=], and rendered by [=user agents=].

    +

    In the context of user interfaces, an item in the perceptual user experience, represented in markup languages by one or more [=elements=], and rendered by [=user agents=].

    In the context of programming, the instantiation of one or more classes and interfaces which define the general characteristics of similar objects. An object in an accessibility API can represent one or more DOM objects. Accessibility APIs have defined interfaces that are distinct from DOM interfaces.
    Ontology
    -

    A description of the characteristics of classes and how they relate to each other.

    +

    A description of the characteristics of classes and how they relate to each other.

    Operable
    -

    Usable by users in ways they can control. References in this document relate to WCAG 2.1 Principle 2: Content must be operable [[WCAG21]]. See Keyboard Accessible.

    +

    Usable by users in ways they can control. References in this document relate to WCAG 2.1 Principle 2: Content must be operable [[WCAG21]]. See Keyboard Accessible.

    Perceivable
    -

    Presentable to users in ways they can sense. References in this document relate to WCAG 2.1 Principle 1: Content must be perceivable [[WCAG21]].

    +

    Presentable to users in ways they can sense. References in this document relate to WCAG 2.1 Principle 1: Content must be perceivable [[WCAG21]].

    Property
    -

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

    +

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

    Relationship
    -

    A connection between two distinct things. Relationships can be of various types to indicate which object labels another, controls another, etc.

    +

    A connection between two distinct things. Relationships can be of various types to indicate which object labels another, controls another, etc.

    Role
    -

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

    +

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

    Semantics
    -

    The meaning of something as understood by a human, defined in a way that computers can process a representation of an object, such as [=elements=] and [=attributes=], and reliably represent the object in a way that various humans will achieve a mutually consistent understanding of the object.

    +

    The meaning of something as understood by a human, defined in a way that computers can process a representation of an object, such as [=elements=] and [=attributes=], and reliably represent the object in a way that various humans will achieve a mutually consistent understanding of the object.

    State
    -

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

    +

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

    Target Element
    -

    An element specified in a WAI-ARIA relation. For example, in <div aria-controls=”elem1”>, where “elem1” is the ID for the target element.

    +

    An element specified in a WAI-ARIA relation. For example, in <div aria-controls=”elem1”>, where “elem1” is the ID for the target element.

    Unicode Braille Patterns
    @@ -410,7 +410,7 @@

    Important Terms

    Widget
    -

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

    +

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

    @@ -474,74 +474,74 @@

    WAI-ARIA States a [aria-checked="true"]::before { background-image: url(checked.gif); }

    If CSS is not used to toggle the visual representation of the check mark, the author could include additional markup and scripts to manage an image that represents whether or not the menuitemcheckbox is checked.

    <li role="menuitemcheckbox" aria-checked="true">
-  <img src="checked.gif" alt="">
-  <!-- note: additional scripts required to toggle image source -->
-  Sort by Last Modified
+	<img src="checked.gif" alt="">
+	<!-- note: additional scripts required to toggle image source -->
+	Sort by Last Modified
 </li>
    -

    Managing Focus and Supporting Keyboard Navigation

    -

    When using standard HTML interactive elements and simple WAI-ARIA widgets, application developers can manipulate the tab order or associate keyboard shortcuts with elements in the document.

    -

    WAI-ARIA includes a number of "managing container" widgets, also known as "composite" widgets. When appropriate, the container is responsible for tracking the last descendant that was active (the default is usually the first item in the container). It is essential that a container maintain a usable and consistent strategy when focus leaves a container and is then later refocused. While there can be exceptions, it is recommended that when a previously focused container is refocused, the active descendant be the same element as the active descendant when the container was last focused. Exceptions include cases where the contents of a container widget have changed, and widgets like a menubar where the user expects to always return to the first item when focus leaves the menu bar. For example, if the second item of a tree group was the active descendant when the user tabbed out of the tree group, then the second item of the tree group remains the active descendant when the tree group gets focus again. The user can also activate the container by clicking on one of the descendants within it. When the container or its active descendant has focus, the user can navigate through the container by pressing additional keys, such as the arrow keys, to change the currently active descendant. Any additional press of the main navigation key (generally the TAB key) will move out of the container to the next widget.

    -

    Usable keyboard navigation in a rich internet application is different from the tabbing paradigm among interactive elements, such as links and form controls, in a static document. In rich internet applications, the user tabs to significantly complex widgets, such as a menu or spreadsheet, and uses the arrow keys to navigate within the widget. The changes that WAI-ARIA introduces to keyboard navigation make this enhanced accessibility possible. In WAI-ARIA, any element can be keyboard focusable. In addition to host language mechanisms such as tabindex, aria-activedescendant provides another mechanism for keyboard operation. Most other aspects of WAI-ARIA widget development depend on keyboard navigation functioning properly.

    -

    - When implementing aria-activedescendant as described below, the user agent keeps the DOM focus on the container element or on an input element that controls the container element. - However, the user agent communicates desktop focus events and states to the assistive technology as if the element referenced by aria-activedescendant has focus. - User agents are not expected to validate that the active descendant is a descendant of the container element. - It is the responsibility of the user agent to ensure that keyboard events are processed at the element that has DOM focus. - Any keyboard events directed at the active descendant bubble up to the DOM element with focus for processing. -

    -
    -

    Information for Authors

    -

    If the author removes the element with focus, the author SHOULD move focus to a logical element. Similarly, authors SHOULD not scroll the element with focus off screen unless the user performed a scrolling action.

    -

    Authors SHOULD ensure that all interactive [=elements=] are focusable and that all parts of composite widgets are either focusable or have a documented alternative method to achieve their function.

    -

    Authors MUST manage focus on the following container roles:

    -
      -
    • grid
      • -
    • listbox
      • -
    • menu
      • -
    • menubar
      • -
    • radiogroup
      • -
    • tree
      • -
    • treegrid
      • -
    • tablist
      • -
    -

    User agents that support WAI-ARIA expand the usage of host language mechanisms such as tabindex, focus, and blur to allow them on all [=elements=]. Where the host language supports it, authors MAY add any element such as a div, span, or img to the default tab order by setting tabindex="0". In addition, any item with tabindex equal to a negative integer is focusable via script or a mouse click, but is not part of the default tab order. This is supported in both [[HTML]] and [[SVG2]].

    -

    Authors MAY use aria-activedescendant to inform assistive technologies which descendant of a widget element is treated as having keyboard focus in the user interface if the role of the widget element supports aria-activedescendant. - This is often a more convenient way of providing keyboard navigation within widgets, such as a listbox, where the widget occupies only one stop in the page Tab sequence and other keys, typically arrow keys, are used to focus elements inside the widget.

    -

    Typically, the author will use host language semantics to put the widget in the Tab sequence (e.g., tabindex="0" in HTML) and aria-activedescendant to point to the ID of the currently active descendant. The author, not the user agent, is responsible for styling the currently active descendant to show it has keyboard focus. The author cannot use :focus to style the currently active descendant since the actual focus is on the container.

    -

    More information on managing focus can be found in the Developing a Keyboard Interface section of the WAI-ARIA Authoring Practices.

    -
    -
    -

    Information for User Agents

    -

    The user agent MUST do the following to implement aria-activedescendant:

    -
      -
    1. Implement the host language method for keyboard navigation so that widgets that support aria-activedescendant can be included in the tab order.
      2. -
    2. For platforms that expose desktop focus or accessibility API focus separately from DOM focus, do not expose the focused state in the accessibility API for any element when it has DOM focus and also has aria-activedescendant which points to a valid ID reference.
      3. -
    3. When the aria-activedescendant attribute changes on an element that currently has DOM focus, remove the focused state from the previously focused object and fire an accessibility API desktop focus event on the new element referenced by aria-activedescendant. If aria-activedescendant is cleared or does not point to an element in the current document, fire a desktop focus event for the object that had the attribute change.
      4. -
    4. Apply the following accessibility API states to any element with an ID attribute that can be referenced by an element with both an aria-activedescendant attribute and has DOM focus. There are two ways an element can be referenced by aria-activedescendant. One way is when it is an accessibility descendant of the element with aria-activedescendant and the other is when it is an accessibility descendant of an element that is controlled by an element with role of combobox, textbox or searchbox with an aria-activedescendant attribute: +

      Managing Focus and Supporting Keyboard Navigation

      +

      When using standard HTML interactive elements and simple WAI-ARIA widgets, application developers can manipulate the tab order or associate keyboard shortcuts with elements in the document.

      +

      WAI-ARIA includes a number of "managing container" widgets, also known as "composite" widgets. When appropriate, the container is responsible for tracking the last descendant that was active (the default is usually the first item in the container). It is essential that a container maintain a usable and consistent strategy when focus leaves a container and is then later refocused. While there can be exceptions, it is recommended that when a previously focused container is refocused, the active descendant be the same element as the active descendant when the container was last focused. Exceptions include cases where the contents of a container widget have changed, and widgets like a menubar where the user expects to always return to the first item when focus leaves the menu bar. For example, if the second item of a tree group was the active descendant when the user tabbed out of the tree group, then the second item of the tree group remains the active descendant when the tree group gets focus again. The user can also activate the container by clicking on one of the descendants within it. When the container or its active descendant has focus, the user can navigate through the container by pressing additional keys, such as the arrow keys, to change the currently active descendant. Any additional press of the main navigation key (generally the TAB key) will move out of the container to the next widget.

      +

      Usable keyboard navigation in a rich internet application is different from the tabbing paradigm among interactive elements, such as links and form controls, in a static document. In rich internet applications, the user tabs to significantly complex widgets, such as a menu or spreadsheet, and uses the arrow keys to navigate within the widget. The changes that WAI-ARIA introduces to keyboard navigation make this enhanced accessibility possible. In WAI-ARIA, any element can be keyboard focusable. In addition to host language mechanisms such as tabindex, aria-activedescendant provides another mechanism for keyboard operation. Most other aspects of WAI-ARIA widget development depend on keyboard navigation functioning properly.

      +

      + When implementing aria-activedescendant as described below, the user agent keeps the DOM focus on the container element or on an input element that controls the container element. + However, the user agent communicates desktop focus events and states to the assistive technology as if the element referenced by aria-activedescendant has focus. + User agents are not expected to validate that the active descendant is a descendant of the container element. + It is the responsibility of the user agent to ensure that keyboard events are processed at the element that has DOM focus. + Any keyboard events directed at the active descendant bubble up to the DOM element with focus for processing. +

      +
      +

      Information for Authors

      +

      If the author removes the element with focus, the author SHOULD move focus to a logical element. Similarly, authors SHOULD not scroll the element with focus off screen unless the user performed a scrolling action.

      +

      Authors SHOULD ensure that all interactive [=elements=] are focusable and that all parts of composite widgets are either focusable or have a documented alternative method to achieve their function.

      +

      Authors MUST manage focus on the following container roles:

      +
        +
      • grid
        • +
      • listbox
        • +
      • menu
        • +
      • menubar
        • +
      • radiogroup
        • +
      • tree
        • +
      • treegrid
        • +
      • tablist
        • +
      +

      User agents that support WAI-ARIA expand the usage of host language mechanisms such as tabindex, focus, and blur to allow them on all [=elements=]. Where the host language supports it, authors MAY add any element such as a div, span, or img to the default tab order by setting tabindex="0". In addition, any item with tabindex equal to a negative integer is focusable via script or a mouse click, but is not part of the default tab order. This is supported in both [[HTML]] and [[SVG2]].

      +

      Authors MAY use aria-activedescendant to inform assistive technologies which descendant of a widget element is treated as having keyboard focus in the user interface if the role of the widget element supports aria-activedescendant. + This is often a more convenient way of providing keyboard navigation within widgets, such as a listbox, where the widget occupies only one stop in the page Tab sequence and other keys, typically arrow keys, are used to focus elements inside the widget.

      +

      Typically, the author will use host language semantics to put the widget in the Tab sequence (e.g., tabindex="0" in HTML) and aria-activedescendant to point to the ID of the currently active descendant. The author, not the user agent, is responsible for styling the currently active descendant to show it has keyboard focus. The author cannot use :focus to style the currently active descendant since the actual focus is on the container.

      +

      More information on managing focus can be found in the Developing a Keyboard Interface section of the WAI-ARIA Authoring Practices.

      +
      +
      +

      Information for User Agents

      +

      The user agent MUST do the following to implement aria-activedescendant:

      +
        +
      1. Implement the host language method for keyboard navigation so that widgets that support aria-activedescendant can be included in the tab order.
        2. +
      2. For platforms that expose desktop focus or accessibility API focus separately from DOM focus, do not expose the focused state in the accessibility API for any element when it has DOM focus and also has aria-activedescendant which points to a valid ID reference.
        3. +
      3. When the aria-activedescendant attribute changes on an element that currently has DOM focus, remove the focused state from the previously focused object and fire an accessibility API desktop focus event on the new element referenced by aria-activedescendant. If aria-activedescendant is cleared or does not point to an element in the current document, fire a desktop focus event for the object that had the attribute change.
        4. +
      4. Apply the following accessibility API states to any element with an ID attribute that can be referenced by an element with both an aria-activedescendant attribute and has DOM focus. There are two ways an element can be referenced by aria-activedescendant. One way is when it is an accessibility descendant of the element with aria-activedescendant and the other is when it is an accessibility descendant of an element that is controlled by an element with role of combobox, textbox or searchbox with an aria-activedescendant attribute:
          -
        1. Focusable, if the element also has a WAI-ARIA role. The element needs to be focusable because it could be referenced by the aria-activedescendant attribute. Native elements that have no role attribute do not need to be checked; their native semantics determine the focusable state.
          2. -
        2. Focused, whenever the element is the target of the aria-activedescendant attribute and the element with the aria-activedescendant attribute has DOM focus.
          3. +
        3. Focusable, if the element also has a WAI-ARIA role. The element needs to be focusable because it could be referenced by the aria-activedescendant attribute. Native elements that have no role attribute do not need to be checked; their native semantics determine the focusable state.
          4. +
        4. Focused, whenever the element is the target of the aria-activedescendant attribute and the element with the aria-activedescendant attribute has DOM focus.
        -
        5. -
      -

      When an assistive technology uses its platform's accessibility API to request a change of focus, user agents MUST do the following:

      -
        -
      1. Remove the platform's focused state from the previously focused object.
        2. -
      2. Set the DOM focus: +
        3. +
      +

      When an assistive technology uses its platform's accessibility API to request a change of focus, user agents MUST do the following:

      +
        +
      1. Remove the platform's focused state from the previously focused object.
        2. +
      2. Set the DOM focus:
          -
        1. If the element can take DOM focus, the user agent MUST set the DOM focus to it.
          2. -
        2. Otherwise, if the element being focused has an ID and the ID is referenced by the aria-activedescendant attribute of an element that is focusable, the user agent MUST set DOM focus to the element that has the aria-activedescendant attribute. -

          An element with an ID can be referenced when it is an accessibility descendant of a container element that has the aria-activedescendant attribute or by a container element that is controlled by an element that has the aria-activedescendant attribute (e.g. see combobox). Otherwise the aria-activedescendant attribute reference indicates an author error.

          -

          The inability to set DOM focus to the containing element indicates an author error.

          -
          3. -
        3. Otherwise, the user agent MAY attempt to set DOM focus to the child element itself.
          4. +
        4. If the element can take DOM focus, the user agent MUST set the DOM focus to it.
          5. +
        5. Otherwise, if the element being focused has an ID and the ID is referenced by the aria-activedescendant attribute of an element that is focusable, the user agent MUST set DOM focus to the element that has the aria-activedescendant attribute. +

          An element with an ID can be referenced when it is an accessibility descendant of a container element that has the aria-activedescendant attribute or by a container element that is controlled by an element that has the aria-activedescendant attribute (e.g. see combobox). Otherwise the aria-activedescendant attribute reference indicates an author error.

          +

          The inability to set DOM focus to the containing element indicates an author error.

          +
          6. +
        6. Otherwise, the user agent MAY attempt to set DOM focus to the child element itself.
        -
        3. -
      3. If the element being focused has an ID and is an accessibility descendant of either a container element with both an aria-activedescendant attribute and has DOM focus, or by a container element that is controlled by an element with both an aria-activedescendant attribute and has DOM focus, the user agent MUST set the accessibility API focused state and fire an accessibility API focus event on the element identified by the value of aria-activedescendant.
        4. -
      -
      +
      5. +
    5. If the element being focused has an ID and is an accessibility descendant of either a container element with both an aria-activedescendant attribute and has DOM focus, or by a container element that is controlled by an element with both an aria-activedescendant attribute and has DOM focus, the user agent MUST set the accessibility API focused state and fire an accessibility API focus event on the element identified by the value of aria-activedescendant.
      6. +
    +
    @@ -663,7 +663,7 @@

    Accessible Name Calculation

    1. author: name comes from values provided by the author in explicit markup features such as the aria-label attribute, the aria-labelledby attribute, or the host language labeling mechanism, such as the alt or title attributes in HTML, with HTML title attribute having the lowest precedence for specifying a text alternative.
    2. contents: name comes from the text value of the element node. Although this might be allowed in addition to "author" in some roles, this is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm [[ACCNAME-1.2]].
      3. -
    3. prohibited: the element does not support name from author. Authors MUST NOT use the aria-label or aria-labelledby attributes to name the element.
      4. +
    4. prohibited: the element does not support name from author. Authors MUST NOT use the aria-label or aria-labelledby attributes to name the element.
    @@ -679,21 +679,21 @@

    Description Computation

    Accessible Name and Description Computation

    Accessible Name and Description Computation is defined in the Accessible Name and Description specification.

    -
    -

    Roles Supporting Name from Author

    -
    -
    +
    +

    Roles Supporting Name from Author

    +
    +
    -
    -

    Roles Supporting Name from Content

    -
    -
    +
    +

    Roles Supporting Name from Content

    +
    +
    -

    Roles which cannot be named (Name prohibited)

    -
    -
    -
    +

    Roles which cannot be named (Name prohibited)

    +
    +
    +

    Presentational Children

    @@ -756,8 +756,8 @@

    Widget Roles

  • menuitemradio
  • option
  • progressbar
    • @@ -832,8 +832,8 @@

    Document Structure Roles

  • time
  • toolbar
    • @@ -1238,8 +1238,8 @@

    Definition of Roles

    A landmark that contains mostly site-oriented content, rather than page-specific content.

    Site-oriented content typically includes things such as the logo or identity of the site sponsor, and a site-specific search tool. A banner usually appears at the top of the page and typically spans the full width.

    Assistive technologies SHOULD enable users to quickly navigate to elements with role banner. - [=user agents=] SHOULD treat elements with role banner as navigational landmarks. - [=user agents=] MAY enable users to quickly navigate to elements with role banner.

    + [=user agents=] SHOULD treat elements with role banner as navigational landmarks. + [=user agents=] MAY enable users to quickly navigate to elements with role banner.

    The author SHOULD mark no more than one element on a page with the banner role.

    Because document and application elements can be nested in the DOM, they can have multiple banner elements as DOM descendants, assuming each of those is associated with different document nodes, either by a DOM nesting (e.g., document within document) or by use of the aria-owns attribute.

    @@ -1428,7 +1428,7 @@

    Definition of Roles

    Related Concepts: - link + link @@ -1500,55 +1500,55 @@

    Definition of Roles

     					<div role="radiogroup" aria-labelledby="cap">
-				    <div role="caption" id="cap">
-				      Choose your favorite fruit
-				    </div>
-				    <!-- ... -->
+						<div role="caption" id="cap">
+							Choose your favorite fruit
+						</div>
+						<!-- ... -->

    If a caption contains content that serves as both a name and description for its containing element, authors MAY instead specify aria-labelledby to reference an element within the caption that represents the "name" of the containing element, and specify aria-describedby to reference an element within the caption that represents the descriptive content.

     					<div role="table" aria-labelledby="name" aria-describedby="desc">
-				    <div role="caption">
-				      <div id="name">Contest Entrants</div>
-				      <div id="desc">
-				        This table shows the total number of entrants (500) the
-				        contest accepted over the past four weeks.
-				      </div>
-				    </div>
-				    <!-- ... -->
+						<div role="caption">
+							<div id="name">Contest Entrants</div>
+							<div id="desc">
+								This table shows the total number of entrants (500) the
+								contest accepted over the past four weeks.
+							</div>
+						</div>
+						<!-- ... -->

    If the caption represents a long-form description, or if the description contains semantic elements which are important in understanding the description, authors MAY instead specify aria-labelledby to reference an element within the caption that represents the "name" of the containing element, and specify aria-details to reference an element within the caption that represents the descriptive content.

     					<div role="figure" aria-labelledby="name" aria-details="details">
-					  <!-- figure content here, such as a complex data viz SVG -->
-				    <div role="caption">
-				      <div id="name">Sales information for 20XX</div>
-				      <div id="details">
-				        This barchart represents the total amount of sales over the course
-				        of five years. <a href="...">Sales information for last year</a> can
-				        be reviewed, or you can overlay <button aria-pressed="false">previous year</button>
-				        information in this graphic.
-				      </div>
-				    </div>
-				    <!-- ... -->
+						<!-- figure content here, such as a complex data viz SVG -->
+						<div role="caption">
+							<div id="name">Sales information for 20XX</div>
+							<div id="details">
+								This barchart represents the total amount of sales over the course
+								of five years. <a href="...">Sales information for last year</a> can
+								be reviewed, or you can overlay <button aria-pressed="false">previous year</button>
+								information in this graphic.
+							</div>
+						</div>
+						<!-- ... -->

    If a caption contains only a description, without a suitable text string to serve as the accessible name for its containing element, then aria-label or aria-labelledby MAY be used to provide an accessible name, and the caption MAY be treated solely as descriptive content, referenced via aria-details. 

     					<div role="figure" aria-label="Sales information" aria-details="details">
-					  <!-- figure content here, such as a complex data viz SVG -->
-				    <div role="caption" id="details">
-				      This barchart represents the total amount of sales over the course
-				      of five years. <a href="...">Sales information for last year</a> can
-				      be reviewed, or you can overlay <button aria-pressed="false">previous year</button>
-				      information in this graphic.
-				    </div>
-				    <!-- ... -->
+						<!-- figure content here, such as a complex data viz SVG -->
+						<div role="caption" id="details">
+							This barchart represents the total amount of sales over the course
+							of five years. <a href="...">Sales information for last year</a> can
+							be reviewed, or you can overlay <button aria-pressed="false">previous year</button>
+							information in this graphic.
+						</div>
+						<!-- ... -->
    @@ -1952,7 +1952,7 @@

    Definition of Roles

    Applying the aria-selected state on a columnheader MUST not cause the user agent to automatically propagate the aria-selected state to all the cells in the corresponding column. An author MAY choose to propagate selection in this manner depending on the specific application.

    While the columnheader role can be used in both interactive grids and non-interactive tables, the use of aria-readonly and aria-required is only applicable to interactive elements. Therefore, authors SHOULD NOT use aria-required or aria-readonly in a columnheader that descends from a table, and user agents SHOULD NOT expose either property to assistive technologies unless the columnheader descends from a grid.

    Because cells are organized into rows, there is not a single container element for the column. The column is the set of gridcell elements in a particular position within their respective row containers.

    -

    While aria-disabled is currently supported on columnheader, in a future version the working group plans to prohibit its use on elements with role columnheader except when the element is in the context of a grid or treegrid.

    +

    While aria-disabled is currently supported on columnheader, in a future version the working group plans to prohibit its use on elements with role columnheader except when the element is in the context of a grid or treegrid.

    @@ -2044,7 +2044,7 @@

    Definition of Roles

    The Guidance for combobox has changed significantly in ARIA 1.2 due to problems with implementation of the previous patterns. Authors and developers of User Agents, Assistive Technologies, and Conformance Checkers are advised to review this section carefully to understand the changes. - Explanation of the changes is available in the ARIA repository wiki. + Explanation of the changes is available in the ARIA repository wiki.

    A combobox functionally combines a named input field with the ability to assist value selection via a supplementary popup element. @@ -2076,15 +2076,15 @@

    Definition of Roles

  • Otherwise, the value of the combobox is represented by its descendant elements and can be determined using the same method used to compute the name of a button from its descendant content.
    • -          <label id="tag_label" for="tag_combo">Tag</label>
-		      <input type="text" id="tag_combo"
-            role="combobox" aria-autocomplete="list"
-            aria-haspopup="listbox" aria-expanded="true"
-            aria-controls="popup_listbox" aria-activedescendant="selected_option">
-				  <ul role="listbox" id="popup_listbox" aria-labelledby="tag_label">
-			      <li role="option">Zebra</li>
-			      <li role="option" id="selected_option">Zoom</li>
-				  </ul>
+					<label id="tag_label" for="tag_combo">Tag</label>
+					<input type="text" id="tag_combo"
+						role="combobox" aria-autocomplete="list"
+						aria-haspopup="listbox" aria-expanded="true"
+						aria-controls="popup_listbox" aria-activedescendant="selected_option">
+					<ul role="listbox" id="popup_listbox" aria-labelledby="tag_label">
+						<li role="option">Zebra</li>
+						<li role="option" id="selected_option">Zoom</li>
+					</ul>

    Please review the following carefully. As a result of these changes a combobox following the ARIA 1.1 combobox specification will no longer conform with the ARIA specification. @@ -2146,7 +2146,7 @@

    Definition of Roles

    @@ -1500,55 +1500,55 @@

    Definition of Roles

     					<div role="radiogroup" aria-labelledby="cap">
-						<div role="caption" id="cap">
-							Choose your favorite fruit
-						</div>
-						<!-- ... -->
+				    <div role="caption" id="cap">
+				      Choose your favorite fruit
+				    </div>
+				    <!-- ... -->

    If a caption contains content that serves as both a name and description for its containing element, authors MAY instead specify aria-labelledby to reference an element within the caption that represents the "name" of the containing element, and specify aria-describedby to reference an element within the caption that represents the descriptive content.

     					<div role="table" aria-labelledby="name" aria-describedby="desc">
-						<div role="caption">
-							<div id="name">Contest Entrants</div>
-							<div id="desc">
-								This table shows the total number of entrants (500) the
-								contest accepted over the past four weeks.
-							</div>
-						</div>
-						<!-- ... -->
+				    <div role="caption">
+				      <div id="name">Contest Entrants</div>
+				      <div id="desc">
+				        This table shows the total number of entrants (500) the
+				        contest accepted over the past four weeks.
+				      </div>
+				    </div>
+				    <!-- ... -->

    If the caption represents a long-form description, or if the description contains semantic elements which are important in understanding the description, authors MAY instead specify aria-labelledby to reference an element within the caption that represents the "name" of the containing element, and specify aria-details to reference an element within the caption that represents the descriptive content.

     					<div role="figure" aria-labelledby="name" aria-details="details">
-						<!-- figure content here, such as a complex data viz SVG -->
-						<div role="caption">
-							<div id="name">Sales information for 20XX</div>
-							<div id="details">
-								This barchart represents the total amount of sales over the course
-								of five years. <a href="...">Sales information for last year</a> can
-								be reviewed, or you can overlay <button aria-pressed="false">previous year</button>
-								information in this graphic.
-							</div>
-						</div>
-						<!-- ... -->
+					  <!-- figure content here, such as a complex data viz SVG -->
+				    <div role="caption">
+				      <div id="name">Sales information for 20XX</div>
+				      <div id="details">
+				        This barchart represents the total amount of sales over the course
+				        of five years. <a href="...">Sales information for last year</a> can
+				        be reviewed, or you can overlay <button aria-pressed="false">previous year</button>
+				        information in this graphic.
+				      </div>
+				    </div>
+				    <!-- ... -->

    If a caption contains only a description, without a suitable text string to serve as the accessible name for its containing element, then aria-label or aria-labelledby MAY be used to provide an accessible name, and the caption MAY be treated solely as descriptive content, referenced via aria-details. 

     					<div role="figure" aria-label="Sales information" aria-details="details">
-						<!-- figure content here, such as a complex data viz SVG -->
-						<div role="caption" id="details">
-							This barchart represents the total amount of sales over the course
-							of five years. <a href="...">Sales information for last year</a> can
-							be reviewed, or you can overlay <button aria-pressed="false">previous year</button>
-							information in this graphic.
-						</div>
-						<!-- ... -->
+					  <!-- figure content here, such as a complex data viz SVG -->
+				    <div role="caption" id="details">
+				      This barchart represents the total amount of sales over the course
+				      of five years. <a href="...">Sales information for last year</a> can
+				      be reviewed, or you can overlay <button aria-pressed="false">previous year</button>
+				      information in this graphic.
+				    </div>
+				    <!-- ... -->
    @@ -1952,7 +1952,7 @@

    Definition of Roles

    Applying the aria-selected state on a columnheader MUST not cause the user agent to automatically propagate the aria-selected state to all the cells in the corresponding column. An author MAY choose to propagate selection in this manner depending on the specific application.

    While the columnheader role can be used in both interactive grids and non-interactive tables, the use of aria-readonly and aria-required is only applicable to interactive elements. Therefore, authors SHOULD NOT use aria-required or aria-readonly in a columnheader that descends from a table, and user agents SHOULD NOT expose either property to assistive technologies unless the columnheader descends from a grid.

    Because cells are organized into rows, there is not a single container element for the column. The column is the set of gridcell elements in a particular position within their respective row containers.

    -

    While aria-disabled is currently supported on columnheader, in a future version the working group plans to prohibit its use on elements with role columnheader except when the element is in the context of a grid or treegrid.

    +

    While aria-disabled is currently supported on columnheader, in a future version the working group plans to prohibit its use on elements with role columnheader except when the element is in the context of a grid or treegrid.

    Characteristics:
    Supported States and Properties:
      -
    • aria-activedescendant
      • +
    • aria-activedescendant
    • aria-autocomplete
    • aria-controls
    • aria-errormessage
      • @@ -2375,8 +2375,8 @@

      Definition of Roles

      A landmark that is designed to be complementary to the main content that it is a sibling to, or a direct descendant of. The contents of a complementary landmark would be expected to remain meaningful if it were to be separated from the main content it is relevant to.

      There are various types of content that would appropriately have this role. For example, in the case of a portal, this can include but not be limited to show times, current weather, related articles, or stocks to watch. If the complementary content is completely separable from the main content, it might be appropriate to use a more general role.

      Assistive technologies SHOULD enable users to quickly navigate to elements with role complementary. - [=user agents=] SHOULD treat elements with role complementary as navigational landmarks. - [=user agents=] MAY enable users to quickly navigate to elements with role complementary.

      + [=user agents=] SHOULD treat elements with role complementary as navigational landmarks. + [=user agents=] MAY enable users to quickly navigate to elements with role complementary.

      @@ -2532,8 +2532,8 @@

      Definition of Roles

      A landmark that contains information about the parent document.

      Examples of information included in this region of the page are copyrights and links to privacy statements.

      Assistive technologies SHOULD enable users to quickly navigate to elements with role contentinfo. - [=user agents=] SHOULD treat elements with role contentinfo as navigational landmarks. - [=user agents=] MAY enable users to quickly navigate to elements with role contentinfo.

      + [=user agents=] SHOULD treat elements with role contentinfo as navigational landmarks. + [=user agents=] MAY enable users to quickly navigate to elements with role contentinfo.

      The author SHOULD mark no more than one element on a page with the contentinfo role.

      Because document and application elements can be nested in the DOM, they can have multiple contentinfo elements as DOM descendants, assuming each of those is associated with different document nodes, either by a DOM nesting (e.g., document within document) or by use of the aria-owns attribute.

      @@ -2611,12 +2611,12 @@

      Definition of Roles

      Characteristics:
      - definition -
      -

      A definition of a term or concept. See related term.

      -

      Authors MUST identify the element being defined and assign that element a role of term.

      -

      Authors SHOULD NOT use the definition role on interactive elements such as form controls because doing so could prevent users of assistive technologies from interacting with those elements.

      -
      + definition +
      +

      A definition of a term or concept. See related term.

      +

      Authors MUST identify the element being defined and assign that element a role of term.

      +

      Authors SHOULD NOT use the definition role on interactive elements such as form controls because doing so could prevent users of assistive technologies from interacting with those elements.

      +
      @@ -4102,9 +4102,9 @@

      Definition of Roles

      A perceivable section containing content that is relevant to a specific, author-specified purpose and sufficiently important that users will likely want to be able to navigate to the section easily and to have it listed in a summary of the page. Such a page summary could be generated dynamically by a user agent or assistive technology.

      landmark is an abstract role used for the ontology. Authors MUST NOT use landmark role in content.

      Authors designate the purpose of the content by assigning a role that is a subclass of the landmark role and, when needed, by providing a brief, descriptive label.

      -

      Elements with a role that is a subclass of the landmark role are known as landmark regions or navigational landmark regions.

      +

      Elements with a role that is a subclass of the landmark role are known as landmark regions or navigational landmark regions.

      Assistive technologies SHOULD enable users to quickly navigate to landmark regions. - [=user agents=] MAY enable users to quickly navigate to landmark regions.

      + [=user agents=] MAY enable users to quickly navigate to landmark regions.

      Characteristics:
      @@ -4551,6 +4551,295 @@

      Definition of Roles

      Characteristics:
      +
      + listitem +
      +

      A single item in a list or directory.

      +

      Authors MUST ensure [=elements=] whose role is listitem are accessibility children of an element whose role is list.

      +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      Characteristics:
      CharacteristicValue
      Is Abstract: 
      Superclass Role:section
      Subclass Roles:Placeholder
      Base Concept:<[^li^]> in HTML
      Related Concepts:
      Required Accessibility Parent Roles: +
        +
      • directory
        • +
      • list
        • +
      +
      Allowed Accessibility Child Roles: 
      Required States and Properties: 
      Supported States and Properties: +
        +
      • aria-posinset
        • +
      • aria-setsize
        • +
      +
      Inherited States and Properties:Placeholder
      Name From:author
      Accessible Name Required: 
      Inherits Name Required: 
      Children Presentational: 
      Inherits Presentational: 
      +
      +
      + listview +
      +

      A composite widget containing a collection of interactive elements that may also contain interactive elements. See related grid and treegrid

      +

      A listview contains listviewitem elements.

      +

      Authors may use a listview to make a collection navigable and interactive. Elements in A listview may also be selectable, but they are not selectable by default. Authors may specify either aria-selected or aria-checked for items in a listview to indicate selection (see listviewitem).

      +

      To be keyboard accessible, authors SHOULD manage focus of listviewitem descendants for all instances of this role, as described in Managing Focus.

      +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      Characteristics:
      CharacteristicValue
      Is Abstract: 
      Superclass Role: +
        +
      • composite
        • +
      • list
        • +
      +
      Subclass Roles:Placeholder
      Base Concept:<[^ul^]> in HTML
      Related Concepts:
      Required Accessibility Parent Roles:
      Allowed Accessibility Child Roles:listviewitem
      Required States and Properties: 
      Supported States and Properties:aria-multiselectable
      Inherited States and Properties:Placeholder
      Name From:author
      Accessible Name Required:True
      Inherits Name Required: 
      Children Presentational: 
      Inherits Presentational: 
      +
      +
      + listviewitem +
      +

      An item in a listview.

      +

      A listviewitem is focusable and can be selectable.

      +

      + A listviewitem element can contain a sub-level group of elements that can be expanded or collapsed. + An expandable collection of listviewitem elements are enclosed in an element with the group role. +

      +

      Authors MUST ensure [=elements=] with role listviewitem are accessibility children of an element with role listview or an element with role group that is the accessibility child of an element with role listviewitem.

      +

      + Authors MAY indicate selection for listviewitem elements using either aria-selected or aria-checked. + Some user interfaces indicate selection with aria-selected in single-select listviews and with aria-checked in multi-select listviews. + Authors SHOULD NOT specify both aria-selected and aria-checked on listviewitem elements contained by the same listview except in the extremely rare circumstances where all the following conditions are met: +

      +
        +
      • The meaning and purpose of aria-selected is different from the meaning and purpose of aria-checked in the user interface.
        • +
      • The user interface makes the meaning and purpose of each state apparent.
        • +
      • The user interface provides a separate method for controlling each state.
        • +
      +

      User agents MUST NOT provide an implicit value for aria-selected for listviewitem elements.

      +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      Characteristics:
      CharacteristicValue
      Is Abstract: 
      Superclass Role: +
        +
      • listitem
        • +
      • widget
        • +
      +
      Subclass Roles:Placeholder
      Base Concept:<[^li^]> in HTML
      Related Concepts: 
      Required Accessibility Parent Roles: + +
      Allowed Accessibility Child Roles: 
      Required States and Properties:
      Supported States and Properties: +
        +
      • aria-checked
        • +
      • aria-disabled
        • +
      • aria-expanded
        • +
      • aria-selected
        • +
      +
      Inherited States and Properties:Placeholder
      Name From: +
        +
      • contents
        • +
      • author
        • +
      +
      Accessible Name Required:
      Inherits Name Required: 
      Children Presentational: 
      Inherits Presentational: 
      +
      log
      @@ -4640,8 +4929,8 @@

      Definition of Roles

      A landmark containing the main content of a document.

      This marks the content that is directly related to or expands upon the central topic of the document. The main role is a non-obtrusive alternative for "skip to main content" links, where the navigation option to go to the main content (or other landmarks) is provided by assistive technologies, or by a user agent or browser extension, through a keyboard shortcut or UI feature such as a side panel or dialog.

      Assistive technologies SHOULD enable users to quickly navigate to elements with role main. - [=user agents=] SHOULD treat elements with role main as navigational landmarks. - [=user agents=] MAY enable users to quickly navigate to elements with role main.

      + [=user agents=] SHOULD treat elements with role main as navigational landmarks. + [=user agents=] MAY enable users to quickly navigate to elements with role main.

      The author SHOULD mark no more than one element on a page with the main role.

      Because document and application elements can be nested in the DOM, they can have multiple main elements as DOM descendants, assuming each of those is associated with different document nodes, either by a DOM nesting (e.g., document within document) or by use of the aria-owns attribute.

      @@ -4899,40 +5188,40 @@

      Definition of Roles

      MathML Example with Embedded TeX Annotation

       					<!-- Note: Use a JavaScript polyfill library to ensure
-					     this renders in user agents that do not support MathML. -->
+							 this renders in user agents that do not support MathML. -->
 					<!-- The math element has an implicit role="math". -->
 					<math xmlns="http://www.w3.org/1998/Math/MathML">
-					  <mrow>
-					    <mi>x</mi>
-					    <mo>=</mo>
-					    <mfrac>
-					      <mrow>
-					        <mo form="prefix">−</mo>
-					        <mi>b</mi>
-					        <mo>±</mo>
-					        <msqrt>
-					          <msup>
-					            <mi>b</mi>
-					            <mn>2</mn>
-					          </msup>
-					          <mo>−</mo>
-					          <mn>4</mn>
-					          <mo>&#x2062;<!-- &InvisibleTimes; --></mo>
-					          <mi>a</mi>
-					          <mo>&#x2062;<!-- &InvisibleTimes; --></mo>
-					          <mi>c</mi>
-					        </msqrt>
-					      </mrow>
-					      <mrow>
-					        <mn>2</mn>
-					        <mo>&#x2062;<!-- &InvisibleTimes; --></mo>
-					        <mi>a</mi>
-					      </mrow>
-					    </mfrac>
-					  </mrow>
-					  <annotation encoding="TeX">
-					    x=\frac{-b\pm\sqrt{b^2-4ac}}{2a}
-					  </annotation>
+						<mrow>
+							<mi>x</mi>
+							<mo>=</mo>
+							<mfrac>
+								<mrow>
+									<mo form="prefix">−</mo>
+									<mi>b</mi>
+									<mo>±</mo>
+									<msqrt>
+										<msup>
+											<mi>b</mi>
+											<mn>2</mn>
+										</msup>
+										<mo>−</mo>
+										<mn>4</mn>
+										<mo>&#x2062;<!-- &InvisibleTimes; --></mo>
+										<mi>a</mi>
+										<mo>&#x2062;<!-- &InvisibleTimes; --></mo>
+										<mi>c</mi>
+									</msqrt>
+								</mrow>
+								<mrow>
+									<mn>2</mn>
+									<mo>&#x2062;<!-- &InvisibleTimes; --></mo>
+									<mi>a</mi>
+								</mrow>
+							</mfrac>
+						</mrow>
+						<annotation encoding="TeX">
+							x=\frac{-b\pm\sqrt{b^2-4ac}}{2a}
+						</annotation>
 					</math>

      Plain HTML or Polyfill DOM Result of the MathML Quadratic Formula

      @@ -5427,7 +5716,7 @@

      Plain HTML or Polyfill DOM Result of the MathML Quadratic Formula

      Authors SHOULD enforce that only one menuitemradio in a group can be checked at the same time. When one item in the group is checked, the previously checked item becomes unchecked (its aria-checked attribute becomes false).

      In order to identify that they are related widgets, authors MUST ensure that menu item radios are accessibility descendants of an element with role menu or menubar.

      -

      If a menu or menubar contains more than one group of menuitemradio elements, or if the menu contains one group and other, unrelated menu items, authors SHOULD contain each set of related menuitemradio elements in an element using the group role. Authors MAY also delimit the group from other menu items with an element using the separator role, or an element with an equivalent role from the native markup language. +

      If a menu or menubar contains more than one group of menuitemradio elements, or if the menu contains one group and other, unrelated menu items, authors SHOULD contain each set of related menuitemradio elements in an element using the group role. Authors MAY also delimit the group from other menu items with an element using the separator role, or an element with an equivalent role from the native markup language.

      @@ -5618,8 +5907,8 @@

      Plain HTML or Polyfill DOM Result of the MathML Quadratic Formula

      A landmark containing a collection of navigational [=elements=] (usually links) for navigating the document or related documents.

      Assistive technologies SHOULD enable users to quickly navigate to elements with role navigation. - [=user agents=] SHOULD treat elements with role navigation as navigational landmarks. - [=user agents=] MAY enable users to quickly navigate to elements with role navigation.

      + [=user agents=] SHOULD treat elements with role navigation as navigational landmarks. + [=user agents=] MAY enable users to quickly navigate to elements with role navigation.

      Characteristics:
      @@ -5721,16 +6010,16 @@

      Plain HTML or Polyfill DOM Result of the MathML Quadratic Formula

      Authors SHOULD NOT provide a meaningful text alternative (for example, use alt="" in HTML) when the none/presentation role is applied to an image.

      In the following code sample, the containing img and is appropriately labeled by the caption paragraph. In this example the img element can be marked as none/presentation because the role and the text alternatives are provided by the containing element.

      <div role="img" aria-labelledby="caption">
-  <img src="example.png" role="none" alt="">
-  <p id="caption">A visible text caption labeling the image.</p>
+	<img src="example.png" role="none" alt="">
+	<p id="caption">A visible text caption labeling the image.</p>
 </div>

      In the following code sample, because the anchor (HTML a element) is acting as the treeitem, the list item (HTML li element) is assigned an explicit WAI-ARIA role of none/presentation to override the user agent's implicit native semantics for list items.

       <ul role="tree">
-  <li role="none">
+	<li role="none">
 	<a role="treeitem" aria-expanded="true">An expanded tree node</a>
-  </li>
-  …
+	</li>
+	…
 </ul>
      Presentational Role Inheritance

      The none/presentation role is used on an element that has implicit native semantics, meaning that there is a default accessibility API role for the element. Some elements are only complete when additional descendant elements are provided. For example, in HTML, table elements (matching the table role) require tr descendants (which have an implicit row role), which in turn require th or td children (the columnheader or rowheader and cell roles, respectively). Similarly, lists require list item children. The descendant elements that complete the semantics of an element are described in WAI-ARIA as Allowed Accessibility Child Roles.

      @@ -5740,18 +6029,18 @@
      Presentational Role Inheritance

      For example, according to an accessibility API, the following markup elements might have identical or very similar role semantics (generic or none role) and identical content.

      <!-- 1. [role="none"] negates the implicit 'list' and 'listitem' role semantics but does not affect the contents. -->
 <ul role="none">
-  <li> Sample Content </li>
-  <li> More Sample Content </li>
+	<li> Sample Content </li>
+	<li> More Sample Content </li>
 </ul>
 
 <!-- 2. There is no implicit role for "foo", so only the contents are exposed. -->
 <foo>
-  <foo> Sample Content </foo>
-  <foo> More Sample Content </foo>
+	<foo> Sample Content </foo>
+	<foo> More Sample Content </foo>
 </foo>

      There are other WAI-ARIA roles with specific allowed children for which this situation is applicable (e.g., feeds and listboxes), but tables and lists are the most common real-world cases in which the none/presentation inheritance is likely to apply.

      For any element with an explicit or inherited role of none/presentation, user agents MUST apply an inherited role of none to all host-language-specific labeling elements for the presentational element. For example, a table element with a role of none/presentation will have the implicit native semantics of its caption element removed, because the caption is merely a label for the presentational table.

      -

      Information about resolving conflicts in the none/presentation role has been moved to Handling Author Errors

      +

      Information about resolving conflicts in the none/presentation role has been moved to Handling Author Errors

      Characteristics:
      @@ -5844,8 +6133,8 @@
      Presentational Role Inheritance
       					<p>... the following results outline support for the tested features.</p>
 					<div role="note">
-					  <p>Please keep in mind that at the time of publishing this page all results were accurate.</p>
-					  <p>If you find any variations in results, please let us know!</p>
+						<p>Please keep in mind that at the time of publishing this page all results were accurate.</p>
+						<p>If you find any variations in results, please let us know!</p>
 					</div>
 					<p>...</p>
      @@ -5855,13 +6144,13 @@
      Presentational Role Inheritance
    • If the note is brief and consists of static text, use aria-describedby.
      • -				  <!-- using aria-details to reference a note containing a link -->
-				  ...
+					<!-- using aria-details to reference a note containing a link -->
+					...
 					<button aria-details="info-note">Get Started</button>
 					...
 					<div role="note" id="info-note">
-					  <p>Need more information before you get started?</p>
-					  <p>Visit our <a href="...">product description page</a> to get all the information you need.</p>
+						<p>Need more information before you get started?</p>
+						<p>Visit our <a href="...">product description page</a> to get all the information you need.</p>
 					</div>
      @@ -5942,30 +6231,30 @@
      Presentational Role Inheritance

      An item in a listbox.

      Authors MUST ensure [=elements=] with role option are accessibility children of an element with role listbox or of an element with role group that is the accessibility child of an element with role listbox. Options not associated with a listbox might not be correctly mapped to an accessibility API.

      -

      In certain conditions, a user agent MAY provide an implicit value for aria-selected for each option in a listbox, and if it does, the user agent MUST ensure the following conditions are met before providing an implicit value:

      -
        -
      • The value of aria-multiselectable on the listbox is false or undefined.
        • -
      • None of the option elements in the listbox have an explicitly declared value for aria-selected or aria-checked.
        • -
      -

      - If a user agent provides an implicit aria-selected value for an option, the value SHOULD be true if the option has DOM focus or the listbox has DOM focus and the option is referenced by aria-activedescendant. - Otherwise, if a user agent provides an implicit aria-selected value for an option, the value SHOULD be false. -

      -

      - Authors SHOULD indicate selection for option elements using one of the following: -

      -
        -
      • An aria-selected value of true on the selected option within a single-select listbox, and optionally aria-selected values of false on unselected options.
        • -
      • Either aria-selected or aria-checked on all options within a multi-select listbox, with a value of true on selected options, and a value of false on unselected options.
        • -
      -

      - Authors SHOULD NOT specify both aria-selected and aria-checked on option elements contained by the same listbox except in the extremely rare circumstances where all the following conditions are met: -

      -
        -
      • The meaning and purpose of aria-selected is different from the meaning and purpose of aria-checked in the user interface.
        • -
      • The user interface makes the meaning and purpose of each state apparent.
        • -
      • The user interface provides a separate method for controlling each state.
        • -
      +

      In certain conditions, a user agent MAY provide an implicit value for aria-selected for each option in a listbox, and if it does, the user agent MUST ensure the following conditions are met before providing an implicit value:

      +
        +
      • The value of aria-multiselectable on the listbox is false or undefined.
        • +
      • None of the option elements in the listbox have an explicitly declared value for aria-selected or aria-checked.
        • +
      +

      + If a user agent provides an implicit aria-selected value for an option, the value SHOULD be true if the option has DOM focus or the listbox has DOM focus and the option is referenced by aria-activedescendant. + Otherwise, if a user agent provides an implicit aria-selected value for an option, the value SHOULD be false. +

      +

      + Authors SHOULD indicate selection for option elements using one of the following: +

      +
        +
      • An aria-selected value of true on the selected option within a single-select listbox, and optionally aria-selected values of false on unselected options.
        • +
      • Either aria-selected or aria-checked on all options within a multi-select listbox, with a value of true on selected options, and a value of false on unselected options.
        • +
      +

      + Authors SHOULD NOT specify both aria-selected and aria-checked on option elements contained by the same listbox except in the extremely rare circumstances where all the following conditions are met: +

      +
        +
      • The meaning and purpose of aria-selected is different from the meaning and purpose of aria-checked in the user interface.
        • +
      • The user interface makes the meaning and purpose of each state apparent.
        • +
      • The user interface provides a separate method for controlling each state.
        • +
      Characteristics:
      @@ -6021,7 +6310,7 @@
      Presentational Role Inheritance
      • aria-checked
      • aria-posinset
        • -
      • aria-selected
        • +
      • aria-selected
      • aria-setsize
      @@ -6063,8 +6352,8 @@
      Presentational Role Inheritance
      Characteristics:

      For a single-selectable tablist, authors SHOULD [=element/hide from all users=] other tabpanel [=elements=] until the user selects the tab associated with that tabpanel. For a multi-selectable tablist, authors SHOULD ensure that the tab for each visible tabpanel has the aria-expanded attribute set to true, and that the tabs associated with the remaining [=element/hidden from all users=] tabpanel elements have their aria-expanded attributes set to false.

      Authors SHOULD ensure that a selected tab has its aria-selected attribute set to true, that inactive tab elements have their aria-selected attribute set to false, and that the currently selected tab provides a visual indication that it is selected.

      -

      In certain conditions, a user agent MAY provide an implicit value for aria-selected for each tab in a tablist, and if it does, the user agent MUST ensure the following conditions are met before providing an implicit value:

      -
        -
      • The value of aria-multiselectable on the tablist is false or undefined.
        • -
      • None of the tab elements in the tablist have an explicitly declared value for aria-selected or aria-expanded.
        • -
      +

      In certain conditions, a user agent MAY provide an implicit value for aria-selected for each tab in a tablist, and if it does, the user agent MUST ensure the following conditions are met before providing an implicit value:

      +
        +
      • The value of aria-multiselectable on the tablist is false or undefined.
        • +
      • None of the tab elements in the tablist have an explicitly declared value for aria-selected or aria-expanded.
        • +
      @@ -8951,8 +9240,8 @@
      Presentational Role Inheritance
      Characteristics: 
      <div id="inaccessibleButton">
-    <!-- Use semantic markup instead. This is just a retrofit example. -->
+		<!-- Use semantic markup instead. This is just a retrofit example. -->
 </div>
      // Get a reference to the element.
 let el = document.getElementById('inaccessibleButton');
@@ -14045,7 +14334,7 @@ 
      Substantive changes since ARIA 1.2
      
 					href="https://github.com/w3c/aria/pull/1137">#1137)
 			
    • Add mark role (#1133)
      • 
-
    +
    -

    Translated to platform-specific accessibility APIs as defined in the Core Accessibility API Mappings.

    +

    Translated to platform-specific accessibility APIs as defined in the Core Accessibility API Mappings.

    Graphical Document
    -

    A document containing graphic representations with user-navigable parts. Charts, maps, diagrams, blueprints, and dashboards are examples of graphical documents. A graphical document is composed using any combination of symbols, images, text, and graphic primitives (shapes such as circles, points, lines, paths, rectangles, etc).

    +

    A document containing graphic representations with user-navigable parts. Charts, maps, diagrams, blueprints, and dashboards are examples of graphical documents. A graphical document is composed using any combination of symbols, images, text, and graphic primitives (shapes such as circles, points, lines, paths, rectangles, etc).

    Hidden
    -

    Indicates that the element is excluded from the accessibility tree and therefore not exposed to accessibility APIs.

    -

    Related: Excluding Elements in the Accessibility Tree, [=element/hidden from all users=], aria-hidden.

    +

    Indicates that the element is excluded from the accessibility tree and therefore not exposed to accessibility APIs.

    +

    Related: Excluding Elements in the Accessibility Tree, [=element/hidden from all users=], aria-hidden.

    Hidden From All Users
    -

    Indicates that the element is not visible, perceivable, or interactive for any user. Note that an element can be [=element/hidden=] but not [=element/hidden from all users=] by using aria-hidden.

    -

    Related: Excluding Elements in the Accessibility Tree, [=element/hidden=], aria-hidden.

    +

    Indicates that the element is not visible, perceivable, or interactive for any user. Note that an element can be [=element/hidden=] but not [=element/hidden from all users=] by using aria-hidden.

    +

    Related: Excluding Elements in the Accessibility Tree, [=element/hidden=], aria-hidden.

    Identifies
    -

    Used in an attribute description to denote that the value type is an ID reference (identifying a single element) or ID reference list (identifying one or more elements).

    -

    Related Terms: Defines, Indicates

    +

    Used in an attribute description to denote that the value type is an ID reference (identifying a single element) or ID reference list (identifying one or more elements).

    +

    Related Terms: Defines, Indicates

    Indicates
    -

    Used in an attribute description to denote that the value type is a named token or otherwise token-like, including the Boolean-like true/false, true/false/undefined, tristate (true/false/mixed), a single named token, or a token list.

    -

    Related Terms: Defines, Identifies

    +

    Used in an attribute description to denote that the value type is a named token or otherwise token-like, including the Boolean-like true/false, true/false/undefined, tristate (true/false/mixed), a single named token, or a token list.

    +

    Related Terms: Defines, Identifies

    Keyboard Accessible
    @@ -350,15 +350,15 @@

    Important Terms

    Landmark
    -

    A type of region on a page to which the user might want quick access. Content in such a region is different from that of other regions on the page and relevant to a specific user purpose, such as navigating, searching, perusing the primary content, etc.

    +

    A type of region on a page to which the user might want quick access. Content in such a region is different from that of other regions on the page and relevant to a specific user purpose, such as navigating, searching, perusing the primary content, etc.

    Live Region
    -

    Live regions are perceivable regions of a web page that are typically updated as a result of an external event. These regions are not always updated as a result of a user interaction and can receive these updates even when they do not have focus. Examples of live regions include a chat log, stock ticker, or a sport scoring section that updates periodically to reflect game statistics. Since these asynchronous areas are expected to update outside the user's area of focus, assistive technologies such as screen readers have either been unaware of their existence or unable to process them for the user. WAI-ARIA has provided a collection of properties that allow the author to identify these live regions and process them: aria-live, aria-relevant, aria-atomic, and aria-busy.

    +

    Live regions are perceivable regions of a web page that are typically updated as a result of an external event. These regions are not always updated as a result of a user interaction and can receive these updates even when they do not have focus. Examples of live regions include a chat log, stock ticker, or a sport scoring section that updates periodically to reflect game statistics. Since these asynchronous areas are expected to update outside the user's area of focus, assistive technologies such as screen readers have either been unaware of their existence or unable to process them for the user. WAI-ARIA has provided a collection of properties that allow the author to identify these live regions and process them: aria-live, aria-relevant, aria-atomic, and aria-busy.

    Managed State
    -

    Accessibility API state that is controlled by the user agent, such as focus and selection. These are contrasted with "unmanaged states" that are typically controlled by the author. Nevertheless, authors can override some managed states, such as aria-posinset and aria-setsize. Many managed states have corresponding CSS pseudo-classes, such as :focus, and pseudo-elements, such as ::selection, that are also updated by the user agent.

    +

    Accessibility API state that is controlled by the user agent, such as focus and selection. These are contrasted with "unmanaged states" that are typically controlled by the author. Nevertheless, authors can override some managed states, such as aria-posinset and aria-setsize. Many managed states have corresponding CSS pseudo-classes, such as :focus, and pseudo-elements, such as ::selection, that are also updated by the user agent.

    Nemeth Braille
    @@ -366,43 +366,43 @@

    Important Terms

    Object
    -

    In the context of user interfaces, an item in the perceptual user experience, represented in markup languages by one or more [=elements=], and rendered by [=user agents=].

    +

    In the context of user interfaces, an item in the perceptual user experience, represented in markup languages by one or more [=elements=], and rendered by [=user agents=].

    In the context of programming, the instantiation of one or more classes and interfaces which define the general characteristics of similar objects. An object in an accessibility API can represent one or more DOM objects. Accessibility APIs have defined interfaces that are distinct from DOM interfaces.
    Ontology
    -

    A description of the characteristics of classes and how they relate to each other.

    +

    A description of the characteristics of classes and how they relate to each other.

    Operable
    -

    Usable by users in ways they can control. References in this document relate to WCAG 2.1 Principle 2: Content must be operable [[WCAG21]]. See Keyboard Accessible.

    +

    Usable by users in ways they can control. References in this document relate to WCAG 2.1 Principle 2: Content must be operable [[WCAG21]]. See Keyboard Accessible.

    Perceivable
    -

    Presentable to users in ways they can sense. References in this document relate to WCAG 2.1 Principle 1: Content must be perceivable [[WCAG21]].

    +

    Presentable to users in ways they can sense. References in this document relate to WCAG 2.1 Principle 1: Content must be perceivable [[WCAG21]].

    Property
    -

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

    +

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

    Relationship
    -

    A connection between two distinct things. Relationships can be of various types to indicate which object labels another, controls another, etc.

    +

    A connection between two distinct things. Relationships can be of various types to indicate which object labels another, controls another, etc.

    Role
    -

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

    +

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

    Semantics
    -

    The meaning of something as understood by a human, defined in a way that computers can process a representation of an object, such as [=elements=] and [=attributes=], and reliably represent the object in a way that various humans will achieve a mutually consistent understanding of the object.

    +

    The meaning of something as understood by a human, defined in a way that computers can process a representation of an object, such as [=elements=] and [=attributes=], and reliably represent the object in a way that various humans will achieve a mutually consistent understanding of the object.

    State
    -

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

    +

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

    Target Element
    -

    An element specified in a WAI-ARIA relation. For example, in <div aria-controls=”elem1”>, where “elem1” is the ID for the target element.

    +

    An element specified in a WAI-ARIA relation. For example, in <div aria-controls=”elem1”>, where “elem1” is the ID for the target element.

    Unicode Braille Patterns
    @@ -410,7 +410,7 @@

    Important Terms

    Widget
    -

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

    +

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

    @@ -474,74 +474,74 @@

    WAI-ARIA States a [aria-checked="true"]::before { background-image: url(checked.gif); }

    If CSS is not used to toggle the visual representation of the check mark, the author could include additional markup and scripts to manage an image that represents whether or not the menuitemcheckbox is checked.

    <li role="menuitemcheckbox" aria-checked="true">
-	<img src="checked.gif" alt="">
-	<!-- note: additional scripts required to toggle image source -->
-	Sort by Last Modified
+  <img src="checked.gif" alt="">
+  <!-- note: additional scripts required to toggle image source -->
+  Sort by Last Modified
 </li>
    -

    Managing Focus and Supporting Keyboard Navigation

    -

    When using standard HTML interactive elements and simple WAI-ARIA widgets, application developers can manipulate the tab order or associate keyboard shortcuts with elements in the document.

    -

    WAI-ARIA includes a number of "managing container" widgets, also known as "composite" widgets. When appropriate, the container is responsible for tracking the last descendant that was active (the default is usually the first item in the container). It is essential that a container maintain a usable and consistent strategy when focus leaves a container and is then later refocused. While there can be exceptions, it is recommended that when a previously focused container is refocused, the active descendant be the same element as the active descendant when the container was last focused. Exceptions include cases where the contents of a container widget have changed, and widgets like a menubar where the user expects to always return to the first item when focus leaves the menu bar. For example, if the second item of a tree group was the active descendant when the user tabbed out of the tree group, then the second item of the tree group remains the active descendant when the tree group gets focus again. The user can also activate the container by clicking on one of the descendants within it. When the container or its active descendant has focus, the user can navigate through the container by pressing additional keys, such as the arrow keys, to change the currently active descendant. Any additional press of the main navigation key (generally the TAB key) will move out of the container to the next widget.

    -

    Usable keyboard navigation in a rich internet application is different from the tabbing paradigm among interactive elements, such as links and form controls, in a static document. In rich internet applications, the user tabs to significantly complex widgets, such as a menu or spreadsheet, and uses the arrow keys to navigate within the widget. The changes that WAI-ARIA introduces to keyboard navigation make this enhanced accessibility possible. In WAI-ARIA, any element can be keyboard focusable. In addition to host language mechanisms such as tabindex, aria-activedescendant provides another mechanism for keyboard operation. Most other aspects of WAI-ARIA widget development depend on keyboard navigation functioning properly.

    -

    - When implementing aria-activedescendant as described below, the user agent keeps the DOM focus on the container element or on an input element that controls the container element. - However, the user agent communicates desktop focus events and states to the assistive technology as if the element referenced by aria-activedescendant has focus. - User agents are not expected to validate that the active descendant is a descendant of the container element. - It is the responsibility of the user agent to ensure that keyboard events are processed at the element that has DOM focus. - Any keyboard events directed at the active descendant bubble up to the DOM element with focus for processing. -

    -
    -

    Information for Authors

    -

    If the author removes the element with focus, the author SHOULD move focus to a logical element. Similarly, authors SHOULD not scroll the element with focus off screen unless the user performed a scrolling action.

    -

    Authors SHOULD ensure that all interactive [=elements=] are focusable and that all parts of composite widgets are either focusable or have a documented alternative method to achieve their function.

    -

    Authors MUST manage focus on the following container roles:

    -
      -
    • grid
      • -
    • listbox
      • -
    • menu
      • -
    • menubar
      • -
    • radiogroup
      • -
    • tree
      • -
    • treegrid
      • -
    • tablist
      • -
    -

    User agents that support WAI-ARIA expand the usage of host language mechanisms such as tabindex, focus, and blur to allow them on all [=elements=]. Where the host language supports it, authors MAY add any element such as a div, span, or img to the default tab order by setting tabindex="0". In addition, any item with tabindex equal to a negative integer is focusable via script or a mouse click, but is not part of the default tab order. This is supported in both [[HTML]] and [[SVG2]].

    -

    Authors MAY use aria-activedescendant to inform assistive technologies which descendant of a widget element is treated as having keyboard focus in the user interface if the role of the widget element supports aria-activedescendant. - This is often a more convenient way of providing keyboard navigation within widgets, such as a listbox, where the widget occupies only one stop in the page Tab sequence and other keys, typically arrow keys, are used to focus elements inside the widget.

    -

    Typically, the author will use host language semantics to put the widget in the Tab sequence (e.g., tabindex="0" in HTML) and aria-activedescendant to point to the ID of the currently active descendant. The author, not the user agent, is responsible for styling the currently active descendant to show it has keyboard focus. The author cannot use :focus to style the currently active descendant since the actual focus is on the container.

    -

    More information on managing focus can be found in the Developing a Keyboard Interface section of the WAI-ARIA Authoring Practices.

    -
    -
    -

    Information for User Agents

    -

    The user agent MUST do the following to implement aria-activedescendant:

    -
      -
    1. Implement the host language method for keyboard navigation so that widgets that support aria-activedescendant can be included in the tab order.
      2. -
    2. For platforms that expose desktop focus or accessibility API focus separately from DOM focus, do not expose the focused state in the accessibility API for any element when it has DOM focus and also has aria-activedescendant which points to a valid ID reference.
      3. -
    3. When the aria-activedescendant attribute changes on an element that currently has DOM focus, remove the focused state from the previously focused object and fire an accessibility API desktop focus event on the new element referenced by aria-activedescendant. If aria-activedescendant is cleared or does not point to an element in the current document, fire a desktop focus event for the object that had the attribute change.
      4. -
    4. Apply the following accessibility API states to any element with an ID attribute that can be referenced by an element with both an aria-activedescendant attribute and has DOM focus. There are two ways an element can be referenced by aria-activedescendant. One way is when it is an accessibility descendant of the element with aria-activedescendant and the other is when it is an accessibility descendant of an element that is controlled by an element with role of combobox, textbox or searchbox with an aria-activedescendant attribute: +

      Managing Focus and Supporting Keyboard Navigation

      +

      When using standard HTML interactive elements and simple WAI-ARIA widgets, application developers can manipulate the tab order or associate keyboard shortcuts with elements in the document.

      +

      WAI-ARIA includes a number of "managing container" widgets, also known as "composite" widgets. When appropriate, the container is responsible for tracking the last descendant that was active (the default is usually the first item in the container). It is essential that a container maintain a usable and consistent strategy when focus leaves a container and is then later refocused. While there can be exceptions, it is recommended that when a previously focused container is refocused, the active descendant be the same element as the active descendant when the container was last focused. Exceptions include cases where the contents of a container widget have changed, and widgets like a menubar where the user expects to always return to the first item when focus leaves the menu bar. For example, if the second item of a tree group was the active descendant when the user tabbed out of the tree group, then the second item of the tree group remains the active descendant when the tree group gets focus again. The user can also activate the container by clicking on one of the descendants within it. When the container or its active descendant has focus, the user can navigate through the container by pressing additional keys, such as the arrow keys, to change the currently active descendant. Any additional press of the main navigation key (generally the TAB key) will move out of the container to the next widget.

      +

      Usable keyboard navigation in a rich internet application is different from the tabbing paradigm among interactive elements, such as links and form controls, in a static document. In rich internet applications, the user tabs to significantly complex widgets, such as a menu or spreadsheet, and uses the arrow keys to navigate within the widget. The changes that WAI-ARIA introduces to keyboard navigation make this enhanced accessibility possible. In WAI-ARIA, any element can be keyboard focusable. In addition to host language mechanisms such as tabindex, aria-activedescendant provides another mechanism for keyboard operation. Most other aspects of WAI-ARIA widget development depend on keyboard navigation functioning properly.

      +

      + When implementing aria-activedescendant as described below, the user agent keeps the DOM focus on the container element or on an input element that controls the container element. + However, the user agent communicates desktop focus events and states to the assistive technology as if the element referenced by aria-activedescendant has focus. + User agents are not expected to validate that the active descendant is a descendant of the container element. + It is the responsibility of the user agent to ensure that keyboard events are processed at the element that has DOM focus. + Any keyboard events directed at the active descendant bubble up to the DOM element with focus for processing. +

      +
      +

      Information for Authors

      +

      If the author removes the element with focus, the author SHOULD move focus to a logical element. Similarly, authors SHOULD not scroll the element with focus off screen unless the user performed a scrolling action.

      +

      Authors SHOULD ensure that all interactive [=elements=] are focusable and that all parts of composite widgets are either focusable or have a documented alternative method to achieve their function.

      +

      Authors MUST manage focus on the following container roles:

      +
        +
      • grid
        • +
      • listbox
        • +
      • menu
        • +
      • menubar
        • +
      • radiogroup
        • +
      • tree
        • +
      • treegrid
        • +
      • tablist
        • +
      +

      User agents that support WAI-ARIA expand the usage of host language mechanisms such as tabindex, focus, and blur to allow them on all [=elements=]. Where the host language supports it, authors MAY add any element such as a div, span, or img to the default tab order by setting tabindex="0". In addition, any item with tabindex equal to a negative integer is focusable via script or a mouse click, but is not part of the default tab order. This is supported in both [[HTML]] and [[SVG2]].

      +

      Authors MAY use aria-activedescendant to inform assistive technologies which descendant of a widget element is treated as having keyboard focus in the user interface if the role of the widget element supports aria-activedescendant. + This is often a more convenient way of providing keyboard navigation within widgets, such as a listbox, where the widget occupies only one stop in the page Tab sequence and other keys, typically arrow keys, are used to focus elements inside the widget.

      +

      Typically, the author will use host language semantics to put the widget in the Tab sequence (e.g., tabindex="0" in HTML) and aria-activedescendant to point to the ID of the currently active descendant. The author, not the user agent, is responsible for styling the currently active descendant to show it has keyboard focus. The author cannot use :focus to style the currently active descendant since the actual focus is on the container.

      +

      More information on managing focus can be found in the Developing a Keyboard Interface section of the WAI-ARIA Authoring Practices.

      +
      +
      +

      Information for User Agents

      +

      The user agent MUST do the following to implement aria-activedescendant:

      +
        +
      1. Implement the host language method for keyboard navigation so that widgets that support aria-activedescendant can be included in the tab order.
        2. +
      2. For platforms that expose desktop focus or accessibility API focus separately from DOM focus, do not expose the focused state in the accessibility API for any element when it has DOM focus and also has aria-activedescendant which points to a valid ID reference.
        3. +
      3. When the aria-activedescendant attribute changes on an element that currently has DOM focus, remove the focused state from the previously focused object and fire an accessibility API desktop focus event on the new element referenced by aria-activedescendant. If aria-activedescendant is cleared or does not point to an element in the current document, fire a desktop focus event for the object that had the attribute change.
        4. +
      4. Apply the following accessibility API states to any element with an ID attribute that can be referenced by an element with both an aria-activedescendant attribute and has DOM focus. There are two ways an element can be referenced by aria-activedescendant. One way is when it is an accessibility descendant of the element with aria-activedescendant and the other is when it is an accessibility descendant of an element that is controlled by an element with role of combobox, textbox or searchbox with an aria-activedescendant attribute:
          -
        1. Focusable, if the element also has a WAI-ARIA role. The element needs to be focusable because it could be referenced by the aria-activedescendant attribute. Native elements that have no role attribute do not need to be checked; their native semantics determine the focusable state.
          2. -
        2. Focused, whenever the element is the target of the aria-activedescendant attribute and the element with the aria-activedescendant attribute has DOM focus.
          3. +
        3. Focusable, if the element also has a WAI-ARIA role. The element needs to be focusable because it could be referenced by the aria-activedescendant attribute. Native elements that have no role attribute do not need to be checked; their native semantics determine the focusable state.
          4. +
        4. Focused, whenever the element is the target of the aria-activedescendant attribute and the element with the aria-activedescendant attribute has DOM focus.
        -
        5. -
      -

      When an assistive technology uses its platform's accessibility API to request a change of focus, user agents MUST do the following:

      -
        -
      1. Remove the platform's focused state from the previously focused object.
        2. -
      2. Set the DOM focus: +
        3. +
      +

      When an assistive technology uses its platform's accessibility API to request a change of focus, user agents MUST do the following:

      +
        +
      1. Remove the platform's focused state from the previously focused object.
        2. +
      2. Set the DOM focus:
          -
        1. If the element can take DOM focus, the user agent MUST set the DOM focus to it.
          2. -
        2. Otherwise, if the element being focused has an ID and the ID is referenced by the aria-activedescendant attribute of an element that is focusable, the user agent MUST set DOM focus to the element that has the aria-activedescendant attribute. -

          An element with an ID can be referenced when it is an accessibility descendant of a container element that has the aria-activedescendant attribute or by a container element that is controlled by an element that has the aria-activedescendant attribute (e.g. see combobox). Otherwise the aria-activedescendant attribute reference indicates an author error.

          -

          The inability to set DOM focus to the containing element indicates an author error.

          -
          3. -
        3. Otherwise, the user agent MAY attempt to set DOM focus to the child element itself.
          4. +
        4. If the element can take DOM focus, the user agent MUST set the DOM focus to it.
          5. +
        5. Otherwise, if the element being focused has an ID and the ID is referenced by the aria-activedescendant attribute of an element that is focusable, the user agent MUST set DOM focus to the element that has the aria-activedescendant attribute. +

          An element with an ID can be referenced when it is an accessibility descendant of a container element that has the aria-activedescendant attribute or by a container element that is controlled by an element that has the aria-activedescendant attribute (e.g. see combobox). Otherwise the aria-activedescendant attribute reference indicates an author error.

          +

          The inability to set DOM focus to the containing element indicates an author error.

          +
          6. +
        6. Otherwise, the user agent MAY attempt to set DOM focus to the child element itself.
        -
        3. -
      3. If the element being focused has an ID and is an accessibility descendant of either a container element with both an aria-activedescendant attribute and has DOM focus, or by a container element that is controlled by an element with both an aria-activedescendant attribute and has DOM focus, the user agent MUST set the accessibility API focused state and fire an accessibility API focus event on the element identified by the value of aria-activedescendant.
        4. -
      -
      +
      5. +
    5. If the element being focused has an ID and is an accessibility descendant of either a container element with both an aria-activedescendant attribute and has DOM focus, or by a container element that is controlled by an element with both an aria-activedescendant attribute and has DOM focus, the user agent MUST set the accessibility API focused state and fire an accessibility API focus event on the element identified by the value of aria-activedescendant.
      6. +
    +
    @@ -663,7 +663,7 @@

    Accessible Name Calculation

    1. author: name comes from values provided by the author in explicit markup features such as the aria-label attribute, the aria-labelledby attribute, or the host language labeling mechanism, such as the alt or title attributes in HTML, with HTML title attribute having the lowest precedence for specifying a text alternative.
    2. contents: name comes from the text value of the element node. Although this might be allowed in addition to "author" in some roles, this is used in content only if higher priority "author" features are not provided. Priority is defined by the accessible name and description computation algorithm [[ACCNAME-1.2]].
      3. -
    3. prohibited: the element does not support name from author. Authors MUST NOT use the aria-label or aria-labelledby attributes to name the element.
      4. +
    4. prohibited: the element does not support name from author. Authors MUST NOT use the aria-label or aria-labelledby attributes to name the element.
    @@ -679,21 +679,21 @@

    Description Computation

    Accessible Name and Description Computation

    Accessible Name and Description Computation is defined in the Accessible Name and Description specification.

    -
    -

    Roles Supporting Name from Author

    -
    -
    +
    +

    Roles Supporting Name from Author

    +
    +
    -
    -

    Roles Supporting Name from Content

    -
    -
    +
    +

    Roles Supporting Name from Content

    +
    +
    -

    Roles which cannot be named (Name prohibited)

    -
    -
    -
    +

    Roles which cannot be named (Name prohibited)

    +
    +
    +

    Presentational Children

    @@ -756,8 +756,8 @@

    Widget Roles

  • menuitemradio
  • option
  • progressbar
    • @@ -832,8 +832,8 @@

    Document Structure Roles

  • time
  • toolbar
    • @@ -1238,8 +1238,8 @@

    Definition of Roles

    A landmark that contains mostly site-oriented content, rather than page-specific content.

    Site-oriented content typically includes things such as the logo or identity of the site sponsor, and a site-specific search tool. A banner usually appears at the top of the page and typically spans the full width.

    Assistive technologies SHOULD enable users to quickly navigate to elements with role banner. - [=user agents=] SHOULD treat elements with role banner as navigational landmarks. - [=user agents=] MAY enable users to quickly navigate to elements with role banner.

    + [=user agents=] SHOULD treat elements with role banner as navigational landmarks. + [=user agents=] MAY enable users to quickly navigate to elements with role banner.

    The author SHOULD mark no more than one element on a page with the banner role.

    Because document and application elements can be nested in the DOM, they can have multiple banner elements as DOM descendants, assuming each of those is associated with different document nodes, either by a DOM nesting (e.g., document within document) or by use of the aria-owns attribute.

    @@ -1428,7 +1428,7 @@

    Definition of Roles

    Related Concepts: - link + link
    @@ -2044,7 +2044,7 @@

    Definition of Roles

    The Guidance for combobox has changed significantly in ARIA 1.2 due to problems with implementation of the previous patterns. Authors and developers of User Agents, Assistive Technologies, and Conformance Checkers are advised to review this section carefully to understand the changes. - Explanation of the changes is available in the ARIA repository wiki. + Explanation of the changes is available in the ARIA repository wiki.

    A combobox functionally combines a named input field with the ability to assist value selection via a supplementary popup element. @@ -2076,15 +2076,15 @@

    Definition of Roles

  • Otherwise, the value of the combobox is represented by its descendant elements and can be determined using the same method used to compute the name of a button from its descendant content.
    • -					<label id="tag_label" for="tag_combo">Tag</label>
-					<input type="text" id="tag_combo"
-						role="combobox" aria-autocomplete="list"
-						aria-haspopup="listbox" aria-expanded="true"
-						aria-controls="popup_listbox" aria-activedescendant="selected_option">
-					<ul role="listbox" id="popup_listbox" aria-labelledby="tag_label">
-						<li role="option">Zebra</li>
-						<li role="option" id="selected_option">Zoom</li>
-					</ul>
+          <label id="tag_label" for="tag_combo">Tag</label>
+		      <input type="text" id="tag_combo"
+            role="combobox" aria-autocomplete="list"
+            aria-haspopup="listbox" aria-expanded="true"
+            aria-controls="popup_listbox" aria-activedescendant="selected_option">
+				  <ul role="listbox" id="popup_listbox" aria-labelledby="tag_label">
+			      <li role="option">Zebra</li>
+			      <li role="option" id="selected_option">Zoom</li>
+				  </ul>

    Please review the following carefully. As a result of these changes a combobox following the ARIA 1.1 combobox specification will no longer conform with the ARIA specification. @@ -2146,7 +2146,7 @@

    Definition of Roles

    - + @@ -4746,7 +4658,7 @@

    Definition of Roles

    - + @@ -4771,15 +4683,15 @@

    Definition of Roles

    - + - + - +
    Characteristics:
    Supported States and Properties:
      -
    • aria-activedescendant
      • +
    • aria-activedescendant
    • aria-autocomplete
    • aria-controls
    • aria-errormessage
      • @@ -2375,8 +2375,8 @@

      Definition of Roles

      A landmark that is designed to be complementary to the main content that it is a sibling to, or a direct descendant of. The contents of a complementary landmark would be expected to remain meaningful if it were to be separated from the main content it is relevant to.

      There are various types of content that would appropriately have this role. For example, in the case of a portal, this can include but not be limited to show times, current weather, related articles, or stocks to watch. If the complementary content is completely separable from the main content, it might be appropriate to use a more general role.

      Assistive technologies SHOULD enable users to quickly navigate to elements with role complementary. - [=user agents=] SHOULD treat elements with role complementary as navigational landmarks. - [=user agents=] MAY enable users to quickly navigate to elements with role complementary.

      + [=user agents=] SHOULD treat elements with role complementary as navigational landmarks. + [=user agents=] MAY enable users to quickly navigate to elements with role complementary.

      @@ -2532,8 +2532,8 @@

      Definition of Roles

      A landmark that contains information about the parent document.

      Examples of information included in this region of the page are copyrights and links to privacy statements.

      Assistive technologies SHOULD enable users to quickly navigate to elements with role contentinfo. - [=user agents=] SHOULD treat elements with role contentinfo as navigational landmarks. - [=user agents=] MAY enable users to quickly navigate to elements with role contentinfo.

      + [=user agents=] SHOULD treat elements with role contentinfo as navigational landmarks. + [=user agents=] MAY enable users to quickly navigate to elements with role contentinfo.

      The author SHOULD mark no more than one element on a page with the contentinfo role.

      Because document and application elements can be nested in the DOM, they can have multiple contentinfo elements as DOM descendants, assuming each of those is associated with different document nodes, either by a DOM nesting (e.g., document within document) or by use of the aria-owns attribute.

      @@ -2611,12 +2611,12 @@

      Definition of Roles

      Characteristics:
      - definition -
      -

      A definition of a term or concept. See related term.

      -

      Authors MUST identify the element being defined and assign that element a role of term.

      -

      Authors SHOULD NOT use the definition role on interactive elements such as form controls because doing so could prevent users of assistive technologies from interacting with those elements.

      -
      + definition +
      +

      A definition of a term or concept. See related term.

      +

      Authors MUST identify the element being defined and assign that element a role of term.

      +

      Authors SHOULD NOT use the definition role on interactive elements such as form controls because doing so could prevent users of assistive technologies from interacting with those elements.

      +
      @@ -4102,9 +4102,9 @@

      Definition of Roles

      A perceivable section containing content that is relevant to a specific, author-specified purpose and sufficiently important that users will likely want to be able to navigate to the section easily and to have it listed in a summary of the page. Such a page summary could be generated dynamically by a user agent or assistive technology.

      landmark is an abstract role used for the ontology. Authors MUST NOT use landmark role in content.

      Authors designate the purpose of the content by assigning a role that is a subclass of the landmark role and, when needed, by providing a brief, descriptive label.

      -

      Elements with a role that is a subclass of the landmark role are known as landmark regions or navigational landmark regions.

      +

      Elements with a role that is a subclass of the landmark role are known as landmark regions or navigational landmark regions.

      Assistive technologies SHOULD enable users to quickly navigate to landmark regions. - [=user agents=] MAY enable users to quickly navigate to landmark regions.

      + [=user agents=] MAY enable users to quickly navigate to landmark regions.

      Characteristics:
      @@ -4551,95 +4551,7 @@

      Definition of Roles

      Characteristics:
      -
      - listitem -
      -

      A single item in a list or directory.

      -

      Authors MUST ensure [=elements=] whose role is listitem are accessibility children of an element whose role is list.

      -
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Characteristics:
      CharacteristicValue
      Is Abstract: 
      Superclass Role:section
      Subclass Roles:Placeholder
      Base Concept:<[^li^]> in HTML
      Related Concepts:
      Required Accessibility Parent Roles: -
        -
      • directory
        • -
      • list
        • -
      -
      Allowed Accessibility Child Roles: 
      Required States and Properties: 
      Supported States and Properties: -
        -
      • aria-posinset
        • -
      • aria-setsize
        • -
      -
      Inherited States and Properties:Placeholder
      Name From:author
      Accessible Name Required: 
      Inherits Name Required: 
      Children Presentational: 
      Inherits Presentational: 
      -
      -
      +
      listview

      @@ -4713,7 +4625,7 @@

      Definition of Roles
    Is Abstract: 
    Superclass Role:
    Required States and Properties: 
    Supported States and Properties:
    Inherits Name Required: 
    Children Presentational: 
    Inherits Presentational: 
    @@ -4831,7 +4743,7 @@

    Definition of Roles

    Is Abstract: -   + Superclass Role: @@ -4852,7 +4764,7 @@

    Definition of Roles

    Related Concepts: -   + Required Accessibility Parent Roles: @@ -4865,7 +4777,7 @@

    Definition of Roles

    Allowed Accessibility Child Roles: -   + Required States and Properties: @@ -4897,15 +4809,15 @@

    Definition of Roles

    Inherits Name Required: -   + Children Presentational: -   + Inherits Presentational: -   + @@ -4999,8 +4911,8 @@

    Definition of Roles

    A landmark containing the main content of a document.

    This marks the content that is directly related to or expands upon the central topic of the document. The main role is a non-obtrusive alternative for "skip to main content" links, where the navigation option to go to the main content (or other landmarks) is provided by assistive technologies, or by a user agent or browser extension, through a keyboard shortcut or UI feature such as a side panel or dialog.

    Assistive technologies SHOULD enable users to quickly navigate to elements with role main. - [=user agents=] SHOULD treat elements with role main as navigational landmarks. - [=user agents=] MAY enable users to quickly navigate to elements with role main.

    + [=user agents=] SHOULD treat elements with role main as navigational landmarks. + [=user agents=] MAY enable users to quickly navigate to elements with role main.

    The author SHOULD mark no more than one element on a page with the main role.

    Because document and application elements can be nested in the DOM, they can have multiple main elements as DOM descendants, assuming each of those is associated with different document nodes, either by a DOM nesting (e.g., document within document) or by use of the aria-owns attribute.

    @@ -5258,40 +5170,40 @@

    Definition of Roles

    MathML Example with Embedded TeX Annotation

     					<!-- Note: Use a JavaScript polyfill library to ensure
-							 this renders in user agents that do not support MathML. -->
+					     this renders in user agents that do not support MathML. -->
 					<!-- The math element has an implicit role="math". -->
 					<math xmlns="http://www.w3.org/1998/Math/MathML">
-						<mrow>
-							<mi>x</mi>
-							<mo>=</mo>
-							<mfrac>
-								<mrow>
-									<mo form="prefix">−</mo>
-									<mi>b</mi>
-									<mo>±</mo>
-									<msqrt>
-										<msup>
-											<mi>b</mi>
-											<mn>2</mn>
-										</msup>
-										<mo>−</mo>
-										<mn>4</mn>
-										<mo>&#x2062;<!-- &InvisibleTimes; --></mo>
-										<mi>a</mi>
-										<mo>&#x2062;<!-- &InvisibleTimes; --></mo>
-										<mi>c</mi>
-									</msqrt>
-								</mrow>
-								<mrow>
-									<mn>2</mn>
-									<mo>&#x2062;<!-- &InvisibleTimes; --></mo>
-									<mi>a</mi>
-								</mrow>
-							</mfrac>
-						</mrow>
-						<annotation encoding="TeX">
-							x=\frac{-b\pm\sqrt{b^2-4ac}}{2a}
-						</annotation>
+					  <mrow>
+					    <mi>x</mi>
+					    <mo>=</mo>
+					    <mfrac>
+					      <mrow>
+					        <mo form="prefix">−</mo>
+					        <mi>b</mi>
+					        <mo>±</mo>
+					        <msqrt>
+					          <msup>
+					            <mi>b</mi>
+					            <mn>2</mn>
+					          </msup>
+					          <mo>−</mo>
+					          <mn>4</mn>
+					          <mo>&#x2062;<!-- &InvisibleTimes; --></mo>
+					          <mi>a</mi>
+					          <mo>&#x2062;<!-- &InvisibleTimes; --></mo>
+					          <mi>c</mi>
+					        </msqrt>
+					      </mrow>
+					      <mrow>
+					        <mn>2</mn>
+					        <mo>&#x2062;<!-- &InvisibleTimes; --></mo>
+					        <mi>a</mi>
+					      </mrow>
+					    </mfrac>
+					  </mrow>
+					  <annotation encoding="TeX">
+					    x=\frac{-b\pm\sqrt{b^2-4ac}}{2a}
+					  </annotation>
 					</math>

    Plain HTML or Polyfill DOM Result of the MathML Quadratic Formula

    @@ -5786,7 +5698,7 @@

    Plain HTML or Polyfill DOM Result of the MathML Quadratic Formula

    Authors SHOULD enforce that only one menuitemradio in a group can be checked at the same time. When one item in the group is checked, the previously checked item becomes unchecked (its aria-checked attribute becomes false).

    In order to identify that they are related widgets, authors MUST ensure that menu item radios are accessibility descendants of an element with role menu or menubar.

    -

    If a menu or menubar contains more than one group of menuitemradio elements, or if the menu contains one group and other, unrelated menu items, authors SHOULD contain each set of related menuitemradio elements in an element using the group role. Authors MAY also delimit the group from other menu items with an element using the separator role, or an element with an equivalent role from the native markup language. +

    If a menu or menubar contains more than one group of menuitemradio elements, or if the menu contains one group and other, unrelated menu items, authors SHOULD contain each set of related menuitemradio elements in an element using the group role. Authors MAY also delimit the group from other menu items with an element using the separator role, or an element with an equivalent role from the native markup language. @@ -5977,8 +5889,8 @@

    Plain HTML or Polyfill DOM Result of the MathML Quadratic Formula

    A landmark containing a collection of navigational [=elements=] (usually links) for navigating the document or related documents.

    Assistive technologies SHOULD enable users to quickly navigate to elements with role navigation. - [=user agents=] SHOULD treat elements with role navigation as navigational landmarks. - [=user agents=] MAY enable users to quickly navigate to elements with role navigation.

    + [=user agents=] SHOULD treat elements with role navigation as navigational landmarks. + [=user agents=] MAY enable users to quickly navigate to elements with role navigation.

    Characteristics:
    @@ -6080,16 +5992,16 @@

    Plain HTML or Polyfill DOM Result of the MathML Quadratic Formula

    Authors SHOULD NOT provide a meaningful text alternative (for example, use alt="" in HTML) when the none/presentation role is applied to an image.

    In the following code sample, the containing img and is appropriately labeled by the caption paragraph. In this example the img element can be marked as none/presentation because the role and the text alternatives are provided by the containing element.

    <div role="img" aria-labelledby="caption">
-	<img src="example.png" role="none" alt="">
-	<p id="caption">A visible text caption labeling the image.</p>
+  <img src="example.png" role="none" alt="">
+  <p id="caption">A visible text caption labeling the image.</p>
 </div>

    In the following code sample, because the anchor (HTML a element) is acting as the treeitem, the list item (HTML li element) is assigned an explicit WAI-ARIA role of none/presentation to override the user agent's implicit native semantics for list items.

     <ul role="tree">
-	<li role="none">
+  <li role="none">
 	<a role="treeitem" aria-expanded="true">An expanded tree node</a>
-	</li>
-	…
+  </li>
+  …
 </ul>
    Presentational Role Inheritance

    The none/presentation role is used on an element that has implicit native semantics, meaning that there is a default accessibility API role for the element. Some elements are only complete when additional descendant elements are provided. For example, in HTML, table elements (matching the table role) require tr descendants (which have an implicit row role), which in turn require th or td children (the columnheader or rowheader and cell roles, respectively). Similarly, lists require list item children. The descendant elements that complete the semantics of an element are described in WAI-ARIA as Allowed Accessibility Child Roles.

    @@ -6099,18 +6011,18 @@
    Presentational Role Inheritance

    For example, according to an accessibility API, the following markup elements might have identical or very similar role semantics (generic or none role) and identical content.

    <!-- 1. [role="none"] negates the implicit 'list' and 'listitem' role semantics but does not affect the contents. -->
 <ul role="none">
-	<li> Sample Content </li>
-	<li> More Sample Content </li>
+  <li> Sample Content </li>
+  <li> More Sample Content </li>
 </ul>
 
 <!-- 2. There is no implicit role for "foo", so only the contents are exposed. -->
 <foo>
-	<foo> Sample Content </foo>
-	<foo> More Sample Content </foo>
+  <foo> Sample Content </foo>
+  <foo> More Sample Content </foo>
 </foo>

    There are other WAI-ARIA roles with specific allowed children for which this situation is applicable (e.g., feeds and listboxes), but tables and lists are the most common real-world cases in which the none/presentation inheritance is likely to apply.

    For any element with an explicit or inherited role of none/presentation, user agents MUST apply an inherited role of none to all host-language-specific labeling elements for the presentational element. For example, a table element with a role of none/presentation will have the implicit native semantics of its caption element removed, because the caption is merely a label for the presentational table.

    -

    Information about resolving conflicts in the none/presentation role has been moved to Handling Author Errors

    +

    Information about resolving conflicts in the none/presentation role has been moved to Handling Author Errors

    Characteristics:
    @@ -6203,8 +6115,8 @@
    Presentational Role Inheritance
     					<p>... the following results outline support for the tested features.</p>
 					<div role="note">
-						<p>Please keep in mind that at the time of publishing this page all results were accurate.</p>
-						<p>If you find any variations in results, please let us know!</p>
+					  <p>Please keep in mind that at the time of publishing this page all results were accurate.</p>
+					  <p>If you find any variations in results, please let us know!</p>
 					</div>
 					<p>...</p>
    @@ -6214,13 +6126,13 @@
    Presentational Role Inheritance
  • If the note is brief and consists of static text, use aria-describedby.
    • -					<!-- using aria-details to reference a note containing a link -->
-					...
+				  <!-- using aria-details to reference a note containing a link -->
+				  ...
 					<button aria-details="info-note">Get Started</button>
 					...
 					<div role="note" id="info-note">
-						<p>Need more information before you get started?</p>
-						<p>Visit our <a href="...">product description page</a> to get all the information you need.</p>
+					  <p>Need more information before you get started?</p>
+					  <p>Visit our <a href="...">product description page</a> to get all the information you need.</p>
 					</div>
    @@ -6301,30 +6213,30 @@
    Presentational Role Inheritance

    An item in a listbox.

    Authors MUST ensure [=elements=] with role option are accessibility children of an element with role listbox or of an element with role group that is the accessibility child of an element with role listbox. Options not associated with a listbox might not be correctly mapped to an accessibility API.

    -

    In certain conditions, a user agent MAY provide an implicit value for aria-selected for each option in a listbox, and if it does, the user agent MUST ensure the following conditions are met before providing an implicit value:

    -
      -
    • The value of aria-multiselectable on the listbox is false or undefined.
      • -
    • None of the option elements in the listbox have an explicitly declared value for aria-selected or aria-checked.
      • -
    -

    - If a user agent provides an implicit aria-selected value for an option, the value SHOULD be true if the option has DOM focus or the listbox has DOM focus and the option is referenced by aria-activedescendant. - Otherwise, if a user agent provides an implicit aria-selected value for an option, the value SHOULD be false. -

    -

    - Authors SHOULD indicate selection for option elements using one of the following: -

    -
      -
    • An aria-selected value of true on the selected option within a single-select listbox, and optionally aria-selected values of false on unselected options.
      • -
    • Either aria-selected or aria-checked on all options within a multi-select listbox, with a value of true on selected options, and a value of false on unselected options.
      • -
    -

    - Authors SHOULD NOT specify both aria-selected and aria-checked on option elements contained by the same listbox except in the extremely rare circumstances where all the following conditions are met: -

    -
      -
    • The meaning and purpose of aria-selected is different from the meaning and purpose of aria-checked in the user interface.
      • -
    • The user interface makes the meaning and purpose of each state apparent.
      • -
    • The user interface provides a separate method for controlling each state.
      • -
    +

    In certain conditions, a user agent MAY provide an implicit value for aria-selected for each option in a listbox, and if it does, the user agent MUST ensure the following conditions are met before providing an implicit value:

    +
      +
    • The value of aria-multiselectable on the listbox is false or undefined.
      • +
    • None of the option elements in the listbox have an explicitly declared value for aria-selected or aria-checked.
      • +
    +

    + If a user agent provides an implicit aria-selected value for an option, the value SHOULD be true if the option has DOM focus or the listbox has DOM focus and the option is referenced by aria-activedescendant. + Otherwise, if a user agent provides an implicit aria-selected value for an option, the value SHOULD be false. +

    +

    + Authors SHOULD indicate selection for option elements using one of the following: +

    +
      +
    • An aria-selected value of true on the selected option within a single-select listbox, and optionally aria-selected values of false on unselected options.
      • +
    • Either aria-selected or aria-checked on all options within a multi-select listbox, with a value of true on selected options, and a value of false on unselected options.
      • +
    +

    + Authors SHOULD NOT specify both aria-selected and aria-checked on option elements contained by the same listbox except in the extremely rare circumstances where all the following conditions are met: +

    +
      +
    • The meaning and purpose of aria-selected is different from the meaning and purpose of aria-checked in the user interface.
      • +
    • The user interface makes the meaning and purpose of each state apparent.
      • +
    • The user interface provides a separate method for controlling each state.
      • +
    Characteristics:
    @@ -6380,7 +6292,7 @@
    Presentational Role Inheritance
    • aria-checked
    • aria-posinset
      • -
    • aria-selected
      • +
    • aria-selected
    • aria-setsize
    @@ -6422,8 +6334,8 @@
    Presentational Role Inheritance
    Characteristics:

    For a single-selectable tablist, authors SHOULD [=element/hide from all users=] other tabpanel [=elements=] until the user selects the tab associated with that tabpanel. For a multi-selectable tablist, authors SHOULD ensure that the tab for each visible tabpanel has the aria-expanded attribute set to true, and that the tabs associated with the remaining [=element/hidden from all users=] tabpanel elements have their aria-expanded attributes set to false.

    Authors SHOULD ensure that a selected tab has its aria-selected attribute set to true, that inactive tab elements have their aria-selected attribute set to false, and that the currently selected tab provides a visual indication that it is selected.

    -

    In certain conditions, a user agent MAY provide an implicit value for aria-selected for each tab in a tablist, and if it does, the user agent MUST ensure the following conditions are met before providing an implicit value:

    -
      -
    • The value of aria-multiselectable on the tablist is false or undefined.
      • -
    • None of the tab elements in the tablist have an explicitly declared value for aria-selected or aria-expanded.
      • -
    +

    In certain conditions, a user agent MAY provide an implicit value for aria-selected for each tab in a tablist, and if it does, the user agent MUST ensure the following conditions are met before providing an implicit value:

    +
      +
    • The value of aria-multiselectable on the tablist is false or undefined.
      • +
    • None of the tab elements in the tablist have an explicitly declared value for aria-selected or aria-expanded.
      • +
    @@ -9310,8 +9222,8 @@
    Presentational Role Inheritance
    Characteristics: 
    <div id="inaccessibleButton">
-		<!-- Use semantic markup instead. This is just a retrofit example. -->
+    <!-- Use semantic markup instead. This is just a retrofit example. -->
 </div>
    // Get a reference to the element.
 let el = document.getElementById('inaccessibleButton');
@@ -14404,7 +14316,7 @@ 
    Substantive changes since ARIA 1.2
    
 					href="https://github.com/w3c/aria/pull/1137">#1137)
 			
  • Add mark role (#1133)
    • 
-			
+