Writing up some best-practice patterns for form controls, and I've assembled this list of native HTML controls that should never be used (because they're not universally supported, and/or their native UI has accessibility problems):
They don't seem to do anything different from "text", except for built-in validation constraints, and in some cases input mode (though that's not universally reliable without an explicit inputmode attribute).
Yea I pretty much hate every date/calender input out there, and most of the color input tools too.
Interestingly, I think most color choosing tools and date choosing tools fail for the same reason: a “nearly infinite” set of possible choices.
Consider a date tool. Do you need to enter a date for next week for an appointment? Or a date/time in a month for a holiday trip, but you have to schedule around two other people.
Or, enter your birthday.
Or, find that event that was ten years ago, but it might have been 9 or 11 years, and you’re in California where we don’t have seasons so you can’t remember time of year…
That’s four different task requirements, and a simple all purpose tool is not an ideal solution.
But “simple all purpose” is what most UIs for date/time are.
@Myndex Those are all pertinent questions yeah. I'm in-progress developing an accessible datepicker, and that's gonna have to come with a lot of guidance on when and how to use it (eg. don't use it for birthdays).
Don't get me started on calculating week numbers ... jesus wept. Thankfully the Date() constructor does most of the work on out-of-range date values though.
@joelanman Including the advice that form fields should never be declaratively disabled or read-only, only dynamically for data integrity (eg. disabling the submit button after the form is submitted to prevent accidental duplicate submission, but never disabling it in advance as a kind of validation).
Noting that screen readers generally don't notify the user at all when their typing produces no input, which kinda rules out read-only fields altogether, not to mention maxlength.
@joelanman Yeah I had that focus management issue in my mind too, but I was thinking -- it doesn't matter if focus is lost, since the page/view is about to be replaced anyway?
Disabling the button will cause it to lose keyboard focus, which could be confusing or annoying for keyboard users, if the page is still usable while it’s waiting for a server response.
A better solution for cases like this is to block the form’s submit event:
@siblingpastry
I might move that sub-clause into its own following sentence, but yeah, that seems fine.
A visual change might be good to apply while the default is being prevented. A cue that the button is now ignoring the user (especially if the button otherwise has a visual change when activated).
@siblingpastry I think number is OK, if you really want a single number, like the amount of items in a shop. (But there might be something that I’m missing.)
I'm also unilaterally advising against <input type="reset"> because its utility is marginal, and far outweighed by its potential for data loss when users click it by mistake.
@siblingpastry Yes. Your form should never lose information unless the user is actively navigating away from the page, and even then a confirmation does not hurt.
@siblingpastry Those are by definition not numbers 😉 I agree there is a lot of misconceptions around it and why I put it in the “beware” column, where I would put all others in the “do not use under any circumstances” column.
@siblingpastry For VO/iOS there is no way to increment/decrement the value for anyone, so I guess that is meant by not applicable. I assume it’s a similar deal with Android/TB.
@siblingpastry@yatil
It's fine if the "spinner" controls of a number input are an affordance only for pointer users, everyone can still enter digits into them.
My recollection is all the accessibility issues listed in the GDS article have since been addressed. All the Voice Control tests listed on a11ysupport are older than the GDS article so they might have also been corrected.
@cwilcox808 I’m not sure I’d relegate those buttons to just affordance, they’re functionality that should be supported directly or by equivalence. I’ll do some testing on Monday see what the current state of play is.
@siblingpastry@cwilcox808 Considering that the spinner buttons would need to be within the size of the input fields, which would make the touch target very small. On iPad, you can use keyboard up/down in the field to change the number. (I think all touch spin buttons like that are quite compromised.)
@yatil@cwilcox808 Interesting, so then that would tend towards just considering them superfluous. And they wouldn’t fail 2.5.8 even when author sized too small and close, because they do have equivalence.
@siblingpastry@cwilcox808 The target’s size is determined by the user agent in that case, so it’s excepted. (But yeah, the main objective of the field is to enter a number, not really the incrementing/decrementing part.)
@yatil@cwilcox808 Only if the input isn’t author-sized, as soon as you set dimensions, that UA exception no longer applies. But equivalence would still pass it.
@siblingpastry@cwilcox808 I don’t agree. The target in this case are the individual up/down buttons. Because the input type number has three targets: The input field and the up and down arrows. The exception applies to them individually. At least I would test it like that. (No power really to go deeper into this. The AG WG probably knows what they meant.)
@yatil Yeah they’re separate targets, but the size of the spin buttons is determined relative to the size of the field, so I reckon that would still count as author sized.
@cwilcox808@siblingpastry@yatil Another aspect of us switching to inputmode is type=number silently rejects non numeric input which we don't think is good practice, we have the same stance on maxlength
@siblingpastry@cwilcox808@yatil I would argue the default hit area for the stepper buttons doesnt meet the minimum required (might be an exception since it's native but I think that's a technicality, it doesn't actually make it accessible)
It would pass that exception yeah. I'd assumed the spinbuttons would size with the field, but now I test that, they don't, they're always the same small size.
However it still passes 2.5.8 either way, because of equivalence -- the spinbuttons are not actually necessary. Which is also why their lack of direct keyboard accessibility doesn't matter.
Add comment