<hr>-in-<select> semantics

[annevk]

To match the visual aesthetics, perhaps sibling <hr> elements, when children of a <select> element, should be presented as one to the end user.

You can use the following data: URL for demonstration purposes (works at least in Chromium and WebKit on macOS): data:text/xml,<select%20xmlns="http://www.w3.org/1999/xhtml"><option>1</option><hr/><hr/><option>2</option></select>.

This might become more common due to whatwg/html#9124.

[scottaohara]

Per the way that AT currently behave with select elements, these HRs likely aren't going to be exposed at all to users, since users shouldn't be able to access them directly.

May be worth at least a comment in the mapping table to state as much, or that in this context they should be treated as presentational elements.

that said, this could be very different for their potential use in the proposed selectmenu - if they were to behave similarly there.
Or in my proposal to allow hr to separate li elements within a list container (ul, ol, menu)... there they'd definitely need to be exposed as one would not necessarily be only navigating by focusable elements in that case.