Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
ColorPalette: Add an accessible color picker based on ChromePicker #10564
This PR attempts to fork out the ChromePicker from
New ColorPicker (this PR)
I've kept the alpha functionality in ChromePicker, as it was referenced in #4726 that we might want to enable this.
The accessibility improvements I made are:
I've tested this on Mac/Chrome, Mac/Safari, Mac/Safari/VoiceOver, Windows/Firefox/NVDA. I'm personally having some trouble with the sliders when using a screen reader, but I have the same problems on the examples, so that might be user error (since I don't use a screen reader daily). I'm also open to the idea of changing the saturation interaction if there is a better role/pattern we can use.
The toggle handles themselves (the little circles that show position over the color graphs) don't have a defined focus style at the moment, so getting a designer's feedback there would be great
To test yourself:
This PR doesn't remove the
Awesome work here. I skimmed through the code (not deeply) and it's looking good to me.
Let's get rid of
react-color as it's not used anymore. and yeah test would be great but I'm fine leaving for later to get this in the UI-freeze milestone. I'll defer to @tofumatt for accessibility validation.
Hi @mtias, previously we already made use of tinycolor2 in the color utils we build (they were just specific wrappers around the lib). ChromePicker also used tinycolor2 (it was one of the reasons we decided to use it instead of other color libraries), this PR is forking ChromePicker and continues to use tinycolor2, I think there is no duplication happening.
Sorry it took me so long to get to this!
So I took this for a spin and the keyboard accessibility is next-level awesome. It's intuitive and I dig it. I'm going to bed soon so I'm gonna run through it with screen-readers tomorrow, but as noted the lack of focus styles on the sliders is the main visual issue I'm having with this. We definitely need those, from maybe @karmatosed or @sarahmonster? Failing that we can just hack something together because it's not clear when I have one focused, but the colour picker itself works a treat.
I'll give a run through with a screenreader tomorrow, but for now I'd say we need a focus style on the slider dots.
I tried this out with Firefox + NVDA and it largely worked pretty well, there are certainly plenty of little tweaks we could make, but I want to focus on the major ones for now. I've left inline comments everywhere I can so it's easier to address things.
One issue is that keyboard focus isn't trapped inside the modal, at least in Firefox + NVDA. Here's a video (contains audio from NVDA): https://www.dropbox.com/s/7ipcjfhn3gs9gdh/Screen%20Recording%202018-10-16%20at%2015.17.10.mov?dl=0
That's after tabbing to the control. You can here the
aria-valuenow non-integer issue in there too.
One last issue is when I press Enter on the custom colour picker I don't have keyboard focus in the colour picker and can't control it. Or actually this could be related to the keyboard up/down/left/right not working in Firefox for the Hue/Lightness picker. It's hard to describe but I can send a screencast if needed, just let me know if I'm not being clear.
Overall though this is great. We should try to keep it simple for now and focus on what I've mentioned, I'll see if there's anything else after but this is so much better than before.
Here's a suggested solution for the focus styling:
I'd also suggest applying a blue-outline focus styling to the "Toggle input type" drop-down button, which should maybe say "Change input type" rather than "toggle" as well, since toggle tends to refer to a binary switch and is represented by physical toggles in the UI.
To clarify about focus not being trapped/keyboard up/down escaping the modal; here's a GIF of me pressing up/down/left/right (it's not logged on screen, sorry, but I'm doing it) a bunch in the colour picker after focusing it with the keyboard. You can see it's focused thanks to @sarahmonster's focus styles, but it's not moving and eventually you can notice elements behind the popover are being selected.
Do we need to use another method to trap the keyboard in that colour picker? @aduth, I think you know a bunch about our keyboard/focus traps–can you spot what's not working here?
(I'm in Firefox for Windows, btw.)
@ryelle thanks so much for working on this. I've left some comments.
Additionally, seems the saturation "dot" button and the slider buttons don't work as expected with Safari + VoiceOver. On Windows, NVDA and JAWS seem not affected. As discussed on Slack, an option could be attaching a keydown event on the buttons and prevent the default (but also allowing tabbing away). That fixed it for me. Although screen readers tend to intercept keystrokes and events might not behave as expected, I wonder why there's the need to prevent a
Forgot to mention I'd propose to consider to expand the input fields labels:
Having just one letter as accessible name of a control is not so ideal for all users, and is problematic for assistive technology users. On the other hand, I understand there's little space available. Maybe some CSS magic could help.
We need to include credits in files that were ported from
This is a really good point, but the properly display these they'd need localisation, which is difficult for us to handle with string interpolation + React at the moment (see #9846). Unless we should always display H/S/L but have screen-reader elements in div alongside/as labels for each letter that explained the labels in a localised way… maybe that could work?
I that that's worth doing but could be done after this gets into the UI freeze. There are a fair few follow-up issues to be extracted from this PR, but they're better-handled as iterations as this PR is already getting pretty tough to manage because GitHub hides a lot of comments.
I will go through after it's merged and file follow-ups for anything we don't address here, but it's important we get this in, at least as a basis for iteration, for the UI freeze.
It looks like all that remains for this to be way better than what we have, an excellent basis for iteration, and something that covers most of the actual visual UI changes we'd want to make here, is to fix the package issues @gziolo mentioned. Let me know if there's anything I can do to help that part of the PR or to clarify anything else I might've missed. I tried to go through all the comments but it can sometimes be tough to tell in these big PRs what's left to do; just the way GitHub handles them
If this is working in Windows for people I need to update my VMWare setup. It also means I think this is good to go and get merged.
If someone can confirm this works well for them on Windows and the new component pieces get added as per @gziolo's request I say we get this merged
Thanks so much for all your work on this @ryelle; it's an epic patch and I am really pleased to see it. It was the big UI component in the Merge: Accessibility milestone I wasn't sure we'd manage to close; happy you proved my doubts wrong
For me, in Windows, the saturation/lightness control does not work with my keyboard. Focus is changed after keyboard input to things entirely outside the Colour Palette.
- this works on Mac fine
- keyboard users can use all of the controls except the saturation/lightness control (before they could use none)
- we use
speak()when the modes change
This is a starting point and should be improved upon going forward, but I want to get this merged for a few reasons:
- future updates should not impact visual UI at all and the rest of the UI minimally (basically we just need to fix keyboard on Windows and improve the UI for screen reader users
- this is on a fork rather than a branch and it's getting a bit difficult to deal with; we've already had some
gituser error that needed repair and I'd like to avoid future issues
I'll go through this and file the appropriate follow-up issues (or just make a PR if possible) that will land in 4.2.
Thanks all for your efforts here, this is way better.
I would be happy if it's just me. I'm on a Windows 10, x64 VMWare image (from Modern.IE) running:
All whilst running NVDA 2018.3.2 and not running any screenreader software.
It happens in all of them, so maybe it is a VM bug...
I guess It's really your VM. I've re-tested on Windows 10 without a screen reader running:
With a screen reader (NVDA, JAWS) running no, the saturation/lightness control does not work with a keyboard. It needs the fix suggested previously. Will prepare a quick PR.