@@ -1245,6 +1553,8 @@ Definition of Roles
Supported States and Properties: |
+ - aria-disabled
+ - aria-haspopup
- aria-expanded
- aria-pressed
@@ -1285,8 +1595,26 @@ Definition of Roles
caption
- On-screen descriptive text for a figure or table in the page.
- Authors SHOULD reference the element with role caption by setting aria-describedby on the figure or table.
+ Visible content that names, and may also describe, a figure, table, grid, or treegrid.
+ When using caption authors SHOULD ensure:
+
+ - The
caption is a direct child of a figure, table, grid, or treegrid.
+ - The
caption is the first child of a table, grid, or treegrid.
+ - The
caption is the first or last child of a figure.
+
+ Authors SHOULD set aria-labelledby on the parent figure, table, grid, or treegrid to reference the element with role caption. However, if a caption contains content that serves as both a name and description for its parent, authors MAY instead set aria-labelledby to reference an element within the caption that contains a concise name, and set aria-describedby to reference an element within the caption that contains 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>
+ <!-- ... -->
+
Characteristics:
@@ -1315,11 +1643,18 @@ Definition of Roles
| Related Concepts: |
- HTML figcaption
HTML caption |
+ <caption> in [[HTML]]
<figcaption> in [[HTML]] |
| Required Context Role: |
- |
+
+
+ - figure
+ - grid
+ - table
+ - treegrid
+
+ |
| Required Owned Elements: |
@@ -1337,9 +1672,18 @@ Definition of Roles
Inherited States and Properties: |
Placeholder |
+
+ | Prohibited States and Properties: |
+
+
+ - aria-label
+ - aria-labelledby
+
+ |
+
| Name From: |
- author |
+ prohibited |
| Accessible Name Required: |
@@ -1389,7 +1733,7 @@ Definition of Roles
| Base Concept: |
- HTML td |
+ <td> in [[HTML]] |
| Related Concepts: |
@@ -1412,8 +1756,10 @@ Definition of Roles
- aria-colindex
+ - aria-colindextext
- aria-colspan
- aria-rowindex
+ - aria-rowindextext
- aria-rowspan
|
@@ -1485,7 +1831,7 @@ Definition of Roles
Related Concepts: |
|
@@ -1510,7 +1856,11 @@ Definition of Roles
Supported States and Properties: |
+ - aria-errormessage
+ - aria-expanded
+ - aria-invalid
- aria-readonly
+ - aria-required
|
@@ -1523,6 +1873,7 @@ Definition of Roles
- contents
+ - encapsulation
- author
|
@@ -1543,10 +1894,105 @@ Definition of Roles
Inherits Presentational: |
|
-
- | Implicit Value for Role: |
- Default for aria-checked is false. |
-
+
+ | Implicit Value for Role: |
+ |
+
+
+
+
+
+ code
+
+ A section whose content represents a fragment of computer code.
+ The primary purpose of the code role is to inform assistive technologies that the content is computer code and thus may require special presentation, in particular with respect to synthesized speech. More specifically, screen readers and other tools which provide text-to-speech presentation of content SHOULD prefer full punctuation verbosity to ensure common symbols (e.g. "-") are spoken.
+
+
+ Characteristics:
+
+
+ | Characteristic |
+ Value |
+
+
+
+
+ | Is Abstract: |
+ |
+
+
+ | Superclass Role: |
+
+ section
+ |
+
+
+ | Subclass Roles: |
+ Placeholder |
+
+
+ | Base Concept: |
+ |
+
+
+ | Related Concepts: |
+
+ <code> in [[HTML]]
+ |
+
+
+ | Required Context Role: |
+ |
+
+
+ | Required Owned Elements: |
+ |
+
+
+ | Required States and Properties: |
+ |
+
+
+ | Supported States and Properties: |
+ |
+
+
+ | Inherited States and Properties: |
+ Placeholder |
+
+
+ | Prohibited States and Properties: |
+
+
+ - aria-label
+ - aria-labelledby
+
+ |
+
+
+ | Name From: |
+ prohibited |
+
+
+ | Accessible Name Required: |
+ |
+
+
+ | Inherits Name Required: |
+ |
+
+
+ | Children Presentational: |
+ |
+
+
+ | Inherits Presentational: |
+ |
+
+
+ | Implicit Value for Role: |
+ |
+
Definition of Roles
A cell containing header information for a column.
columnheader can be used as a column header in a table or grid. It could also be used in a pie chart to show a similar relationship in the data.
The columnheader establishes a relationship between it and all cells in the corresponding column. It is the structural equivalent to an HTML th element with a column scope.
- Authors MUST ensure elements with role columnheader are contained in, or owned by, an element with the role row.
+ Authors MUST ensure elements with role columnheader are contained in, or owned by, an element with the role row.
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.
Characteristics:
@@ -1590,7 +2037,7 @@ Definition of Roles
| Base Concept: |
- HTML th[scope="col"] |
+ <th[scope="col"]> in [[HTML]] |
| Related Concepts: |
@@ -1647,24 +2094,69 @@ Definition of Roles
combobox
- A composite widget containing a single-line textbox and another element, such as a listbox or grid, that can dynamically pop up to help the user set the value of the textbox.
- Authors MUST ensure an element with role combobox contains or owns a text input element with role textbox or searchbox and that the text input has aria-multiline set to false. If the combobox provides autocompletion behavior for the text input as described in aria-autocomplete, authors MUST set aria-autocomplete on the textbox element to the value that corresponds to the provided behavior.
- Typically, the default state of a combobox is collapsed. In the collapsed state, only the textbox element of a combobox is visible. A combobox is said to be expanded when both the textbox and a secondary element that serves as its popup are visible. Authors MUST set aria-expanded to true on an element with role combobox when it is expanded and false when it is collapsed. Elements with the role combobox have an implicit aria-expanded value of false.
- When a combobox is expanded, authors MUST ensure it contains or owns an element that has a role of listbox, tree, grid, or dialog. This element is the combobox popup. When the combobox is expanded, authors MUST set aria-controls on the textbox element to a value that refers to the combobox popup element.
- Elements with the role combobox have an implicit aria-haspopup value of listbox. If the combobox popup element has a role other than listbox, authors MUST specify a value for aria-haspopup that corresponds to the type of its popup.
- To be keyboard accessible, authors SHOULD manage focus of descendants for all instances of this role, as described in Managing Focus. When a combobox receives focus, authors SHOULD ensure focus is placed on the textbox element.
- Authors SHOULD provide keyboard mechanisms for moving focus between the textbox element and the elements contained in the popup. For example, one common convention is that Down Arrow moves focus from the text input to the first focusable descendant of the popup element. If the popup element supports aria-activedescendant, in lieu of moving focus, such keyboard mechanisms can control the value of aria-activedescendant on the textbox element. When a descendant of the popup element is active, authors MAY set aria-activedescendant on the textbox to a value that refers to the active element within the popup while focus remains on the textbox element.
+ An input that controls another element, such as a listbox or grid, that can dynamically pop up to help the user set the value of the input.
+
+ 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.
+
+
+ A combobox functionally combines a named input field with the ability to assist value selection via a supplementary popup element.
+ A combobox input MAY be either a single-line text field that supports editing and typing or an element that only displays the current value of the combobox.
+ If the combobox supports text input and provides autocompletion behavior as described in aria-autocomplete, authors MUST set aria-autocomplete on the combobox element to the value that corresponds to the provided behavior.
+
+
+ Typically, the initial state of a combobox is collapsed.
+ In the collapsed state, only the combobox element and a separate, optional popup control button are visible.
+ A combobox is said to be expanded when both the combobox element showing its current value and its associated popup element are visible.
+ Authors MUST set aria-expanded to true on an element with role combobox when it is expanded and false when it is collapsed.
+
+
+ Authors MUST ensure the popup element associated with a combobox has a role of listbox, tree, grid, or dialog.
+ Authors MUST set aria-controls on a combobox element to a value that refers to the combobox popup element.
+
+
+ Elements with the role combobox have an implicit aria-haspopup value of listbox.
+ If the combobox popup element has a role other than listbox, authors MUST specify a value for aria-haspopup that corresponds to the role of its popup.
+
+
+ If the user interface includes an additional icon that allows the visibility of the popup to be controlled via pointer and touch events, authors SHOULD ensure that element has role button, that it is focusable but not included in the page Tab sequence, and that it is not a descendant of the element with role combobox.
+ In addition, to be keyboard accessible, authors SHOULD provide keyboard mechanisms for moving focus between the combobox element and elements contained in the popup.
+ For example, one common convention is that Down Arrow moves focus from the input to the first focusable descendant of the popup element.
+ If the popup element supports aria-activedescendant, in lieu of moving focus, such keyboard mechanisms can control the value of aria-activedescendant on the combobox element.
+ When a descendant of the popup element is active, authors MAY set aria-activedescendant on the combobox to a value that refers to the active element within the popup while focus remains on the combobox element.
+
+
+ User agents MUST expose the value of elements with role combobox to assistive technologies.
+ The value of a combobox is represented by one of the following:
+
+
+ - If the
combobox element is a host language element that provides a value, such as an HTML input element, the value of the combobox is the value of that element.
+ - 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.
+
- <div aria-label="Tag" role="combobox" aria-expanded="true" aria-owns="owned_listbox" aria-haspopup="listbox">
- <input type="text" aria-autocomplete="list" aria-controls="owned_listbox" aria-activedescendant="selected_option">
- </div>
- <ul role="listbox" id="owned_listbox">
- <li role="option">Zebra</li>
- <li role="option" id="selected_option">Zoom</li>
+ <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">
+ <li role="option">Zebra</li>
+ <li role="option" id="selected_option">Zoom</li>
</ul>
- The ARIA 1.0 specification describes a combobox pattern where a text input element has the combobox role and owns a listbox element. User agents, assistive technologies, and conformance checkers SHOULD continue to support the ARIA 1.0 pattern so that existing implementations of the ARIA 1.0 pattern remain functional.
- The features and behaviors of combobox implementations vary widely. Consequently, there are many important authoring considerations. See the WAI-ARIA Authoring Practices Guide [[WAI-ARIA-PRACTICES-1.1]] for additional details on implementing combobox design patterns.
+
+ 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.
+
+
+ The structural requirements for combobox defined by this version of the specification are different from the requirements defined by ARIA 1.0 and ARIA 1.1:
+
+ - The ARIA 1.0 specification required the input element with the
combobox role to be a single-line text field and reference the popup element with aria-owns instead of aria-controls.
+ - The ARIA 1.1 specification, which was not broadly supported by assistive technologies, required the
combobox to be a non-focusable element with two required owned elements -- a focusable textbox and a popup element controlled by the textbox.
+ - The changes introduced in ARIA 1.2 improve interoperability with assistive technologies and enable authors to create presentations of combobox that more closely imitate a native HTML
select element.
+
+
+ The features and behaviors of combobox implementations vary widely. Consequently, there are many important authoring considerations. See the WAI-ARIA Authoring Practices for additional details on implementing combobox design patterns.
Characteristics:
@@ -1681,7 +2173,7 @@ Definition of Roles
| Superclass Role: |
- select |
+ input |
| Subclass Roles: |
@@ -1694,10 +2186,7 @@ Definition of Roles
| Related Concepts: |
-
+ <select> in [[HTML]]
|
@@ -1706,15 +2195,7 @@ Definition of Roles
| Required Owned Elements: |
-
- textbox and, when expanded, one of:
-
- - listbox
- - tree
- - grid
- - dialog
-
- |
+ |
| Required States and Properties: |
@@ -1729,7 +2210,11 @@ Definition of Roles
Supported States and Properties: |
+ - aria-activedescendant
- aria-autocomplete
+ - aria-errormessage
+ - aria-haspopup
+ - aria-invalid
- aria-readonly
- aria-required
@@ -1762,7 +2247,6 @@ Definition of Roles
|
| Implicit Value for Role: |
- Default for aria-expanded is false.
Default for aria-haspopup is listbox.
|
@@ -1802,7 +2286,7 @@ Definition of Roles
| Related Concepts: |
- menuitem in [[HTML51]] |
+ |
| Required Context Role: |
@@ -1847,10 +2331,111 @@ Definition of Roles
+
complementary
- A supporting section of the document, designed to be complementary to the main content at a similar level in the DOM hierarchy, but remains meaningful when separated from the main content.
+ A landmark that is designed to be complementary to the main content at a similar level in the DOM hierarchy, but remaining meaningful when separated from the main content.
There are various types of content that would appropriately have this role. For example, in the case of a portal, this may include but not be limited to show times, current weather, related articles, or stocks to watch. The complementary role indicates that contained content is relevant to the main content. If the complementary content is completely separable from the main content, it may be appropriate to use a more general role.
User agents SHOULD treat elements with the role of complementary as navigational landmarks.
@@ -1929,7 +2514,7 @@ Definition of Roles
composite
- A widget that may contain navigable descendants or owned children.
+ A widget that may contain navigable descendants or owned children.
Authors SHOULD ensure that a composite widget exists as a single navigation stop within the larger navigation system of the web page. Once the composite widget has focus, authors SHOULD provide a separate navigation mechanism for users to navigate to elements that are descendants or owned children of the composite element.
composite is an abstract role used for the ontology. Authors should not use this role in content.
@@ -1968,7 +2553,12 @@ Definition of Roles
| Supported States and Properties: |
- aria-activedescendant |
+
+
+ - aria-activedescendant
+ - aria-disabled
+
+ |
| Inherited States and Properties: |
@@ -2000,7 +2590,7 @@ Definition of Roles
contentinfo
- A large perceivable region that contains information about the parent document.
+ 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.
User agents SHOULD treat elements with the role of contentinfo as navigational landmarks.
@@ -2083,7 +2673,7 @@ Definition of Roles
definition
A definition of a term or concept. See related term.
- Authors SHOULD identify the element being defined by giving that element a role of term and referencing it with the aria-labelledby attribute.
+ Authors SHOULD identify the element being defined by giving that element a role of term and referencing it with the aria-labelledby attribute or by making the element with role term a descendant of the element with role definition.
Characteristics:
@@ -2110,14 +2700,79 @@ Definition of Roles
Base Concept: |
|
+
+ | Required Context Role: |
+ |
+
+
+ | Required Owned Elements: |
+ |
+
+
+ | Required States and Properties: |
+ |
+
+
+ | Supported States and Properties: |
+ |
+
+
+ | Inherited States and Properties: |
+ Placeholder |
+
+
+ | Name From: |
+ author |
+
+
+ | Accessible Name Required: |
+ |
+
+
+ | Inherits Name Required: |
+ |
+
+
+ | Children Presentational: |
+ |
+
+
+ | Inherits Presentational: |
+ |
+
+
+
+
+
+ deletion
+
+ A deletion contains content that is marked as removed or content that is being suggested for removal. See related insertion.
+ Deletions are typically used to either mark differences between two versions of content or to designate content suggested for removal in scenarios where multiple people are revising content.
+
+
+ Characteristics:
+
+
+ | Characteristic |
+ Value |
+
+
+
+
+ | Is Abstract: |
+ |
+
+
+ | Superclass Role: |
+ section |
+
+
+ | Base Concept: |
+ |
+
| Related Concepts: |
-
-
- |
+ <del> in [[HTML]] |
| Required Context Role: |
@@ -2133,15 +2788,24 @@ Definition of Roles
| Supported States and Properties: |
- |
+ |
| Inherited States and Properties: |
Placeholder |
+
+ | Prohibited States and Properties: |
+
+
+ - aria-label
+ - aria-labelledby
+
+ |
+
| Name From: |
- author |
+ prohibited |
| Accessible Name Required: |
@@ -2167,7 +2831,7 @@ Definition of Roles
A dialog is a descendant window of the primary window of a web application. For HTML pages, the primary application window is the entire web document, i.e., the body element.
Dialogs are most often used to prompt the user to enter or respond to information. A dialog that is designed to interrupt workflow is usually modal. See related alertdialog.
- Authors SHOULD provide a dialog label, which can be done with the aria-label or aria-labelledby attribute.
+ Authors MUST provide an accessible name for a dialog, which can be done with the aria-label or aria-labelledby attribute.
Authors SHOULD ensure that all dialogs (both modal and non-modal) have at least one focusable descendant element. Authors SHOULD focus an element in the modal dialog when it is displayed, and authors SHOULD manage focus of modal dialogs.
In the description of this role, the term "web application" does not refer to the application role, which specifies specific assistive technology behaviors.
@@ -2246,8 +2910,9 @@ Definition of Roles
directory
- A list of references to members of a group, such as a static table of contents.
- Authors SHOULD use this role for a static table of contents, whether linked or unlinked. This includes tables of contents built with lists, including nested lists. Dynamic tables of contents, however, might use a tree role instead.
+ [Deprecated in ARIA 1.2] A list of references to members of a group, such as a static table of contents.
+ As exposed by accessibility APIs, the directory role is essentially equivalent to the list role. So, using directory does not provide any additional benefits to assistive technology users. Authors are advised to treat directory as deprecated and to use list, or a host language's equivalent semantics instead.
+ A directory is a static table of contents, whether linked or unlinked. This includes tables of contents built with lists, including nested lists. Dynamic tables of contents, however, might use a tree role instead.
Characteristics:
@@ -2276,7 +2941,7 @@ Definition of Roles
| Related Concepts: |
- DAISY Guide |
+ |
| Required Context Role: |
@@ -2355,7 +3020,7 @@ Definition of Roles
| Related Concepts: |
- Device Independence Delivery Unit |
+ |
| Required Context Role: |
@@ -2371,7 +3036,7 @@ Definition of Roles
| Supported States and Properties: |
- aria-expanded |
+ |
| Inherited States and Properties: |
@@ -2400,6 +3065,94 @@ Definition of Roles
+
+ emphasis
+
+ One or more emphasized characters. See related strong.
+ The purpose of the emphasis role is to stress or emphasize content. It is not for communicating changes in typographical presentation that do not impact the meaning of the content. Authors SHOULD use the emphasis role only if its absence would change the meaning of the content.
+ The emphasis role is not intended to convey importance; for that purpose, the strong role is more appropriate.
+
+
+ Characteristics:
+
+
+ | Characteristic |
+ Value |
+
+
+
+
+ | Is Abstract: |
+ |
+
+
+ | Superclass Role: |
+ section |
+
+
+ | Subclass Roles: |
+ Placeholder |
+
+
+ | Base Concept: |
+ |
+
+
+ | Related Concepts: |
+ <em> in [[HTML]] |
+
+
+ | Required Context Role: |
+ |
+
+
+ | Required Owned Elements: |
+ |
+
+
+ | Required States and Properties: |
+ |
+
+
+ | Supported States and Properties: |
+ |
+
+
+ | Inherited States and Properties: |
+ Placeholder |
+
+
+ | Prohibited States and Properties: |
+
+
+ - aria-label
+ - aria-labelledby
+
+ |
+
+
+ | Name From: |
+ prohibited |
+
+
+ | Accessible Name Required: |
+ |
+
+
+ | Inherits Name Required: |
+ |
+
+
+ | Children Presentational: |
+ |
+
+
+ | Inherits Presentational: |
+ |
+
+
+
+
feed
@@ -2410,10 +3163,10 @@ Definition of Roles
Authors SHOULD make each article in a feed focusable and ensure that the application scrolls an article into view when user agent focus is set on the article or one of its descendant elements. For example, in HTML, each article element should have a tabindex value of either -1 or 0.
When an assistive technology reading cursor moves from one article to another, assistive technologies SHOULD set user agent focus on the article that contains the reading cursor. If the reading cursor lands on a focusable element inside the article, the assistive technology MAY set focus on that element in lieu of setting focus on the containing article.
Because the ability to scroll to another article with an assistive technology reading cursor depends on the presence of another article in the page, authors SHOULD attempt to load additional articles before user agent focus reaches an article at either end of the set of articles that has been loaded. Alternatively, authors MAY include an article at either or both ends of the loaded set of articles that includes an element, such as a button, that lets the user request more articles to be loaded.
- In addition to providing a brief label, authors MAY apply aria-describedby to article elements in a feed to suggest to screen readers which elements to speak after the label when users navigate by article. Screen readers MAY provide users with a way to quickly scan feed content by speaking both the label and accessible description when navigating by article, enabling the user to ignore repetitive or less important elements, such as embedded interaction widgets, that the author has left out of the description.
+ In addition to providing a brief label, authors MAY apply aria-describedby to article elements in a feed to suggest to screen readers which elements to speak after the label when users navigate by article. Screen readers MAY provide users with a way to quickly scan feed content by speaking both the label and accessible description when navigating by article, enabling the user to ignore repetitive or less important elements, such as embedded interaction widgets, that the author has left out of the description.
Authors SHOULD provide keyboard commands for moving focus among articles in a feed so users who do not utilize an assistive technology that provides article navigation features can use the keyboard to navigate the feed.
If the number of articles available in a feed supply is static, authors MAY specify aria-setsize on article elements in that feed. However, if the total number is extremely large, indefinite, or changes often, authors MAY set aria-setsize to -1 to communicate the unknown size of the set.
- See the WAI-ARIA Authoring Practices [[WAI-ARIA-PRACTICES-1.1]] for additional details on implementing a feed design pattern.
+ See the WAI-ARIA Authoring Practices for additional details on implementing a feed design pattern.
Characteristics:
@@ -2522,7 +3275,7 @@ Definition of Roles
| Related Concepts: |
- HTML figure
+ <figure> in [[HTML]]
|
@@ -2572,7 +3325,9 @@ Definition of Roles
form
A landmark region that contains a collection of items and objects that, as a whole, combine to create a form. See related search.
- A form may be a mix of host language form controls, scripted controls, and hyperlinks. Authors are reminded to use native host language semantics to create form controls, whenever possible. For search facilities, authors SHOULD use the search role and not the generic form role. Authors SHOULD provide a visible label for the form referenced with aria-labelledby. If an author uses a script to submit a form based on a user action that would otherwise not trigger an onsubmit event (for example, a form submission triggered by the user changing a form element's value), the author SHOULD provide the user with advance notification of the behavior.
+ A form may contain a mix of host language form controls, scripted controls, and hyperlinks. Authors are reminded to use native host language semantics to create form controls whenever possible. If the purpose of a form is to submit search criteria, authors SHOULD use the search role instead of the generic form role.
+ Authors MUST give each element with role form a brief label that describes the purpose of the form. Authors SHOULD reference a visible label with aria-labelledby if a visible label is present. Authors SHOULD include the label inside of a heading whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading.
+ If an author uses a script to submit a form based on a user action that would otherwise not trigger an onsubmit event (for example, a form submission triggered by the user changing a form element's value), the author SHOULD provide the user with advance notification of the behavior.
User agents SHOULD treat elements with the role of form as navigational landmarks.
@@ -2598,7 +3353,7 @@ Definition of Roles
| Base Concept: |
- HTML form |
+ <form> in [[HTML]] |
| Related Concepts: |
@@ -2630,7 +3385,7 @@ Definition of Roles
| Accessible Name Required: |
- |
+ true |
| Inherits Name Required: |
@@ -2647,19 +3402,109 @@ Definition of Roles
-
- grid
+
+ generic
- A composite widget containing a collection of one or more rows with one or more cells where some or all cells in the grid are focusable by using methods of two-dimensional navigation, such as directional arrow keys.
- The grid role does not imply a specific visual, e.g., tabular, presentation. It describes relationships among elements. It may be used for purposes as simple as grouping a collection of checkboxes or navigation links or as complex as creating a full-featured spreadsheet application.
- The cell elements of a grid have role gridcell. Authors MAY designate a cell as a row or column header by using either the rowheader or columnheader role in lieu of the gridcell role. Authors MUST ensure elements with role gridcell, columnheader, or rowheader are owned by elements with role row, which are in turn owned by an element with role rowgroup, or grid.
- To be keyboard accessible, authors SHOULD manage focus of descendants of a grid as described in Managing Focus. When a user is navigating the grid content with a keyboard, authors SHOULD set focus as follows:
-
- - If a gridcell contains a single interactive widget that will not consume arrow key presses when it receives focus, such as a checkbox, button, or link, authors MAY set focus on the interactive element contained in that cell. This allows the contained widget to be directly operable.
- - Otherwise, authors SHOULD ensure the element that receives focus is a gridcell, rowheader, or columnheader element.
-
- Authors SHOULD provide a mechanism for changing to an interaction or edit mode that allows users to navigate and interact with content contained inside a focusable cell if that focusable cell contains any of the following:
-
+ A nameless container element that has no semantic meaning on its own.
+ The generic role is intended for use as the implicit role of generic elements in host languages (such as HTML div or span), so is primarily for implementors of user agents. Authors SHOULD NOT use this role in content. Authors MAY use presentation or none to remove implicit accessibility semantics, or a semantic container role such as group to semantically group descendants in a named container.
+ Like an element with role presentation, an element with role generic can provide a limited number of accessible states and properties for its descendants, such as aria-live attributes. However, unlike elements with role presentation, generic elements are exposed in accessibility APIs so that assistive technologies can gather certain properties such as layout and bounds.
+
+
+ Characteristics:
+
+
+ | Characteristic |
+ Value |
+
+
+
+
+ | Is Abstract: |
+ |
+
+
+ | Superclass Role: |
+ structure |
+
+
+ | Subclass Roles: |
+ Placeholder |
+
+
+ | Base Concept: |
+ |
+
+
+ | Related Concepts: |
+ HTML div, HTML span |
+
+
+ | Required Context Role: |
+ |
+
+
+ | Required Owned Elements: |
+ |
+
+
+ | Required States and Properties: |
+ |
+
+
+ | Supported States and Properties: |
+ |
+
+
+ | Inherited States and Properties: |
+ Placeholder |
+
+
+ | Prohibited States and Properties: |
+
+
+ - aria-brailleroledescription
+ - aria-label
+ - aria-labelledby
+ - aria-roledescription
+
+ |
+
+
+ | Name From: |
+ prohibited |
+
+
+ | Accessible Name Required: |
+ |
+
+
+ | Inherits Name Required: |
+ |
+
+
+ | Children Presentational: |
+ |
+
+
+ | Inherits Presentational: |
+ |
+
+
+
+
+
+ grid
+
+ A composite widget containing a collection of one or more rows with one or more cells where some or all cells in the grid are focusable by using methods of two-dimensional navigation, such as directional arrow keys.
+ The grid role does not imply a specific visual, e.g., tabular, presentation. It describes relationships among elements. It may be used for purposes as simple as grouping a collection of checkboxes or navigation links or as complex as creating a full-featured spreadsheet application.
+ The cell elements of a grid have role gridcell. Authors MAY designate a cell as a row or column header by using either the rowheader or columnheader role in lieu of the gridcell role. Authors MUST ensure elements with role gridcell, columnheader, or rowheader are owned by elements with role row, which are in turn owned by an element with role rowgroup, or grid.
+ To be keyboard accessible, authors SHOULD manage focus of descendants of a grid as described in Managing Focus. When a user is navigating the grid content with a keyboard, authors SHOULD set focus as follows:
+
+ - If a gridcell contains a single interactive widget that will not consume arrow key presses when it receives focus, such as a checkbox, button, or link, authors MAY set focus on the interactive element contained in that cell. This allows the contained widget to be directly operable.
+ - Otherwise, authors SHOULD ensure the element that receives focus is a gridcell, rowheader, or columnheader element.
+
+ Authors SHOULD provide a mechanism for changing to an interaction or edit mode that allows users to navigate and interact with content contained inside a focusable cell if that focusable cell contains any of the following:
+
- a widget that requires arrow keys to operate, e.g., a combobox or radiogroup
- multiple interactive elements
- editable content
@@ -2667,12 +3512,12 @@ Definition of Roles
For example, if a cell in a spreadsheet contains a combobox or editable text, the Enter key might be used to activate a cell interaction or editing mode when that cell has focus so the directional arrow keys can be used to operate the contained combobox or textbox. Depending on the implementation, pressing Enter again, Tab, Escape, or another key may switch the application back to the grid navigation mode.
Authors MAY use a gridcell to display the result of a formula, which could be editable by the user. In a spreadsheet application, for example, a gridcell may show a value calculated from a formula until the user activates the gridcell for editing when a textbox appears in the gridcell containing the formula in an editable state.
- If aria-readonly is set on an element with role grid, user agents MUST propagate the value to all gridcell elements owned by the grid and expose the value in the accessibility API. An author MAY override the propagated value of aria-readonly for an individual gridcell element.
+ If aria-readonly is set on an element with role grid, user agents MUST propagate the value to all gridcell elements owned by the grid and expose the value in the accessibility API. An author MAY override the propagated value of aria-readonly for an individual gridcell element.
In a grid that provides cell content editing functions, if the content of a focusable gridcell element is not editable, authors MAY set aria-readonly to true on the gridcell element. However, the value of aria-readonly, whether specified for a grid or individual cells, only indicates whether the content contained in cells is editable. It does not represent availability of functions for navigating or manipulating the grid itself.
An unspecified value for aria-readonly does not imply that a grid or a gridcell contains editable content. For example, if a grid presents a collection of elements that are not editable, such as a collection of link elements representing dates in a datepicker, it is not necessary for the author to specify a value for aria-readonly.
Authors MAY indicate that a focusable gridcell is selectable as the object of an action with the aria-selected attribute. If the grid allows multiple gridcells to be selected, the author SHOULD set aria-multiselectable to true on the element with role grid.
Since WAI-ARIA can augment an element of the host language, a grid can reuse the elements and attributes of a native table, such as an HTML table element. For example, if an author applies the grid role to an HTML table element, the author does not need to apply the row and gridcell roles to the descendant HTML tr and td elements because the user agent will automatically make the appropriate translations. When the author is reusing a native host language table element and needs a gridcell element to span multiple rows or columns, the author SHOULD apply the appropriate host language attributes instead of WAI-ARIA aria-rowspan or aria-colspan properties.
- See the WAI-ARIA Authoring Practices Guide [[WAI-ARIA-PRACTICES-1.1]] for additional details on implementing grid design patterns.
+ See the WAI-ARIA Authoring Practices for additional details on implementing grid design patterns.
Characteristics:
@@ -2702,7 +3547,7 @@ Definition of Roles
| Base Concept: |
- HTML table |
+ <table> in [[HTML]] |
| Related Concepts: |
@@ -2729,7 +3574,6 @@ Definition of Roles
Supported States and Properties: |
- - aria-level
- aria-multiselectable
- aria-readonly
@@ -2769,7 +3613,7 @@ Definition of Roles
A gridcell may be focusable, editable, and selectable. A gridcell may have relationships such as aria-controls to address the application of functional relationships.
If an author intends a gridcell to have a row header, column header, or both, and if the relevant headers cannot be determined from the DOM structure, authors SHOULD explicitly indicate which header cells are relevant to the gridcell by applying aria-describedby on the gridcell and referencing elements with role rowheader or columnheader.
In a treegrid, authors MAY define a gridcell as expandable by using the aria-expanded attribute. If the aria-expanded attribute is provided, it applies only to the individual cell. It is not a proxy for the container row, which also can be expanded. The main use case for providing this attribute on a gridcell is pivot table behavior.
- Authors MUST ensure elements with role gridcell are contained in, or owned by, an element with the role row.
+ Authors MUST ensure elements with role gridcell are contained in, or owned by, an element with the role row.
Characteristics:
@@ -2799,7 +3643,7 @@ Definition of Roles
| Base Concept: |
- HTML td |
+ <td> in [[HTML]] |
| Related Concepts: |
@@ -2821,6 +3665,11 @@ Definition of Roles
Supported States and Properties: |
+ - aria-disabled
+ - aria-errormessage
+ - aria-expanded
+ - aria-haspopup
+ - aria-invalid
- aria-readonly
- aria-required
- aria-selected
@@ -2842,7 +3691,7 @@ Definition of Roles
|
| Accessible Name Required: |
- True |
+ |
| Inherits Name Required: |
@@ -2862,10 +3711,10 @@ Definition of Roles
group
- A set of user interface objects which are not intended to be included in a page summary or table of contents by assistive technologies.
- Contrast with region which is a grouping of user interface objects that will be included in a page summary or table of contents.
- Authors SHOULD use a group to form logical collection of items in a widget such as children in a tree widget forming a collection of siblings in a hierarchy, or a collection of items having the same container in a directory. However, when a group is used in the context of list, authors MUST limit its children to listitem elements. Therefore, proper handling of group by authors and assistive technologies is determined by the context in which it is provided.
- Authors MAY nest group elements. If a section is significant enough to warrant inclusion in the web page's table of contents, the author SHOULD assign the section a role of region or a standard landmark role.
+ A set of user interface objects that is not intended to be included in a page summary or table of contents by assistive technologies.
+ Contrast with region, which is a grouping of user interface objects that will be included in a page summary or table of contents.
+ Authors SHOULD use a group to form a logical collection of items in a widget, such as children in a tree widget forming a collection of siblings in a hierarchy. However, when a group is used in the context of a listbox, authors MUST limit its children to option elements. Therefore, proper handling of group by authors and assistive technologies is determined by the context in which it is provided.
+ Authors MAY nest group elements. If a section is significant enough to warrant inclusion in the web page's table of contents, the author SHOULD assign it a role of region or a standard landmark role.
Characteristics:
@@ -2894,7 +3743,7 @@ Definition of Roles
| Related Concepts: |
- HTML fieldset |
+ <fieldset> in [[HTML]] |
| Required Context Role: |
@@ -2910,7 +3759,12 @@ Definition of Roles
| Supported States and Properties: |
- aria-activedescendant |
+
+
+ - aria-activedescendant
+ - aria-disabled
+
+ |
| Inherited States and Properties: |
@@ -2918,7 +3772,12 @@ Definition of Roles
| Name From: |
- author |
+
+
+ |
| Accessible Name Required: |
@@ -2943,7 +3802,7 @@ Definition of Roles
heading
A heading for a section of the page.
- Often, heading elements will be referenced with the aria-labelledby attribute of the section for which they serve as a heading. If headings are organized into a logical outline, the aria-level attribute is used to indicate the nesting level.
+ To ensure elements with a role of heading are organized into a logical outline, authors MUST use the aria-level attribute to indicate the proper nesting level.
Characteristics:
@@ -2972,7 +3831,7 @@ Definition of Roles
| Related Concepts: |
- HTML h1, h2, h3, h4, h5, and h6 |
+ <h1>, <h2>, <h3>, <h4>, <h5>, and <h6> in [[HTML]] |
| Required Context Role: |
@@ -3019,10 +3878,6 @@ Definition of Roles
Inherits Presentational: |
|
-
- | Implicit Value for Role: |
- Default for aria-level is 2. |
-
@@ -3059,11 +3914,8 @@ Definition of Roles
| Related Concepts: |
-
-
- |
+ <img> in [[HTML]] |
+
| Required Context Role: |
@@ -3140,7 +3992,7 @@ Definition of Roles
| Related Concepts: |
- XForms input |
+ |
| Required States and Properties: |
@@ -3148,7 +4000,7 @@ Definition of Roles
| Supported States and Properties: |
- |
+ aria-disabled |
| Inherited States and Properties: |
@@ -3177,14 +4029,11 @@ Definition of Roles
-
- landmark
+
+ insertion
- 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.
- 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.
-Assistive technologies SHOULD enable users to quickly navigate to landmark regions. Mainstream user agents MAY enable users to quickly navigate to landmark regions.
- landmark is an abstract role used for the ontology. Authors should not use this role in content.
+ An insertion contains content that is marked as added or content that is being suggested for addition. See related deletion.
+ Insertions are typically used to either mark differences between two versions of content or to designate content suggested for addition in scenarios where multiple people are revising content.
Characteristics:
@@ -3197,23 +4046,19 @@ Definition of Roles
| Is Abstract: |
- True |
+ |
| Superclass Role: |
section |
-
- | Subclass Roles: |
- Placeholder |
-
| Base Concept: |
|
| Related Concepts: |
- |
+ <ins> in [[HTML]] |
| Required Context Role: |
@@ -3229,19 +4074,28 @@ Definition of Roles
| Supported States and Properties: |
- |
+ |
| Inherited States and Properties: |
Placeholder |
+
+ | Prohibited States and Properties: |
+
+
+ - aria-label
+ - aria-labelledby
+
+ |
+
| Name From: |
- author |
+ prohibited |
| Accessible Name Required: |
- False |
+ |
| Inherits Name Required: |
@@ -3258,12 +4112,32 @@ Definition of Roles
-
- link
+
+ label
- An interactive reference to an internal or external resource that, when activated, causes the user agent to navigate to that resource. See related button.
- If this is a native link in the host language (such as an HTML anchor with an href value), activating the link causes the user agent to navigate to that resource. If this is a simulated link, the web application author is responsible for managing navigation.
- If pressing the link triggers an action but does not change browser focus or page location, authors are advised to consider using the button role instead of the link role.
+ A visible name or caption for a user interface component.
+ An element with role label can provide an accessible name for a user interface component if it is programmatically associated with the element. Authors MAY associate an element with role label with another element by using one of two methods:
+
+ - encapsulation: The element with role
label contains the element it names.
+ - reference: The element with role
label is referenced by the element it names via the aria-labelledby attribute.
+
+ The encapsulation method of naming is supported only if the element being named has one of the following roles:
+
+ - checkbox
+ - listbox
+ - meter
+ - radio
+ - searchbox
+ - spinbutton
+ - switch
+ - textbox
+
+ Authors SHOULD ensure that:
+
+ - All elements with role
label are associated with one or more other elements.
+ - When an element with role
label is activated by touch or a pointer and its associated element is focusable, focus moves to the associated element. If more than one focusable element is associated with the same label, focus moves to the first element.
+
+ Implementation of the label role as described here is currently unlikely. At this time it is anticipated that the label role will not be available in the ARIA 1.3 release
Characteristics:
@@ -3276,48 +4150,40 @@ Definition of Roles
| Is Abstract: |
- |
+ |
| Superclass Role: |
- command |
+ section |
| Subclass Roles: |
- Placeholder |
+ |
| Base Concept: |
- |
+ <label> in [[HTML]] |
+
| Related Concepts: |
-
-
- |
+ |
| Required Context Role: |
- |
+ |
| Required Owned Elements: |
- |
+ |
| Required States and Properties: |
- |
+ |
| Supported States and Properties: |
-
-
- |
+ |
| Inherited States and Properties: |
@@ -3338,24 +4204,27 @@ Definition of Roles
| Inherits Name Required: |
- |
+ |
| Children Presentational: |
- |
+ |
| Inherits Presentational: |
- |
+ |
-
- list
+
+ landmark
- A section containing listitem elements. See related listbox.
- Lists contain children whose role is listitem, or elements whose role is group which in turn contains children whose role is listitem.
+ 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.
+ 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.
+Assistive technologies SHOULD enable users to quickly navigate to landmark regions. Mainstream user agents MAY enable users to quickly navigate to landmark regions.
+ landmark is an abstract role used for the ontology. Authors should not use this role in content.
Characteristics:
@@ -3368,7 +4237,7 @@ Definition of Roles
| Is Abstract: |
- |
+ True |
| Superclass Role: |
@@ -3380,16 +4249,11 @@ Definition of Roles
| Base Concept: |
-
-
- |
+ |
| Related Concepts: |
- |
+ |
| Required Context Role: |
@@ -3397,12 +4261,7 @@ Definition of Roles
| Required Owned Elements: |
-
-
- - group → listitem
- - listitem
-
- |
+ |
| Required States and Properties: |
@@ -3422,7 +4281,7 @@ Definition of Roles
| Accessible Name Required: |
- |
+ False |
| Inherits Name Required: |
@@ -3439,13 +4298,25 @@ Definition of Roles
-
- listbox
+
+ legend
- A widget that allows the user to select one or more items from a list of choices. See related combobox and list.
- Items within the list are static and, unlike standard HTML select elements, may contain images. List boxes contain children whose role is option or elements whose role is group which in turn contains children whose role is option.
- To be keyboard accessible, authors SHOULD manage focus of option descendants for all instances of this role, as described in Managing Focus.
- Elements with the role listbox have an implicit aria-orientation value of vertical.
+ A visible name or caption for a group of related user interface components.
+ A element with role legend element can provide an accessible name for elements with grouping roles if it is progammatically associated with the element. Authors MAY associate an element with role legend with an element by using one of two methods:
+
+ - legend: The element contains an element with role
legend element. If the element contains more than one element with role legend, only the first descendant element with role legend is used for computing the accessible name.
+ - reference: The element with role
legend is referenced by the element it names via the aria-labelledby attribute.
+
+ The legend method of naming is supported only if the element being named has one of the following grouping roles:
+
+ Authors SHOULD ensure that:
+
+ - All elements with role
legend are associated with one or more elements with grouping roles.
+ - When an element with role
legend is activated by touch or a pointer, focus moves to the first focusable element in the associated group of user interface components.
+
Characteristics:
@@ -3462,42 +4333,27 @@ Definition of Roles
| Superclass Role: |
-
-
- |
+ section |
| Subclass Roles: |
- Placeholder |
+ |
| Base Concept: |
- |
+ <legend> in [[HTML]] |
| Related Concepts: |
-
-
- |
+ |
| Required Context Role: |
- |
+ |
| Required Owned Elements: |
-
-
- - group → option
- - option
-
- |
+ |
| Required States and Properties: |
@@ -3505,13 +4361,7 @@ Definition of Roles
| Supported States and Properties: |
-
-
- - aria-multiselectable
- - aria-readonly
- - aria-required
-
- |
+ |
| Inherited States and Properties: |
@@ -3519,7 +4369,12 @@ Definition of Roles
| Name From: |
- author |
+
+
+ |
| Accessible Name Required: |
@@ -3537,18 +4392,15 @@ Definition of Roles
Inherits Presentational: |
|
-
- | Implicit Value for Role: |
- Default for aria-orientation is vertical. |
-
-
- listitem
+
+ link
- A single item in a list or directory.
- Authors MUST ensure elements with role listitem are contained in, or owned by, an element with the role list or group.
+ An interactive reference to an internal or external resource that, when activated, causes the user agent to navigate to that resource. See related button.
+ If this is a native link in the host language (such as an HTML anchor with an href value), activating the link causes the user agent to navigate to that resource. If this is a simulated link, the web application author is responsible for managing navigation.
+ If pressing the link triggers an action but does not change browser focus or page location, authors are advised to consider using the button role instead of the link role.
Characteristics:
@@ -3565,7 +4417,7 @@ Definition of Roles
| Superclass Role: |
- section |
+ command |
| Subclass Roles: |
@@ -3573,21 +4425,22 @@ Definition of Roles
| Base Concept: |
- HTML li |
+ |
| Related Concepts: |
- XForms item |
-
-
- | Required Context Role: |
-
+ |
- - group
- - list
+ <a> in [[HTML]]<link> in [[HTML]]
|
+
+ | Required Context Role: |
+ |
+
| Required Owned Elements: |
|
@@ -3600,9 +4453,9 @@ Definition of Roles
Supported States and Properties: |
- - aria-level
- - aria-posinset
- - aria-setsize
+ - aria-disabled
+ - aria-expanded
+ - aria-haspopup
|
@@ -3612,11 +4465,16 @@ Definition of Roles
| Name From: |
- author |
+
+
+ |
| Accessible Name Required: |
- |
+ True |
| Inherits Name Required: |
@@ -3633,12 +4491,11 @@ Definition of Roles
-
- log
+
+ list
- A type of live region where new information is added in meaningful order and old information may disappear. See related marquee.
- Examples include chat logs, messaging history, game log, or an error log. In contrast to other live regions, in this role there is a relationship between the arrival of new items in the log and the reading order. The log contains a meaningful sequence and new information is added only to the end of the log, not at arbitrary points.
- Elements with the role log have an implicit aria-live value of polite.
+ A section containing listitem elements. See related listbox.
+ Lists contain children whose role is listitem.
Characteristics:
@@ -3663,7 +4520,12 @@ Definition of Roles
| Base Concept: |
- |
+
+
+ <ol> in [[HTML]]<ul> in [[HTML]]
+ |
| Related Concepts: |
@@ -3675,7 +4537,7 @@ Definition of Roles
| Required Owned Elements: |
- |
+ listitem |
| Required States and Properties: |
@@ -3695,7 +4557,7 @@ Definition of Roles
| Accessible Name Required: |
- True |
+ |
| Inherits Name Required: |
@@ -3709,22 +4571,16 @@ Definition of Roles
Inherits Presentational: |
|
-
- | Implicit Value for Role: |
- Default for aria-live is polite. |
-
-
- main
+
+ listbox
- 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 the user agent through a dialog or by assistive technologies.
- User agents SHOULD treat elements with the role of main as navigational landmarks.
-
- Within any document or application, the author SHOULD mark no more than one element with the main role.
- Because document and application elements can be nested in the DOM, they may 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.
+ A widget that allows the user to select one or more items from a list of choices. See related combobox and list.
+ Items within the list are static and, unlike standard HTML select elements, may contain images. List boxes contain children whose role is option or elements whose role is group which in turn contains children whose role is option.
+ To be keyboard accessible, authors SHOULD manage focus of option descendants for all instances of this role, as described in Managing Focus.
+ Elements with the role listbox have an implicit aria-orientation value of vertical.
Characteristics:
@@ -3741,7 +4597,11 @@ Definition of Roles
| Superclass Role: |
- landmark |
+
+
+ |
| Subclass Roles: |
@@ -3753,7 +4613,12 @@ Definition of Roles
| Related Concepts: |
- |
+
+
+ - list
+ <select> in [[HTML]]
+ |
| Required Context Role: |
@@ -3761,7 +4626,12 @@ Definition of Roles
| Required Owned Elements: |
- |
+
+
+ - group → option
+ - option
+
+ |
| Required States and Properties: |
@@ -3769,7 +4639,16 @@ Definition of Roles
| Supported States and Properties: |
- |
+
+
+ - aria-errormessage
+ - aria-expanded
+ - aria-invalid
+ - aria-multiselectable
+ - aria-readonly
+ - aria-required
+
+ |
| Inherited States and Properties: |
@@ -3777,11 +4656,16 @@ Definition of Roles
| Name From: |
- author |
+
+
+ - encapsulation
+ - author
+
+ |
| Accessible Name Required: |
- |
+ True |
| Inherits Name Required: |
@@ -3795,15 +4679,18 @@ Definition of Roles
Inherits Presentational: |
|
+
+ | Implicit Value for Role: |
+ Default for aria-orientation is vertical. |
+
-
- marquee
+
+ listitem
- A type of live region where non-essential information changes frequently. See related log.
- Common usages of marquee include stock tickers and ad banners. The primary difference between a marquee and a log is that logs usually have a meaningful order or sequence of important content changes.
- Elements with the role marquee have an implicit aria-live value of off.
+ A single item in a list or directory.
+ Authors MUST ensure elements whose role is listitem are contained in, or owned by, an element whose role is list.
Characteristics:
@@ -3828,15 +4715,20 @@ Definition of Roles
| Base Concept: |
- |
+ <li> in [[HTML]] |
| Related Concepts: |
- |
+ |
| Required Context Role: |
- |
+
+
+ |
| Required Owned Elements: |
@@ -3848,7 +4740,13 @@ Definition of Roles
| Supported States and Properties: |
- |
+
+
+ - aria-level
+ - aria-posinset
+ - aria-setsize
+
+ |
| Inherited States and Properties: |
@@ -3856,11 +4754,11 @@ Definition of Roles
| Name From: |
- author |
+ author |
| Accessible Name Required: |
- True |
+ |
| Inherits Name Required: |
@@ -3877,63 +4775,12 @@ Definition of Roles
-
- math
+
+ log
- Content that represents a mathematical expression.
- Content with the role math is intended to be marked up in an accessible format such as MathML [[MathML3]], or with another type of textual representation such as TeX or LaTeX, which can be converted to an accessible format by native browser implementations or a polyfill library.
- While it is not ideal to use an image of a mathematical expression, there exists a significant amount of legacy content where images are used to represent mathematical expressions. Authors SHOULD ensure that images of math are labeled by text that describes the mathematical expression as it might be spoken.
-
- Browsers that support native implementations of MathML are able to provide a more robust, accessible math experience than can be accomplished with plain text approximations of math. Some rendering engines have close integration with screen readers that allow spacial touch exploration of the formula and refreshable braille display output in the Nemeth Braille format. This level of integration is not supported with images of mathematical formulas, even if the author provides a plain text approximation.
- At the time of this writing, some mainstream browsers do not support MathML natively, and must be retrofit using a JavaScript polyfill library. When authoring math content, use native MathML wherever possible, and test thoroughly. Use a polyfill library or provide a fallback image with a text alternative approximation if necessary.
-
- MathML Example with Embedded TeX Annotation
-
- <!-- Note: Use a JavaScript polyfill library to ensure
- 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>⁢<!-- ⁢ --></mo>
- <mi>a</mi>
- <mo>⁢<!-- ⁢ --></mo>
- <mi>c</mi>
- </msqrt>
- </mrow>
- <mrow>
- <mn>2</mn>
- <mo>⁢<!-- ⁢ --></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
- If a rendering engine does not support a native math format such as MathML, authors MAY use JavaScript to downgrade the content to a format the browser can display, such as this HTML image using a data URI and plain text alternative.
-
- <img role="math" src="..." alt="x=⟮−b±√⟮b²−4ac⟯⟯÷2a">
-
-
+ A type of live region where new information is added in meaningful order and old information may disappear. See related marquee.
+ Examples include chat logs, messaging history, game log, or an error log. In contrast to other live regions, in this role there is a relationship between the arrival of new items in the log and the reading order. The log contains a meaningful sequence and new information is added only to the end of the log, not at arbitrary points.
+ Elements with the role log have an implicit aria-live value of polite.
Characteristics:
@@ -3990,7 +4837,7 @@ Plain HTML or Polyfill DOM Result of the MathML Quadratic Formula
| Accessible Name Required: |
- |
+ |
| Inherits Name Required: |
@@ -3998,22 +4845,28 @@ Plain HTML or Polyfill DOM Result of the MathML Quadratic Formula
| Children Presentational: |
- True |
+ |
| Inherits Presentational: |
|
+
+ | Implicit Value for Role: |
+ Default for aria-live is polite. |
+
-
+
+
-
-
- paragraph
+
-
- presentation
+
+ navigation
- An element whose implicit native role semantics will not be mapped to the accessibility API. See synonym none.
-
- Note regarding the ARIA 1.1 none role.
- In ARIA 1.1, the working group introduced none as a synonym to the presentation role, due to author confusion surrounding the intended meaning of the word "presentation" or "presentational." Many individuals erroneously consider role="presentation" to be synonymous with aria-hidden="true", and we believe role="none" conveys the actual meaning more unambiguously.
- Until implementations include sufficient support for role="none", web authors are advised to use the presentation role alone role="presentation" or redundantly as a fallback to the none role role="none presentation".
-
- The intended use is when an element is used to change the look of the page but does not have all the functional, interactive, or structural relevance implied by the element type, or may be used to provide for an accessible fallback in older browsers that do not support WAI-ARIA.
- Example use cases:
-
- - An element whose content is completely presentational (like a spacer image, decorative graphic, or clearing element);
- - An image that is in a container with the img role and where the full text alternative is available and is marked up with aria-labelledby and (if needed) aria-describedby;
- - An element used as an additional markup "hook" for CSS; or
- - A layout table and/or any of its associated rows, cells, etc.
-
- For any element with a role of presentation and which is not focusable, the user agent MUST NOT expose the implicit native semantics of the element (the role and its states and properties) to accessibility APIs. However, the user agent MUST expose content and descendant elements that do not have an explicit or inherited role of presentation. Thus, the presentation role causes a given element to be treated as having no role or to be removed from the accessibility tree, but does not cause the content contained within the element to be removed from the accessibility tree.
- For example, according to an accessibility API, the following markup elements would appear to have identical role semantics (no role) and identical content.
-
-<h1 role="presentation"> Sample Content </h1>
-
-
-<span> Sample Content </span>
-
-
-<span role="presentation"> Sample Content </span>
-
-
- Sample Content
-
- The 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 grid role) require tr descendants (the row role), which in turn require th or td children (the gridcell, columnheader, rowheader roles). Similarly, lists require list item children. The descendant elements that complete the semantics of an element are described in WAI-ARIA as required owned elements.
- When an explicit or inherited role of presentation is applied to an element with the implicit semantic of a WAI-ARIA role that has required owned elements, in addition to the element with the explicit role of presentation, the user agent MUST apply an inherited role of presentation to any owned elements that do not have an explicit role defined. Also, when an explicit or inherited role of presentation is applied to a host language element which has required children as defined by the host language specification, in addition to the element with the explicit role of presentation, the user agent MUST apply an inherited role of presentation to any required children that do not have an explicit role defined.
- In HTML, the img element is treated as a single entity regardless of the type of image file. Consequently, using role="presentation" or role="none" on an HTML img is equivalent to using aria-hidden="true". In order to make the image contents accessible, authors can embed the object using an object or iframe element, or use inline SVG code, and follow the accessibility guidelines for the image content.
- For any element with an explicit or inherited role of presentation and which is not focusable, user agents MUST ignore role-specific WAI-ARIA states and properties for that element. For example, in HTML, a ul or ol element with a role of presentation will have the implicit native semantics of its li elements removed because the list role to which the ul or ol corresponds has a required owned element of listitem. Likewise, although an HTML table element does not have an implicit native semantic role corresponding directly to a WAI-ARIA role, the implicit native semantics of its thead/tbody/tfoot/tr/th/td descendants will also be removed, because the HTML specification indicates that these are required structural descendants of the table element.
- Only the implicit native semantics of elements that correspond to WAI-ARIA required owned elements are removed. All other content remains intact, including nested tables or lists, unless those elements also have a explicit role of presentation applied.
- For example, according to an accessibility API, the following markup elements would appear to have identical role semantics (no roles) and identical content.
-
-<ul role="presentation">
- <li> Sample Content </li>
- <li> More Sample Content </li>
-</ul>
-
-
-<foo>
- <foo> Sample Content </foo>
- <foo> More Sample Content </foo>
-</foo>
- There are other WAI-ARIA roles with required children for which this situation is applicable (e.g., radiogroups and listboxes), but tables and lists are the most common real-world cases in which the presentation inheritance is likely to apply.
- For any element with an explicit or inherited role of presentation, user agents MUST apply an inherited role of presentation to all host-language-specific labeling elements for the presentational element. For example, a table element with a role of presentation will have the implicit native semantics of its caption element removed, because the caption is merely a label for the presentational table.
- Authors SHOULD NOT provide meaningful alternative text (for example, use alt="" in HTML) when the 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 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="presentation" 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 presentation to override the user agent's implicit native semantics for list items.
-
-<ul role="tree">
- <li role="presentation">
- <a role="treeitem" aria-expanded="true">An expanded tree node</a>
- </li>
- …
-</ul>
-
- Presentational Roles Conflict Resolution
- There are a number of ways presentational role conflicts are resolved.
- Host languages elements, having implicit presentational roles for which no roles, may be applied, MUST never be exposed to in the accessibility tree. With this exception, user agents MUST always expose global WAI-ARIA states and properties to accessibility APIs. In this case, the user agent ignores the presentation role and exposes the element according to its implicit native semantics. However, user agents MUST ignore any non-global, role-specific WAI-ARIA states and properties, unless it is on an inherited presentational role where an explicit role is applied.
- For example, aria-haspopup is a global attribute and would always be applied; aria-level is not a global attribute and would therefore only apply if the element was not in a presentational state.
-
-
-<h1 role="presentation" aria-haspopup="true"> Sample Content </h1>
-
-<h1 role="presentation" aria-level="2"> Sample Content </h1>
-
- Explicit roles on a descendant or owned element override the inherited role of presentation, and cause the owned element to behave as any other element with an explicit role. If the action of exposing the implicit role causes the accessibility tree to be malformed, the expected results are undefined and the user agent MAY resort to an internal recovery mechanism to repair the accessibility tree.
- If an element with a role of presentation is focusable, or otherwise interactive, user agents MUST ignore the normal effect of the role and expose the element with implicit native semantics, in order to ensure that the element is both understandable and operable.
- User agents MUST always expose global WAI-ARIA states and properties to accessibility APIs, even if an element has an explicit or inherited role of presentation. In this case, the user agent ignores the presentation role and exposes the element according to its implicit native semantics. However, user agents MUST ignore any non-global, role-specific WAI-ARIA states and properties, unless it is on an inherited presentational role where an explicit role is applied.
-
+ A landmark containing a collection of navigational elements (usually links) for navigating the document or related documents.
+ User agents SHOULD treat elements with the role of navigation as navigational landmarks.
Characteristics:
@@ -5047,7 +5844,7 @@ Presentational Roles Conflict Resolution
| Superclass Role: |
- structure |
+ landmark |
| Subclass Roles: |
@@ -5059,7 +5856,7 @@ Presentational Roles Conflict Resolution
| Related Concepts: |
- |
+ <nav> in [[HTML]] |
| Required Context Role: |
@@ -5083,7 +5880,7 @@ Presentational Roles Conflict Resolution
| Name From: |
- author (if role discarded by error conditions) |
+ author |
| Accessible Name Required: |
@@ -5104,12 +5901,20 @@ Presentational Roles Conflict Resolution
-
- progressbar
+
+ none
- An element that displays the progress status for tasks that take a long time.
- A progressbar indicates that the user's request has been received and the application is making progress toward completing the requested action. The author SHOULD supply values for aria-valuenow, aria-valuemin, and aria-valuemax, unless the value is indeterminate, in which case the author SHOULD omit the aria-valuenow attribute. Authors SHOULD update these values when the visual progress indicator is updated. If the progressbar is describing the loading progress of a particular region of a page, the author SHOULD use aria-describedby to point to the status, and set the aria-busy attribute to true on the region until it is finished loading. It is not possible for the user to alter the value of a progressbar because it is always read-only.
- Assistive technologies generally will render the value of aria-valuenow as a percent of a range between the value of aria-valuemin and aria-valuemax, unless aria-valuetext is specified. It is best to set the values for aria-valuemin, aria-valuemax, and aria-valuenow in a manner that is appropriate for this calculation.
+ An element whose implicit native role semantics will not be mapped to the accessibility API. See synonym presentation.
+
+ Note regarding the ARIA 1.1 none role.
+ In ARIA 1.1, the working group introduced none as a synonym to the presentation role, due to author confusion surrounding the intended meaning of the word "presentation" or "presentational." Many individuals erroneously consider role="presentation" to be synonymous with aria-hidden="true", and we believe role="none" conveys the actual meaning more unambiguously.
+
+
+
+
+ note
+
+ A section whose content is parenthetic or ancillary to the main content of the resource.
Characteristics:
@@ -5126,7 +5931,7 @@ Presentational Roles Conflict Resolution
| Superclass Role: |
- range |
+ section |
| Subclass Roles: |
@@ -5138,7 +5943,7 @@ Presentational Roles Conflict Resolution
| Related Concepts: |
- status |
+ |
| Required Context Role: |
@@ -5166,7 +5971,7 @@ Presentational Roles Conflict Resolution
| Accessible Name Required: |
- True |
+ |
| Inherits Name Required: |
@@ -5174,7 +5979,7 @@ Presentational Roles Conflict Resolution
| Children Presentational: |
- True |
+ |
| Inherits Presentational: |
@@ -5183,11 +5988,29 @@ Presentational Roles Conflict Resolution
-
- radio
+
+ option
- A checkable input in a group of elements with the same role, only one of which can be checked at a time.
- Authors SHOULD ensure that elements with role radio are explicitly grouped in order to indicate which ones affect the same value. This is achieved by enclosing the radio elements in an element with role radiogroup. If it is not possible to make the radio buttons DOM children of the radiogroup, authors SHOULD use the aria-owns attribute on the radiogroup element to indicate the relationship to its children.
+ An item in a listbox.
+ Authors MUST ensure elements with role option are contained in, or owned by, an element with the role listbox or group within a listbox. Options not associated with a listbox might not be correctly mapped to an accessibility API.
+ User agents MAY provide an implicit value of aria-selected for each option in a listbox if the following conditions are met, but user agents MUST NOT provide an implicit value of aria-selected if any of the following conditions are not met:
+
+ - 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.
+
+
+ The option role supports both aria-selected and aria-checked because it is common for authors to use selection in single-select list boxes and check marks in multi-select list boxes.
+ However, 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 mening and purpose of each state apparent.
+ - The user interface provides a separate method for controling each state.
+
Characteristics:
@@ -5204,11 +6027,7 @@ Presentational Roles Conflict Resolution
| Superclass Role: |
-
-
- |
+ input |
| Subclass Roles: |
@@ -5216,15 +6035,22 @@ Presentational Roles Conflict Resolution
| Base Concept: |
- |
+ <option> in [[HTML]] |
| Related Concepts: |
- HTML input[type="radio"] |
+
+ listitem
+ |
| Required Context Role: |
- |
+
+
+ |
| Required Owned Elements: |
@@ -5232,17 +6058,15 @@ Presentational Roles Conflict Resolution
| Required States and Properties: |
-
-
- |
+ |
| Supported States and Properties: |
+ - aria-checked
- aria-posinset
+ - aria-selected
- aria-setsize
|
@@ -5278,17 +6102,32 @@ Presentational Roles Conflict Resolution
| Implicit Value for Role: |
- Default for aria-checked is false. |
+ |
-
- radiogroup
+
+ An input for entering a password.
+
+ The Working Group is still considering implications of the password role:
+
+ - It might create security or privacy risks that custom password fields without the role would not;
+ - The use of such fields might not be widespread enough to justify the risks;
+ - Mitigating risks might require specific assisitve technology support that is not normally specified in ARIA.
+
+ The role has been included in this Working Draft to solicit wide review on these questions. The ARIA Working Group particularly seeks input from security and privacy experts, assistive technology developers, and authors who potentially would use the role.
+ If input suggests excessive risks or insufficient need, the role may be removed from the next publication of this specification.
+
+ The password role does not convey or apply any of the security or privacy considerations found in native password fields. Authors are responsible for making sure that custom password fields have robust security and privacy protection, as befits their use.
+ The password role makes it possible for assistive technologies to customize their behavior in order to not inadvertently expose private information. For instance, a screen reader which normally echoes key presses might instead remain silent or echo each displayed character as it is inserted. In order to facilitate the latter behavior, authors SHOULD set the password element's text to characters which obscure the real value, when that value is obscured on screen. Authors SHOULD also update that text each time a character is inserted or deleted by the user.
+ In order to ensure that passwords will not be overheard during input, assistive technologies SHOULD NOT echo key presses of printable characters when an element with role password has focus, unless the user has explicitly enabled this option. If the user has enabled key echo, assistive technologies SHOULD present each rendered character as it is inserted rather than speaking a predetermined character, such as "star." Presenting the rendered characters ensures that all users receive the same information, including notification when the value is being entered into an unobscured password field.
+ Authors SHOULD limit the use of the password role to single-line elements which are editable. Authors MAY use the password role on elements which are not currently editable due to application-specific conditions. However, in that instance, authors MUST indicate that the element is read only by setting aria-readonly to true or using the appropriate native host language attribute. User agents MUST ignore the password role when it is applied to elements which are neither editable nor explicitly marked as read only. Host languages SHOULD document that the password role can only be used on elements that are editable and not permanently read only.
Characteristics:
@@ -5305,7 +6144,7 @@ Presentational Roles Conflict Resolution
| Superclass Role: |
- select |
+ input |
| Subclass Roles: |
@@ -5313,19 +6152,11 @@ Presentational Roles Conflict Resolution
| Base Concept: |
- |
+ HTML input[type="password"] |
| Related Concepts: |
- list |
-
-
- | Required Context Role: |
- |
-
-
- | Required Owned Elements: |
- radio |
+ |
| Required States and Properties: |
@@ -5335,6 +6166,7 @@ Presentational Roles Conflict Resolution
Supported States and Properties: |
+ - aria-placeholder
- aria-readonly
- aria-required
@@ -5367,11 +6199,11 @@ Presentational Roles Conflict Resolution
|
-
- range
+ -->
+
+ paragraph
- An input representing a range of values that can be set by the user.
- range is an abstract role used for the ontology. Authors should not use this role in content.
+ A paragraph of content.
Characteristics:
@@ -5384,11 +6216,11 @@ Presentational Roles Conflict Resolution
| Is Abstract: |
- True |
+ |
| Superclass Role: |
- widget |
+ section |
| Subclass Roles: |
@@ -5400,7 +6232,15 @@ Presentational Roles Conflict Resolution
| Related Concepts: |
- |
+ <p> in [[HTML]] |
+
+
+ | Required Context Role: |
+ |
+
+
+ | Required Owned Elements: |
+ |
| Required States and Properties: |
@@ -5408,21 +6248,24 @@ Presentational Roles Conflict Resolution
| Supported States and Properties: |
-
-
- - aria-valuemax
- - aria-valuemin
- - aria-valuenow
-
- aria-valuetext |
+ |
| Inherited States and Properties: |
Placeholder |
+
+ | Prohibited States and Properties: |
+
+
+ - aria-label
+ - aria-labelledby
+
+ |
+
| Name From: |
- author |
+ prohibited |
| Accessible Name Required: |
@@ -5443,13 +6286,87 @@ Presentational Roles Conflict Resolution
-
- region
+
+ presentation
- 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.
- Authors SHOULD limit use of the region role to sections containing content with a purpose that is not accurately described by one of the other landmark roles, such as main, complementary, or navigation.
- Authors MUST give each element with role region a brief label that describes the purpose of the content in the region. Authors SHOULD reference a visible label with aria-labelledby if a visible label is present. Authors SHOULD include the label inside of a heading whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role heading.
- Assistive technologies SHOULD enable users to quickly navigate to elements with role region. Mainstream user agents MAY enable users to quickly navigate to elements with role region.
+ An element whose implicit native role semantics will not be mapped to the accessibility API. See synonym none.
+
+ Note regarding the ARIA 1.1 none role.
+ In ARIA 1.1, the working group introduced none as a synonym to the presentation role, due to author confusion surrounding the intended meaning of the word "presentation" or "presentational." Many individuals erroneously consider role="presentation" to be synonymous with aria-hidden="true", and we believe role="none" conveys the actual meaning more unambiguously.
+ Until implementations include sufficient support for role="none", web authors are advised to use the presentation role alone role="presentation" or redundantly as a fallback to the none role role="none presentation".
+
+ The intended use is when an element is used to change the look of the page but does not have all the functional, interactive, or structural relevance implied by the element type, or may be used to provide for an accessible fallback in older browsers that do not support WAI-ARIA.
+ Example use cases:
+
+ - An element whose content is completely presentational (like a spacer image, decorative graphic, or clearing element);
+ - An image that is in a container with the img role and where the full text alternative is available and is marked up with aria-labelledby and (if needed) aria-describedby;
+ - An element used as an additional markup "hook" for CSS; or
+ - A layout table and/or any of its associated rows, cells, etc.
+
+ For any element with a role of presentation and which is not focusable, the user agent MUST NOT expose the implicit native semantics of the element (the role and its states and properties) to accessibility APIs. However, the user agent MUST expose content and descendant elements that do not have an explicit or inherited role of presentation. Thus, the presentation role causes a given element to be treated as having no role or to be removed from the accessibility tree, but does not cause the content contained within the element to be removed from the accessibility tree.
+ For example, according to an accessibility API, the following markup elements would appear to have identical role semantics (no role) and identical content.
+
+<h1 role="presentation"> Sample Content </h1>
+
+
+<span> Sample Content </span>
+
+
+<span role="presentation"> Sample Content </span>
+
+
+ Sample Content
+
+ The 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 (the row role), which in turn require th or td children (the cell, columnheader, rowheader roles). Similarly, lists require list item children. The descendant elements that complete the semantics of an element are described in WAI-ARIA as required owned elements.
+ When an explicit or inherited role of presentation is applied to an element with the implicit semantic of a WAI-ARIA role that has required owned elements, in addition to the element with the explicit role of presentation, the user agent MUST apply an inherited role of presentation to any owned elements that do not have an explicit role defined. Also, when an explicit or inherited role of presentation is applied to a host language element which has required children as defined by the host language specification, in addition to the element with the explicit role of presentation, the user agent MUST apply an inherited role of presentation to any required children that do not have an explicit role defined.
+ In HTML, the <img> element is treated as a single entity regardless of the type of image file. Consequently, using role="presentation" or role="none" on an HTML img is equivalent to using aria-hidden="true". In order to make the image contents accessible, authors can embed the object using an <object> or <iframe> element, or use inline SVG code, and follow the accessibility guidelines for the image content.
+ For any element with an explicit or inherited role of presentation and which is not focusable, user agents MUST ignore role-specific WAI-ARIA states and properties for that element. For example, in HTML, a ul or ol element with a role of presentation will have the implicit native semantics of its li elements removed because the list role to which the ul or ol corresponds has a required owned element of listitem. Likewise, the implicit native semantics of an HTML table element's thead/tbody/tfoot/tr/th/td descendants will also be removed, because the HTML specification indicates that these are required structural descendants of the table element.
+ Only the implicit native semantics of elements that correspond to WAI-ARIA required owned elements are removed. All other content remains intact, including nested tables or lists, unless those elements also have an explicit role of presentation applied.
+ For example, according to an accessibility API, the following markup elements would appear to have identical role semantics (no roles) and identical content.
+
+<ul role="presentation">
+ <li> Sample Content </li>
+ <li> More Sample Content </li>
+</ul>
+
+
+<foo>
+ <foo> Sample Content </foo>
+ <foo> More Sample Content </foo>
+</foo>
+ There are other WAI-ARIA roles with required children for which this situation is applicable (e.g., radiogroups and listboxes), but tables and lists are the most common real-world cases in which the presentation inheritance is likely to apply.
+ For any element with an explicit or inherited role of presentation, user agents MUST apply an inherited role of presentation to all host-language-specific labeling elements for the presentational element. For example, a table element with a role of presentation will have the implicit native semantics of its caption element removed, because the caption is merely a label for the presentational table.
+ Authors SHOULD NOT provide meaningful alternative text (for example, use alt="" in HTML) when the 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 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="presentation" 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 presentation to override the user agent's implicit native semantics for list items.
+
+<ul role="tree">
+ <li role="presentation">
+ <a role="treeitem" aria-expanded="true">An expanded tree node</a>
+ </li>
+ …
+</ul>
+
+ Presentational Roles Conflict Resolution
+ There are a number of ways presentational role conflicts are resolved.
+ User agents MUST NOT expose elements having explicit or inherited presentational role in the accessibility tree, with these exceptions:
+
+ - If an element is focusable, or otherwise interactive, user agents MUST ignore the
presentation role and expose the element with its implicit role, in order to ensure that the element is operable.
+ - If a required owned element has an explicit non-presentational role, user agents MUST ignore an inherited presentational role and expose the element with its explicit role. If the action of exposing the explicit role causes the accessibility tree to be malformed, the expected results are undefined.
+ - If an element has global WAI-ARIA states or properties, user agents MUST ignore the
presentation role and expose the element with its implicit role. However, if an element has only non-global, role-specific WAI-ARIA states or properties, the element MUST NOT be exposed unless the presentational role is inherited and an explicit non-presentational role is applied.
+
+ For example, aria-describedby is a global attribute and would always be applied; aria-level is not a global attribute and would therefore only apply if the element was not in a presentational state.
+
+
+<h1 role="presentation" aria-describedby="comment-1"> Sample Content </h1>
+
+<h1 role="presentation" aria-level="2"> Sample Content </h1>
+
+
Characteristics:
@@ -5466,7 +6383,7 @@ Presentational Roles Conflict Resolution
| Superclass Role: |
- landmark |
+ structure |
| Subclass Roles: |
@@ -5478,13 +6395,7 @@ Presentational Roles Conflict Resolution
| Related Concepts: |
-
-
- |
+ |
| Required Context Role: |
@@ -5506,13 +6417,22 @@ Presentational Roles Conflict Resolution
Inherited States and Properties: |
Placeholder |
+
+ | Prohibited States and Properties: |
+
+
+ - aria-label
+ - aria-labelledby
+
+ |
+
| Name From: |
- author |
+ prohibited |
| Accessible Name Required: |
- True |
+ |
| Inherits Name Required: |
@@ -5529,12 +6449,20 @@ Presentational Roles Conflict Resolution
-
- roletype
+
+ progressbar
- The base role from which all other roles in this taxonomy inherit.
- Properties of this role describe the structural and functional purpose of objects that are assigned this role (known in RDF terms as "instances"). A role is a concept that can be used to understand and operate instances.
- roletype is an abstract role used for the ontology. Authors should not use this role in content.
+ An element that displays the progress status for tasks that take a long time.
+ A progressbar indicates that the user's request has been received and the application is making progress toward completing the requested action.
+ Authors MAY set aria-valuemin and aria-valuemax to indicate the minimum and maximum progress indicator values. Otherwise, their implicit values follow the same rules as <input[type="range"]> in [[HTML]]:
+
+ - If
aria-valuemin is missing or not a number, it defaults to 0 (zero).
+ - If
aria-valuemax is missing or not a number, it defaults to 100.
+
+
+ The author SHOULD supply a value for aria-valuenow unless the value is indeterminate, in which case the author SHOULD omit the aria-valuenow attribute.
+ Authors SHOULD update this value when the visual progress indicator is updated. If the progressbar is describing the loading progress of a particular region of a page, the author SHOULD use aria-describedby to point to the status, and set the aria-busy attribute to true on the region until it is finished loading. It is not possible for the user to alter the value of a progressbar because it is always read-only.
+ Assistive technologies generally will render the value of aria-valuenow as a percent of a range between the value of aria-valuemin and aria-valuemax, unless aria-valuetext is specified.
Characteristics:
@@ -5547,11 +6475,16 @@ Presentational Roles Conflict Resolution
| Is Abstract: |
- True |
+ |
| Superclass Role: |
- |
+
+
+ |
| Subclass Roles: |
@@ -5563,13 +6496,15 @@ Presentational Roles Conflict Resolution
| Related Concepts: |
-
-
- |
+ status |
+
+
+ | Required Context Role: |
+ |
+
+
+ | Required Owned Elements: |
+ |
| Required States and Properties: |
@@ -5577,7 +6512,7 @@ Presentational Roles Conflict Resolution
| Supported States and Properties: |
- Placeholder for global states and properties |
+ |
| Inherited States and Properties: |
@@ -5585,15 +6520,11 @@ Presentational Roles Conflict Resolution
| Name From: |
-
-
- |
+ author |
| Accessible Name Required: |
- |
+ True |
| Inherits Name Required: |
@@ -5601,22 +6532,27 @@ Presentational Roles Conflict Resolution
| Children Presentational: |
- |
+ True |
| Inherits Presentational: |
|
+
+ | Implicit Value for Role: |
+
+ Default for aria-valuemin is 0.
+ Default for aria-valuemax is 100.
+ |
+
-
- row
+
+ radio
- A row of cells in a tabular container.
- Rows contain cell or gridcell elements, and thus serve to organize the table or grid.
- In a treegrid, authors MAY mark rows as expandable, using the aria-expanded attribute to indicate the present status. This is not the case for an ordinary table or grid, in which the aria-expanded attribute is not present.
- Authors MUST ensure elements with role row are contained in, or owned by, an element with the role table, grid, rowgroup, or treegrid.
+ A checkable input in a group of elements with the same role, only one of which can be checked at a time.
+ Authors SHOULD ensure that elements with role radio are explicitly grouped in order to indicate which ones affect the same value. This is achieved by enclosing the radio elements in an element with role radiogroup. If it is not possible to make the radio buttons DOM children of the radiogroup, authors SHOULD use the aria-owns attribute on the radiogroup element to indicate the relationship to its children.
Characteristics:
@@ -5635,8 +6571,7 @@ Presentational Roles Conflict Resolution
Superclass Role: |
|
@@ -5646,46 +6581,34 @@ Presentational Roles Conflict Resolution
| Base Concept: |
- HTML tr |
+ |
| Related Concepts: |
- |
+ <input[type="radio"]> in [[HTML]] |
| Required Context Role: |
-
-
- - grid
- - rowgroup
- - table
- - treegrid
-
- |
+ |
| Required Owned Elements: |
-
-
- - cell
- - columnheader
- - gridcell
- - rowheader
-
- |
+ |
| Required States and Properties: |
- |
+
+
+ |
| Supported States and Properties: |
- - aria-colindex
- - aria-level
- - aria-rowindex
- - aria-selected
+ - aria-posinset
+ - aria-setsize
|
@@ -5698,13 +6621,14 @@ Presentational Roles Conflict Resolution
- contents
+ - encapsulation
- author
|
| Accessible Name Required: |
- |
+ True |
| Inherits Name Required: |
@@ -5712,7 +6636,7 @@ Presentational Roles Conflict Resolution
| Children Presentational: |
- |
+ True |
| Inherits Presentational: |
@@ -5721,14 +6645,12 @@ Presentational Roles Conflict Resolution
-
- rowgroup
+
+ radiogroup
- A structure containing one or more row elements in a tabular container.
- The rowgroup role establishes a relationship between owned row elements. It is a structural equivalent to the thead, tfoot, and tbody elements in an HTML table element.
- Authors MUST ensure elements with role rowgroup are contained in, or owned by, an element with the role table or grid.
- The rowgroup role exists, in part, to support role symmetry in HTML, and allows for the propagation of presentation inheritance on HTML table elements with an explicit presentation role applied.
- This role does not differentiate between types of row groups (e.g., thead vs. tbody), but an issue has been raised for WAI-ARIA 2.0.
+ A group of radio buttons.
+ A radiogroup is a type of select list that can only have a single entry checked at any one time. Authors SHOULD enforce that only one radio button 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).
+
Characteristics:
@@ -5745,7 +6667,7 @@ Presentational Roles Conflict Resolution
| Superclass Role: |
- structure |
+ select |
| Subclass Roles: |
@@ -5753,31 +6675,19 @@ Presentational Roles Conflict Resolution
| Base Concept: |
-
-
- |
+ |
| Related Concepts: |
- |
+ list |
| Required Context Role: |
-
-
- - grid
- - table
- - treegrid
-
- |
+ |
| Required Owned Elements: |
- row |
+ radio |
| Required States and Properties: |
@@ -5785,7 +6695,14 @@ Presentational Roles Conflict Resolution
| Supported States and Properties: |
- |
+
+
+ - aria-errormessage
+ - aria-invalid
+ - aria-readonly
+ - aria-required
+
+ |
| Inherited States and Properties: |
@@ -5795,14 +6712,14 @@ Presentational Roles Conflict Resolution
Name From: |
- - contents
- author
+ - legend
|
| Accessible Name Required: |
- |
+ True |
| Inherits Name Required: |
@@ -5819,14 +6736,11 @@ Presentational Roles Conflict Resolution
- |
-
+
+ aria-description
+
+ Defines a string value that describes or annotates the current element. See related aria-describedby.
+ The aria-description attribute is similar to aria-label in that both provide a flat string to associate with the element, but a label should be concise, whereas a description is intended to provide more verbose information.
+ The purpose of aria-description is the same as that of aria-describedby. It provides the user with additional descriptive text for the object. The most common accessibility API mapping for a description is the accessible description property. User agents MUST give precedence to aria-describedby over aria-description when computing the accessible description property.
+ In cases where providing a visible description is not the desired user experience, authors MAY set the accessible description of the element using aria-description. However, if the description text is available in the DOM, authors SHOULD NOT use aria-description, but should use one of the following instead:
+
+ - Authors SHOULD use aria-describedby when the related description or annotation elements contain a simple, small description that is best experienced as a flat string, rather than by having the user navigate to them.
+ - Authors SHOULD use aria-details when the related description or annotation elements contain useful semantics or structure, or there is a lot of content within them, making it difficult to experience as a flat string. Using aria-details will allow assistive technology users to visit the structured content and provide additional navigation commands, making it easier to understand the structure, or to experience the information in smaller pieces.
+
+
+
+ Characteristics:
+
+
+ | Characteristic |
+ Value |
+
+
+
+
+ | Related Concepts: |
+ title attribute in [[HTML]] |
+
+
+ | Used in Roles: |
+ All elements of the base markup |
+
+
+ | Inherits into Roles: |
+ Placeholder |
+
+
+ | Value: |
+ string |
+
+
+
+
+
aria-details
- Identifies the element that provides a detailed, extended description for the object. See related aria-describedby.
- The aria-details attribute references a single element that provides more detailed information than would normally be provided by aria-describedby. It enables assistive technologies to make users aware of the availability of an extended description as well as navigate to it. Authors SHOULD ensure the element referenced by aria-details is visible to all users.
- Unlike elements referenced by aria-describedby, the element referenced by aria-details is not used in either the Accessible Name Computation or the Accessible Description Computation as defined in the Accessible Name and Description specification [[ACCNAME-AAM-1.1]]. Thus, the content of an element referenced by aria-details is not flattened to a string when presented to assistive technology users. This makes aria-details particularly useful when converting the information to a string would cause a loss of information or make the extended description more difficult to understand.
- In some user agents, multiple reference relationships for descriptive information are not supported by the accessibility API. In such cases, if both aria-describedby and aria-details are provided on an element, aria-details takes precedence.
+ Identifies the element (or elements) that provide additional information related to the object. See related aria-describedby.
+ The aria-details property is for referencing elements that provide more detailed information than would normally be provided via aria-describedby. The presence of aria-details enables assistive technologies to make users aware of the availability of extended information and navigate to it. Authors SHOULD ensure that elements referenced by aria-details are visible to all users.
+ Assistive technologies MAY use the role of elements referenced by the aria-details property to help users understand the types of information associated with the element. Authors MAY convey the type of details associated with an element as follows:
+
+ - Comment:
aria-details refers to an element with role comment.
+ - Definition:
aria-details is applied to an element with role term and refers to an element with role definition.
+ - Footnote:
aria-details refers to an element with role doc-footnote. This role is defined in [[DPUB-ARIA-1.0]].
+ - Endnote:
aria-details refers to an element with role doc-endnote. This role is defined in [[DPUB-ARIA-1.0]].
+ - Description or general annotation:
aria-details refers to an element with any other role.
+
+
+ Unlike elements referenced by aria-describedby, elements referenced by aria-details are not used in the Accessible Description Computation as defined in the Accessible Name and Description specification. Thus, the content of elements referenced by aria-details are not flattened to a string when presented to assistive technology users. This makes aria-details particularly useful when converting the information to a string would cause a loss of information or make the extended information more difficult to understand.
+ The aria-details property supports referring to multiple elements. For example, a paragraph in a document editor may reference multiple comments that are not related to each other. If a user agent relies on an accessibility API that does not support exposing multiple descriptive relations, the user agent SHOULD expose the relationship to the first element referenced by aria-details.
+ It is valid for an element to have both aria-details and a description specified with either aria-describedby or aria-description. If a user agent relies on an accessibility API that does not support exposing multiple descriptive relations, and if an element has both aria-details and aria-describedby, the user agent SHOULD expose the aria-details relation and the description string computed from the aria-describedby relationship.
A common use for aria-details is in digital publishing where an extended description needs to be conveyed in a book that requires structural markup or the embedding of other technology to provide illustrative content. The following example demonstrates this scenario.
<!-- Provision of an extended description -->
@@ -9177,9 +11204,9 @@ Definitions of States and Properties (all aria-* attributes)
The following drawing illustrates an application of the Pythagorean Theorem when used to
construct a skateboard ramp.
</p>
- <object data="skatebd-ramp.svg" type="image/svg+xml"/>
+ <object data="skatebd-ramp.svg" type="image/svg+xml"></object>
<p>
- In this example you will notice a skateboard with a base and vertical board whose width
+ In this example you will notice a skateboard ramp with a base and vertical board whose width
is the width of the ramp. To compute how long the ramp must be, simply calculate the
base length, square it, sum it with the square of the height of the ramp, and take the
square root of the sum.
@@ -9210,7 +11237,7 @@ Definitions of States and Properties (all aria-* attributes)
| Value: |
- ID reference |
+ ID reference list |
@@ -9221,6 +11248,9 @@ Definitions of States and Properties (all aria-* attributes)
Indicates that the element is perceivable but disabled, so it is not editable or otherwise operable. See related aria-hidden and aria-readonly.
For example, irrelevant options in a radio group may be disabled. Disabled elements might not receive focus from the tab order. For some disabled elements, applications might choose not to support navigation to descendants. In addition to setting the aria-disabled attribute, authors SHOULD change the appearance (grayed out, etc.) to indicate that the item has been disabled.
The state of being disabled applies to the current element and all focusable descendant elements of the element on which the aria-disabled attribute is applied.
+ While aria-disabled and proper scripting can successfully disable an element with role link, fully disabling a host language equivalent can be problematic. Authors are advised not to use aria-disabled on elements that cannot be disabled through features of the host language alone.
+ While aria-disabled is currently supported on columnheader, rowheader, and row, in a future version the working group plans to prohibit its use on elements with any of those three roles except when they are in the context of a grid or treegrid.
+ This state is being deprecated as a global state in ARIA 1.2. In future versions it will only be allowed on roles where it is specifically supported.
Characteristics:
@@ -9237,7 +11267,7 @@ Definitions of States and Properties (all aria-* attributes)
| Used in Roles: |
- All elements of the base markup |
+ Use as a global deprecated in ARIA 1.2 |
| Inherits into Roles: |
@@ -9275,7 +11305,7 @@ Definitions of States and Properties (all aria-* attributes)
[Deprecated in ARIA 1.1] Indicates what functions can be performed when a dragged object is released on the drop target.
The aria-dropeffect property is expected to be replaced by a new feature in a future version of WAI-ARIA. Authors are therefore advised to treat aria-dropeffect as deprecated.
This property allows assistive technologies to convey the possible drag options available to users, including whether a pop-up menu of choices is provided by the application. Typically, drop effect functions can only be provided once an object has been grabbed for a drag operation as the drop effect functions available are dependent on the object being dragged.
- More than one drop effect may be supported for a given element. Therefore, the value of this attribute is a space-delimited set of tokens indicating the possible effects, or none if there is no supported operation. In addition to setting the aria-dropeffect attribute, authors SHOULD show a visual indication of potential drop targets.
+ More than one drop effect may be supported for a given element. Therefore, the value of this attribute is a space-separated set of tokens indicating the possible effects, or none if there is no supported operation. In addition to setting the aria-dropeffect attribute, authors SHOULD show a visual indication of potential drop targets.
Characteristics:
@@ -9346,23 +11376,25 @@ Definitions of States and Properties (all aria-* attributes)
Identifies the element that provides an error message for an object. See related aria-invalid and aria-describedby.
The aria-errormessage attribute references another element that contains error message text. Authors MUST use aria-invalid in conjunction with aria-errormessage.
When the value of an object is not valid, aria-invalid is set to true, which indicates that the message contained by an element referenced by aria-errormessage is pertinent.
- When an object is in a valid state, it has either aria-invalid set to false or it does not have the aria-invalid attribute. If a valid object has aria-errormessage, the element referenced by aria-errormessage is not rendered because the message it contains is not pertinent.
- When aria-errormessage is pertinent, authors MUST ensure the content is not hidden so users can navigate to and examine the error message. Similarly, when aria-errormessage is not pertinent, authors MUST either ensure the content is not rendered or remove the aria-errormessage attribute or its value.
+ When an object is in a valid state, it has either aria-invalid set to false or it does not have the aria-invalid attribute. Authors MAY use aria-errormessage on an object that is currently valid, but only if the element referenced by aria-errormessage is hidden, because the message it contains is not pertinent.
+ When aria-errormessage is pertinent, authors MUST ensure the content is not hidden so users can navigate to and examine the error message. Similarly, when aria-errormessage is not pertinent, authors MUST either ensure the content is hidden or remove the aria-errormessage attribute or its value.
User agents MUST NOT expose aria-errormessage for an object with an aria-invalid value of false.
Authors MAY call attention to a newly rendered error message with a live region by either applying an aria-live property or using one of the live region roles, such as alert. A live region is appropriate when an error message is displayed to users after they have provided an invalid value.
- A typical message describes what is wrong and informs users what is required. For example, an error message might be, Invalid time: the time must be between 9:00 AM and 5:00 PM. The following example code shows markup for an initial valid state and for a subsequent invalid state. Note the changes to aria-invalid on the text input object, and to aria-live on the element containing the text of the error message:
+ A typical message describes what is wrong and informs users what is required. For example, an error message might be, Invalid time: the time must be between 9:00 AM and 5:00 PM. The following example code shows markup for an initial valid state and for a subsequent invalid state. Note the changes to aria-invalid on the text input object, and to aria-live on the element containing the text of the error message:
<!-- Initial valid state -->
<label for="startTime"> Please enter a start time for the meeting: </label>
<input id="startTime" type="text" aria-errormessage="msgID" value="" aria-invalid="false">
- <span id="msgID" aria-live="off" style="visibility:hidden"> Invalid time: the time must be between 9:00 AM and 5:00 PM" </span>
+ <span id="msgID" aria-live="assertive"><span style="visibility:hidden">Invalid time: the time must be between 9:00 AM and 5:00 PM</span></span>
<!-- User has input an invalid value -->
<label for="startTime"> Please enter a start time for the meeting: </label>
<input id="startTime" type="text" aria-errormessage="msgID" aria-invalid="true" value="11:30 PM" >
- <span id="msgID" aria-live="assertive" style="visibility:visible"> Invalid time: the time must be between 9:00 AM and 5:00 PM" </span>
+ <span id="msgID" aria-live="assertive"><span style="visibility:visible">Invalid time: the time must be between 9:00 AM and 5:00 PM</span></span>
-
+ This example uses aria-live="assertive" to indicate that assistive technologies should immediately announce the error message rather than completing other queued announcements first. This increases the likelihood that users are aware of the error message before they move focus out of the input.
+ This state is being deprecated as a global state in ARIA 1.2. In future versions it will only be allowed on roles where it is specifically supported.
+
Characteristics:
@@ -9374,7 +11406,11 @@ Definitions of States and Properties (all aria-* attributes)
| Used in Roles: |
- All elements of the base markup |
+ Use as a global deprecated in ARIA 1.2 |
+
+
+ | Inherits into Roles: |
+ Placeholder |
| Value: |
@@ -9386,9 +11422,9 @@ Definitions of States and Properties (all aria-* attributes)
aria-expanded
- Indicates whether the element, or another grouping element it controls, is currently expanded or collapsed.
- For example, this indicates whether a portion of a tree is expanded or collapsed. In other instances, this may be applied to page sections to mark expandable and collapsible regions that are flexible for managing content density. Simplifying the user interface by collapsing sections may improve usability for all, including those with cognitive or developmental disabilities.
- If the element with the aria-expanded attribute controls the expansion of another grouping container that is not 'owned by' the element, the author SHOULD reference the container by using the aria-controls attribute.
+ Indicates whether a grouping element owned or controlled by this element is expanded or collapsed.
+ The aria-expanded attribute is applied to a focusable, interactive element that toggles visibility of content in another element. For example, it is applied to a parent treeitem to indicate whether its child branch of the tree is shown. Similarly, it can be applied to a button that controls visibility of a section of page content.
+ If a grouping container that can be expanded or collapsed is not owned by the element that has the aria-expanded attribute, the author SHOULD identify the controlling relationship by referencing the container from the element that has aria-expanded with the aria-controls property.
Characteristics:
@@ -9401,7 +11437,7 @@ Definitions of States and Properties (all aria-* attributes)
| Related Concepts: |
- Tapered prompts in voice browsing. Switch in SMIL [[SMIL3]]. |
+ |
| Used in Roles: |
@@ -9428,15 +11464,15 @@ Definitions of States and Properties (all aria-* attributes)
| false |
- The element, or another grouping element it controls, is collapsed. |
+ The grouping element this element owns or controls is collapsed. |
| true |
- The element, or another grouping element it controls, is expanded. |
+ The grouping element this element owns or controls is expanded. |
| undefined (default) |
- The element, or another grouping element it controls, is neither expandable nor collapsible; all its child elements are shown or there are no child elements. |
+ The element does not own or control a grouping element that is expandable. |
@@ -9445,8 +11481,8 @@ Definitions of States and Properties (all aria-* attributes)
aria-flowto
Identifies the next element (or elements) in an alternate reading order of content which, at the user's discretion, allows assistive technology to override the general default of reading in document source order.
- When aria-flowto has a single IDREF, it allows assistive technologies to, at the user's request, forego normal document reading order and go to the targeted object. However, when aria-flowto is provided with multiple IDREFS, assistive technologies SHOULD present the referenced elements as path choices.
- In the case of one or more IDREFS, user agents or assistive technologies SHOULD give the user the option of navigating to any of the targeted elements. The name of the path can be determined by the name of the target element of the aria-flowto attribute. Accessibility APIs can provide named path relationships.
+ When aria-flowto has a single ID reference, it allows assistive technologies to, at the user's request, forego normal document reading order and go to the targeted object. However, when aria-flowto is provided with multiple ID references, assistive technologies SHOULD present the referenced elements as path choices.
+ In the case of one or more ID references, user agents or assistive technologies SHOULD give the user the option of navigating to any of the targeted elements. The name of the path can be determined by the name of the target element of the aria-flowto attribute. Accessibility APIs can provide named path relationships.
Characteristics:
@@ -9542,10 +11578,16 @@ Definitions of States and Properties (all aria-* attributes)
Indicates the availability and type of interactive popup element, such as menu or dialog, that can be triggered by an element.
A popup element usually appears as a block of content that is on top of other content. Authors MUST ensure that the role of the element that serves as the container for the popup content is menu, listbox, tree, grid, or dialog, and that the value of aria-haspopup matches the role of the popup container.
- For the popup element to be keyboard accessible, authors SHOULD ensure that the element that can trigger the popup is focusable, that there is a keyboard mechanism for opening the popup, and that the popup element manages focus of all its descendants as described in Managing Focus.
- The aria-haspopup property is an enumerated type. User agents MUST treat any value of aria-haspopup that is not included in the list of allowed values, including an empty string, as if the value false had been provided. To provide backward compatibility with ARIA 1.0 content, user agents MUST treat an aria-haspopup value of true as equivalent to a value of menu.
- Assistive technologies SHOULD NOT expose the aria-haspopup property if it has a value of false.
- A tooltip is not considered to be a popup in this context.
+ For the popup element to be keyboard accessible, authors SHOULD ensure that the element that can trigger the popup is focusable, that there is a keyboard mechanism for opening the popup, and that the popup element manages focus of all its descendants as described in Managing Focus.
+ The aria-haspopup property is an enumerated type. User agents MUST treat any value of aria-haspopup that is not included in the list of allowed values, including an empty string, as if the value false had been provided. To provide backward compatibility with ARIA 1.0 content, user agents MUST treat an aria-haspopup value of true as equivalent to a value of menu.
+ Assistive technologies SHOULD NOT expose the aria-haspopup property if it has a value of false.
+ A tooltip is not considered to be a popup in this context.
+ aria-haspopup is most relevant to use when there is a visual indicator in the element that triggers the popup.
+ For example, many controls styled with a downward pointing triangle, chevron, or ellipsis (three consecutive dots) have become standard visual indicators that a popup will display when the control is activated.
+ If some functional difference is relevant to display to a sighted user by means of a different visual style, that functional difference is usually relevant to convey to users of assistive technology.
+ If there is no visual indication that an element will trigger a popup, authors are advised to consider whether use of aria-haspopup is necessary, and avoid using it when it's not.
+
+ This property is being deprecated as a global property in ARIA 1.2. In future versions it will only be allowed on roles where it is specifically supported.
Characteristics:
@@ -9559,15 +11601,12 @@ Definitions of States and Properties (all aria-* attributes)
| Related Concepts: |
-
+ aria-controls
|
| Used in Roles: |
- All elements of the base markup |
+ Use as a global deprecated in ARIA 1.2 |
| Inherits into Roles: |
@@ -9624,12 +11663,9 @@ Definitions of States and Properties (all aria-* attributes)
Indicates whether the element is exposed to an accessibility API. See related aria-disabled.
User agents determine an element's hidden status based on whether it is rendered, and the rendering is usually controlled by CSS. For example, an element whose display property is set to none is not rendered. An element is considered hidden if it, or any of its ancestors are not rendered or have their aria-hidden attribute value set to true.
- [aria-hidden="true"] { visibility: hidden; }
Authors MAY, with caution, use aria-hidden to hide visibly rendered content from assistive technologies only if the act of hiding this content is intended to improve the experience for users of assistive technologies by removing redundant or extraneous content. Authors using aria-hidden to hide visible content from screen readers MUST ensure that identical or equivalent meaning and functionality is exposed to assistive technologies.
Authors are advised to use extreme caution and consider a wide range of disabilities when hiding visibly rendered content from assistive technologies. For example, a sighted, dexterity-impaired individual may use voice-controlled assistive technologies to access a visual interface. If an author hides visible link text "Go to checkout" and exposes similar, yet non-identical link text "Check out now" to the accessibility API, the user may be unable to access the interface they perceive using voice control. Similar problems may also arise for screen reader users. For example, a sighted telephone support technician may attempt to have the blind screen reader user click the "Go to checkout" link, which they may be unable to find using a type-ahead item search ("Go to…").
At the time of this writing, aria-hidden="false" is known to work inconsistently in browsers. As future implementations improve, use caution and test thoroughly before relying on this approach.
- It is recommended that authors key visibility of elements off this attribute, rather than change visibility and separately update this property. CSS 2 introduced a way to select on attribute values ([[CSS3-SELECTORS]]). The following CSS declaration makes content visible unless the aria-hidden attribute is true; scripts need only update the value of this attribute to change visibility:
- [aria-hidden="true"] { visibility: hidden; }
Characteristics:
@@ -9689,6 +11725,7 @@ Definitions of States and Properties (all aria-* attributes)
If the value is computed to be invalid or out-of-range, the application author SHOULD set this attribute to true. User agents SHOULD inform the user of the error. Application authors SHOULD provide suggestions for corrections if they are known.
When the user attempts to submit data involving a field for which aria-required is true, authors MAY use the aria-invalid attribute to signal there is an error. However, if the user has not attempted to submit the form, authors SHOULD NOT set the aria-invalid attribute on required widgets simply because the user has not yet entered data.
For future expansion, the aria-invalid attribute is an enumerated type. Any value not recognized in the list of allowed values MUST be treated by user agents as if the value true had been provided. If the attribute is not present, or its value is false, or its value is an empty string, the default value of false applies.
+ This state is being deprecated as a global state in ARIA 1.2. In future versions it will only be allowed on roles where it is specifically supported.
Characteristics:
@@ -9701,11 +11738,11 @@ Definitions of States and Properties (all aria-* attributes)
| Related Concepts: |
- XForms [[XFORMS11]] 'invalid' event. This state is true if a form field is required but empty. However, the XForms valid property would be set to false. |
+ |
| Used in Roles: |
- All elements of the base markup |
+ Use as a global deprecated in ARIA 1.2 |
| Inherits into Roles: |
@@ -9749,7 +11786,7 @@ Definitions of States and Properties (all aria-* attributes)
aria-keyshortcuts
Indicates keyboard shortcuts that an author has implemented to activate or give focus to an element.
- The value of the aria-keyshortcuts attribute is a space-delimited list of keyboard shortcuts that can be pressed to activate a command or textbox widget. The keys defined in the shortcuts represent the physical keys pressed and not the actual characters generated. Each keyboard shortcut consists of one or more tokens delimited by the plus sign ("+") representing zero or more modifier keys and exactly one non-modifier key that must be pressed simultaneously to activate the given shortcut.
+ The value of the aria-keyshortcuts attribute is a space-separated list of keyboard shortcuts that can be pressed to activate a command or textbox widget. The keys defined in the shortcuts represent the physical keys pressed and not the actual characters generated. Each keyboard shortcut consists of one or more tokens delimited by the plus sign ("+") representing zero or more modifier keys and exactly one non-modifier key that must be pressed simultaneously to activate the given shortcut.
Authors MUST specify modifier keys exactly according to the UI Events KeyboardEvent key Values spec [[!uievents-key]] - for example, "Alt", "Control", "Shift", "Meta", or "AltGraph". Note that Meta corresponds to the Command key, and Alt to the Option key, on Apple computers.
The valid names for non-modifier keys are any printable character such as "A", "B", "1", "2", "$", "Plus" for a plus sign, "Space" for the spacebar, or the names of any other non-modifier key specified in the UI Events KeyboardEvent key Values spec [[!uievents-key]] - for example, "Enter", "Tab", "ArrowRight", "PageDown", "Escape", or "F1". The use of "Space" for the spacebar is an exception to the UI Events KeyboardEvent key Values spec [[!uievents-key]] as the space or spacebar key is encoded as ' ' and would be treated as a whitespace character.
Authors MUST ensure modifier keys come first when they are part of a keyboard shortcut. Authors MUST ensure that required non-modifier keys come last when they are part of a shortcut. The order of the modifier keys is not otherwise significant, so "Alt+Shift+T" and "Shift+Alt+T" are equivalent, but "T+Shift+Alt" is not valid because all of the modifier keys don't come first, and "Alt" is not valid because it doesn't include at least one non-modifier key.
@@ -9769,7 +11806,7 @@ Definitions of States and Properties (all aria-* attributes)
User agents MUST NOT change keyboard behavior in response to the aria-keyshortcuts attribute. Authors MUST handle scripted keyboard events to process aria-keyshortcuts. The aria-keyshortcuts attribute exposes the existence of these shortcuts so that assistive technologies can communicate this information to users.
Authors SHOULD provide a way to expose keyboard shortcuts so that all users may discover them, such as through the use of a tooltip. Authors MUST ensure that aria-keyshortcuts applied to disabled elements are unavailable.
- Authors SHOULD avoid implementing shortcut keys that inhibit operating system, user agent, or assistive technology functionality. This requires the author to carefully consider both which keys to assign and the contexts and conditions in which the keys are available to the user. For guidance, see the keyboard shortcuts section of the WAI-ARIA Authoring Practices Guide [[WAI-ARIA-PRACTICES-1.1]].
+ Authors SHOULD avoid implementing shortcut keys that inhibit operating system, user agent, or assistive technology functionality. This requires the author to carefully consider both which keys to assign and the contexts and conditions in which the keys are available to the user. For guidance, see the keyboard shortcuts section of the WAI-ARIA Authoring Practices.
Characteristics:
@@ -9804,7 +11841,7 @@ Definitions of States and Properties (all aria-* attributes)
Defines a string value that labels the current element. See related aria-labelledby.
The purpose of aria-label is the same as that of aria-labelledby. It provides the user with a recognizable name of the object. The most common accessibility API mapping for a label is the accessible name property.
- If the label text is visible on screen, authors SHOULD use aria-labelledby and SHOULD NOT use aria-label. There may be instances where the name of an element cannot be determined programmatically from the content of the element, and there are cases where providing a visible label is not the desired user experience. Most host languages provide an attribute that could be used to name the element (e.g., the title attribute in HTML), yet this could present a browser tooltip. In the cases where a visible label or visible tooltip is undesirable, authors MAY set the accessible name of the element using aria-label. As required by the text alternative computation, user agents give precedence to aria-labelledby over aria-label when computing the accessible name property.
+ If the label text is available in the DOM (i.e. typically visible text content), authors SHOULD use aria-labelledby and SHOULD NOT use aria-label. There may be instances where the name of an element cannot be determined programmatically from the DOM, and there are cases where referencing DOM content is not the desired user experience. Most host languages provide an attribute that could be used to name the element (e.g., the title attribute in [[HTML]]), yet this could present a browser tooltip. In the cases where DOM content or a tooltip is undesirable, authors MAY set the accessible name of the element using aria-label. As required by the accessible name and description computation, user agents give precedence to aria-labelledby over aria-label when computing the accessible name property.
Characteristics:
@@ -9817,11 +11854,11 @@ Definitions of States and Properties (all aria-* attributes)
| Related Concepts: |
- HTML title |
+ |
| Used in Roles: |
- All elements of the base markup |
+ All elements of the base markup except for some roles or elements that prohibit its use |
| Inherits into Roles: |
@@ -9837,9 +11874,9 @@ Definitions of States and Properties (all aria-* attributes)
aria-labelledby
- Identifies the element (or elements) that labels the current element. See related aria-describedby.
+ Identifies the element (or elements) that labels the current element. See related aria-label and aria-describedby.
The purpose of aria-labelledby is the same as that of aria-label. It provides the user with a recognizable name of the object. The most common accessibility API mapping for a label is the accessible name property.
- If the interface is such that it is not possible to have a visible label on the screen, authors SHOULD use aria-label and SHOULD NOT use aria-labelledby. As required by the text alternative computation, user agents give precedence to aria-labelledby over aria-label when computing the accessible name property.
+ If the interface is such that it is not possible to have a visible label on the screen, authors SHOULD use aria-label and SHOULD NOT use aria-labelledby. As required by the accessible name and description computation, user agents give precedence to aria-labelledby over aria-label when computing the accessible name property.
The aria-labelledby attribute is similar to aria-describedby in that both reference other elements to calculate a text alternative, but a label should be concise, where a description is intended to provide more verbose information.
The expected spelling of this property in U.S. English is "labeledby." However, the accessibility API features to which this property is mapped have established the "labelledby" spelling. This property is spelled that way to match the convention and minimize the difficulty for developers.
@@ -9855,11 +11892,11 @@ Definitions of States and Properties (all aria-* attributes)
| Related Concepts: |
- HTML label |
+ <label> in [[HTML]] |
| Used in Roles: |
- All elements of the base markup |
+ All elements of the base markup except for some roles or elements that prohibit its use |
| Inherits into Roles: |
@@ -9872,6 +11909,56 @@ Definitions of States and Properties (all aria-* attributes)
+
+ aria-braillelabel
+
+ Defines a string value that labels the current element, which is intended to be converted into Braille. See related aria-label.
+ The purpose of aria-braillelabel is similar to that of aria-label. It provides the user with a recognizable name of the object in Braille.
+ The aria-braillelabel property gives authors the ability to override how assistive technologies localize and express the accessible name of an element in Braille. Thus inappropriately using aria-braillelabel may inhibit users' ability to understand an element on braille interfaces. Authors SHOULD limit use of aria-braillelabel to instances where the name of an element when converted to Braille is not the desired user experience.
+ When using aria-braillelabel, authors SHOULD also ensure that:
+
+ - The element to which
aria-braillelabel is applied has a valid accessible name.
+ - The value of
aria-braillelabel is not empty or does not contain only whitespace characters.
+ - The value of
aria-braillelabel does not contain any characters in Unicode Braille Patterns (U+2800..U+28FF) or consists of only characters in Unicode Braille Patterns (U+2800..U+28FF) while not containing only Braille Pattern dots-0 (U+2800).
+ - The value of
aria-braillelabel is not identical to the element's accessible name.
+
+ Note that Assistive Technologies with braille support can convert the accessible name to Braille. In addition, assistive technologies will be able to customize such braille output according to user preferences. Using only the accessible name, e.g., from content or via aria-label is almost always the better user experience and authors are strongly discouraged from using aria-braillelabel to replicate aria-label. Instead, aria-braillelabel is meant to be used only if the accessible name cannot provide an adequate braille representation, i.e., when a specialized braille description is very different from a text description converted to Braille. It is very important to note that when using aria-braillelabel authors are solely responsible to align the attribute value with the document language and clearly communicate the use of this attribute to the user. This is even more important when the value consists of Unicode Braille Patterns because Assistive Technologies will pass such content directly to the user without applying user specific braille translations; in general, authors are strongly discouraged from using Unicode Braille Patterns in aria-braillelabel.
+
+ Assistive technologies SHOULD use the value of aria-braillelabel when presenting the accessible name of an element in Braille, but SHOULD NOT change other functionality. For example, an assistive technology that provides aural rendering SHOULD use the accessible name.
+ Assistive technologies SHOULD expose the aria-braillelabel property as follows:
+
+ - If the value of
aria-braillelabel does not contain characters in Unicode Braille Patterns (U+2800..U+28FF), translate the value according to the user's preferred translation table.
+ - Otherwise, pass the value to the user without translation.
+
+ The following example shows the use of aria-braillelabel to customize a button's name in braille output.
+ <button aria-braillelabel="****">
+ <img alt="4 stars" src="images/stars.jpg">
+</button>
+ In the previous example, a braille display may display "btn ****" in Braille rather than the verbose "btn gra 4 stars".
+
+ Characteristics:
+
+
+ | Characteristic |
+ Value |
+
+
+
+
+ | Used in Roles: |
+ All elements of the base markup |
+
+
+ | Inherits into Roles: |
+ Placeholder |
+
+
+ | Value: |
+ string |
+
+
+
+
aria-level
@@ -9963,7 +12050,7 @@ Definitions of States and Properties (all aria-* attributes)
| off (default) |
- Indicates that updates to the region should not be presented to the user unless the used is currently focused on that region. |
+ Indicates that updates to the region should not be presented to the user unless the user is currently focused on that region. |
| polite |
@@ -10196,7 +12283,7 @@ Definitions of States and Properties (all aria-* attributes)
aria-owns
Identifies an element (or elements) in order to define a visual, functional, or contextual parent/child relationship between DOM elements where the DOM hierarchy cannot be used to represent the relationship. See related aria-controls.
- The value of the aria-owns attribute is a space-separated list of IDREFS that reference one or more elements in the document by ID. The reason for adding aria-owns is to expose a parent/child contextual relationship to assistive technologies that is otherwise impossible to infer from the DOM.
+ The value of the aria-owns attribute is a space-separated ID reference list that references one or more elements in the document by ID. The reason for adding aria-owns is to expose a parent/child contextual relationship to assistive technologies that is otherwise impossible to infer from the DOM.
If an element has both aria-owns and DOM children then the order of the child elements with respect to the parent/child relationship is the DOM children first, then the elements referenced in aria-owns. If the author intends that the DOM children are not first, then list the DOM children in aria-owns in the desired order. Authors SHOULD NOT use aria-owns as a replacement for the DOM hierarchy. If the relationship is represented in the DOM, do not use aria-owns. Authors MUST ensure that an element's ID is not specified in more than one other element's aria-owns attribute at any time. In other words, an element can have only one explicit owner.
@@ -10233,7 +12320,8 @@ Definitions of States and Properties (all aria-* attributes)
Defines a short hint (a word or short phrase) intended to aid the user with data entry when the control has no value. A hint could be a sample value or a brief description of the expected format.
Authors SHOULD NOT use aria-placeholder instead of a label as their purposes are different: The label indicates what kind of information is expected. The placeholder text is a hint about the expected value. See related aria-labelledby and aria-label.
Authors SHOULD present this hint to the user by displaying the hint text at any time the control's value is the empty string. This includes cases where the control first receives focus, and when users remove a previously-entered value.
- As is the case with the related HTML placeholder attribute, use of placeholder text as a replacement for a displayed label can reduce the accessibility and usability of the control for a range of users including older users and users with cognitive, mobility, fine motor skill or vision impairments. While the hint given by the control's label is shown at all times, the short hint given in the placeholder attribute is only shown before the user enters a value. Furthermore, placeholder text may be mistaken for a pre-filled value, and as commonly implemented the default color of the placeholder text provides insufficient contrast and the lack of a separate visible label reduces the size of the hit region available for setting focus on the control.
+ As is the case with the related placeholder attribute in [[HTML]], use of placeholder text as a replacement for a displayed label can reduce the accessibility and usability of the control for a range of users including older users and users with cognitive, mobility, fine motor skill or vision impairments. While the hint given by the control's label is shown at all times, the short hint given in the placeholder attribute is only shown before the user enters a value. Furthermore, placeholder text may be mistaken for a pre-filled value, and as commonly implemented the default color of the placeholder text provides insufficient contrast and the lack of a separate visible label reduces the size of the hit region available for setting focus on the control.
+ The following examples do not use the HTML label element as it cannot be used to label HTML elements with contenteditable.
The following example shows a searchbox in which the user has entered a value:
<span id="label">Birthday:</span>
@@ -10256,7 +12344,7 @@ Definitions of States and Properties (all aria-* attributes)
| Related Concepts: |
- HTML placeholder |
+ placeholder attribute in [[HTML]] |
| Used in Roles: |
@@ -10321,7 +12409,7 @@ Definitions of States and Properties (all aria-* attributes)
aria-pressed
Indicates the current "pressed" state of toggle buttons. See related aria-checked and aria-selected.
- Toggle buttons require a full press-and-release cycle to change their value. Activating it once changes the value to true, and activating it another time changes the value back to false. A value of mixed means that the values of more than one item controlled by the button do not all share the same value. Examples of mixed-state buttons are described in WAI-ARIA Authoring Practices [[WAI-ARIA-PRACTICES-1.1]]. If the attribute is not present, the button is not a toggle button.
+ Toggle buttons require a full press-and-release cycle to change their value. Activating it once changes the value to true, and activating it another time changes the value back to false. A value of mixed means that the values of more than one item controlled by the button do not all share the same value. If the attribute is not present, the button is not a toggle button.
The aria-pressed attribute is similar but not identical to the aria-checked attribute. Operating systems support pressed on buttons and checked on checkboxes.
@@ -10403,7 +12491,7 @@ Definitions of States and Properties (all aria-* attributes)
| Related Concepts: |
- XForms [[XFORMS10]] Readonly |
+ readonly attribute in [[HTML]] |
| Used in Roles: |
@@ -10443,13 +12531,13 @@ Definitions of States and Properties (all aria-* attributes)
aria-relevant
Indicates what notifications the user agent will trigger when the accessibility tree within a live region is modified. See related aria-atomic.
- The attribute is represented as a space delimited list of the following values: additions, removals, text; or a single catch-all value all.
+ The attribute is represented as a space-separated list of the following values: additions, removals, text; or a single catch-all value all.
This is used to describe semantically meaningful changes, as opposed to merely presentational ones. For example, nodes that are removed from the top of a log are merely removed for purposes of creating room for other entries, and the removal of them does not have meaning. However, in the case of a buddy list, removal of a buddy name indicates that they are no longer online, and this is a meaningful event. In that case aria-relevant will be set to all. When the aria-relevant attribute is not provided, the default value, additions text, indicates that text modifications and node additions are relevant, but that node removals are irrelevant.
aria-relevant values of removals or all are to be used sparingly. Assistive technologies only need to be informed of content removal when its removal represents an important change, such as a buddy leaving a chat room.
Text removals should only be considered relevant if one of the specified values is 'removals' or 'all'. For example, for a text change from 'foo' to 'bar' in a live region with a default aria-relevant value, the text addition ('bar') would be spoken, but the text removal ('foo') would not.
aria-relevant is an optional attribute of live regions. This is a suggestion to assistive technologies, but assistive technologies are not required to present changes of all the relevant types.
When aria-relevant is not defined, an element's value is inherited from the nearest ancestor with a defined value. Although the value is a token list, inherited values are not additive; the value provided on a descendant element completely overrides any inherited value from an ancestor element.
- When text changes are denoted as relevant, user agents MUST monitor any descendant node change that affects the text alternative computation of the live region as if the accessible name were determined from contents (nameFrom: contents). For example, a text change would be triggered if the HTML alt attribute of a contained image changed. However, no change would be triggered if there was a text change to a node outside the live region, even if that node was referenced (via aria-labelledby) by an element contained in the live region.
+ When text changes are denoted as relevant, user agents MUST monitor any descendant node change that affects the accessible name and description computation of the live region as if the accessible name were determined from contents (nameFrom: contents). For example, a text change would be triggered if the HTML alt attribute of a contained image changed. However, no change would be triggered if there was a text change to a node outside the live region, even if that node was referenced (via aria-labelledby) by an element contained in the live region.
Characteristics:
@@ -10492,7 +12580,7 @@ Definitions of States and Properties (all aria-* attributes)
Element nodes are added to the accessibility tree within the live region. |
- | additions text |
+ additions text (default) |
Equivalent to the combination of values, "additions text". |
@@ -10529,7 +12617,7 @@ Definitions of States and Properties (all aria-* attributes)
| Related Concepts: |
- HTML required |
+ required attribute in [[HTML]] |
| Used in Roles: |
@@ -10579,7 +12667,8 @@ Definitions of States and Properties (all aria-* attributes)
User agents MUST NOT expose the aria-roledescription property if any of the following conditions exist:
- The element to which
aria-roledescription is applied does not have a valid WAI-ARIA role or does not have an implicit WAI-ARIA role semantic.
- - The value of aria-roledescription is empty or contains only whitespace characters.
+ - The element to which
aria-roledescription is applied has an explicit or implicit WAI-ARIA role where aria-roledescription is prohibited.
+ - The value of
aria-roledescription is empty or contains only whitespace characters.
Assistive technologies SHOULD use the value of aria-roledescription when presenting the role of an element, but SHOULD NOT change other functionality based on the role of an element that has a value for aria-roledescription. For example, an assistive technology that provides functions for navigating to the next region or button SHOULD allow those functions to navigate to regions and buttons that have an aria-roledescription.
The following two examples show the use of aria-roledescription to indicate that a non-interactive container is a "slide" in a web-based presentation application.
@@ -10592,10 +12681,6 @@ Definitions of States and Properties (all aria-* attributes)
<!-- remaining slide contents -->
</section>
In the previous examples, a screen reader user may hear "Quarterly Report, slide" rather than the more vague "Quarterly Report, region" or "Quarterly Report, group."
- The following examples show the use of aria-roledescription to indicate that a button in a web-based email client is associated with an "attachment."
- <div role="button" tabindex="0" aria-roledescription="attachment button">family_reunion.jpg</div>
- <button aria-roledescription="attachment button">family_reunion.jpg</button>
- In the previous two examples, because "button" is part of the localized description, a screen reader user should still understand how to interact with that control.
Characteristics:
@@ -10695,7 +12780,7 @@ Definitions of States and Properties (all aria-* attributes)
aria-rowindex
- Defines an element's row index or position with respect to the total number of rows within a table, grid, or treegrid. See related aria-rowcount and aria-rowspan.
+ Defines an element's row index or position with respect to the total number of rows within a table, grid, or treegrid. See related aria-rowindextext, aria-rowcount, and aria-rowspan.
If all of the rows are present in the DOM, it is not necessary to set this attribute as the user agent can automatically calculate the index of each row. However, if only a portion of the rows is present in the DOM at a given moment, this attribute is needed to provide an explicit indication of each row's position with respect to the full table.
Authors MUST set the value for aria-rowindex to an integer greater than or equal to 1, greater than the aria-rowindex value of any previous rows, and less than or equal to the number of rows in the full table. For a cell or gridcell which spans multiple rows, authors MUST set the value of aria-rowindex to the start of the span.
Authors SHOULD place aria-rowindex on each row. Authors MAY also place aria-rowindex on all of the children or owned elements of each row.
@@ -10792,6 +12877,42 @@ Definitions of States and Properties (all aria-* attributes)
+
+ aria-rowindextext
+
+ Defines a human readable text alternative of aria-rowindex. See related aria-colindextext.
+ Authors SHOULD only use aria-rowindextext when the provided or calculated value of aria-rowindex is not meaningful or does not reflect the displayed index, as can be seen in the game Battleship.
+ Authors SHOULD NOT use aria-rowindextext as a replacement for aria-rowindex because some assistive technologies rely upon the numeric row index for the purpose of keeping track of the user's position or providing alternative table navigation.
+ Authors SHOULD place aria-rowindextext on each row. Authors MAY also place aria-rowindextext on all of the children or owned elements of each row.
+
+
+ Characteristics:
+
+
+ | Characteristic |
+ Value |
+
+
+
+
+ | Related Concepts: |
+ |
+
+
+ | Used in Roles: |
+ Placeholder |
+
+
+ | Inherits into Roles: |
+ Placeholder |
+
+
+ | Value: |
+ string |
+
+
+
+
aria-rowspan
@@ -11021,7 +13142,7 @@ Definitions of States and Properties (all aria-* attributes)
| Related Concepts: |
- XForms [[XFORMS10]] range |
+ <range> element max attribute in [[HTML]] |
| Used in Roles: |
@@ -11056,7 +13177,7 @@ Definitions of States and Properties (all aria-* attributes)
| Related Concepts: |
- XForms [[XFORMS10]] range |
+ <range> element min attribute in [[HTML]] |
| Used in Roles: |
@@ -11082,7 +13203,7 @@ Definitions of States and Properties (all aria-* attributes)
The value of aria-valuenow is a decimal number. If the range is a set of numeric values, then aria-valuenow is one of those values. For example, if the range is [0, 1], a valid aria-valuenow is 0.5. A value outside the range, such as -2.5 or 1.1, is invalid.
For progressbar elements and scrollbar elements, assistive technologies SHOULD render the value to users as a percent, calculated as a position on the range from aria-valuemin to aria-valuemax if both are defined, otherwise the actual value with a percent indicator. For elements with role slider and spinbutton, assistive technologies SHOULD render the actual value to users.
When the rendered value cannot be accurately represented as a number, authors SHOULD use the aria-valuetext attribute in conjunction with aria-valuenow to provide a user-friendly representation of the range's current value. For example, a slider may have rendered values of small, medium, and large. In this case, the values of aria-valuetext would be one of the strings: small, medium, or large.
- If aria-valuetext is specified, assistive technologies render that instead of the value of aria-valuenow.
+ If aria-valuetext is specified, assistive technologies render that instead of the value of aria-valuenow.
Characteristics:
@@ -11095,7 +13216,7 @@ Definitions of States and Properties (all aria-* attributes)
| Related Concepts: |
- XForms [[XFORMS10]] range, start |
+ <range> element value attribute in [[HTML]] |
| Used in Roles: |
@@ -11119,7 +13240,7 @@ Definitions of States and Properties (all aria-* attributes)
This property is used, for example, on a range widget such as a slider or progress bar.
If the aria-valuetext attribute is set, authors SHOULD also set the aria-valuenow attribute, unless that value is unknown (for example, on an indeterminate progressbar).
Authors SHOULD only set the aria-valuetext attribute when the rendered value cannot be meaningfully represented as a number. For example, a slider may have rendered values of small, medium, and large. In this case, the values of aria-valuenow could range from 1 through 3, which indicate the position of each value in the value space, but the aria-valuetext would be one of the strings: small, medium, or large. If the aria-valuetext attribute is absent, the assistive technologies will rely solely on the aria-valuenow attribute for the current value.
- If aria-valuetext is specified, assistive technologies SHOULD render that value instead of the value of aria-valuenow.
+ If aria-valuetext is specified, assistive technologies SHOULD render that value instead of the value of aria-valuenow.
Characteristics:
@@ -11132,7 +13253,7 @@ Definitions of States and Properties (all aria-* attributes)
| Related Concepts: |
- XForms [[XFORMS10]] range, start |
+ |
| Used in Roles: |
@@ -11151,6 +13272,58 @@ Definitions of States and Properties (all aria-* attributes)
+
+ Accessibility Tree
+ The accessibility tree and the DOM tree are parallel structures. The accessibility tree includes the user interface objects of the user agent and the objects of the document. Accessible objects are created in the accessibility tree for every DOM element that should be exposed to an assistive technology, either because it may fire an accessibility event or because it has a property, relationship or feature which needs to be exposed.
+
+ Excluding Elements from the Accessibility Tree
+ The following elements are not exposed via the accessibility API and user agents MUST NOT include them in the accessibility tree:
+
+ - Elements, including their descendent elements, that have host language semantics specifying that the element is not displayed, such as CSS
display:none, visibility:hidden, or the HTML hidden attribute.
+ - Elements with none or presentation as the first role in the role attribute. However, their exclusion is conditional. In addition, the element's descendants and text content are generally included. These exceptions and conditions are documented in the presentation (role) section.
+
+ If not already excluded from the accessibility tree per the above rules, user agents SHOULD NOT include the following elements in the accessibility tree:
+
+ - Elements, including their descendants, that have aria-hidden set to
true. In other words, aria-hidden="true" on a parent overrides aria-hidden="false" on descendants.
+ -
+
Any descendants of elements that have the characteristic "Children Presentational: True" unless the descendant is not allowed to be presentational because it meets one of the conditions for exception described in Presentational Roles Conflict Resolution. However, the text content of any excluded descendants is included.
+ Elements with the following roles have the characteristic "Children Presentational: True":
+
+ - button
+ - checkbox
+ - img
+ - menuitemcheckbox
+ - menuitemradio
+ - meter
+ - option
+ - progressbar
+ - radio
+ - scrollbar
+ - separator
+ - slider
+ - switch
+ - tab
+
+
+
+
+
+
Implementation in Host Languages
The roles, state, and properties defined in this specification do not form a complete web language or format. They are intended to be used in the context of a host language. This section discusses how host languages are to implement WAI-ARIA, to ensure that the markup specified here will integrate smoothly and effectively with the host language markup.
@@ -11163,7 +13336,7 @@ Role Attribute
The attribute name MUST be role;
The attribute value MUST allow a token list as the value;
The appearance of the name literal of any concrete WAI-ARIA role as one of these tokens MUST NOT in and of itself make the attribute value illegal in the host-language syntax; and
- The first name literal of a non-abstract WAI-ARIA role in the list of tokens in the role attribute defines the role according to which the user agent MUST process the element. User Agent processing for roles is defined in the Core Accessibility API Mappings [[CORE-AAM-1.1]].
+ The first name literal of a non-abstract WAI-ARIA role in the list of tokens in the role attribute defines the role according to which the user agent MUST process the element. User Agent processing for roles is defined in the Core Accessibility API Mappings [[CORE-AAM-1.2]].
@@ -11181,14 +13354,14 @@ State and Property Attributes
Focus Navigation
- An implementing host language MUST provide support for the author to make all interactive elements focusable, that is, any renderable or event-receiving elements. An implementing host language MUST provide a facility to allow web authors to define whether these focusable, interactive elements appear in the default tab navigation order. The tabindex attribute in HTML 5 is an example of one implementation.
+ An implementing host language MUST provide support for the author to make all interactive elements focusable, that is, any renderable or event-receiving elements. An implementing host language MUST provide a facility to allow web authors to define whether these focusable, interactive elements appear in the default tab navigation order. The tabindex attribute in HTML is an example of one implementation.
Implicit WAI-ARIA Semantics
WAI-ARIA is designed to provide semantic information about objects when host languages lack native semantics for the object. WAI-ARIA is designed, however, to provide additional semantics for many host languages. Furthermore, host languages over time can evolve and provide new native features that correspond to WAI-ARIA features. Therefore, there are many situations in which WAI-ARIA semantics are redundant with host language semantics.
These host language features can be viewed as having "implicit WAI-ARIA semantics". User agent processing of features with implicit WAI-ARIA semantics would be similar to the processing for the WAI-ARIA feature. The processing might not be identical because of lexical differences between the host language feature and the WAI-ARIA feature, but generally the user agent would expose the same information to the accessibility API. Features with implicit WAI-ARIA semantics satisfy WAI-ARIA structural requirements such as required owned elements, required states and properties, etc. and do not require explicit WAI-ARIA semantics to be provided. On elements with implicit WAI-ARIA roles, authors can also use WAI-ARIA states and properties supported by those roles without requiring explicit indication of the WAI-ARIA role.
For example, if an element with the functionality already exists, such as a checkbox or radio button, use the native semantics of the host language. WAI-ARIA markup is only intended to be used to enhance the native semantics (e.g., indicating that the element is required with aria-required), or to change the semantics to a different purpose from the standard functionality of the element.
- Implicit WAI-ARIA semantics affect the conflict resolution procedures in the following section, Conflicts with Host Language Semantics. Therefore, implicit WAI-ARIA semantics need to be defined in a normative specification, such as the host language specification or the Core Accessibility API Mappings [[CORE-AAM-1.1]].
+ Implicit WAI-ARIA semantics affect the conflict resolution procedures in the following section, Conflicts with Host Language Semantics. Therefore, implicit WAI-ARIA semantics need to be defined in a normative specification, such as the host language specification or the Core Accessibility API Mappings.
Conflicts with Host Language Semantics
@@ -11197,10 +13370,11 @@ Conflicts with Host Language Semantics
Host languages can have features that have implicit WAI-ARIA semantics corresponding to roles. When a WAI-ARIA role is provided, user agents MUST use the semantic of the WAI-ARIA role for processing, not the native semantic, unless the role requires WAI-ARIA states and properties whose attributes are explicitly forbidden on the native element by the host language. Values for roles do not conflict in the same way as values for states and properties (for example, the HTML 'checked' attribute and the 'aria-checked' attribute could have conflicting values), and authors are expected to have valid reason to provide a WAI-ARIA role even on elements that would not normally be repurposed.
When WAI-ARIA states and properties correspond to host language features that have the same implicit WAI-ARIA semantic, it can be particularly problematic to use the WAI-ARIA feature. If the WAI-ARIA feature and the host language feature are both provided but their values are not kept in sync, user agents and assistive technologies cannot know which value to use. Therefore, to prevent providing conflicting states and properties to assistive technologies, host languages MUST explicitly declare where the use of WAI-ARIA attributes on each host language element conflicts with native attributes for that element. When a host language declares a WAI-ARIA attribute to be in direct semantic conflict with a native attribute for a given element, user agents MUST ignore the WAI-ARIA attribute and instead use the host language attribute with the same implicit semantic.
Host languages MAY document features that cannot be overridden with WAI-ARIA (these are called "strong native semantics"). These can be features that have implicit WAI-ARIA semantics, as well as features where the processing would be uncertain if the semantics were changed with WAI-ARIA. Conformance checkers MAY signal an error or warning when a WAI-ARIA role is used on elements with strong native semantics, but as described above, user agents MUST still use the value of the semantic of the WAI-ARIA role when exposing the element to accessibility APIs unless the native host language semantic is permanently presentational.
- The opportunity for host languages to create exceptions to the WAI-ARIA override of native features is meant to avoid potential author errors or problems with intrinsic processing of host language features. Author errors could happen when a host language and WAI-ARIA provide similar but not identical features, where it might not be clear how changing one but not the other affects the accessibility API. Intrinsic processing refers to the way a feature is processed, beyond simple rendering and exposure to the Accessibility API, that cannot reasonably be changed in response to a ARIA feature, and would lead to unpredictable results were ARIA allowed. In these situations, there is good reason for host languages to limit the scope of WAI-ARIA. However, this provision does not give blanket permission for host languages to forbid the use of WAI-ARIA simply by documenting, feature by feature, that it may not be used. Host languages should create restrictions on the use of ARIA only when it is critical to effective processing of content.
+ The opportunity for host languages to create exceptions to the WAI-ARIA override of native features is meant to avoid potential author errors or problems with intrinsic processing of host language features. Author errors could happen when a host language and WAI-ARIA provide similar but not identical features, where it might not be clear how changing one but not the other affects the accessibility API. Intrinsic processing refers to the way a feature is processed, beyond simple rendering and exposure to the Accessibility API, that cannot reasonably be changed in response to an ARIA feature, and would lead to unpredictable results were ARIA allowed. In these situations, there is good reason for host languages to limit the scope of WAI-ARIA. However, this provision does not give blanket permission for host languages to forbid the use of WAI-ARIA simply by documenting, feature by feature, that it may not be used. Host languages should create restrictions on the use of ARIA only when it is critical to effective processing of content.
Certain ARIA features are critical to building a complete model in the accessibility API. Such features are not expected to conflict with native host language semantics (though they may complement them). Therefore, host languages MUST NOT declare strong native semantics that prevent use of the following ARIA features:
- aria-describedby
+ - aria-description
- aria-label
- aria-labelledby
@@ -11220,134 +13394,308 @@ State and Property Attribute Processing
State and property attributes are included in host languages, and therefore syntax for representation of their value types is governed by the host language. For each of the value types defined in Value, an appropriate value type from the host language is used. Recommended correspondences between WAI-ARIA value types and various host language value types are listed in Mapping WAI-ARIA Value types to languages. This is a non-normative mapping in order to accommodate new host languages supporting WAI-ARIA.
The list value types—ID reference list and token list—allow more than one value of the given type to be provided. The values are separated by delimiter characters recognized by the host language for list attributes, such as space characters, commas, etc. Some languages may require a specific, single delimiter, while others may allow various delimiters.
Global states and properties are supported on any element in the host language. However, authors MUST only use non-global states and properties on elements with a role supporting the state or property; either defined as an explicit WAI-ARIA role, or as defined by the host language implicit WAI-ARIA semantic matching an appropriate WAI-ARIA role. When a role attribute is added to an element, the semantics and behavior of the element, including support for WAI-ARIA states and properties, are augmented or overridden by the role behavior. User agents MUST ignore non-global states and properties used on an element without a role supporting the state or property; either defined as an explicit WAI-ARIA role, or as defined by the host language WAI-ARIA semantic matching an appropriate WAI-ARIA role. For example, the aria-valuetext attribute may be used on a progressbar.
- WAI-ARIA roles have associated states and properties that are qualified as "supported" or "required". An example of a property supported by the combobox role is aria-autocomplete. The property is designated "supported" in this case because a given combobox might or might not implement auto completion. In contrast, the combobox role requires the aria-expanded state in order to indicate that it is expandable. Comboboxes have a descendant listbox that is either open or closed. If the listbox is open, the combobox is in its expanded state; otherwise it is collapsed.
+ WAI-ARIA roles have associated states and properties that are qualified as "supported" or "required". An example of a property supported by the combobox role is aria-autocomplete. The property is designated "supported" in this case because a given combobox might or might not implement auto completion. In contrast, the combobox role requires the aria-expanded state in order to indicate that it is expandable. Comboboxes have a controlled popup element, such as a listbox, that is either open or closed. If the listbox is open, the combobox is in its expanded state; otherwise it is collapsed.
When WAI-ARIA roles are used, supported states and properties that are not present in the DOM are treated according to their default value. Keeping with the combobox example, a missing aria-autocomplete attribute is equivalent to aria-autocomplete="none", meaning the combobox does not offer auto completion.
However, required states and properties that are absent are an author error. Missing required states and properties are treated as if they were present and have an implicit neutral value that is not necessarily their default value. For example, the default value of aria-expanded is undefined, meaning neither expandable nor collapsible. But that does not apply to the case of a combobox. In this case, aria-expanded is needed to convey the expandable/collapsible nature of the combobox. Thus, the implicit value of aria-expanded for the combobox role is false, meaning expandable (and currently collapsed). The characteristics table associated with each WAI-ARIA role has an "Implicit Value for Role" entry that specifies the value of a state or property to use in the context of that role when the state or property is missing.
Elements that have implicit WAI-ARIA semantics support the full set of WAI-ARIA states and properties supported by the corresponding role. Therefore, authors MAY omit the role when setting states and properties. The role is only needed when the implicit WAI-ARIA role of the element needs to be changed.
- Sometimes states and properties are present in the DOM but have a zero-length string ("") as their value. This is equivalent to their absence. User agents SHOULD treat state and property attributes with a value of "" the same as they treat an absent attribute. For supported states and properties, this corresponds to the default value, but if it is a required attribute, it signals an author error, and the implicit value for the role is used.
+ Sometimes states and properties are present in the DOM but have a zero-length string ("") as their value. Authors MAY specify a zero-length string ("") for any supported (but not required) state or property. User agents SHOULD treat state and property attributes with a value of "" the same as they treat an absent attribute. For supported states and properties, this corresponds to the default value, but if it is a required attribute, it signals an author error, and the implicit value for the role is used.
+
+ ID Reference Error Processing
+ User agents SHOULD ignore ID references that do not match the ID of another element in the same document.
+ It is the web author's responsibility to ensure that IDs are unique. If more than one element has the same ID, the user agent SHOULD use the first element found with the given ID. The behavior will be the same as getElementById.
+ If the same element is specified multiple times in a single WAI-ARIA relation, user agents SHOULD return multiple pointers to the same element.
+ aria-activedescendant is defined as referencing only a single ID reference. Any aria-activedescendant value that does not match an existing ID reference exactly is an author error and will not match any element in the DOM.
+
+
+
+ CSS Selectors
+ This section might be removed in a future version.
+ Support for attribute selectors MUST include WAI-ARIA attributes. For example, .fooMenuItem[aria-haspopup="true"] would select all elements with class fooMenuItem, and WAI-ARIA property aria-haspopup with value of true. The presentation MUST be updated for dynamic changes to WAI-ARIA attributes. This allows authors to match styling with WAI-ARIA semantics.
+
+
+
+ Handling Author Errors
+
+ Roles
+ User agents are expected to perform validation of WAI-ARIA roles.
+ As stated in the Definition of Roles section, it is considered an authoring error to use abstract roles in content. User agents MUST NOT map abstract roles via the standard role mechanism of the accessibility API.
+ If the role attribute contains no tokens matching the name of a non-abstract WAI-ARIA role, the user agent MUST treat the element as if no role had been provided. For example, <table role="foo"> should be exposed in the same way as <table> and <input type="text" role="structure"> in the same way as <input type="text">.
+
+
+ States and Properties
+ In general, user agents do not do much validation of WAI-ARIA properties. User agents MAY do some minor validation on request, such as making sure valid IDs are specified for WAI-ARIA relations, and enforcing things like aria-posinset being within 1 and aria-setsize, inclusive. User agents are not responsible for logical validation, such as the following:
+
+ - Circular references created by relations, such as specifying that two elements own each other.
+ - Correct usage with regard to DOM tree structure, such as an element being owned by more than one other element.
+ - Elements with WAI-ARIA roles correctly implement the behavior of the specified role. For example, user agents do not verify that an element with a role of checkbox actually behaves like a checkbox.
+ - Elements that do not correctly observe required child / parent role relationships or that appear elsewhere than in their required parent.
+ - Determining whether aria-activedescendant actually points to an owned element of the container widget.
+ - Determining implicit values of aria-setsize and aria-posinset when they are specified on some but not all the elements of the set.
+
+ If the author specifies a non-numeric value for a decimal or integer value type, the user agent SHOULD do the following:
+
+ - When asked for the string version of the property, return the string if specified by the author.
+ - When asked for the numeric version:
+
+
+
+ If a WAI-ARIA property contains an unknown or disallowed value, the user agent SHOULD expose to platform accessibility APIs as follows:
+
+ - When exposing as a platform accessibility API attribute, expose the unknown value — do not vet it against possible values.
+ - When exposing as a platform API Boolean state:
+
+ - For values of "" (empty string), "undefined" or no attribute present:
+
+
+ - Treat any other value as true.
+
+
+ - Otherwise, ignore the value and treat the property as not present.
+
+ In UIA, the user agent might leave the corresponding property set to "unsupported."
+ User agents MUST NOT expose WAI-ARIA attributes that reference unresolved IDs. For example:
+
+ - When the state or property has only one ID reference that cannot be resolved, treat as if the state or property is not present.
+ - When the state or property has a list of ID references, ignore any that can't be resolved. If none in the list can be resolved, treat as if the state or property is not present.
+
+ User Agents MUST NOT expose aria-roledescription when:
+
+ - The element it is applied to has an invalid WAI-ARIA role, or
+ - The element does not have an implicit WAI-ARIA role
+
+ If a required WAI-ARIA attribute for a given role is missing, user agents SHOULD process the attribute as if the values given in the following table were provided.
+
+ Fallback values for missing required attributes
+
+
+ | WAI-ARIA role |
+ Required Attribute |
+ Fallback value |
+
+
+
+
+ | checkbox |
+ aria-checked |
+ false |
+
+
+ | combobox |
+ aria-controls |
+ no mapping |
+
+
+ | combobox |
+ aria-expanded |
+ false |
+
+
+ | heading |
+ aria-level |
+ 2 |
+
+
+ | menuitemcheckbox |
+ aria-checked |
+ false |
+
+
+ | menuitemradio |
+ aria-checked |
+ false |
+
+
+ | radio |
+ aria-checked |
+ false |
+
+
+ | scrollbar |
+ aria-controls |
+ no mapping |
+
+
+ | scrollbar |
+ aria-valuenow |
+ If missing or not a number,(aria-valuemax - aria-valuemin) / 2. If present but less than aria-valuemin, the value of aria-valuemin. If present but greater than aria-valuemax, the value of aria-valuemax. |
+
+
+ | separator (if focusable) |
+ aria-valuenow |
+ If missing or not a number,(aria-valuemax - aria-valuemin) / 2. If present but less than aria-valuemin, the value of aria-valuemin. If present but greater than aria-valuemax, the value of aria-valuemax. |
+
+
+ | slider |
+ aria-valuenow |
+ If missing or not a number,(aria-valuemax - aria-valuemin) / 2. If present but less than aria-valuemin, the value of aria-valuemin. If present but greater than aria-valuemax, the value of aria-valuemax. |
+
+
+ | switch |
+ aria-checked |
+ false |
+
+
+ | meter |
+ aria-valuenow |
+ A value matching the implicit or explicitly set aria-valuemin. |
+
+
+
+ Implicit Values for non-required states and properties appear in the characteristics table for each role. These are not considered fallback values so are not included here.
IDL Interface
- Conforming user agents MUST implement the following IDL interfaces.
-
- Interface Mixin AccessibilityRole
+ Conforming user agents MUST implement the following IDL interface.
+
+ Interface Mixin ARIAMixin
- interface mixin AccessibilityRole {
+ interface mixin ARIAMixin {
attribute DOMString? role;
+
+
+ attribute DOMString ariaAtomic;
+ attribute DOMString ariaAutoComplete;
+ attribute DOMString ariaBusy;
+ attribute DOMString ariaChecked;
+ attribute DOMString ariaColCount;
+ attribute DOMString ariaColIndex;
+ attribute DOMString ariaColIndexText;
+ attribute DOMString ariaColSpan;
+
+ attribute DOMString ariaCurrent;
+
+ attribute DOMString ariaDescription;
+
+ attribute DOMString ariaDisabled;
+
+ attribute DOMString ariaExpanded;
+
+ attribute DOMString ariaHasPopup;
+ attribute DOMString ariaHidden;
+ attribute DOMString ariaInvalid;
+ attribute DOMString ariaKeyShortcuts;
+ attribute DOMString ariaLabel;
+
+ attribute DOMString ariaLevel;
+ attribute DOMString ariaLive;
+ attribute DOMString ariaModal;
+ attribute DOMString ariaMultiLine;
+ attribute DOMString ariaMultiSelectable;
+ attribute DOMString ariaOrientation;
+
+ attribute DOMString ariaPlaceholder;
+ attribute DOMString ariaPosInSet;
+ attribute DOMString ariaPressed;
+ attribute DOMString ariaReadOnly;
+
+ attribute DOMString ariaRequired;
+ attribute DOMString ariaRoleDescription;
+ attribute DOMString ariaRowCount;
+ attribute DOMString ariaRowIndex;
+ attribute DOMString ariaRowIndexText;
+ attribute DOMString ariaRowSpan;
+ attribute DOMString ariaSelected;
+ attribute DOMString ariaSetSize;
+ attribute DOMString ariaSort;
+ attribute DOMString ariaValueMax;
+ attribute DOMString ariaValueMin;
+ attribute DOMString ariaValueNow;
+ attribute DOMString ariaValueText;
};
- Element includes AccessibilityRole;
- User agents MUST reflect the role content attribute as the role IDL attribute.
+
+ Interfaces that include ARIAMixin must provide the following algorithms:
+
+
+ ARIAMixin getter steps, which take the host interface instance, IDL attribute name, and content attribute name, and must return a string value; and
+ ARIAMixin setter steps, which take the host interface instance, IDL attribute name, content attribute name, and string value, and must return nothing.
+
+ For every IDL attribute idlAttribute defined in ARIAMixin, on getting, it must perform the following steps:
+
+
+ Let contentAttribute be the ARIA content attribute determined by looking up idlAttribute in the ARIA Attribute Correspondence table. Return the result of running the ARIAMixin getter steps, given this, idlAttribute, and contentAttribute.
+
+ Similarly, on setting, it must perform the following steps:
+
+
+ Let contentAttribute be the ARIA content attribute determined by looking up idlAttribute in the ARIA Attribute Correspondence table. Run the ARIAMixin setter steps, given this, idlAttribute, contentAttribute, and the given value.
+
+ This very general framework is motivated by the desire for different host interfaces, such as Element and ElementInternals, to give these IDL attributes different behaviors. The alternative is requiring each host interface to duplicate the IDL attributes independently, so that they can specify independent behaviors, but that comes with a high risk of them getting out of sync.
-
- Interface Mixin AriaAttributes
-
- interface mixin AriaAttributes {
- attribute DOMString? ariaActiveDescendant;
- attribute DOMString? ariaAtomic;
- attribute DOMString? ariaAutoComplete;
- attribute DOMString? ariaBusy;
- attribute DOMString? ariaChecked;
- attribute DOMString? ariaColCount;
- attribute DOMString? ariaColIndex;
- attribute DOMString? ariaColSpan;
- attribute DOMString? ariaControls;
- attribute DOMString? ariaCurrent;
- attribute DOMString? ariaDescribedBy;
- attribute DOMString? ariaDetails;
- attribute DOMString? ariaDisabled;
- attribute DOMString? ariaErrorMessage;
- attribute DOMString? ariaExpanded;
- attribute DOMString? ariaFlowTo;
- attribute DOMString? ariaHasPopup;
- attribute DOMString? ariaHidden;
- attribute DOMString? ariaInvalid;
- attribute DOMString? ariaKeyShortcuts;
- attribute DOMString? ariaLabel;
- attribute DOMString? ariaLabelledBy;
- attribute DOMString? ariaLevel;
- attribute DOMString? ariaLive;
- attribute DOMString? ariaModal;
- attribute DOMString? ariaMultiLine;
- attribute DOMString? ariaMultiSelectable;
- attribute DOMString? ariaOrientation;
- attribute DOMString? ariaOwns;
- attribute DOMString? ariaPlaceholder;
- attribute DOMString? ariaPosInSet;
- attribute DOMString? ariaPressed;
- attribute DOMString? ariaReadOnly;
- attribute DOMString? ariaRelevant;
- attribute DOMString? ariaRequired;
- attribute DOMString? ariaRoleDescription;
- attribute DOMString? ariaRowCount;
- attribute DOMString? ariaRowIndex;
- attribute DOMString? ariaRowSpan;
- attribute DOMString? ariaSelected;
- attribute DOMString? ariaSetSize;
- attribute DOMString? ariaSort;
- attribute DOMString? ariaValueMax;
- attribute DOMString? ariaValueMin;
- attribute DOMString? ariaValueNow;
- attribute DOMString? ariaValueText;
- };
- Element includes AriaAttributes;
-
-
- ARIA Attribute Reflection
- User agents MUST reflect the following content attributes to each of the corresponding IDL attributes.
-
- | IDL Attribute | Reflected ARIA Content Attribute |
|---|
- | ariaActiveDescendant | aria-activedescendant |
- | ariaAtomic | aria-atomic |
- | ariaAutoComplete | aria-autocomplete |
- | ariaBusy | aria-busy |
- | ariaChecked | aria-checked |
- | ariaColCount | aria-colcount |
- | ariaColIndex | aria-colindex |
- | ariaColSpan | aria-colspan |
- | ariaControls | aria-controls |
- | ariaCurrent | aria-current |
- | ariaDescribedBy | aria-describedby |
- | ariaDetails | aria-details |
- | ariaDisabled | aria-disabled |
- | ariaErrorMessage | aria-errormessage |
- | ariaExpanded | aria-expanded |
- | ariaFlowTo | aria-flowto |
- | ariaHasPopup | aria-haspopup |
- | ariaHidden | aria-hidden |
- | ariaInvalid | aria-invalid |
- | ariaKeyShortcuts | aria-keyshortcuts |
- | ariaLabel | aria-label |
- | ariaLabelledBy | aria-labelledby |
- | ariaLevel | aria-level |
- | ariaLive | aria-live |
- | ariaModal | aria-modal |
- | ariaMultiLine | aria-multiline |
- | ariaMultiSelectable | aria-multiselectable |
- | ariaOrientation | aria-orientation |
- | ariaOwns | aria-owns |
- | ariaPlaceholder | aria-placeholder |
- | ariaPosInSet | aria-posinset |
- | ariaPressed | aria-pressed |
- | ariaReadOnly | aria-readonly |
- | ariaRelevant | aria-relevant |
- | ariaRequired | aria-required |
- | ariaRoleDescription | aria-roledescription |
- | ariaRowCount | aria-rowcount |
- | ariaRowIndex | aria-rowindex |
- | ariaRowSpan | aria-rowspan |
- | ariaSelected | aria-selected |
- | ariaSetSize | aria-setsize |
- | ariaSort | aria-sort |
- | ariaValueMax | aria-valuemax |
- | ariaValueMin | aria-valuemin |
- | ariaValueNow | aria-valuenow |
- | ariaValueText | aria-valuetext |
-
- Note: Attributes aria-dropeffect and aria-grabbed were deprecated in ARIA 1.1 and do not have corresponding IDL attributes.
-
+
+ ARIA Attribute Correspondence
+ The following table provides a correspondence between IDL attribute names and content attribute names, for use by ARIAMixin.
+
+
+ | IDL Attribute | Reflected ARIA Content Attribute |
|---|
+ | role | role |
+
+ | ariaAtomic | aria-atomic |
+ | ariaAutoComplete | aria-autocomplete |
+ | ariaBusy | aria-busy |
+ | ariaChecked | aria-checked |
+ | ariaColCount | aria-colcount |
+ | ariaColIndex | aria-colindex |
+ | ariaColIndexText | aria-colindextext |
+ | ariaColSpan | aria-colspan |
+
+ | ariaCurrent | aria-current |
+
+ | ariaDescription | aria-description |
+
+ | ariaDisabled | aria-disabled |
+
+ | ariaExpanded | aria-expanded |
+
+ | ariaHasPopup | aria-haspopup |
+ | ariaHidden | aria-hidden |
+ | ariaInvalid | aria-invalid |
+ | ariaKeyShortcuts | aria-keyshortcuts |
+ | ariaLabel | aria-label |
+
+ | ariaLevel | aria-level |
+ | ariaLive | aria-live |
+ | ariaModal | aria-modal |
+ | ariaMultiLine | aria-multiline |
+ | ariaMultiSelectable | aria-multiselectable |
+ | ariaOrientation | aria-orientation |
+
+ | ariaPlaceholder | aria-placeholder |
+ | ariaPosInSet | aria-posinset |
+ | ariaPressed | aria-pressed |
+ | ariaReadOnly | aria-readonly |
+
+ | ariaRequired | aria-required |
+ | ariaRoleDescription | aria-roledescription |
+ | ariaRowCount | aria-rowcount |
+ | ariaRowIndex | aria-rowindex |
+ | ariaRowIndexText | aria-rowindextext |
+ | ariaRowSpan | aria-rowspan |
+ | ariaSelected | aria-selected |
+ | ariaSetSize | aria-setsize |
+ | ariaSort | aria-sort |
+ | ariaValueMax | aria-valuemax |
+ | ariaValueMin | aria-valuemin |
+ | ariaValueNow | aria-valuenow |
+ | ariaValueText | aria-valuetext |
+
+ Note: Attributes aria-dropeffect and aria-grabbed were deprecated in ARIA 1.1 and do not have corresponding IDL attributes.
+
+
+ ARIAMixin Mixed in to Element
+
+ User agents MUST include ARIAMixin on Element:
+
+
+ Element includes ARIAMixin;
+
+
+ For Element:
+
+ The ARIAMixin getter steps given element, idlAttribute, and contentAttribute are to return the result of the getter algorithm for idlAttribute reflecting contentAttribute on element. The ARIAMixin setter steps given element, idlAttribute, contentAttribute, and value are to perform the setter algorithm for idlAttribute reflecting contentAttribute on element, given value.
+
+ In practice, this means that, e.g., the role IDL on Element reflects the role content attribute; the ariaValueMin IDL attribute reflects the aria-valuemin content attribute; etc.
+
+
-
- Schemata
- WAI-ARIA roles, states, and properties are available in a number of machine-readable formats to support validation of content using WAI-ARIA attributes. WAI-ARIA is not finalized, however, so these files are subject to change without notice. Todo: Remove disclaimers about not final at rec.
- It is not appropriate to use these document types for live content. These are made available only for download, to support local use in development, evaluation, and validation tools. Using these versions directly from the W3C server could cause automatic blockage, preventing them from loading.
- If it is necessary to use schemata in content, follow guidelines to avoid excessive DTD traffic. For instance, use caching proxies to avoid fetching the schema each time it is used, or ensure software uses a local cache, such as with XML catalogs.
-
-
- WAI-ARIA Attributes Module
- This module declares the WAI-ARIA attributes as a module that can be included in a modularized DTD. A sample XHTML DTD using this module follows. Note the WAI-ARIA attributes are in no namespace, and the attribute name begins with "aria-" to reduce the likelihood of collision with existing attributes.
- This module is available from http://www.w3.org/MarkUp/DTD/aria-attributes-1.mod.
-
-
- XHTML plus WAI-ARIA DTD
- This DTD extends XHTML 1.1 and adds the WAI-ARIA state and property attributes to all its elements. In order to provide broader keyboard support and conform with the Focus Navigation section above, it also adds the tabindex attribute to a wider set of elements.
- This is not a formal document type and may be obsoleted by future formal XHTML DTDs that support WAI-ARIA.
- The XHTML 1.1 plus WAI-ARIA DTD is available from http://www.w3.org/WAI/ARIA/schemata/xhtml-aria-1.dtd.
- Documents written using this XHTML Family markup language can be validated using the above DTD. If a document author wants to facilitate such validation, they can include the following declaration at the top of their document:
- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+ARIA 1.0//EN"
- "http://www.w3.org/WAI/ARIA/schemata/xhtml-aria-1.dtd">
- However, note that when this DOCTYPE is present in a document, most user agents treat the document as generic XML rather than HTML. This causes them to be unable to support named character entities defined by the DTD (e.g., ©). Therefore, authors need to avoid use of named entities outside of the predefined entities in XML ([[XML11]], Section 4.6).
- To avoid the above problem, authors can omit the above DOCTYPE statement. This causes user agents to treat the document as generic HTML with named character entity support as well as built-in ARIA support. However, it causes user agents to enter "quirks" mode which affects CSS rendering, and causes conformance checkers to fail the document due to the added ARIA attributes.
- To avoid the issues of named character entity support and quirks mode, authors can instead use the following generic DOCTYPE declaration for HTML:
- <!DOCTYPE html>
- However, this still does not guarantee that documents will be validated by conformance checkers.
-
-
- SGML Open Catalog Entry for XHTML+ARIA
- This section contains the SGML Open Catalog-format definition [[SGML-CATALOG]] of the public identifiers for XHTML+ARIA 1.0.
- -- .......................................................................... --
--- File catalog ............................................................ --
-
--- XHTML+ARIA Catalog Data File
-
- Revision: $Revision: 1.40 $
-
- See "Entity Management", SGML Open Technical Resolution 9401 for detailed
- information on supplying and using catalog data. This document is available
- from OASIS at URL:
-
- <http://www.oasis-open.org/html/tr9401.html>
-
---
-
--- .......................................................................... --
--- SGML declaration associated with XHTML .................................. --
-
-OVERRIDE YES
-
-SGMLDECL "xml1.dcl"
-
--- :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: --
-
--- XHTML+ARIA modules .............................................. --
-
-
-PUBLIC "-//W3C//DTD XHTML+ARIA 1.0//EN" "xhtml-aria-1.dtd"
-
-
-PUBLIC "-//W3C//ENTITIES XHTML ARIA Attributes 1.0//EN" "aria-attributes-1.mod"
-
--- End of catalog data ..................................................... --
--- .......................................................................... --
-
-
-
- WAI-ARIA Attributes XML Schema Module
- This module declares the WAI-ARIA attributes as an XML Schema module that can be included in a modularized schema. Note the WAI-ARIA attributes are in no namespace, and the attribute name begins with "aria-" to reduce the likelihood of collision with existing attributes.
- This module is available from http://www.w3.org/MarkUp/SCHEMA/aria-attributes-1.xsd.
-
-
- HTML 4.01 plus WAI-ARIA DTD
- This standalone DTD adds WAI-ARIA state and property attributes to all elements in HTML 4.01, as well as a role attribute. In order to provide broader keyboard support, it also adds the tabindex attribute to a wider set of elements.
- The DTD is based on the HTML 4.01 Transitional DTD, and includes all entity references needed to make it a standalone file. This is not an official W3C DTD and should be considered a derivative work of HTML 4.01.
- Documents written using this markup language can be validated using the above DTD. If a document author wants to facilitate such validation, they can include the following declaration at the top of their document:
- <!DOCTYPE html PUBLIC "-//W3C//DTD HTML+ARIA 1.0//EN"
- "http://www.w3.org/WAI/ARIA/schemata/html4-aria-1.dtd">
- However, note that when this DOCTYPE is present in a document, most user agents treat the document as generic XML rather than HTML. This causes them to be unable to support named character entities defined by the DTD (e.g., ©). Therefore, authors need to avoid use of named entities outside of the predefined entities in XML ([[XML11]], Section 4.6).
- To avoid the above problem, authors can omit the above DOCTYPE statement. This causes user agents to treat the document as generic HTML with named character entity support as well as built-in ARIA support. However, it causes user agents to enter "quirks" mode which affects CSS rendering, and causes conformance checkers to fail the document due to the added ARIA attributes.
- To avoid the issues of named character entity support and quirks mode, authors can instead use the following generic DOCTYPE declaration for HTML:
- <!DOCTYPE html>
- However, this still does not guarantee that documents will be validated by conformance checkers.
- The HTML Working Group is incorporating WAI-ARIA into HTML5. Official support for WAI-ARIA in HTML will be provided in that specification. This DTD is made available only as a bridging solution for applications requiring DTD validation but not using HTML 5.
- This module is available from http://www.w3.org/WAI/ARIA/schemata/html4-aria-1.dtd.
-
-
|
