Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editorial: clarify summary element role mapping #434

Merged
merged 2 commits into from
Nov 2, 2022

Conversation

scottaohara
Copy link
Member

@scottaohara scottaohara commented Nov 2, 2022

Closes #355

Since the original issue was filed, and I have spent more time researching details/summary and trying to get consensus on what to do with the summary element in particular, I think it does make sense to adjust this per JAWS-test's issue. The role is now stated as "no corresponding role" since there is no direct ARIA mapping in HTML AAM, but the note was added to indicate the reality of how the role is actually mapped.

This PR contains no normative changes, as element roles are not defined by this specification.


Preview | Diff

Closes #355

Since the original issue was filed, and I have spent more time researching details/summary and trying to get consensus on what to do with the summary element in particular, I think it does make sense to adjust this per JAWS-test's issue.  The role is now stated as "no corresponding role" since there is no direct ARIA mapping in HTML AAM, but the note was added to indicate the reality of how the role is actually mapped.
index.html Outdated Show resolved Hide resolved
Copy link
Member

@patrickhlauke patrickhlauke left a comment

Choose a reason for hiding this comment

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

Seems ok to me, considering that HTML spec/user agents seem unwilling to change to disallow interactive content inside <summary>

@stevefaulkner stevefaulkner merged commit a3841fb into gh-pages Nov 2, 2022
@stevefaulkner stevefaulkner deleted the summary-role-editorial branch November 2, 2022 15:10
@JAWS-test
Copy link

@scottaohara

However, the permitted attributes still state:

... and any aria-* attributes applicable to the button role.

I suggest removing that as well, since the attributes are not meaningful (e.g. aria-haspopup) or contradict implicit attributes of the HTML element (aria-expanded)

@scottaohara
Copy link
Member Author

you're right @JAWS-test. but that will need to be considered a normative change. so we need to do that separate.

scottaohara added a commit that referenced this pull request Nov 2, 2022
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 a commit that referenced this pull request May 31, 2023
…ary element (#435)

* revise allowed attributes on summary element

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

* further clarifications for summary element allowances
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.


* updated changelog
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.

Implicit ARIA semantics for summary should not be "button"
4 participants