Ensure elements in the focus order have a role appropriate for interactive content

The focus-order-semantics rule ensures that all elements in the keyboard focus order have an appropriate role, either as native HTML elements or with valid ARIA roles, so assistive technologies can accurately communicate their purpose to users.

What is being tested?

This rule checks that:

• All interactive elements in the focus order have a valid semantic role.
• Native HTML elements (like <button>, <input>, <a>) do not require extra ARIA roles.
• Custom widgets use appropriate ARIA roles (like role="button", role="dialog").

Why it matters

Without proper roles, screen readers cannot communicate the type or purpose of interactive elements, leaving users unaware of how to interact with them. This can make a page completely unusable for people relying on assistive technologies.

How to fix the problem

• Use native HTML elements whenever possible—they have built-in semantics.
• For custom widgets, add a valid ARIA role that matches the element’s function (e.g., role="button" for clickable elements).
• Avoid using invalid or abstract roles like role="input" or role="composite" on interactive elements.

Good example

<button>Submit</button>

<div role="button" tabindex="0">Custom Button</div>

Incorrect example

<div tabindex="0">Submit</div>
<!-- Missing role, screen reader won’t know this is a button -->

<div role="paragraph" tabindex="0">Submit</div>
<!-- Invalid role, paragraph is not interactive -->

Best practices

• Stick to native HTML where possible for built-in accessibility.
• For custom components, apply correct ARIA roles and manage keyboard focus properly.
• Test your app with a screen reader or keyboard to ensure all interactive elements are announced and operable.