Splitting within Selects

By admin
Splitting within Selects

Updated

October 28, 2023
DATE

, originally posted

October 23, 2023
DATE

;

3
CARDINAL

Comments

The native HTML <select> is renowned for its styling limitations. Even with control over the closed state and trigger appearance, the options themselves are still defined primarily by the browser and the OS. While I think this is generally fine (preferred, even), the <selectlist> (nee <selectmenu> ) hopes to change that.

But until that happens,

Apple
ORG

and

Google
ORG

feel it is important to:

…add <hr> (horizontal rule) elements into the list of select options and they will appear as separators to help visually break up the options for a better user experience. Select element: now with horizontal rules,

Monday
DATE

,

23 October 2023
DATE

This feature is not the same as <optgroup> . Whether or not that matters for you depends on your use case and needed support.

Since some may consider me a bit of an accessibility curmudgeon, I am going to try to limit my own opinions in this post and report current behavior.

Demo

I made a demo to compare these

two
CARDINAL

methods for splitting options.

The

first
ORDINAL

is from

the Google Chrome’s
ORG

Select element: now with horizontal rules . This case is for when you want to offer a visual cue to group options together, but don’t feel you need to convey those groups to all users.

The

second
ORDINAL

is from

MDN
ORG

’s <optgroup> : The

Option Group
ORG

element . This case is when you want to both group options and name the groups, both visually and programmatically.

You can also visit the demo directly.

Key for the icons used in the lists that follow:

Good, meaning it works well for everyone;

Fine, but could be improved;

Caution, has issues but may be ok in some cases;

Buggy, probably avoid.

Using <hr>

My sample code:

<select name="majors" id="major-select"> <option value="">Select a major</option> <hr> <option value="arth">Art History</option> <option value="finearts">Fine Arts</option> <option value="gdes">Graphic Design</option> <option value="lit">Literature</option> <option value="music">Music</option> <hr> <option value="aeroeng">Aerospace Engineering</option> <option value="biochemeng">Biochemical Engineering</option> <option value="civileng">Civil Engineering</option> <option value="compeng">Computer Engineering</option> <option value="eleng">Electrical Engineering</option> <option value="mecheng">Mechanical Engineering</option> <hr> <option value="polysci">Political

Science</option>
PERSON

<option value="intr">International Relations</option> <option value="bizdev">Business Development</option> <hr> <option value="math">Mathematics</option> <option value="econ">Economics</option> <option value="stat">Statistics</option> </select>

The tests are a bit unfair since I am using current and older versions of

Firefox
ORG

, a beta release of

Chrome
ORG

, and the latest

Safari
ORG

.

Desktop

Firefox

118
CARDINAL

/ Windows

11
CARDINAL

:

does not expose the <hr> visually in the page;

visually in the page; does not expose the <hr> programmatically in the rendered

DOM
ORG

;

programmatically in the rendered

DOM
ORG

; does not expose the <hr> within the accessibility tree;

within the accessibility tree; does not announce the <hr> when using

NVDA
ORG

;

when using

NVDA
ORG

; has no contrast concern since it does not appear.

Firefox

115
CARDINAL

/ Ubuntu 22.04.2 LTS:

does not expose the <hr> visually in the page;

visually in the page; does not expose the <hr> programmatically in the rendered

DOM
ORG

;

programmatically in the rendered

DOM
ORG

; does not expose the <hr> within the accessibility tree;

within the accessibility tree; does not announce the <hr> when using

NVDA
ORG

;

when using

NVDA
ORG

; has no contrast concern since it does not appear.


Chrome Canary
PERSON

(

120
CARDINAL

) / Windows

11
CARDINAL

:

exposes the <hr> visually in the page only when the menu is expanded (arrowing within the collapsed menu does not show them);

visually in the page only when the menu is expanded (arrowing within the collapsed menu does not show them); exposes the <hr> programmatically in the rendered

DOM
ORG

;

programmatically in the rendered

DOM
ORG

; does not expose the <hr> within the accessibility tree;

within the accessibility tree; does not announce the <hr> when using

JAWS
ORG

;

when using

JAWS
ORG

; has sufficient contrast since it matches the text color.


Safari
PERSON


17
CARDINAL

/ macOS

14.0
CARDINAL

:

exposes the <hr> visually in the page (arrowing within the collapsed menu expands it);

visually in the page (arrowing within the collapsed menu expands it); exposes the <hr> programmatically in the rendered

DOM
ORG

;

programmatically in the rendered

DOM
ORG

; does not expose the <hr> within the accessibility tree;

within the accessibility tree; does not announce the <hr> when using VoiceOver;

when using VoiceOver; has insufficient contrast (

1.3:1
CARDINAL

), though the spacing arguably does the job.


Mobile
GPE

Firefox

118
CARDINAL

/ Android

13
CARDINAL

:

does not expose the <hr> visually in the page;

visually in the page; does not announce the <hr> when using TalkBack;

when using TalkBack; has no contrast concern since it does not appear.


Chrome Canary
PERSON

(

120
CARDINAL

) / Android

13
CARDINAL

:

exposes the <hr> as its own empty selectable option;

as its own empty selectable option; does not announce the <hr> when using TalkBack, but is a swipe-stop;

when using TalkBack, but is a swipe-stop; has unknown contrast since it is blank.


Safari
PERSON

17 / iPadOS 17.0.3:

does not expose the <hr> visually in the page;

visually in the page; does not announce the <hr> when using VoiceOver, because it is not in the page;

when using VoiceOver, because it is not in the page; has unknown contrast since it is blank.

Using <optgroup>

My sample code:

<select id="dino-select"> <optgroup label="Theropods"> <option>Tyrannosaurus</option> <option>Velociraptor</option> <option>Deinonychus</option> </optgroup> <optgroup label="Sauropods"> <option>Diplodocus</option> <option>Saltasaurus</option> <option>Apatosaurus</option> </optgroup> </select>

The tests are a bit unfair since I am using current and older versions of

Firefox
ORG

, a beta release of

Chrome
ORG

, and the latest

Safari
ORG

.

Desktop

Firefox

118
CARDINAL

/ Windows

11
CARDINAL

:

exposes the <optgroup> visually in the page only when the menu is expanded (arrowing within the collapsed menu does not show them);

visually in the page only when the menu is expanded (arrowing within the collapsed menu does not show them); exposes the <optgroup> programmatically in the rendered

DOM
ORG

;

programmatically in the rendered

DOM
ORG

; exposes the <optgroup> within the accessibility tree;

within the accessibility tree; announces the <optgroup> when using

NVDA
ORG

if I expand the control;

when using

NVDA
ORG

if I expand the control; has sufficient contrast since it matches the text color.

Firefox

115
CARDINAL

/ Ubuntu 22.04.2 LTS:

exposes the <optgroup> visually in the page only when the menu is expanded (arrowing within the collapsed menu does not show them);

visually in the page only when the menu is expanded (arrowing within the collapsed menu does not show them); exposes the <optgroup> programmatically in the rendered

DOM
ORG

;

programmatically in the rendered

DOM
ORG

; exposes the <optgroup> within the accessibility tree;

within the accessibility tree; does not announce the <optgroup> when using

Orca
PERSON

if I expand the control;

when using

Orca
PERSON

if I expand the control; has sufficient contrast since it matches the text color.


Chrome Canary
PERSON

(

120
CARDINAL

) / Windows

11
CARDINAL

:

exposes the <optgroup> visually in the page only when the menu is expanded (arrowing within the collapsed menu does not show them);

visually in the page only when the menu is expanded (arrowing within the collapsed menu does not show them); exposes the <optgroup> programmatically in the rendered

DOM
ORG

;

programmatically in the rendered

DOM
ORG

; does not expose the <optgroup> within the accessibility tree;

within the accessibility tree; does not announce the <optgroup> when using

JAWS
ORG

;

when using

JAWS
ORG

; has sufficient contrast since it matches the text color.


Safari
PERSON


17
CARDINAL

/ macOS

14.0
CARDINAL

:

exposes the <optgroup> visually in the page (arrowing within the collapsed menu expands it);

visually in the page (arrowing within the collapsed menu expands it); exposes the <optgroup> programmatically in the rendered

DOM
ORG

;

programmatically in the rendered

DOM
ORG

; does not expose the <optgroup> within the accessibility tree;

within the accessibility tree; announces the <optgroup> as “dimmed” when using VoiceOver;

as “dimmed” when using VoiceOver; has insufficient contrast (

1.4:1
CARDINAL

), making the text essentially useless to low vision users.


Mobile
GPE

Firefox

118
CARDINAL

/ Android

13
CARDINAL

:

exposes the <optgroup> visually in the page;

visually in the page; announces the <optgroup> as “disabled” when using TalkBack;

as “disabled” when using TalkBack; has insufficient text contrast (

2.9:1
CARDINAL

).


Chrome Canary
PERSON

(

120
CARDINAL

) / Android

13
CARDINAL

:

exposes the <optgroup> visually in the page;

visually in the page; announces the <optgroup> when using TalkBack, but is an unselectable swipe-stop;

when using TalkBack, but is an unselectable swipe-stop; has sufficient contrast since it matches the text color.


Safari
PERSON

17 / iPadOS 17.0.3:

exposes the <optgroup> visually in the page;

visually in the page; announces the <optgroup> when using VoiceOver, but is an unselectable swipe-stop;

when using VoiceOver, but is an unselectable swipe-stop; has insufficient text contrast.

History

Because it is interesting to see how standards and browsers move, sometimes in lockstep and sometimes not, I did a little digging. This is also a good indicator of priorities.

<hr> in <select>

Way back in

2005
DATE

,

Safari 2.0.2
ORG

added support for <hr> in <select> , even though it was not to spec. It was so popular that nobody remembered. It also did not work without

JavaScript
ORG

, as

Kent Tamura
PERSON

noted in

2012
DATE

with Bug 80686 – HTML parser: allow <hr> to be used inside <select> as a separator where it languished for

eleven years
DATE

.

On

26 January 2018
DATE

,

Eric Shepherd
PERSON

filed #1156: Proposal: Allow adding separator rows to <select> boxes using <hr> against the W3C HTML specification. It was closed

six months later
DATE

after a decision that it was a layout issue and outside the domain of HTML.

On

the same day
DATE

,

Eric Shepherd
PERSON

also filed the same issue against the

WHATWG
PERSON

HTML specification as #3410: Proposal: Allow adding separator rows to <select> boxes using <hr>. In

April 2021
DATE


Sam Sneddon
PERSON

discovered the code was in

WebKit
ORG

(and

Blink
PERSON

) dating back to

2005
DATE

.

On

5 April 2023
DATE

,

Anne van Kesteren
PERSON

(

Apple
ORG

) opened WebKit pull request #

12407
MONEY

HTML parser: allow <hr> to be used inside <select> as a separator, updating that

2012
DATE

bug report at the same time. On

the same day
DATE

,

Anne van Kesteren
PERSON

(

Apple
ORG

) opened #

9124
MONEY

Allow <hr> to be used inside <select> as a separator against

WHATWG
PERSON

HTML.

27 days later
DATE

on

2 May 2023
DATE


Anne van Kesteren
PERSON

(

Apple
ORG

) merged it (see the current

WHATWG
PERSON

HTML entry for the <select> element).

Mason Freed
ORG

noted there is no Web Platform Test for it.

Also on

2 May 2023
DATE

,

Anne van Kesteren
PERSON

opened

#480 Document
MONEY

<

hr>-in-<select
PERSON

> against the W3C HTML Accessibility API Mappings (HTML-AAM) spec.

Scott O’Hara
PERSON

merged PR

#504
MONEY

Update: hr within select element on

9 October 2023
DATE

. Read that thread for a little sausage-making insight.

Also also on

2 May 2023
DATE

,

Anne van Kesteren
PERSON

filed issue #

26536
MONEY

Document <

hr>-in-<select
PERSON

> to add the just-merged WHATWG HTML change to the

MDN
ORG

HTML documentation. That issue is still open.

Also also also on

2 May 2023
DATE

,

Anne van Kesteren
PERSON

filed #

1830909
MONEY

Implement <hr>-in-<select> against Firefox. That issue is still open.


WebKit Features
PRODUCT

in

Safari 17.0
ORG

was posted on

18 September 2023
DATE

, where it announced this new feature of both the browser and HTML. Without noting support issues (decisions) in VoiceOver.

On

19 September 2023
DATE

,

Joey Arhar
PERSON

(

Google
ORG

) announced Intent to Ship: Horizontal rules inside select elements for

Blink
PERSON

(Chrome). The specification reference was the WHATWG HTML Pull Request (not the spec itself). The justification was that

Blink
PERSON

’s inherited WebKit had this (broken) code already and that

Safari 17
ORG

had just announced it as a new feature. The

interopability
ORG

and compatibility notes pointed to

Safari
ORG

, but noted no signal from

Mozilla
ORG

and no signal from web developers.

On

20 September 2023
DATE

,

Joey Arhar
PERSON

opened #

887
MONEY

Allow <hr> tags inside <select> tags against

the Mozilla Standards Position
LAW

repo. It was closed on

2 October 2023
DATE

as “positive” (meaning

Mozilla
ORG

is on board). I can find no implementation timeline, but thanks to a pointer from

Jamie Teh
PERSON

, we can see it is in progress as of

24 September 2023
DATE

.


Jamie Teh
PERSON

also gave some insight into option counts in

Firefox
ORG

related to grouping via separators.

To recap:


2005
DATE

:

Safari 2.0.2
ORG

adds support for <hr> in <select> , which is not allowed by HTML.

in , which is not allowed by HTML.

2018
DATE

: W3C HTML feature request added to allow this, W3C closes as outside scope of HTML.


2018
DATE

:

WHAWTG
NORP

HTML feature request added to allow this, no action taken.


5 April 2023
DATE

:

Apple
ORG

opens

WebKit
ORG

PR to allow <hr> in <select> .

in .

5 April 2023
DATE

:

Apple
ORG

opens

WHATWG HTML
ORG

PR to allow <hr> in <select> .

in .

2 May 2023
DATE

:

Apple
ORG

rep merges

WHATWG HTML PR
ORG

(sans Web Platform Test).


2 May 2023
DATE

:

Apple
ORG

files issue against

HTML-AAM
ORG

.


2 May 2023
DATE

:

Apple
ORG

files issue to add <hr> in <select> to MDN documenation.

in to

MDN
ORG

documenation.

2 May 2023
DATE

:

Apple
ORG

files issue to add <hr> in <select> to Firefox.

in to

Firefox
ORG

.

18 September 2023
DATE

:

Apple
ORG

announced

Safari 17
ORG

supports <hr> in <select> .

in .

19 September 2023
DATE

:

Google
ORG

announces intent to ship <hr> in <select> .

in .

20 September 2023
DATE

:

Google
ORG

filed issue against

Mozilla Standards Position
ORG

repo.


24 September 2023
DATE

:

Mozilla
ORG

starts work.

<optgroup>

I have a lot less history here.

The <optgroup> element was in

HTML 4.01
LAW

, which became a W3C Recommendation on

24 December 1999
DATE

.

A very quick search in the

WebKit
ORG

bug tracker resulted in Bug

175817
CARDINAL

: OPTGROUP label is not readable on every OPTION from

22
CARDINAL


August 2017
DATE

which addresses its lack of exposure by VoiceOver.

The same very quick search in the

Chromium
ORG

bug tracker resulted in

four
CARDINAL

accessibility bugs:


MDN
PERSON

’s browser compatibility chart for <optgroup> shows full compatibility seemingly since the dawn of browsers. A11ySupport.io, on the other hand, lists <optgroup> screen reader support as

7
CARDINAL

out of

33
CARDINAL

using tests from

four years to a month ago
DATE

.

Interestingly, WCAG Technique H85: Using optgroup to group option elements inside a select implies that <optgroup> is accessibility supported when it is not (despite

MDN
ORG

’s implication).

Verdict


Today
DATE

only Safari 17 on macOS partially supports <hr> in <select> , but that will change when

Chrome 119
ORG

comes out and also partially supports it. Until

Firefox
ORG

adds support, I would avoid <hr> in <select> . When Firefox adds support, I will likely still avoid <hr> in <select> until the bugs are ironed out. At the very least, it is a visual-only affordance, so I am not sure it is an equivalent experience for low- and no-vision users.

Instead, consider pushing for bug fixes on <optgroup> since it provides a visual cue and group label when done well. In my opinion, that is more valuable than a visual-only cue.

Playing catch-up.

On the Masto,

Matt Machell
PERSON

asked about stuffing an <hr> into an <optgroup> . It closes the <optgroup> (well, browsers will once they all can react to this recent addition):

An optgroup element’s end tag can be omitted if the optgroup element is immediately followed by another optgroup element, if it is immediately followed by an hr element, or if there is no more content in the parent element.

WHATWG
PERSON

HTML § 4.10.9 The optgroup element

I embedded an example in my demo so you can see how it works

today
DATE

. A rare case where I consider it ugly and weird enough to suggest you avoid it for that reason alone.


James Teh
PERSON

(

Mozilla
ORG

, formerly

NVDA
ORG

) weighed in on the closed W3C

HTML-AAM
ORG

PR to note that

NVDA
ORG

users can do a little review cursor navigation to find the separators, while VoiceOver seems to disallow that. He also notes that

Firefox
ORG

calculates position within groups (such as menus and lists) by accounting for separators, well before the spec said not to do that, so this can throw a wrench into current interface expectations.

James Craig
PERSON

(

Apple
ORG

) responded and the conversation continues.

Since

WHATWG HTML
ORG

is versionless, and since it essentially only takes

one
CARDINAL

browser implementation to get into

WHATWG HTML
ORG

, and since the people approving PRs to

WHATWG HTML
ORG

seem to be the same ones adding features to

Safari
ORG

and

Chrome
ORG

, perhaps the best way to stay on top of HTML

today
DATE

is to look at

Chrome
ORG

“intent to ship” announcements and

Safari
ORG

feature releases.

Remember that there are long-standing accessibility bugs in all major browsers. Remember that

Apple
ORG

is working hard to erase its huge deficit in baseline support, and pushing changes to HTML and then rushing them to market makes for good PR. Remember that

WHATWG
PERSON

’s process generally dismisses accessibility experts and demonstrable problems — it took

872 days
DATE

to fix <main> in WHATWG HTML,

2,495 days
DATE

to fix

WHATWG
PERSON

HTML’s wrong advice about

the Document Outline Algorithm
LAW

, but

only 27 days
DATE

for

Apple
ORG

to push this into

WHATWG
PERSON

HTML. Remember this as you work on and use the web platform.

Meanwhile, this discussion prompted

Wilco Fiers
PERSON

(

Deque
ORG

, axe) to poke his open

ARIA
PERSON

issue Why is separator allowed between

menuitem
PERSON

, but no other “item” roles?