<input type=color> enhancements

[annevk]

https://w3c.github.io/html-aam/#el-input-color doesn't seem to have a whole lot of guidance for implementations.

In whatwg/html#10456 we're adding some additional features that only impact AT in so far as that more colors can now be expressed (either set by the web developer or returned by the picker).

I thought I'd raise this issue so we can at least figure out if we want to say more here or if the current wording is sufficient.

[keithamus]

Thanks for filing! I don't think there's anything actionable here. Currently the mappings expose as best as they can by announcing the control as a colour picker, where applicable. There are no specific roles we could expose to be more specific based on the additional attributes; and while role descriptions could potentially be refined that may err on the side of overly verbose.

So all being said, thanks for bringing it to our attention! I think the spec is good as-is.

[annevk]

Thanks, I guess that's reasonable. One thing that I had to patch in WebKit and currently does not appear to be covered in the specification is the accessible name computation. https://w3c.github.io/html-aam/#accname-computation seems to suggest that web developers have to use aria-label or aria-describedby as the control is not explicitly covered, but a) that's not the case in practice and b) that should never be the case for built-in form controls.

[jnurthen]

@annevk wouldn't it fall into https://w3c.github.io/html-aam/#other-form-elements-accessible-name-computation

[annevk]

@jnurthen right, so I guess you can also rely on the label element or title attribute, but what happens in VoiceOver at least is that the selected color is read out (by name). Which that does not cover.

[jnurthen]

@annevk isn't that the value not the label?

[annevk]

Yeah it is, sorry for getting them mixed up. I guess value is not described at all?

[jnurthen]

currently it is not specified - we have an open issue to track this though
w3c/accname#184

[annevk]

And that was duplicated against w3c/accname#200 it seems, but that seems good. Okay, let's close this then. If any questions about <input type=color> arise feel free to ping me.

[scottaohara]

briefly discussed during the ARIA wg call's triage, and maybe beyond the scope of what this issue was asking for - but an existing issue #557 was created (based on yet an older issue) where there is no place that actually defines how browsers should align on the implementation of controls like type=color, other form controls, or the summary element for that matter...

maybe it is too late to do that? but in the scope of the color picker, in the collapsed state - if one can't fully perceive colors, then there's no good identifier of what color is actually chosen. In some browsers - like Firefox on macOS, there are different views to the picker popup, so one can get a better sense of what color is chosen. And on Windows, the Firefox popup actually shows the number values for hue, sat, lum, red, green, blue. Chrome/Edge similarly have a popup that shows rgb with the popup.

It'd be out of scope for us to tell UAs what the popup should consist of (though clearly it doesn't have to be a specific UA popup, since every browser seems to show something different). but maybe defining features that should be present in the popup is something all browsers could do better / needs to be defined somewhere.

[scottaohara]

@annevk, interested in what you think of the above, since i was responding while you closed this issue.

[annevk]

If we consider the control to consist of an in-page part and a picker part then I think it's fairly reasonable for specifications to give recommendations (should-level) for either. For in-page probably more so than for the picker.

What would be helpful is to have some data on what AT end users would like to see <input type=color> do. How can we make it most useful for them and do they need to know the nuance between "red" being in sRGB or Display P3 or is just "red" sufficient and they can go into the picker for more details. Or indeed expose multiple values in some way.

(@scottaohara also, you should feel free to reopen if you don't consider this done.)

[scottaohara]

thanks @annevk

i think we can keep this closed, as we have the other existing issue that mentions this input, as well as others.

ping @rahimabdi since he and i talked about this / other related stuff during our html aam synch today.