Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The ChromePicker (Custom color picker) is not accessible #7246

Closed
afercia opened this issue Jun 10, 2018 · 8 comments
Closed

The ChromePicker (Custom color picker) is not accessible #7246

afercia opened this issue Jun 10, 2018 · 8 comments
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Priority] High Used to indicate top priority items that need quick attention

Comments

@afercia
Copy link
Contributor

afercia commented Jun 10, 2018

The ChromePicker provided by react-color has accessibility issues that make it almost unusable for keyboard users and screen reader users.

A few months ago, this was quickly discussed on Slack. At that time, the chrome picker wasn't considered "stable" so it wasn't the right time to pay attention to it.

Re: react-color see also #2383:

The library doesn't force us to use their existing pickers. (It'd be good for us to report issues back to them so they can fix, in any case.) And I've stated that we are likely to build our own using their primitives since we want to have a "clear-color" option, a way to choose whatever color—not just those provided by the palette or the theme—, and obviously accessibility features.

/Cc @mtias

By the way, I see there's now a pending PR to add an alpha transparency UI control to the chrome picker, so I have the impression the current plan is to keep this component?

If so, I'd strongly recommend to reconsider the plan as ChromePicker doesn't meet the accessibility and quality standards Gutenberg aims to implement.

Main issues identified so far:

  • the only focusable UI controls are the color code fields
  • these fields are completely unlabelled, they're announced just as "edit text"
  • all the other UI controls (the hue slider, the arrows to change color format) are just clickable DIVs
  • it's impossible to use the color "handle" with a keyboard

On the other hand, I'd like to remind the WordPress color picker based on Iris is way better with regards to accessibility and it would need just some minor improvements.

Screenshots with Safari and VoiceOver:

screen shot 2018-06-09 at 14 39 47
screen shot 2018-06-09 at 14 40 44

@afercia afercia added the [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). label Jun 10, 2018
@afercia
Copy link
Contributor Author

afercia commented Jun 10, 2018

For reference, here's how accessible sliders should be implemented:

@danielbachhuber
Copy link
Member

If so, I'd strongly recommend to reconsider the plan as ChromePicker doesn't meet the accessibility and quality standards Gutenberg aims to implement.

What's the alternative?

@afercia
Copy link
Contributor Author

afercia commented Jun 18, 2018

What's the alternative?

I think the best person who can answer your question is @mtias as he worked on Iris and he certainly knows better than me if it can be easily react-ified 🙂

@grahamarmfield
Copy link

Some years ago when the Customiser was being built, someone built a fairly good keyboard accessible colour picker for that. Could we not use the same model here?

(screenshot attached)
customiser-colour-picker

@aristath
Copy link
Member

@grahamarmfield that's exactly what @afercia also suggested on his previous comment
From what I can tell we're waiting for feedback from @mtias on this one.

@CalumChilds
Copy link

Some years ago when the Customiser was being built, someone built a fairly good keyboard accessible colour picker for that. Could we not use the same model here?

(screenshot attached)
customiser-colour-picker

Just use the same one as the customizer.

@mtias mtias added the [Priority] High Used to indicate top priority items that need quick attention label Oct 2, 2018
@ryelle
Copy link
Contributor

ryelle commented Oct 2, 2018

I was looking into this today, and while we could contribute back to react-color to add tab-able controls, adding labels (specifically a label for the hex/rgb/hsl button ↕️, and a fieldset legend for the RGB/HSL inputs) also brings in the issue of translations, which react-colors doesn't offer support for.

I think it would be a better approach to fork the ChromePicker & improve it, rather than trying to reactify iris (since we already have the color palette on the screen, and will maybe want to allow for controlling the alpha in the future).

@tofumatt
Copy link
Member

The improvements made in #10564 dramatically increase the accessibility of the colour picker, so I'm going to close this issues as it relates to the near-unusable state of the original colour picker (it was really difficult to use with a screenreader and/or keyboard).

I've filed #10975 as follow-up issue to address some points made in #10564.

Closing this one as fixed though; we should iterate in #10975.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Priority] High Used to indicate top priority items that need quick attention
Projects
None yet
Development

No branches or pull requests

8 participants