Last Comment Bug 559767 - make <input type="color"> accessible
: make <input type="color"> accessible
Status: NEW
: access
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: unspecified
: All All
-- normal with 6 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: alexander :surkov
Mentors:
Depends on: 547004 559766
Blocks: html5a11y 2013q4a11y 956711
  Show dependency treegraph
 
Reported: 2010-04-15 23:47 PDT by alexander :surkov
Modified: 2014-12-17 04:34 PST (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description User image alexander :surkov 2010-04-15 23:47:49 PDT
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 User image steve faulkner 2013-10-30 08:50:24 PDT
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 User image steve faulkner 2013-10-30 08:53:20 PDT
acc value example value='0% red 0% green 0% blue'
Comment 3 User image alexander :surkov 2013-11-06 06:00:28 PST
(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 User image James Teh [:Jamie] 2013-11-06 20:45:18 PST
(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 User image alexander :surkov 2013-11-07 06:56:23 PST
(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 User image alexander :surkov 2013-12-11 08:39:29 PST
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 User image steve faulkner 2014-11-11 06:20:34 PST
(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 User image James Teh [:Jamie] 2014-11-11 14:20:56 PST
(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 User image alexander :surkov 2014-12-11 13:37:48 PST
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 User image Joanmarie Diggs 2014-12-17 04:34:24 PST
(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.

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