Correction: conditionally revise allowed attributes and roles on summary element - #435
Merged
Merged
Conversation
Normative follow-on from #434 The spec was updated to note that the summary element doesnt' always map to the button element. The allowed attributes indicated that all attributes that were applicable to the button role were allowed. However, in practice this doesn't make sense and could break or be in contradiction to the implicit semantics. The allowed aria-* attributes for the button role include * aria-disabled * aria-haspopup * aria-expanded * aria-pressed Of those four, aria-expanded and pressed are the ones that would pose problems by conflicting or not making any sense with the implicit expanded/collapsed states provided by the element (who gets the state per the parent details having an open attribute or not).
scottaohara
added
needs implementation commitment
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
stevefaulkner
approved these changes
Feb 6, 2023
move to the parent paragraph element, rather than being on a child span.
this addition to the PR takes into account that only a summary element that serves as the 'summary for its parent details' needs to adhere to these rules. otherwise, a summary element that doesn't meet the criteria of the HTML spec is essentially just a generic element, so any roles/attributes can be used on that.
scottaohara
changed the title
scottaohara
added
Allowed roles
removed extra instance of nested "proposed correction" classes within an element that already had these classes
This was referenced Feb 13, 2023
scottaohara
added
Meets 2 implementations req
This was referenced Jul 1, 2025
chutchins25
added a commit
to dequelabs/axe-core
that referenced
this pull request
Jul 29, 2026
A summary that is not its parent details element's disclosure trigger is exposed as generic and may take any role. A summary that is the details summary continues to allow no explicit role. Per ARIA in HTML (w3c/html-aria#435). The attribute-side of the spec change (disallowing aria-expanded and aria-pressed on a details summary) is tracked separately in #5241. Closes #3911
straker
added a commit
to dequelabs/axe-core
that referenced
this pull request
Aug 4, 2026
Updates the roles allowed on a `<summary>` element based on whether it is its parent `<details>` element's disclosure trigger, per the ARIA in HTML update. ## What & why Per [ARIA in HTML](https://www.w3.org/TR/html-aria/) (`#el-summary`, [w3c/html-aria#435](w3c/html-aria#435)): - A `summary` that **is** the "summary for its parent `details`" (the first `summary` child of a `details`) allows **no explicit role** — browsers expose it as the disclosure trigger. - A `summary` that is **not** the details summary (standalone, or a 2nd+ `summary`) is exposed as generic and allows **any role**. axe previously modeled `summary` with an unconditional `allowedRoles: false`. This converts it to a `variant` using a `condition` matcher (the same pattern introduced for `figure` in #3443). ## Scope — role side only Issue #3911 covers both the allowed **roles** and the allowed **`aria-*` attributes** for `summary`. This PR implements the **role** side. The attribute side (the spec disallows `aria-expanded`/`aria-pressed` on a details-summary) is intentionally deferred — it requires an element-level disallowed-attribute mechanism axe does not have today, and is tracked in **#5241**. ## Behavior change A standalone / non-details `<summary>` now permits **any** role, where previously only the implicit `button` role was allowed. This is a spec-correct loosening; a `<details>`-summary's role handling is unchanged in effect (still restricted to its implicit `button` role). ## Tests - `get-element-spec` unit — variant resolution for the three cases (details summary, non-first summary, standalone). - `aria-allowed-role` check unit — incl. an open **Shadow DOM** case. - `aria-allowed-role` virtual-rule — details/summary structures built with `SerialVirtualNode`, incl. the no-parent default. - `aria-allowed-role` integration HTML/JSON — first-summary fail, 2nd-summary pass, standalone pass, implicit-button pass. Closes #3911 --------- Co-authored-by: Steven Lambert <2433219+straker@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Normative follow-on from #434
The spec was updated to note that the summary element doesnt' always map to the button element. The allowed attributes indicated that all attributes that were applicable to the button role were allowed. However, in practice this doesn't make sense and could break or be in contradiction to the implicit semantics.
The allowed aria-* attributes for the button role include
Edit: after testing,
aria-expandedandaria-pressedprovide zero value on asummaryelement, as they are presently ignored by user agents (browsers/AT). https://codepen.io/scottohara/pen/ZEjZPoRmarkup and results of linked codepen
Concerning the allowed roles for a summary element. A summary element can be one of two things, the 'summary for its parent details' - where it acts as the triggering element for the disclosure widget. Or, if it doesn't meet the conditions to be that (e.g., it is not a child of a details element, or it is not the first instance of a summary element - e.g., it's the 2+ summary element within a details), then it is treated as a generic element, so any role/attribute should be allowed.
test cases - https://w3c.github.io/html-aria/tests/summary-allowances.html
(linked issues to each checker referenced in the following thread)
Preview | Diff