Detection and Validation of the tabindex Attribute

Purpose

The main objective of this feature is to detect, classify, and validate the use of the tabindex attribute in DOM elements. The goal is to ensure compliance with accessibility best practices, minimizing keyboard navigation errors and improving the experience for users who rely on focus to interact with interfaces.

Currently, the logic operates on elements present on the active page, with plans for evolution to reduce false positives through more semantic and contextual analysis.

---

Overview

The system identifies elements that contain the tabindex attribute, evaluates its value and context, and classifies its use as correct or potentially problematic. In cases where detection alone cannot automatically determine whether the use is valid, the system will request user interaction (auditor or expert) to confirm the intent.

The collected information is sent to a11ybot as part of the automatic accessibility report, enabling issue tracking and resolution.

---

tabindex Classification

The tabindex attribute can take different values, which directly affect the keyboard navigation order:

• tabindex="0" → The element enters the natural tabbing flow.
• tabindex="-1" → The element is excluded from the tabbing flow, but remains focusable via JavaScript.
• tabindex="1" or higher → Forces a custom tabbing order, which can break expected navigation logic.

---

Acceptance Criteria by Category

1. tabindex="-1" on Interactive Elements

Objective: Ensure that elements excluded from keyboard focus are actually hidden or have a justification.

Requirements:

• Detect all elements with tabindex="-1".
• Verify whether the element is:
  • Visually hidden via CSS (display: none, visibility: hidden, opacity: 0, etc.).

Actions:

• If any condition is met → No error is reported.
• If no condition is met → Ask the user whether the behavior is intentional.
  • If it is an error → Report as: Unfocused element with (Tab/Shift+Tab)

---

2. tabindex="0" on Non-Interactive Elements

Objective: Validate whether non-interactive elements should be part of the tabbing flow.

Requirements:

• Detect elements such as <div>, <span>, <p>, etc. with tabindex="0".
• Determine whether they act as containers for other elements that also receive focus.

Actions:

• Ask the user whether the use of tabindex="0" is intentional.
• If confirmed as an error:
  • If it is a container with multiple foci → Multiple focus on interactive controls due to nesting between them
  • If it is an individual non-interactive element → Non-interactive elements focused (Tab - Shift+Tab)

---

3. Positive tabindex on Interactive and Non-Interactive Elements

Objective: Detect cases where natural navigation order is altered through positive tabindex values.

Requirements:

• Detect positive tabindex on:
  • Interactive elements (<button>, <a>, <input>, etc.).
  • Non-interactive elements (<div>, <span>, <p>, etc.).
  • Non-interactive containers with focused children.

Actions:

• Ask the user whether the use of positive tabindex is intentional.
• If confirmed as an error:
  • For interactive elements → Focus order is not logical and intuitive in the (Tab - Shift+Tab) navigation order
  • For non-interactive elements → Non-interactive elements focused (Tab - Shift+Tab)
  • For containers with multiple foci → Multiple focus on interactive controls due to nesting between them

---

User Interaction

When the system cannot automatically determine whether the use of tabindex is correct, a confirmation interface will open for the user (auditor or expert) to indicate whether the behavior is:

• Intentional (not reported).
• An error (included in the report with the corresponding category).

---

Integration with a11ybot

• All collected data, including automatic classification and user responses, is sent to a11ybot.
• The bot integrates this information into the accessibility report alongside other findings from the automatic analysis.

---

Current Status and Future Improvements

Aspect	Current Status	Future
Contextual analysis	Partial	Planned improvement
Semantic discrimination	Limited	Planned improvement
Automatic intent evaluation	Partial	Planned improvement

---

Technical Notes

• This feature must run in the context of the active page.
• Elements are analyzed in real time when the page loads or when the scan is run manually.
• False positives must be handled appropriately through exclusions and user confirmations.

---

Conclusion

This feature is part of the comprehensive effort to improve the accessibility of our interfaces, ensuring that the keyboard navigation focus is logical, predictable, and accessible to all users. Its correct implementation and validation will allow for the detection of hard-to-identify errors and will facilitate their resolution collaboratively.