-
Notifications
You must be signed in to change notification settings - Fork 48
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
Conversation
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.
There was a problem hiding this 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>
However, the permitted attributes still state:
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) |
you're right @JAWS-test. but that will need to be considered a normative change. so we need to do that separate. |
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).
…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
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