jQuery UI Tabs Creates Nested Focusable Elements Violating WCAG 2.1 AA

[Nikhil-porter]

jQuery UI Tabs widget generates invalid ARIA markup that creates nested interactive elements, causing multiple accessibility violations including:

• Nested focusable elements (<li> and <a> both focusable)
• Invalid ARIA role hierarchy
• Screen reader announcement conflicts
• Keyboard focus management issues

Technical Details
Current Problematic Output

<ul role="tablist">
  <li role="tab" tabindex="0" aria-selected="true">
    <a href="#tab1" class="ui-tabs-anchor">Tab 1</a>
  </li>
</ul>

<li role="tab" tabindex="0">is focusable
Child <a> element receives focus events
Creates ambiguous focus target for assistive technologies
Invalid ARIA Role Inheritance
Parent <li> has role="tab"
Child <a> has no role but receives focus
Breaks expected ARIA tab pattern
Programmatic Focus Issues

jQuery UI internally adds tabindex="0" to LIs via _tabindex() method
Manual removal of tabindex is overwritten during widget refresh
Keyboard navigation events conflict between LI and anchor

[octavpo]

I'm seeing the same issue from axe-core DevTools accessibility checker. This has been reported before and the reason I've seen given for why it's not fixed is that removing the tags would lose a nice current feature where if you right-click on it and choose something like 'Open link in a new tab', it will open the page in a new browser tab with the other tab selected. In my view that's a "nice to have" feature, while accessibility is a requirement these days.

One way I could see this addressed is to add a new option named something like 'tab', which would have a selector that identifies two things at the same time: the elements to use as tabs (so they'll get the 'tab' role) and the property that makes the link between tabs and tab panels. So the value for the current implementation would be 'a[href]', but if we leave the elements out and add a let's say 'data-panel' attribute to 'li' elements, we could specify 'li[data-panel]' as the value.

This wouldn't completely leave the current implementation unchanged, as it would also move the 'tab' roles to the elements for the default value, I'm not sure if that's an issue. If it is maybe two separate options could work (one for identifying the 'tab' elements, one for identifying the link properties).