How can long list entries within selects fulfill SC 1.4.10?

[JAWS-test]

Line breaks cannot be inserted in native select elements. Nor do they break automatically. How do I comply with SC 1.4.10 if my list entries are long?

I must either scroll (when scrolling, however, the list is closed automatically, see example 1 at https://codepen.io/jaws-test/pen/QWyPzgM) or limit the width of the select element, but then I cannot see the list entries completely and cannot scroll (example 2).

As far as I know, there is no solution with HTML and CSS. So selects should be excluded from 1.4.10 (according to "Except for parts of the content which require two-dimensional layout for usage or meaning."), right?

But since the operation is very complicated even with scrolling, the question would be whether to either talk to the browser manufacturers and define a new requirement for browsers (line break inside option elements; in the UAAG). Alternatively, it could also be defined in the WCAG that list entries may never be longer than 320px wide?

[mbgower]

Draft Working Group Response

A select element meets the "two-dimensional layout for usage" exception.

Rationale

As you point out, the presentation of select elements is controlled by user agents, not authors, and there is no author method to reflow a long select item across multiple lines.
Hence, a select element requires two-dimensional layout for usage: the element provides a vertical list of options, and each option is displayed on a line (without the ability to reflow).

Incidentally, this inherited behaviour can result in truncation even without content resizing. If the currently selected option is a long string, it will not entirely display when a select element is collapsed. And when the select component is expanded, the string of the option is only expanded across the visible viewport; there is no ability to show the remainder of a string that exceeds the viewport's width. It would be nice if user agents could provide some method of allowing full viewing of each option, but that is not something the WCAG 2 Task Force can control (or even influence, with any success).

[fstrr]

As you point out, the presentation of select elements is controlled by user agents, not authors, and there is no author method to break a long select item across multiple lines.

This isn't strictly true now. The presentation of "default" select elements is still controlled by user agents, but there are now customizable selects that allow significant customization.

[mbgower]

allow significant customization

Thanks for sharing, @fstrr. But at a quick glance, none of the customization options seem to provide an author a means to address the truncation shortcomings of the native element. If I'm missing something, please point me to it.

[fstrr]

One of the linked demos uses CSS grid on an option element to place content on multiple lines, which allows the width to be adjusted. Does that work?

[patrickhlauke]

I think the bottom line is that if the component relies solely on user agent rendering/functionality, then it's outside of the author's control and the author can't be held responsible for it (other than suggesting that as best practice they don't use native/user agent rendered controls, which feels a bit counterproductive in many cases)

[mbgower]

One of the linked demos uses CSS grid on an option element to place content on multiple lines, which allows the width to be adjusted. Does that work?

Interesting. So that theortetically gives the author the ability to break something across two lines. Is there any way for the author to cause the content to reflow as the string width reaches the maximum viewable space? If not, I think it is still info that cannot really reflow, and therefore requires 2-dimensional layout.

Is this another SC that we should consider adding a 'default user agent presentation' exception for in a future release?

This speaks to an ongoing challenge that the objective of this SC -- supporting the ability to reflow text (i.e. body) content -- is not really aligned with the normative language created in the SC.

[fstrr]

Is there any way for the author to cause the content to reflow as the string width reaches the maximum viewable space?

and

Is this another SC that we should consider adding a 'default user agent presentation' exception for in a future release?

I put a super quick currently-chromium-only demo together and it looks like a simple white-space: normal rule will break text so that it wraps and supports Reflow. So, yep, we should add a default user agent presentation exception for a future release.

Demo note: when you put your browser into Reflow dimensions, you might have to refresh the page to get all the options to display properly for some buggy reason.