The default bug view has changed. See this FAQ.

make <input type="color"> accessible

NEW
Unassigned

Status

()

Core
Disability Access APIs
7 years ago
2 years ago

People

(Reporter: surkov, Unassigned)

Tracking

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

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 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

3 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

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

Comment 3

3 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

Comment 4

3 years ago
(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

3 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

3 years ago
Blocks: 923199
(Reporter)

Comment 6

3 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

3 years ago
Blocks: 956711
(Reporter)

Updated

3 years ago
Flags: needinfo?(jamie)

Comment 7

2 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??

Comment 8

2 years ago
(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

2 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

2 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.
You need to log in before you can comment on or make changes to this bug.