Product

axe-core

Product Version

4.10.2

Latest Version

• I have tested the issue with the latest version of the product

Issue Description

A common pattern with tab panels is for the panel to be focusable, but not clickable. The tab panel in this case isn't a "target" for the purposes of 2.5.5/2.5.8 because it doesn't respond to pointer events. However, because axe-core currently considers tabpanel to be a widget role type, the target-offset check considers a focusable tabpanel to be a target.

I think the fix for this is likely to update aria-roles.js to treat tabpanel as a structure role rather than a widget role. The ARIA spec is ambiguous about which is correct (wai-aria-1.2 §5.3.2 Widget Roles says that tabpanel is a widget, but the tabpanel role section says it rolls up to section/structure), but I think in practice structure is more accurate and would fix the false positive here.

Expectation

When an interactive target is contained in a focusable tabpanel, it shouldn't cause target-offset violations.

Actual

Axe reports a violation.

How to Reproduce

<div role="tabpanel" tabindex="0">
  <h2>My cool tabpanel content</h2>
  <input id="target" type="checkbox">A checkbox inside the focusable tabpanel</input>
</div>

await axe.run('#target', { runOnly: 'target-size' })

Additional context

I think we meant to address this in #4371 / #4421, but missed it due to the ambiguity in the ARIA spec mentioned above.