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 3.3 Be cautious of side effects for an example of where specifying unnecessary roles can be problematic.EXAMPLE 4: Redundant role on button

<!-- 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 4.4 Case requirements for ARIA role, state and property attributes for more information.EXAMPLE 5: Redundant role on fieldset and main

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

The following uses a role=list on an ul element. This is generally unnecessary, because the ul element is implicitly exposed as a role=list. However, some user agents suppress a list's implicit ARIA semantics if list markers are removed. Authors can use role=list to reinstate the role if necessary, though this practice would generally not be recommended, otherwise.EXAMPLE 6: Redundant role on list

<!-- 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.EXAMPLE 7: Unintended consequences

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

Adhere to the rules of ARIA

Accessible Rich Internet Applications (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.EXAMPLE 8: Abstract roles are not for authors

<!-- 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.EXAMPLE 9: Do not specify elements as generic

<!-- 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.EXAMPLE 10: The implicit checked state takes precedent over the explicit ARIA attribute

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