Element in the focus order has no matching interactive role

What is this issue?

An element is reachable by keyboard focus (it has tabindex="0" or an equivalent) but carries role="presentation", role="none", or no role at all despite behaving interactively, so its role, state, and property: the three things assistive technology needs to describe an element: its role (what kind of thing it is), its state (its current condition), and its properties (other characteristics) expose nothing about why it can receive focus.

This is a semantics gap, not a sequencing gap: the element’s position in the tab order can be perfectly correct while its announcement is empty or actively wrong. A screen reader user who tabs to it hears silence, or hears it described as decorative content that happens to be focusable; either way, they get no explanation for the Tab stop they just used.

Why does this matter?

Every Tab press is a unit of a keyboard user’s attention and time. When focus lands on an element that announces nothing (no role, no name, no indication of what pressing Enter or Space would do), the user has to guess whether it’s broken, decorative, or genuinely interactive with a missing label, and there’s no way to tell which from the announcement alone.

This compounds on pages with several such gaps: a keyboard user tabbing through a page full of unexplained stops loses trust in the tab order as a reliable map of what’s interactive, and starts treating every stop as a possible dead end worth double-checking, which slows down every single page on the site, not just the one with the defect.

Who is affected?

• Keyboard users: land on a Tab stop that gives no visual or behavioral cue for why it’s focusable, wasting a keystroke with no information gained.
• Screen reader users: hear either silence or a contradictory announcement (something explicitly marked as non-semantic, role="presentation", that nonetheless received focus), which is more disorienting than simply not being able to reach the element at all.

What users experience

Wei uses JAWS on Windows to review a dashboard at work. He tabs through a summary card and reaches an inner <div> with tabindex="0" and role="presentation", added by a previous developer to make the whole card “feel clickable” during a hover-highlight experiment that was later abandoned. JAWS announces nothing at all for that stop; the screen reader reads silence, then moves to the next real control. Wei assumes his screen reader glitched, tabs back to double-check, and loses several seconds confirming there’s nothing there before continuing: on every card, on every visit to the page.

How do I fix it?

Give the element a real interactive role that matches what happens when it receives focus and gets activated (role="button" for something that triggers an action, role="link" for something that navigates) so the announcement finally explains why the element is a Tab stop. This works because assistive technology’s announcement is built entirely from the exposed role, name, and state; once the role accurately describes the element’s actual behavior, the mismatch disappears.

If the element genuinely isn’t interactive (leftover from a removed feature, or added defensively “just in case”), remove tabindex entirely instead. This is the simpler and more common fix in practice: an element with no real interactive purpose doesn’t belong in the tab order at all, and removing it there is both less code and a cleaner outcome than inventing a role for something that does nothing.

Code Examples

<div tabindex="0" role="presentation">
  <h3>Q3 Revenue</h3>
  <p>$482,000</p>
</div>

<!-- Method 1: give it a real role, if it's genuinely interactive -->
<div tabindex="0" role="button" aria-label="View Q3 revenue details">
  <h3>Q3 Revenue</h3>
  <p>$482,000</p>
</div>

<!-- Method 2: remove it from the tab order, if it isn't interactive at all -->
<div>
  <h3>Q3 Revenue</h3>
  <p>$482,000</p>
</div>

Method 1 keeps the card in the tab order but replaces the contradictory role="presentation" with a role that matches its actual behavior, so a screen reader now announces “View Q3 revenue details, button” instead of nothing. Method 2 accepts that the card was never meant to be a Tab stop and removes the attribute causing the problem at its source, which is the right call whenever the card doesn’t actually do anything when activated.

Common Mistakes

Mistake: “I added tabindex=‘0’ to make the card feel more interactive, and role=‘presentation’ to keep it visually unstyled by assistive tech.” role="presentation" doesn’t change visual styling for sighted users at all; CSS controls that independently. It tells assistive technology to strip the element’s semantics entirely, which directly contradicts making it keyboard-focusable at the same time. The two attributes are working against each other, not toward the same goal.

Mistake: “It’s fine because sighted mouse users never see a problem.” The element renders and behaves normally for anyone not using a screen reader, which is exactly why this defect survives visual QA passes: nothing looks wrong on screen. The failure is entirely in what assistive technology announces, which visual inspection can’t catch.

Mistake: “Removing tabindex is always the safer fix, so just remove it everywhere this shows up.” Removing tabindex is safe only when the element genuinely does nothing. If the element does trigger real functionality on click, removing tabindex doesn’t fix the semantics gap; it hides working functionality from keyboard users entirely, which is a more severe failure than the one you started with.

How RedFlag Detects This

Automated: axe-core rule, runs on every scan. RedFlag calls axe-core’s focus-order-semantics rule as part of every scan, restricted to the WCAG 2.0/2.1/2.2 A and AA rule set (extension/content.js’s AXE_SCAN_OPTIONS). The rule inspects elements present in the tab order and flags any whose role (explicit via an ARIA role attribute, or implicit from the element type) gives assistive technology no coherent interactive semantics for a focusable element.

False negative: axe-core checks the role attribute’s presence and validity; it can’t judge whether the role that is present accurately describes what the element actually does when activated, so a focusable <div role="button"> that does nothing on click or Enter passes this check even though it’s still confusing to use. False positive: none typical for this specific role/focusability mismatch, since the condition axe-core evaluates is structural. Manual step: Tab to every flagged element and confirm what a screen reader announces makes sense given what pressing Enter or Space actually does.

Manual Testing

1. Open the page in Chrome or Firefox with NVDA or VoiceOver running.
2. Tab through the page and note every stop where the announcement is silent, generic, or contradicts what you can see on screen (for example, “presentation” or nothing announced for something that visually looks clickable).
3. For each flagged stop, check the DOM (browser DevTools → Elements → Accessibility pane) for its tabindex and role attributes.
4. Press Enter and Space at that stop and confirm whether anything actually happens; that tells you whether the fix is a real role or removing tabindex entirely.
5. Re-test with the screen reader after the fix and confirm the announcement now matches the element’s actual behavior.

Related WCAG Success Criteria

2.4.3 Focus Order: Components must receive focus in an order that preserves meaning and operability. This rule is a narrower slice of that requirement: the order can be entirely correct while an individual stop within it still fails to preserve operability, because its semantics don’t explain what it is.

4.1.2 Name, Role, Value: Every interface component must expose a name, role, and current value to assistive technology. A focusable element with a contradictory or missing role fails 4.1.2 at the exact moment it receives focus, which is why this rule sits at the intersection of both criteria rather than belonging cleanly to just one.

Related Issues

Element has a positive tabindex is a related but distinct focus-order defect; that page covers an element landing in the wrong position in the sequence, while this page covers an element landing in the right position with no explanation once it gets there.

Manual check flagged an incorrect tab order and Tab order doesn’t match visual order both cover sequence-level problems (where focus goes), which commonly get investigated in the same keyboard walkthrough as this rule’s semantics-level problem.

Modal opens without moving focus into it and Modal is missing focus management cover focus-management defects in the same 2.4.3 Focus Order family, specific to dialog lifecycles rather than individual elements.

Interactive controls are nested inside each other often surfaces during the same keyboard walkthrough as this rule: a nested control creates a focus stop the accessibility tree can’t cleanly represent, which is exactly the kind of unexplained stop this page’s semantics check is designed to catch.

References

• W3C Understanding 2.4.3: Focus Order
• W3C Understanding 4.1.2: Name, Role, Value
• MDN: ARIA role attribute
• ARIA Authoring Practices: Button Pattern