conflicting-focus-management-methods
Web validation
Composite widgets such as tab lists rely on predictable keyboard focus. Mixing two focusable targets in one widget breaks that predictability. When the container and an item both sit in the tab sequence, keyboard users must Tab twice for the same control, and assistive technology can announce the same thing twice. Keeping a single real focus location maintains a logical focus order and clear announcements.
Pass Patterns
Container holds focus with aria-activedescendant
Only the container is focusable, and aria-activedescendant points to the virtually focused item.
<div role="tablist" aria-activedescendant="tab_1" tabindex="0">
<div role="tab" id="tab_1" aria-controls="panel_1" aria-selected="true">Tab 1</div>
<div role="tab" id="tab_2" aria-controls="panel_2" aria-selected="false">Tab 2</div>
</div>One item is focusable with roving tabindex
One tab is tabbable at a time and the container is skipped, so there is a single focus target.
<div role="tablist">
<div role="tab" tabindex="0" aria-controls="panel_1" aria-selected="true">Tab 1</div>
<div role="tab" tabindex="-1" aria-controls="panel_2" aria-selected="false">Tab 2</div>
</div>Fail Patterns
Container and an item are both focusable
The container has tabindex="0" with aria-activedescendant, and a tab also has tabindex="0", so the two focus methods conflict.
<div role="tablist" aria-activedescendant="tab_1" tabindex="0">
<div role="tab" id="tab_1" tabindex="0" aria-controls="panel_1" aria-selected="true">Tab 1</div>
<div role="tab" id="tab_2" tabindex="-1" aria-controls="panel_2" aria-selected="false">Tab 2</div>
</div>Try It Yourself
Using a keyboard
- Load the page and press Tab until you reach the tab list.
- Press Tab again.
- Watch where focus lands.
Expected results: Focus lands on the widget once, then arrow keys move between tabs.
Actual results: Focus stops on the container and again on a tab, adding an extra stop.
Using a screen reader
New to screen reader testing, or need a refresher?
Review this article first: Practical guides for using screen readers
- Load the page and open a screen reader.
- Move to the tab list with the Tab key.
- Arrow through the tabs and listen to what is announced.
Expected results: Each tab is announced once.
Actual results: The container and a tab are announced separately, which is confusing.
FAQ
How does this issue relate to 2.4.3 Focus Order?
SC 2.4.3 requires that focusable components receive focus in an order that preserves meaning and operability. When a composite widget exposes two focus targets, keyboard users hit an extra, redundant stop, and the container's aria-activedescendant can point to one item while real focus sits on another, so the focus sequence no longer reflects a single, predictable location.
Why is this issue marked as Moderate?
Conflicting focus targets make a widget less predictable for keyboard and assistive technology users, adding extra Tab stops and duplicate announcements. It usually slows navigation rather than blocking it, so the severity is moderate.
Standards and Regulations
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 2.4.3 Focus Order (A) | If a web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. |
| EN 301 549 | 9.2.4.3 Focus Order | Same as the WCAG text. |
| 508 Trusted Tester | 2.4.3-focus-order-meaning, 4.F | The focus order preserves the meaning and operability of the web page. |