First Rule of ARIA Use

If you can use a native HTML element [[HTML]] or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

Under what circumstances may this not be possible?

• If the feature is available in HTML [[HTML]] but it is not implemented or it is implemented, but accessibility support is not.
• If the visual design constraints rule out the use of a particular native element, because the element cannot be styled as required.
• If the feature is not currently available in HTML.

Second Rule of ARIA Use

Do not change native semantics, unless you really have to.

For example: Developer wants to build a heading that's a tab.

Do not do this:

<h2 role=tab>heading tab</h2>     

Do this:

<div role=tab><h2>heading tab</h2></div>

If a non-interactive element is used as the basis for an interactive element, developers have to add the semantics using ARIA and the appropriate interaction behavior using scripting. In the case of a button, for example, it is much better and easier to Just use a (native HTML) button.

It is OK to use native HTML elements, that have similar semantics to ARIA roles used, for fallback. For example, using HTML list elements for the skeleton of an ARIA-enabled, scripted tree widget.

Third Rule of ARIA Use

All interactive ARIA controls must be usable with the keyboard.

If you create a widget that a user can click or tap or drag or drop or slide or scroll, a user must also be able to navigate to the widget and perform an equivalent action using the keyboard.

All interactive widgets must be scripted to respond to standard keystrokes or keystroke combinations where applicable.

For example, if using role=button the element must be able to receive focus and a user must be able to activate the action associated with the element using both the enter (on WIN OS) or return (MAC OS) and the space key.

Refer to the APG Patterns and Developing a Keyboard Interface sections of WAI-ARIA Authoring Practices Guide.

Fourth Rule of ARIA Use

Do not use role="presentation" or aria-hidden="true" on a focusable element .

Using either of these on a focusable element will result in some users focusing on 'nothing'.

Do not do this:

<button role=presentation>press me</button>   

Do not do this:

<button aria-hidden="true">press me</button>   

Applying aria-hidden to a parent/ancestor of a visible interactive element will also result in the interactive element being hidden, so don't do this either:

<div aria-hidden="true">
<button>press me</button>
</div>

If an interactive element cannot be seen or interacted with, then you can apply aria-hidden, as long as it's not focusable. For example:

 button {opacity:0}

<button tabindex="-1" aria-hidden="true">press me</button>

If an interactive element is hidden using display:none or visibility:hidden (either on the element itself, or any of the element's ancestors), it won't be focusable, and it will also be removed from the accessibility tree. This makes the addition of aria-hidden="true" or explicitly setting tabindex="-1" unnecessary.