Repository navigation
1.3.1 minimum semantics for groups of details / summary elements
#5193
Unanswered
detlevhfischer
asked this question in
Q&A
Replies: 3 comments
|
I would not require extra list semantics, no. If an author chooses to do it (seems like overkill to me), fine. but not a fail if they don't do it. |
0 replies
|
I agree about not adding list semantics. Depending on the circumstances, I might enclose the set of disclosure elements in a div element with role=”group” and an appropriate aria-label attribute, but I would not regard this as essential.
Steve Green
Managing Director
Test Partners Ltd
|
0 replies
|
This may be too specific, but since the |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
The quirks of
details/summaryhave been well described by @scottaohara in his articles The details and summary elements and The details and summary elements, again. My question concerns the overall semantics when severaldetails/summaryelements are used in content (think of a list of FAQs). Then the question arises what semantics we can expect authors to implement above the disclosure functionality, i.e. above the output as a series of buttons with expanded state. Sincesummarymaps in many browsers tobutton, it will flatten / remove any headings semantics we would want to use insidesummary. Would you expect or even mandate list markup for a group of several details/summary elements to provide info on the number of elements in the group and a way to jump past that section? My hunch is no, not using markup beyonddetails/summarywouldn't fail 1.3.1, but I'd like to hear other folks' opinions.All reactions