make <input type="color"> accessible

NEW
Unassigned

Status

()

defect
9 years ago
7 days ago

People

(Reporter: surkov, Unassigned)

Tracking

(Depends on 1 bug, Blocks 1 bug, {access})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
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

6 years ago
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

6 years ago
acc value example value='0% red 0% green 0% blue'
(Reporter)

Comment 3

6 years ago
(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
(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?
(Reporter)

Comment 5

6 years ago
(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.
(Reporter)

Updated

6 years ago
Blocks: 2013q4a11y
(Reporter)

Comment 6

5 years ago
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)?
(Reporter)

Updated

5 years ago
Blocks: 956711
(Reporter)

Updated

5 years ago
Flags: needinfo?(jamie)

Comment 7

5 years ago
(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??
(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.
Flags: needinfo?(jamie)
(Reporter)

Comment 9

4 years ago
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

4 years ago
(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.
It took 3 years, but now that there are other implementations out there are less questions..
Attachment #8930759 - Flags: review?(surkov.alexander)
(Reporter)

Comment 12

a year ago
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.
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?
(Reporter)

Comment 14

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

could you please answer my previous comment?
Flags: needinfo?(eitan)
Attachment #8930759 - Flags: review?(surkov.alexander)
(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.
Flags: needinfo?(eitan)
(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.
(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.
(Reporter)

Comment 18

a year ago
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?
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.
(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.
(Reporter)

Comment 21

a year ago
(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.
Depends on: 1445061

Updated

2 months ago
Duplicate of this bug: 1526820

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! :)

You need to log in before you can comment on or make changes to this bug.