Description
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.