Indicates the entered value does not conform to the format expected by the application.

Set the aria-invalid state to indicate that the user input is incorrect or not within acceptable ranges. To indicate that input is required, use aria-required.

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. Authors may prevent form submission when an associated form element has its aria-invalid attribute set to true.

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.

Note  For cross-browser compatibility, always use the aria attribute syntax to access and modify aria properties, for example object.setAttribute("aria-valuenow", newValue)

Syntax

HTML
<element aria-invalid="p" ... >
JavaScript
object.setAttribute("aria-invalid",value);var value = object.getAttribute("aria-invalid");

Indicates that the element and all of its descendants are not visible or perceivable to any user as implemented by the author.

If an element is only visible after some user action, authors must set the aria-hidden attribute to true. When the element is presented, authors must set the aria-hidden attribute to false or remove the attribute, indicating that the element is visible.

Some assistive technologies access aria information directly through the DOM and not through platform accessibility supported by the browser. Authors must set aria-hidden="true" on content that is not displayed, regardless of the mechanism used to hide it. This allows assistive technologies or user agents to properly skip hidden elements in the document.

It is recommended that authors key visibility of elements off this attribute, rather than change visibility and separately have to remember to update this property. CSS 2 provides a way to select on attribute values. 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; }

Note: Authors are reminded that visibility:hidden and display:none apply to all CSS media types; therefore, use of either will hide the content from assistive technologies that access the DOM through a rendering engine.

However, in order to support assistive technologies that access the DOM directly, or other authoring techniques to visibly hide content (for example, opacity or off-screen positioning), authors need to ensure the aria-hidden attribute is always updated accordingly when an element is shown or hidden, unless the intent of using off-screen positioning is to make the content visible only to screen reader users and not others.

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.

Note: 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…").

Note: Authors are advised to avoid using aria-hidden="false" with styles or attributes that have historically prevented rendering in all modalities, such as display:none or visibility:hidden in CSS, or the hidden attribute in HTML 5.

At the time of this writing, aria-hidden="false" is known to work inconsistently when used in conjunction with such features. As future implementations improve, use caution and test thoroughly before relying on this approach.

Note:  For cross-browser compatibility, always use the aria attribute syntax to access and modify aria properties, for example object.setAttribute("aria-valuenow", newValue).

Syntax

HTML
<element aria-hidden="p" ... >
JavaScript
object.setAttribute("aria-hidden",value);var value = object.getAttribute("aria-hidden");

Indicates an element's "grabbed" state in a drag-and-drop operation.

When the aria-grabbed attribute is set to true it has been selected for dragging, false indicates that the element can be grabbed for a drag-and-drop operation, but is not currently grabbed, and undefined (or no value) indicates the element cannot be grabbed (default).

When aria-grabbed is set to true, you should also update the aria-dropeffect attribute of all potential drop targets. When an element is not selected for drag (the value is set to false,undefined, or the attribute is removed), revert the aria-dropeffect attributes of the associated drop targets to none.

Syntax

<element aria-grabbed="true|false|undefined" ... /> 

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.

Note  For cross-browser compatibility, always use the aria attribute syntax to access and modify aria properties, for example object.setAttribute("aria-valuenow", newValue).

Syntax

HTML
<element aria-expanded="p" ... >
JavaScript
object.setAttribute("aria-expanded",value);var value = object.getAttribute("aria-expanded");

Indicates that the element is perceivable but disabled, so it is not editable or otherwise operable.

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.

Note  For cross-browser compatibility, always use the aria attribute syntax to access and modify aria properties, for example object.setAttribute("aria-valuenow", newValue).

Syntax

HTML
<element aria-disabled="p" ... >
JavaScript
object.setAttribute("aria-disabled",value);var value = object.getAttribute("aria-disabled");

Indicates the current "checked" state of checkboxes, radio buttons, and other widgets.

aria-checked state is used when the current state of elements such as checkboxes, radio buttons needs to be intimated to the user. On standard browsers, operating systems and screen reader combinations this state can be intimated with the HTML semantics. If this information cannot be received by the screen reader, aria-checked can be used in the mark-up. The standard HTML checkbox exposes only two possible values "checked" (true) and "unchecked" (false), but aria-checked has three possible values.

• aria-checked="true" indicates the element is checked state.
• aria-checked="false" indicates the element is in unchecked state.
• aria-checked="mixed" indicates partial check for elements that have tri states.

How to use aria-checked

In HTML mark-up, aria-checked can be coded as follows:

<label for=”male”>Male</label>
<input type=”checkbox” id=”male” role=”checkbox” aria-checked=”true” />

The aria-checked attribute can also be called via  JavaScript.

object.setAttribute(“aria-checked”,value);var value = object.getAttribute(“aria-checked”);

The mixed value is not supported on radio or menuitemradio or any element that inherits from these in the taxonomy, and user agents must treat a mixed value as equivalent to false for those roles.

Note  For cross-browser compatibility, always use the aria attribute syntax to access and modify aria properties, for example object.setAttribute("aria-valuenow", newValue).

Syntax

HTML
<element aria-checked="p" ... >
JavaScript
object.setAttribute("aria-checked",value);var value = object.getAttribute("aria-checked");

Indicates whether an element, and its subtree, are currently being updated.

aria-busy state should be used by the content authors when a portion on a web page has auto updating content.

aria-busy="true" is set when a relevant portion of the page is currently getting updated and the users are waiting to read the updated content. Users of assistive technology will not be able to read anything while the content is getting updated. They could probably hear "busy" with some screen readers. Once the content is updated, content authors can set aria-busy="false" or remove the aria-busy attribute Once the content is updated, the assistive technologies gather the updated information and provide it to the user.

aria-busy state is used as part of a live region. To notify the live region aria-live property is used. aria-live has three possible values aria-live="off", aria-live="polite" and aria-live="assertive".

In this example we have used aria-live="polite". 

This politeness level is used when the user is not doing anything or when the user is waiting for the update to happen. If the user is busy with other task on the page the screen reader will not interrupt to provide the updated content of the live region. See the following example to understand how an aria-busy state can be used.

Example

<h2>Current Score</h2> 
<p aria-live="polite" aria-busy="true"></p>

In the above example when the update is done, content authors should take care that the aria-busy=”false” and the updated content is available in the paragraph.

<p ARIA-live="polite" aria-busy="false">the current score is 23/0 after 4 overs</p>

This property applies to live regions in the user interface. If authors know that multiple parts of the same live region need to be loaded, they can set aria-busy to true when the first part is loaded, and then set it to false when the last part is loaded.

The default is that aria-busy is false.  When a widget is missing required owned elements due to script execution or loading, authors must mark a containing element with aria-busy equal to true. For example, until a page is fully initialized and complete, an author could mark the document element as busy. If there is an error updating the element, author may set the aria-invalid attribute to true.

Note  For cross-browser compatibility, always use the aria attribute syntax to access and modify aria properties, for example object.setAttribute("aria-valuenow", newValue).

Syntax

HTML
<element aria-busy="p" ... >
JavaScript
object.setAttribute("aria-busy",value);var value = object.getAttribute("aria-busy");

A cell containing header information for a row in a grid.

To form a logical relation between the headers and the corresponding data in data tables < th> tags are used. These < th> tags are supported with HTML scope attribute. scope="row" forms a relation between row header and its corresponding data.

In certain scenarios use of < th scope="row"> might not be possible. Usage of role="rowheader" helps in these situations. Role="columnheader" does the same functionality for < th scope="col">. Screen readers such as JAWS and NVDA recognize the columnheader (role) and rowheader (role).

Authors must ensure elements with role rowheader are contained in or owned by an element with the role row.

A section of a page that consists of a composition that forms an independent part of a document, page, or site.

Article is a landmark role. An article role is marked to the module which forms a meaning by itself without depending on the remaining content of the page.

An article is not a navigational landmark, but may be nested to form a discussion where assistive technologies could pay attention to article nesting to assist the user in following the discussion. An article could be a forum post, a magazine or newspaper article, a web log entry, a user-submitted comment, or any other independent item of content.

It is independent in that its contents could stand alone, for example in syndication. However, the element is still associated with its ancestors; for instance, contact information that applies to a parent body element still covers the article as well.

When nesting articles, the child articles represent content that is related to the content of the parent article. For instance, a web log entry on a site that accepts user-submitted comments could represent the comments as articles nested within the article for the web log entry. Author, heading, date, or other information associated with an article does not apply to nested articles.

When the user navigates an element assigned the role of article, assistive technologies that typically intercept standard keyboard events should switch to document browsing mode, as opposed to passing keyboard events through to the web application. Assistive technologies may provide a feature allowing the user to navigate the hierarchy of any nested article elements.

Syntax

<div role="article">..</div>

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

The banner role is assigned to the portion of the page which contains the site-specific content rather than a page-specific content. Usually the portion of the page that includes logo, navigation panel and the search functionality together are marked with role="banner". A banner usually appears at the top of the page and typically spans the full width. Take care that no more than one element is marked as role="banner" in the page.

User agents should treat elements with the role of banner as navigational landmarks.

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

Syntax

<div role="banner">Header , navigation and search sections form a banner region </div>