Avoid overriding interactive elements with non-interactive roles

ARIA is useful for revising or correcting the role of an element when a different role is necessary to expose to users. However, it is rarely in the user or author's best interest to try and use ARIA to override an interactive element, for instance a `button`, with a role generally exposed by a non-interactive element. For instance, a heading.

As an example, the following uses a `role=heading` on a [^button^] element. This is not allowed, because the `button` element has default functionality that conflicts with user expectations for the heading role.

          <button role="heading">search</button>
        

An author would need to take additional steps to ensure the default functionality and presentation of the `button` was removed, and even doing so may still not be enough to fully supress the element's implicit features depending on how the user chooses to engage with the web page. E.g., by turning on Windows high contrast themes, or viewing the web page in a browser's reader mode.

Avoid specifying redundant roles

The following example illustrates a [^button^] element which has also been provided an explicit `role=button`. Specifying this role is unnecessary, as a "button" element is already exposed with an implicit `button` role. In practice this particular instance of redundancy will likely not have unforeseen side effects, other than unnecessarily making the markup more verbose, and incorrectly signaling to other authors that this practice is useful. Please review the section [[[#side-effects]]] for an example of where specifying unnecessary roles can be problematic.

          <!-- Avoid doing this! -->
          <button role="button">...</button>
        

Similarly, the following uses a `role=group` on a [^fieldset^] element, and a `role=Main` on a [^main^] element. This is unnecessary, because the `fieldset` element is implicitly exposed as a `role=group`, as is the `main` element implicitly exposed as a `role=main`. Again, in practice this will likely not have any unforeseen side effects to users of assistive technology, as long as the declaration of the `role` value uses [=ASCII lowercase=]. Please see [[[#case-sensitivity]]] for more information.

          <!-- Avoid doing this! -->
          <fieldset role="group">...</fieldset>
          <!-- or this! -->
          <main role="Main">...</main>
        

The following uses a `role=list` on an [^ul^] element. As the `ul` element has an implicit role of `list`, explicitly adding the role would generally be considered redundant. However, some user agents suppress a list's implicit ARIA semantics if the list markers are removed from the visual presentation of the list items. Generally the redundant declaration of an element's implicit role would not be recommended, but in specific situations such as this, and where the role is necessary to expose, authors can explicitly add the role.

          <!-- Generally avoid doing this! -->
          <ul role="list">...</ul>
        

Be cautious of side effects

The following uses a `role=button` on a [^summary^] element. This is unnecessary and can result in cross-platform issues. For instance, preventing the element from correctly exposing its state, and forcing the role of `button`, when it might otherwise be exposed with a platform or browser specific role.

          <details>
            <!-- Avoid doing this! -->
            <summary role="button">more information</summary>
            ...
          </details>
        

Adhere to the rules of ARIA

[[[wai-aria-1.2]]] defines a number of roles which are not meant to be used by authors. Many of these roles are categorized as Abstract Roles which are explicitly stated as not to be used by authors. The following example illustrates the invalid use of an abstract `select` role, where an author likely meant to use the `combobox` role instead.

          <!-- Do not do this! -->
          <div role="select" ...>...</div>
        

ARIA also defines a `generic` role which is meant to provide feature parity with a number of HTML elements that do not have more specific ARIA semantics of their own. For instance, HTML's [^div^] and [^span^] elements, among others. ARIA discourages authors from using the `generic` role as its intended purpose is for use by implementors of user agents.

In the following example, rather than using a `generic` role, authors are advised to use a `div` in place of the `article` element. If changing the HTML element is not possible, specifying a role of `presentation` or `none` would be acceptable alternaties to remove the implicit role of the `article`.

          <!-- Avoid doing this! -->
          <article role="generic" ...>...</article>
        

Additionally, ARIA specifically mentions in Conflicts with Host Language Semantics that if authors use both native HTML features for exposing states and properties as well as their ARIA counterparts, then the host language features take priority over the explicit ARIA attributes that are also used.

For instance, in the following example an author is using HTML's `input type=checkbox` and has specified an `aria-checked=true`. However, user agents are meant to ignore the `aria-checked` attribute. Instead user agents would expose the state based on the native features of the form control.

          <!-- Do not do this! -->
          <input type="checkbox" checked aria-checked="false">
        

Adhere to the rules of HTML

While ARIA can be used to alter the way HTML features are exposed to users of assistive technologies, these modifications do not change the underlying parsing and allowed content models of HTML. For instance, a [^div^] allows an author to specify any role on it. However, this does not mean that the element can then be used in a way that deviates from the rules HTML has defined for the element.

For instance, in the following example an author has specified a role of `link` on a `div` element. While HTML allows for a hyperlink (exposed as a `role=link`) to be a descendant of a `p` element, the HTML parser does not allow a `div` to be a descendant of a `p` element.

          <!-- Do not do this! -->
          <p>
            ... <div role=link tabindex=0>...</div> ... 
          </p>
        

The HTML parser will modify the above markup to be output as the following:

          <!-- The previous example's markup will render as follows -->
          <p>...</p>
          <div role=link tabindex=0>...</div> 
          ... 
          <p></p>
          
          <!-- Instead of a div, use a span. Spans are allowed descendants of p elements! -->
          <p>
            ... <span role=link tabindex=0>...</span> ...
          </p>
        

While this specification indicates the allowed ARIA attributes that can be specified on each HTML element, this example illustrates that even if a role is allowed, the context in which it is used can still result in potential rendering and accessibility issues.