1.4.10 Reflow: Can selects with long options be considered to fall under the exception

[detlevhfischer]

In an audit of legacy content, there are "open" (multiline) select elements with longish content in the option elements (say, trip number, traveller, place, date).
This should REALLY be data tables, but implementing it that way is currently not feasible and the question remains whether such an implementation could still be considered a PASS of 1.4.10 if the content in the options can be scrolled to in a magnified view (or narrow view of 320 px). As I see it, there is no normative definition what content falls under the exception, just a range of examples in the second Note. Any opinions? I'd be very obliged...

[JAWS-test]

related: #1233 and #1523

[alastc]

Hi Detlev,

I'm not clear on the scenario, are the selects causing scrolling at 320px or is the text getting cut off, or something else?

I don't see a select element as something which needs to be 2D, there's no relationship, it's just a list of text items.

[patrickhlauke]

<select multiple> will grow as wide as its content, with each item on a single line without any possible reflow. depending on the styling given, this either means the select will be wider than 320px (leading to horizontal scrolling), or (if forcing a maximum width) options will be cut off. likewise, regular <select> also doesn't allow options to reflow, so similar problems happen. (i think depending on various factors, again either leading to horizontal scrolling or content being cut off).

does this directly fail reflow? the <select> itself can't be styled further, so authors should implement a custom widget that does reflow its content/options? (I tend to say yes, it's a fail, for exceedingly long content in the options)

[mbgower]

Except for parts of the content which require two-dimensional layout for usage or meaning.

I think my argument would be that a native select behaves this way. There is no way for the author to override the behaviour, and therefore it requires the 2-d layout.

It would be better if we had a user agent exception in here, but barring that, I am comfortable allowing these.
The alternative -- telling every author in the world they cannot use native selects anymore because the element cannot reflow -- is something I'm less comfortable with, for what I hope are obvious reasons. That would seem to be a very backward result.

[scottaohara]

Agreed with @mbgower. Even putting a max-width on a select element won't do squat to stop the OS-listbox popup from extending beyond the 320px viewport if the option text is too long (i see this happen quite often for instances where selects contain very long IP addresses, or authentication codes).

telling every author in the world they cannot use native selects anymore because the element cannot reflow...

agreed. this would be unreasonable.

[alastc]

There is no way for the author to override the behaviour, and therefore it requires the 2-d layout.

Currently it can fail in two ways, either:

1. Cutting off text (loss of content) if you put a max-width on it, or
2. Causing horizontal scrolling if you allow it to expand.

In most contexts where you cut-off text there is a way of getting the full content. E.g. a news headline is cut-off in the list, but click through for the whole headline.

AFAICT for selects that isn't an option, so that would lean me towards the 2D exception.

Just playing devil's advocate for a moment, is it essential to use a select? I don't see them around much these days, are there better ways of doing the same thing?

[patrickhlauke]

I don't see them around much these days

Lucky you, I still swim in them on many of the intranet-type sites I regularly audit...

are there better ways of doing the same thing?

when there's only a few options, a set of radio buttons offers more flexibility. but of course, that takes up far more space than a <select>. only alternative is building a custom dropbox/combobox (and all the problems and pitfalls this entails)

[alastc]

Yea, combo-boxes seems to be the common (and difficult to get right) method these days.

@patrickhlauke so have you been failing these examples, and if so what did you recommend instead?

I agree with the sentiment above of not wanting to fail these, but I'm thinking about the lack of normative support for that.

[patrickhlauke]

@patrickhlauke so have you been failing these examples, and if so what did you recommend instead?

Luckily I haven't encountered ones all too often where the option value was so excessively long as to be problematic at 320 CSS px width. But on the few occasions where I have, I flagged it as a mild failure, and suggested - depending on what the exact situation was - to either see if the option text can realistically be shortened and still make sense, or to consider an alternative instead (series of radio buttons, or a completely custom combobox implementation, pointing them to ARIA-PRACTICES examples). But yes, felt a bit "wrong" as it's something not directly under their control.

[fstrr]

This issue is labelled as a discussion, so we’re moving this to Discussions. There doesn’t seem to be an update to make to the documentation, but if that changes, we can move it back to the issues list.