Color design tools - accessibility issues

[talldan]

As part of #36165, I thought I'd see if I could spot any accessibility issues with the color panel UI.

I'm not an accessibility expert, so these are more topics for discussion where it'd be great if those with more experience could offer an opinion.

I did testing using Safari and Voiceover. It'd be good to get feedback using other screenreaders.

I inserted a quote block and then accessed the tools in the block inspector using the keyboard.

Panel - View options dropdown

The color panel has 'View options' menu for resetting some parts of the UI and controlling visibility of others:

This is something that's common to other design tools.

If a color is set for 'Text', the first menu item is announced by voiceover as '1. Reset text, ticked'. It has the role menuitemcheckbox, which seems incorrect. This is just a button that resets the color so I don't think it should have a checked state and it should also have the role menuitem. I couldn't see where the number '1' comes from, other menu items don't have a number. The label could be a bit more descriptive 'Reset text color' or 'Reset text to default'.

When selecting an option from this dropdown, the dropdown is closed which results in focus moving unexpectedly. I thought that might be because the button suddenly becomes disabled, but it also happens for other menu items that don't do this. It might be a good idea to use only aria-disabled for these disabled menu items so that they can still be focused.

It'd be good to get some more feedback on whether there's enough information about what this menu does. I'm not sure it's obvious enough. An option could be to make some of the actions announce what effect they had using the speak utility from the @wordpress/a11y package.

Foreground/Background Popover

Keyboard navigation

I tried using arrow keys with Voiceover to navigate through content, and it resulted in the popover being closed unexpectedly.

Tabs

The first thing I noticed is that the use of radio buttons for switching between Solid and Gradient might be incorrect:

The radio buttons don't have any associated context (usually there would be a paragraph or heading that acts a bit like a label before a radio button), so it's unclear what they do and that the content of the popover below is changed as an outcome. Particularly since the block doesn't actually show a gradient when this option is selected, further options have to be chosen. These buttons seem more like tabs, but the implementation is different to the tabs in the Block Inspector, which just use role="button" and more explicit aria-label ('Block (Selected)'). There is also a role="tab" (example here - https://www.w3.org/TR/wai-aria-practices/examples/tabs/tabs-1/tabs.html), but I don't know how well supported that is.

I wonder if there's an opportunity to reuse or update and use TabPanel from the components package here (https://wordpress.github.io/gutenberg/?path=/story/components-tabpanel--default).

There seems to be a bug (at least in Safari), sometimes the selected radio button has a white background and white text when opening the popover:

Theme colors

The theme colors often have lacking descriptions like 'Foreground' and 'Background'. I think that's particularly confusing because you can choose a color called 'Foreground' for the 'Background'. On the other hand the Custom Color Picker button has a really descriptive label (e.g. 'Custom color picker. The currently selected color is called "Foreground" and has a value of "000000"').

Color buttons

I did wonder whether the color buttons should be radio buttons, but then they can be deselected, and I think that means they can't be radio buttons.

[ramonjd]

Would the color contrast checker be eligible for inclusion?

There are a few open issues https://github.com/WordPress/gutenberg/issues?q=is%3Aissue+is%3Aopen+color+contrast+

Furthermore, I ran into some peculiarities while enabling it for alpha and link colors.

For example:

• Coming up with the right "fudge" to check contrast on semi-transparent backgrounds (probably no satisfactory solution)
• The contrast checker will test and warn about unreadable global styles colors even though the user hasn't interacted with the panel.

[talldan]

@ramonjd Yep, I think it's worth including it 👍

Thanks for the reminder.

[joedolson]

The tools panels have been pretty thoroughly refactored since this issue was raised - I can see that most of the issues are no longer present. The controls aren't menuitemcheckboxes anymore, the labels are clearer, everything works from the keyboard (in a quick inspection, anyway.)

There are still problems with the theme colors, but those are ultimately a theme problem; the colors should probably provide more usable context when named by the theme.

Should this be closed?