[select] - Ensure any new UA defaults meet WCAG 2.2 target size (minimum)

[scottaohara]

Opening this so we make sure to consider making the default styling for the select element adhere to the 24x24px target size minimum, per the new WCAG 2.2 requirement. While there is an exception for unstyled controls provided by the user agent to not meet this minimum... being new styling it'd be great to at least meet the minimum bar.

The current select element (as rendered in Edge on Windows) is 26x19px (if a single character 'option' used as the default). The select with no chosen option is a tiny 22x19px

The select on the left is the current select element's default rendering (again 22x19px), with the one on the right being modified to be a minimum 24x24px.

If the triggering element cannot be updated in sizing, so as to not be so different from the existing select element - then I'd at least hope we could make the options meet the minimum - as those are honestly more the concern being that they're 'touching' sibling targets that the rule was created for, so as to help users with motor disabilities have a higher success rate in choosing the correct target via pointer devices (mouse, touch, etc.).

While this issue is just about the current 'select' work, we should keep this in mind for any new interactive elements that might come out of open ui.

https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html

[lukewarlow]

Fully agree with this, other UI that comes to mind is the textarea resize handle which while I haven't checked I would all but guarantee doesn't mean the requirements.

[scottaohara]

oh yeh.... absolutely doesn't. many default styles for form controls/their parts don't meet the minimum. hence an exception had to be written...

[mfreed7]

Fully supportive of this proposal. The current approach (using appearance:base-select on the <select> to opt-in to new behavior) has some limitations around changing styling such as overall width/height. But I believe @josepharhar has figured out an implementation that would make it possible.

[mfreed7]

See also #552

[css-meeting-bot]

The Open UI Community Group just discussed [select] - Ensure any new UA defaults meet WCAG 2.2 target size (minimum), and agreed to the following:

• RESOLVED: For this and all future controls we resolve to ensure that interactive elements will not share the same area - with a boundary of 24px, meeting WCAG 2.5.8 Target Size requirements

The full IRC log of that discussion

<hdv> scotto: not expecting a lot out of this right now, but wanted to make sure the group sees this issue
<luke> q+
<hdv> scotto: the issue is about making everything deemed a target for a pointer device (mouse, touch, pointing software), that it meets the new target minimium size of WCAG 2.2, being 24x24px minimum or at least that as spacing around the target
<masonf> q+
<hdv> scotto: this would be important for <select>/<selectlist> but also for components like split buttons, where the split button part is often implemented with a very small target size
<flackr> q+
<masonf> ack luke
<hdv> luke: +2000 for this
<hdv> luke: I think the default control should be accessible to start with
<hdv> luke: especially in UA UI
<hdv> luke: I think select is a great example
<hdv> luke: wasn't there a target size requirement already?
<hdv> scotto: yes a Level AAA requirement, which requires 44x44, that would not be ideal for some desktop / web circumstances, which is why this new “(Minimum)” requirement was added
<hdv> masonf: the current approach for selectlist would be the <select> and you toggle into that using the CSS appearance property, something like appearance-base. There have been some implementation questions around whether it is possible to do width and height. That's still in the early stages but jarhar seems to have figured out some things around this recently
<hdv> luke: I think field size and content should be the default rather than the legacy fixed behaviour
<hdv> masonf: wonder if that should be raised somehwere?
<hdv> luke: I can raise a CSSWG issue
<hdv> masonf: agree minimum size makes sense. To clarifly, we're talking default size here, right? It would still be possible for an author to make it 1x1px if they wanted that?
<hdv> scotto: exactly
<hdv> scotto: this is about the base UA styles
<masonf> q?
<masonf> https://github.com//issues/552
<masonf> ack mason
<masonf> ack flackr
<hdv> masonf: generally speaking, not only this minimum size thing, any issues to default styles, we should probably discuss in https://github.com//issues/552
<hdv> flackr: the browser has a way to detect what control is closest to what you're touching? do we have that for clicking?
<hdv> scotto: this rule is geared towards people who are authoring content
<masonf> q+
<hdv> scotto: there's no expectation that browsers would be doing anything… but if there's 24px spacing that gives more room for people if they don't hit the target, they're not necessarily activating anything else, it prevents activating something users don't want to
<hdv> scotto: it takes a very special design to have two checkboxes as siblings next to each other
<hdv> masonf: is there a resolution you'd like? maybe something like to ensure minimum size is 24px?
<hdv> flackr: suppose we're inventing some future component like a combobox… that thing we might think a 24px button would be too big, but ensuring there is 24px worth of space might suffice?
<hdv> scotto: yes if the clickable/touchable space is there that's fine, it's a space issue more of a design issue
<hdv> keithamus: more like you can't have two interactive elements in the same 24px boundary?
<masonf> q?
<masonf> ack mason
<keithamus> PROPOSED RESOLUTION: For this and all future controls we resolve to ensure that interactive elements will not share the same area - with a boundary of 24px, meeting WCAG 2.5.8 Target Size requirements
<hdv> SashaFirsov: the ideal tap size is different per platform, is there a way to use or invent some kind of system prop?
<hdv> flackr: we're talking CSS pixels which are device agnostic already
<hdv> SashaFirsov: but it's different per platform
<hdv> masonf: should be based on device pixel ratio already
<hdv> scotto: the baseline in the WCAG success criterion is set in CSS pixels
<masonf> https://developer.mozilla.org/en-US/docs/Glossary/CSS_pixel
<flackr> See also https://www.w3.org/TR/css-values-3/#reference-pixel
<bkardell_> +1 resolution
<hdv> keithamus: understand your concern, but it's tackled by using CSS pixels in this case
<scotto> here's the draft note on converting wcag to non-web content that also talks about the conversion - https://wcag2ict.netlify.app/#target-size-minimum
<hdv> keithamus: understandable, but would be good to align with the WCAG guidelines
<keithamus> q?
<hdv> scotto: yes. See also the WCAG2ICT note I just linked to, that applies WCAG to non web content
<hdv> scotto: it defines CSS pixel for devices that don't use pixels. Would suggest logging issues with these definitions with WCAG2ICT
<luke> +1
<scotto> +1 to resolution
<brecht_dr> +1
<hdv> +1 to resolution
<dbaron> +1
<keithamus> RESOLVED: For this and all future controls we resolve to ensure that interactive elements will not share the same area - with a boundary of 24px, meeting WCAG 2.5.8 Target Size requirements
<bkardell_> +1

[josepharhar]

For the button this doesn't require any changes because the fallback button as I've implemented is already 24x24, but option elements are not big enough. I tried these styles:

select option {
  min-inline-size: 24px;
  min-block-size: 24px;
}

However, now the text is at the top of the block. In order to make it centered, which I figure people would want, I'd have to make the option element a flex container like this:

select option {
  min-inline-size: 24px;
  min-block-size: 24px;
  display: flex;
  align-items: center;
}

Or maybe it would be better to just increase the font size to be big enough to meet the requirement without setting other rules? I could use some guidance here.

I'm going to reopen this since it has "select" in the title, but I can also make another issue if people want.

[gregwhitworth]

@josepharhar has the doc been updated to reflect this req; if so can we close this?

[scottaohara]

@josepharhar anything that can contribute to the overall size would be 'fine' to use. whether that be a font increase, more default padding, line height. (and by 'fine' i mean in regards to meeting the rule, what's fine to use for browser implementation might be another story)

[josepharhar]

We can center the text using padding-top and padding-bottom, but I don't know if there is a good way in CSS to say that they should be equal and contribute to making the option element have a minimum total size and keep the text in the center.

[css-meeting-bot]

The Open UI Community Group just discussed [select] - Ensure any new UA defaults meet WCAG 2.2 target size (minimum), and agreed to the following:

• RESOLVED: use align-content with display:block and min-size properties to ensure minimum size for options

The full IRC log of that discussion

<hdv> jarhar: threre's a couple of ways to implement this… wanted to check what do you all think is the best way to do this in CSS?
<hdv> jarhar: we could use min inline size and then block size to make sure it is big enough, but problem with that is that it pushes the text halfway the box, I think that loks funny
<gregwhitworth> q+
<hdv> jarhar: we could also make the option element a flex container but not sure if that would have weird side effects
<hdv> jarhar: not sure if we can apply the min size concept and only apply padding when we actually need it
<flackr> q+
<hdv> jarhar: somebody from Microsoft shared some CSS used across selects
<masonf> `justify-self: center;`?
<hdv> jarhar: but that would change the already shipped
<hdv> jarhar: so wanted to ask what we should do?
<hdv> gregwhitworth: is this in the concept of appearance base-select?
<hdv> jarhar: yes, but whatever we decide I can recommend for appearance auto as well
<hdv> gregwhitworth: ok, was going to say the latter is up to the UA
<hdv> gregwhitworth: I'm fine for discussion of each problem but do we have a base UA stylesheet?
<hdv> masonf: there is an issue for the entire stylesheet, doesn't have a lot of discussion, hoping to add it to the joint tf discussion list
<hdv> gregwhitworth: would be good to get eyes on it
<Luke> q+
<hdv> ack greg
<gregwhitworth> ack flackr
<hdv> flackr: something like line-height seems like the canonical way, but would be issue if it is multiline
<gregwhitworth> I like using flex
<gregwhitworth> ack Luke
<sanketj_> q+
<gregwhitworth> valid point
<hdv> Luke: I thought some of the alignment properties apply to block elements these days, so we could probably try and keep it block…
<hdv> flackr: I like that suggestion too
<gregwhitworth> ack sanketj_
<hdv> flackr: did have an issue with flex being potential performance issue
<masonf> From the previous question, here's the issue discussing the entire <select> stylesheet: https://github.com//issues/552
<hdv> sanketj_: to clarify…  one issue is about the style of select which is about meeting minimum size in WCAG… and the second one is about making it more customisable
<hdv> sanketj_: so they shouldn't affect one another?
<hdv> sanketj_: is it fair to say the choice we make for regular select today doesn't make customisable select more difficult?
<hdv> masonf: it doesn't lock us down in styleable select
<hdv> masonf: they don't have to be the same… but it is definitely nicer if they match
<chrishtr> Whether the styles can differ from auto is not yet decided at the task force
<gregwhitworth> q?
<hdv> sanketj_: seems reasonable… if we can get to consensus soon, then we would avoid holding up accessibility improvements
<gregwhitworth> ack dbaron
<hdv> dbaron: I think it's a hard problem… because with appearance auto we have to think about things that may be broken re existing content
<hdv> dbaron: the flex approach is kind of appealing to me… there is some risk for existing content, if you're trying to make it work for appearance auto
<hdv> dbaron: there may be people in the wild that have a reset style that sets options to display: block, in which case the flex would get overridden and alignment would no longer work and items end up top of their box
<masonf> 2024: centering is still hard. :-(
<hdv> dbaron: re applying alignment props from flex to display:block… I think there was talk about it, but not sure if that has actually shipped
<hdv> dbaron: I think line height is risky, because there will always be a risk of overlapping… if you do line height as a length, and someone sets font size larger than line height it overlaps… if you set it as a number you create something that looks good, but if people set font size it could end up quite large
<flackr> line-height: max(24px, 1.2em) ?
<gregwhitworth> q?
<hdv> dbaron: if you want a solution that works for both appearance base-select and appearance auto, it might be helpful to do some research into how people do styles on selects today and find out how often they do things like setting display:block
<flackr> my pref is still getting the block align options but good points on all
<hdv> jarhar: the codepen brad frost just posted looks perfect
<hdv> [ said codepen: https://codepen.io/bradfrost/pen/PovoKWQ]
<hdv> sanketj_: question I have for other implementors… would you follow if we did this succesfully?
<hdv> Luke: would be worth speaking to Mozilla
<hdv> masonf: the size 1 and multiple would have an implication
<hdv> dbaron: I should correct what I said earlier… Chromium did ship align properties on display:block earlier
<jarhar> proposed resolution: use align-content with display:block and min-size properties to ensure minimum size for options
<hdv> Luke: question, is Chromium looking to replace the macOS dropdown?
<hdv> masonf: for appearance auto?
<flackr> +1 to proposed resolution
<hdv> Luke: yes
<hdv> masonf: situation is complex… I would personally find it wonderful, others don't… there's currently a flag that makes it happen but doesn't look like we would ship it
<Luke> +1
<gregwhitworth> +1 to proposed resolution
<masonf> +1
<hdv> +1
<scotto> +1
<sanketj_> +1
<jarhar> RESOLVED: use align-content with display:block and min-size properties to ensure minimum size for options
<dbaron> +1