fix(aria-allowed-role): allow li roles under non-list parents by MohammediYunus · Pull Request #5457 · dequelabs/axe-core · GitHub
Skip to content

fix(aria-allowed-role): allow li roles under non-list parents - #5457

Closed
MohammediYunus wants to merge 1 commit into
dequelabs:developfrom
MohammediYunus:fix/li-non-list-parent-roles
Closed

MohammediYunus wants to merge 1 commit into
dequelabs:developfrom
MohammediYunus:fix/li-non-list-parent-roles

Conversation

@MohammediYunus

Copy link
Copy Markdown

List items used as tab panels are reported by aria-allowed-role even when their parent has no list semantics. This fixes the presentational list pattern in #4910 by allowing arbitrary roles only when the immediate represented parent is known not to have the list role.

Native and explicit list restrictions, presentation conflicts, role-token precedence, custom-element roles and unknown-parent behavior remain covered. Parent classification avoids accessible-name lookup, which can recurse through the child being checked. The patch adds matcher, standards, serialized-tree and HTML/JSON regressions, including shadow DOM cases.

Validation:

  • Build, TypeScript, formatting, lint and the Node/jsdom test scripts pass.
  • Eight new regressions fail on the original bundle and pass with the fix. The focused Chromium runs pass 167 unit/virtual tests and 19 rule-fixture assertions.
  • All eight browser groups were attempted in local Chromium: 8,806 passed, 101 skipped. Five assertion failures and one existing fixture hook timeout blocking 134 assertions also reproduce against the original bundle. The failures concern selector generation, object loading, shadow ID references and target offsets.
  • The full test command exits 1 after the first failing group; the remaining seven groups were run separately with continue-on-error. These runs use the original WTR assertions and timeouts with a local passive browser launcher and a content-hash bundle URL. No runner or existing test expectation changes are included. Stock Selenium and Firefox remain unverified.
  • A broader selected jsdom run passes 469 tests with two fixture errors because setHTMLUnsafe is unavailable; those shadow cases pass in Chromium.

Closes: #4910

Allow roles such as tabpanel on li when the immediate represented parent
has no list semantics. Preserve restrictions when the parent is a list
or its context is unknown, and avoid accessible-name recursion during
parent classification.

Cover role-token fallback, presentation conflicts, custom elements and
shadow trees with matcher, standards, virtual and HTML/JSON regressions.

Closes: dequelabs#4910
@MohammediYunus
MohammediYunus requested a review from a team as a code owner October 9, 2026 04:08

@straker straker left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the pr. Unfortunately I don't think we should merge it in as is. Ideally we'd want to use getRole in the matcher in order to resolve the role of the parent, but we can't at the moment and I don't want to duplicate all the same logic as in is-sectioning-content to work around the issue.

I think until we implement #5263 we shouldn't work on fixing this bug.

@straker straker closed this Oct 13, 2026
@MohammediYunus

Copy link
Copy Markdown
Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

False positive on Splide li's - "aria role should be appropriate for the element"

2 participants