Focus Order Semantics

• June 1, 2025

Rule ID: focus-order-semantics
Ruleset: axe-core 4.10
User Impact: Minor
Guidelines: Deque Best Practice

How to Fix the Problem

1. Identify all focusable elements
   Run through your page using Tab and Shift+Tab to see which elements receive focus. Note any custom widgets (e.g., <div>, <span>) or form controls without an explicit semantic.

2. Use native HTML semantics whenever possible

   • Standard controls such as <button>, <a href="…">, <input>, <select>, and <textarea> already carry the correct role.

   • Remove any unnecessary or incorrect role attributes on these elements.

3. Add appropriate ARIA roles to custom widgets
   For interactive elements built from non-semantic containers, include a valid WAI-ARIA role:

   html

   CopyEdit

   <div role="button" tabindex="0">Click me</div>
<span role="checkbox" aria-checked="false" tabindex="0"></span>


   Ensure that:

   • The chosen role matches the intended behavior (e.g., role="button", role="textbox", role="checkbox").

   • Interactive behavior (click, keydown) corresponds to the ARIA pattern.

4. Verify valid and specific roles
   Do not use abstract ARIA roles (e.g., role="structure") for interactive content. Instead, pick from these categories:

   • Landmark Roles: banner, navigation, main, region, search, contentinfo

   • Widget Roles: button, checkbox, textbox, slider, tab, tabpanel, menuitem, etc.

   • Document/Section Roles: document (for nested document contexts)

   • Application Role: application (to enable rich keyboard interactions)

   • Presentation Role: presentation (to suppress native semantics when needed)

   • Other Semantic Roles: img, link, list, listitem, option, radio, radiogroup, etc.

5. Test with assistive technology
   Use a screen reader (e.g., NVDA, VoiceOver) and keyboard-only navigation to confirm each element:

   • Receives focus in the correct order.

   • Announces its role and name/label appropriately.

   • Operates as expected (e.g., activating a “button” performs the click handler).

Why it Matters

• Clarity of purpose: Screen reader users rely on role information to know what each element does. Without a valid role, a focusable element may be announced as “text” or simply “frame,” leaving its purpose ambiguous.

• Operability: Incorrect or missing roles can prevent elements from being focusable or operable via keyboard, blocking users who cannot use a mouse.

• Consistent experience: When ARIA roles accurately reflect widget behavior, assistive technologies can provide the right feedback and keyboard support, ensuring that all users can navigate and interact with your content confidently.

Rule Description

Every element that can receive keyboard focus must convey its semantic role—either through native HTML semantics or via a valid ARIA role attribute. This ensures that assistive technologies can interpret and announce the element’s purpose correctly, enabling effective keyboard navigation and interaction for users with disabilities.

The Algorithm (in simple terms)

1. Collect all elements in the page’s focus order.

2. For each element:

   • If it’s a native interactive HTML control, ensure there is no conflicting or invalid role attribute.

   • If it’s a custom widget (e.g., <div>, <span>), check for a role attribute:

     • Pass if role matches one of the valid WAI-ARIA widget or landmark roles.

     • Fail if no role is present or if the role is not appropriate for its intended function.