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

Consider allowing <hr> within list elements (ol, ul, menu) #9126

Open
scottaohara opened this issue Apr 5, 2023 · 2 comments
Open

Consider allowing <hr> within list elements (ol, ul, menu) #9126

scottaohara opened this issue Apr 5, 2023 · 2 comments
Labels
a11y-tracker Group bringing to attention of a11y, or tracked by the a11y Group but not needing response. accessibility Affects accessibility addition/proposal New features or enhancements document conformance

Comments

@scottaohara
Copy link
Collaborator

I saw that #9124 was made today, and it reminded me that I had been wanting to file this issue for some time.

Late last year, I was working with developers who wanted to 'group' their list items, but did not want to include nested lists as they reasonably did not want to expose 3 nested lists within a larger list. Rather, as they were visually delineating the groupings of list items by a horizontal separator, they thought to use an hr element. But as that was not valid HTML, they then did <li role=separator>. But that role is also an invalid child of a list element, or element with role=list.

Their other option was to nest the hr within an li element, but that included it in the total count of list items, which was not their intent.

They finally settled on <li aria-hidden=true><hr></li> to mitigate the validation errors, and to ensure the separator did not contribute to the list item count total, but at the loss of exposing any separator semantics.

As HTML updated to allow div to group dt and dd elements, and per the mentioned PR #9124 to allow hr within select, it seems reasonable that ol, ul and menu elements should also allow hr as a way to separate li elements into 'groups'. There doesn't appear to be a parsing issue with this now, but as my testing (from oct 2022) shows, there are presently some inconsistencies with how AT handles the separator. But these inconsistencies could be ironed out if this was an allowed pattern, as opposed to the current behavior which is essentially mitigating author 'error'.

@annevk annevk added addition/proposal New features or enhancements document conformance accessibility Affects accessibility a11y-tracker Group bringing to attention of a11y, or tracked by the a11y Group but not needing response. labels Apr 5, 2023
@iDad5
Copy link

iDad5 commented Oct 17, 2023

I'm not sure if this is the right place to address my thoughts, so please excuse if I’m doing it wrong, and please don't hesitate to guide me into a better direction.
I strongly second this proposal, but I'd like to suggest that a more flexible/powerful separator element inside list elements would be preferable.

In case you have a list of – for example – events that happen regularly, a separator that marks the start of a year or month could be very useful.
Splitting the list, in my opinion, isn't semantically correct as the list elements are of the exact same nature, regardless of the date they are held. If the list gets long, a separator that can hold useful information like the year in my case would be preferable to a simple


.

@shannonmoeller

This comment was marked as spam.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a11y-tracker Group bringing to attention of a11y, or tracked by the a11y Group but not needing response. accessibility Affects accessibility addition/proposal New features or enhancements document conformance
Development

No branches or pull requests

4 participants