Comments (10)
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...
from open-ui.
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.
from open-ui.
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.
from open-ui.
See also #552
from open-ui.
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
from open-ui.
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.
from open-ui.
@josepharhar has the doc been updated to reflect this req; if so can we close this?
from open-ui.
@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)
from open-ui.
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.
from open-ui.
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
from open-ui.
Related Issues (20)
- [focusgroup] Should focusgroup direction follow the DOM order or the visual order? HOT 4
- [switch] Should the switch element support swipe actions? HOT 7
- [switch] Should the switch have a toggle() method? HOT 1
- [popover] moving keyboard focus out of a popover should dismiss it HOT 9
- Target minimum size for select HOT 2
- [interest invokers] Touch inputs HOT 7
- Explore `<input>` Element as a child within `<select>` for Combobox HOT 3
- [invokers] Implicit targets HOT 10
- Toggle Button Proposal HOT 15
- Dismissing popovers when focus leaves HOT 6
- Will the stylable <select> element be able to break outside the browser window? HOT 6
- [invokers] setRangeText for textarea and inputs HOT 1
- [select] `<selectedoption for=id>` as an alternative to split buttons and `<button type=popover>` HOT 5
- [interest invokers] How to define/control the action on "losing interest" HOT 3
- Foundation for the Global Design System component library HOT 9
- [invokers] add a way to list supported commands?
- [invokers] add an invoke method?
- [Invokes] commands should be dash delimited HOT 1
- [select] mouse focus when clicking invoker to open dropdown
- [select] Removing the capability for the author to provide a datalist element HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from open-ui.