Techniques

Use native HTML elements instead of custom elements with ARIA roles

  • Many HTML elements already have a considerable degree of accessibility support built in. Where possible, avoid using ARIA by using the semantically correct HTML element.
    • For example, if a form input field has a visible label, use the native HTML element <label> (and programmatically associate it with the input field, using the ‘for’ attribute), rather than using the aria-label attribute.

Do not assign an HTML element an incongruous ARIA role

  • It is misleading to label an <h1> element as a button using an ARIA role, and will interfere with the use of assistive technologies. 

Do not assign an HTML element an identical ARIA role

  • This is not required, and may lead to potential mismatched roles if changes are made to the code in one area but not the other.
  • Note: The HTML <nav> element is an exception to this rule: in order to make the structure more accessible to browsers and screen readers that support ARIA (as well as ensuring that browsers and screen readers that don't support HTML5 can also understand the structure), add the ARIA role="navigation" to nav elements.

Examples

An example where ARIA is beneficial to accessibility

  1. <label for="password">Enter a password</label>
  2. <input type="password" id="password" aria-describedby="password-help" />
  3. <span id="password-help">Passwords should be 8 characters or more</span>

The help text is associated with the input field so it is announced when the input field receives focus.

An example where ARIA is detrimental to accessibility

  1. <h2 role="button">Press me</h2>

The <h2> element is redefined as a button. It will no longer convey its heading semantics to users. In addition, it will not receive focus or execute any button operations without further coding.

Examples of good practice

References

WCAG 2.1

  • 4.1.2 Name, Role, Value (A)

EN 301 549 v 2.1.2

  • 9.4.1.2 Name, Role, Value

Further reading