559767 - make <input type="color"> accessible

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[alexander :surkov (:asurkov)]

Should have associtated color picker (we could try to reuse accessible class for similar XUL widget). Also it can have associated list of predefined options.

Comment 1

[steve faulkner]

needs acc API support to be hooked up. suggest implement like chrome:
current color populates acc value property in RGB format, IA2 role=color chooser

Comment 2

[steve faulkner]

acc value example value='0% red 0% green 0% blue'

Comment 3

[alexander :surkov (:asurkov)]

(In reply to steve faulkner from comment #2)
> acc value example value='0% red 0% green 0% blue'

cc'ing Jamie to get his thoughts

Comment 4

[James Teh [:Jamie]]

(In reply to steve faulkner from comment #2)
> acc value example value='0% red 0% green 0% blue'
Is this localised? If we're using accValue, it probably should be unless we're clearly documenting that ATs should treat accValue specially for colour choosers. If not, a format which is easier to decode (such as what Firefox already uses for communicating colours in text attributes) might be better. Alternatively, we could do both; i.e. expose accValue as a localised string and also expose an object attribute with a decodable string.

Mick, any thoughts?

Comment 5

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #4)

> If not, a format which is easier to decode (such as what
> Firefox already uses for communicating colours in text attributes) might be
> better.

agree

> Alternatively, we could do both; i.e. expose accValue as a localised
> string and also expose an object attribute with a decodable string.

Firefox doesn't do a good job on localizing the things historically except probably accessible actions, and rgb format itself (no matter whether localized or not) as user-typed value is not really user friendly. So if accessible value is something that is announced as is by AT to the user then a best choice would be to expose human readable string like "green" or "magenta" to give a hint what color is. Otherwise I would go with IA2 rgb format as Jamie noticed.

Comment 6

[alexander :surkov (:asurkov)]

input@type="color" is rendered as a button. Should accessible value be applied to button? How to differentiate it from ordinal buttons (xml-roles:colorpicker)?

Comment 7

[steve faulkner]

(In reply to alexander :surkov from comment #5)
> (In reply to James Teh [:Jamie] from comment #4)
> 
> > If not, a format which is easier to decode (such as what
> > Firefox already uses for communicating colours in text attributes) might be
> > better.
> 
> agree
> 
> > Alternatively, we could do both; i.e. expose accValue as a localised
> > string and also expose an object attribute with a decodable string.
> 
> Firefox doesn't do a good job on localizing the things historically except
> probably accessible actions, and rgb format itself (no matter whether
> localized or not) as user-typed value is not really user friendly. So if
> accessible value is something that is announced as is by AT to the user then
> a best choice would be to expose human readable string like "green" or
> "magenta" to give a hint what color is. Otherwise I would go with IA2 rgb
> format as Jamie noticed.

any movement on this??

Comment 8

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #5)
> So if
> accessible value is something that is announced as is by AT to the user
It is in most cases. There are exceptions to this; e.g. links and documents often have URLs as values, so we don't announce those. However, I'd argue this is a legacy MSAA thing rather than the way we would have done it with a more modern API. Also, since Chrome is already using value differently, it might be best to avoid using value for machine readable data.

> then
> a best choice would be to expose human readable string like "green" or
> "magenta" to give a hint what color is.
That'd be fine with me, though I still think RGB should be exposed as an object attribute. Another alternative is to just expose RGB as an object attribute and not expose value at all.

(In reply to alexander :surkov from comment #6)
> input@type="color" is rendered as a button.
As noted in comment 1, Chrome uses IA2_ROLE_COLOR_CHOOSER and I think this makes sense. The IA2 spec sayas this is a special dialog, but I wonder if anyone actually uses it like that. It doesn't make much sense to me to have special dialog roles.

Whatever we do, we're going to need to discuss with the IA2 community. At the very least, we need to get a new object attribute into the spec.

Copying Joanie for opinion regarding ATK.

Comment 9

[alexander :surkov (:asurkov)]

just in case, I've sent a letter about the change on ATK mail list.

[1] https://mail.gnome.org/archives/gnome-accessibility-devel/2014-December/msg00007.html

Comment 10

[Joanmarie Diggs]

(In reply to James Teh [:Jamie] from comment #8)

[...]

> (In reply to alexander :surkov from comment #6)
> > input@type="color" is rendered as a button.
> As noted in comment 1, Chrome uses IA2_ROLE_COLOR_CHOOSER and I think this
> makes sense. The IA2 spec sayas this is a special dialog, but I wonder if
> anyone actually uses it like that. It doesn't make much sense to me to have
> special dialog roles.
> 
> Whatever we do, we're going to need to discuss with the IA2 community. At
> the very least, we need to get a new object attribute into the spec.
> 
> Copying Joanie for opinion regarding ATK.

Oops. Missed that in my bugmail. Sorry.

The problem/concern I have with repurposing the role is that it might actually remove information. For instance, right now the color input in Gecko is a button. So to choose a color, you push the button. But in WebKit (Safari, WebKitGtk) it is a text input field. As a result, to choose a color, you type. If the role presented by a screen reader is "button" for Gecko and "entry" for WebKit, the user knows what keys to press to interact with that control. If instead it's changed to "color chooser," that information is lost.

Comment 11

[Eitan Isaacson [:eeejay]]

Attachment: Add a11y API for input@type=color. r?surkov

It took 3 years, but now that there are other implementations out there are less questions..

Comment 12

[alexander :surkov (:asurkov)]

Comment on attachment 8930759 [details] [diff] [review]
Add a11y API for input@type=color. r?surkov

Review of attachment 8930759 [details] [diff] [review]:
-----------------------------------------------------------------

We were left in unknowns 3 years ago on implementation of this widget. Eitan, do you confirm that other browsers went with this role as well?

::: accessible/html/HTMLFormControlAccessible.cpp
@@ +177,5 @@
>  {
>    mGenericTypes |= eButton;
> +  mRole = aContent->AttrValueIs(kNameSpaceID_None, nsGkAtoms::type,
> +                                nsGkAtoms::color, eIgnoreCase)
> +    ? roles::COLOR_CHOOSER : roles::PUSHBUTTON;

I wouldn't cache the value. It is bad for memory. AttrValueIs check should be fast enough to invoke it every time we need a role. Also you won't update role if attribute is changed.

Comment 13

[Joanmarie Diggs]

I've not tried the patch yet, but if you switch the role from button to color chooser, I think you might wind up with a color chooser (button) which causes a color chooser (dialog) to appear upon activation. I'm pretty sure Gtk+ color chooser dialogs have role color chooser.

If the way in which you interact with the widget is as if it were a button, what is the advantage of changing the role?

Comment 14

[alexander :surkov (:asurkov)]

Comment on attachment 8930759 [details] [diff] [review]
Add a11y API for input@type=color. r?surkov

could you please answer my previous comment?

Comment 15

[Eitan Isaacson [:eeejay]]

(In reply to alexander :surkov from comment #12)
> Comment on attachment 8930759 [details] [diff] [review]
> Add a11y API for input@type=color. r?surkov
> 
> Review of attachment 8930759 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> We were left in unknowns 3 years ago on implementation of this widget.
> Eitan, do you confirm that other browsers went with this role as well?

Right! My comment was to suggest that now there are less unknowns, and that present me is more informed than past you.

1. The a11y api mappings spec says it should be a color chooser (https://w3c.github.io/html-aam/#el-input-color).
2. Chrome maps it to color chooser.

> 
> ::: accessible/html/HTMLFormControlAccessible.cpp
> @@ +177,5 @@
> >  {
> >    mGenericTypes |= eButton;
> > +  mRole = aContent->AttrValueIs(kNameSpaceID_None, nsGkAtoms::type,
> > +                                nsGkAtoms::color, eIgnoreCase)
> > +    ? roles::COLOR_CHOOSER : roles::PUSHBUTTON;
> 
> I wouldn't cache the value. It is bad for memory. AttrValueIs check should
> be fast enough to invoke it every time we need a role. Also you won't update
> role if attribute is changed.

Sounds good. I'll update the patch.

Comment 16

[Eitan Isaacson [:eeejay]]

(In reply to Joanmarie Diggs from comment #13)
> I've not tried the patch yet, but if you switch the role from button to
> color chooser, I think you might wind up with a color chooser (button) which
> causes a color chooser (dialog) to appear upon activation. I'm pretty sure
> Gtk+ color chooser dialogs have role color chooser.
> 
> If the way in which you interact with the widget is as if it were a button,
> what is the advantage of changing the role?

Yeah. Not sure what to say.. how does Windows use the equivalent role.

From a screen reader perspective this mapping doesn't really improve the experience. The button should be labeled, and its purpose clear.

Very much could be that the two sources I mentioned above are not doing this right.

Even if Alex is an editor on that spec, and he is never really wrong.

Comment 17

[James Teh [:Jamie]]

(In reply to Eitan Isaacson [:eeejay] from comment #15)
> 1. The a11y api mappings spec says it should be a color chooser
> (https://w3c.github.io/html-aam/#el-input-color).

This wouldn't be the first time that spec was wrong. :) I'd question how/why that decision was made and who was consulted.

It's worth noting this from the IA2 spec:

  /// A specialized dialog that lets the user choose a color.
  IA2_ROLE_COLOR_CHOOSER,

Now, at the end of the day, I've never even seen that role used, so if we need to change IA2, we can probably change it. The point is that the two specs currently disagree, so something needs to be changed.

(In reply to Eitan Isaacson [:eeejay] from comment #16)
> how does Windows use the equivalent role.

I don't think I've ever seen it used.

Comment 18

[alexander :surkov (:asurkov)]

So the story has a long background, I wish we reached agreement sooner than later, otherwise this issue is going to become a longdesc one :)

So Joanie's concern is COLOR_CHOOSER is used for dialogs on Linux, which is valid concern I believe. We can change IA2 to whatever is reasonable, but I wish we kept IA2 and ATK close as possible.

Also the HTML-AAM spec IA2 parts says: "ROLE_SYSTEM_TEXT if implemented as a textbox; IA2_ROLE_COLOR_CHOOSER if implemented as a color picker", which may be read as use COLOR_PICKER role if the widget is implemented as a color-picker dialog. You may argue that's not how people read it but anyways, to keep Linux world safe and to keep IA2 and ATK in sync, we may request to change and ask Chrome to adjust their implementation.

Are there concerns/objections if we used button role for a input@type='color' widget and color_picker for a color chooser dialog?

Comment 19

[Eitan Isaacson [:eeejay]]

Not sure I agree with your HTML-AAM interpretation. But I do agree that there is very little user benefit from the color picker role on a button.

The one benefit I see from my patch is that it exposes the currently picked color as a value.

Is it ok for a button to have a 'value'? Would screen readers add that to their utterance?

We can integrate the picked color into the name calculation, but that would open a hornets' nest of problems.

(In reply to alexander :surkov from comment #18)
> Are there concerns/objections if we used button role for a
> input@type='color' widget and color_picker for a color chooser dialog?

Do we implement a dialog? I think the one provided by this input type comes from the toolkit/os.

Comment 20

[James Teh [:Jamie]]

(In reply to Eitan Isaacson [:eeejay] from comment #19)
> Is it ok for a button to have a 'value'? Would screen readers add that to
> their utterance?

For NVDA, the value will currently be reported in focus mode, but not browse mode. That would need to be tweaked in NVDA. I can't comment on other screen readers.

Note that NVDA doesn't always report the value properly for the color chooser role either, so either way, something is going to need to be tweaked.

> We can integrate the picked color into the name calculation, but that would
> open a hornets' nest of problems.

Indeed. Let's not do that.

> Do we implement a dialog? I think the one provided by this input type comes
> from the toolkit/os.

Yup, it's an OS dialog... and the way Firefox is popping it up is causing focus loss. That's a separate bug, though.

A few other comments after trying this patch:

1. The value is currently exposed in machine readable form. That isn't going to make sense to most users. Chrome exposes percentages in its value, but that is localised. However, even this doesn't, for example, allow NVDA to use its colour heuristics to provide a name. See comment 8 for a discussion of this.
2. The div accessible inside the color input should probably be pruned if possible.

Comment 21

[alexander :surkov (:asurkov)]

(In reply to Eitan Isaacson [:eeejay] from comment #19)
> Not sure I agree with your HTML-AAM interpretation. But I do agree that
> there is very little user benefit from the color picker role on a button.

So is the consensus that COLOR_PICKER should be reserved for dialogs, the color picker input should be exposed as a button, and its color should be exposed as a value? If so I will open HTML-AAM issue.

> Do we implement a dialog? I think the one provided by this input type comes
> from the toolkit/os.

yes, I think so, it doesn't matter in terms of HTML mapping spec though.

Comment 23

[Carolyn MacLeod]

Please note that bug 1526820 that was marked as a duplicate of this bug is actually a separate bug.

Jamie's comment 20, above, says:

Yup, it's an OS dialog... and the way Firefox is popping it up is causing focus loss. That's a separate bug, though.

The separate bug being referred to is bug 1526820. So please reopen that one. Thanks! :)

Comment 24

[steve faulkner]

Testing today on firefox 76/windows 10:
test case: https://thepaciellogroup.github.io/AT-browser-tests/test-files/input-color.html
outstanding issues:

• current colour on button not announced
• no indication that it haspopup (color picker)

Comment 25

[steve faulkner]

Testing today on firefox 100.0b5 (64-bit)/windows 10:
test case: https://thepaciellogroup.github.io/AT-browser-tests/test-files/input-color.html
outstanding issues:

• current colour on button not announced (latest NVDA)
• no indication that it haspopup (color picker)