color picker best practice

[Ennoriel]

As the author of a color picker library, I'd like to make it as accessible as possible (svelte awesome color picker). However there is no such thing as a 2 dimension slider documented anywhere.

The thing is also that the most common color representation is the HSV one which is not very intuitive to explain in labels.

At the moment, the color picker is made of 2 distinct areas:

• a Hue, Saturation, Vibrance (brightness) and Alpha (transparency) pickers with the Saturation and Vibrance being a 2 dimensions picker.
• Inputs either hexadecimal, RGB or HSV.

I have troubles with the 2 dimensions picker to compute the aria-min, aria-max, aria-valuenow and aria-valuetext properties. The role and keyboard events are also not standard...

I am thinking of dividing the picker in 2 distinct keyboard selectable sliders for each property but would that be better? What would you suggest otherwise? Would that fit in the design patterns?

I have a work in progress version of the picker where I display the 3:0, 4.5:0 and 7:0 contrast levels within the picker and really don't know how to make it accessible the right way.

[JAWS-test]

A two-dimensional slider is currently not defined. I see four possibilities:

1. split on two one-dimensional sliders.
2. two-dimensional slider with operation hint (aria-describedby) that arrow key operation is possible in 2 dimensions and use of aria-valuetext to output the values
3. addition to ARIA specification of slider, so that two-dimensional slider is allowed
4. additional alternative input possibility to the slider: input of values via spin button

Please note:

• operation hints should not be in the aria-label (you have the hint for arrow key operation there).
• the normal sliders do not need a hint for arrow key operation (you currently have it there)
• the colorpicker should not be opened automatically when the buttons are focused, but only after activating the buttons - a keyboard user might want to navigate over the button and not be "trapped" in the colorpicker
• the colorpicker should be able to be closed with ESC
• for blind users the exceeding of a limit value concerning AA or AAA WCAG contrast requirements can be transmitted e.g. via Live Region

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed color picker best practice · Issue #2742 · w3c/aria-practices.

The full IRC log of that discussion

<jugglinmike> subtopic: color picker best practice · Issue #2742 · w3c/aria-practices
<jugglinmike> github: https://github.com/w3c/aria-practices/issues/2742
<jugglinmike> Matt_King: There have been plenty of people who have requested a two-dimensional color picker over the years. This appears to be one of those
<jugglinmike> Matt_King: The response from JAWS-test appears to address the possibilities pretty well
<Jem> https://svelte-awesome-color-picker-git-feature-contrast-level-ennoriel.vercel.app/open
<jugglinmike> Matt_King: I'm unable to access inputs on the provided demo page
<jugglinmike> [the group discusses the demo's visual behavior]
<jugglinmike> Matt_King: Ah, if I turn off JAWS's virtual cursor, I get a different experience
<jugglinmike> MarkMcCarthy: the inputs have ARIA labels, but they're on DIV elements without a role. That's probably why JAWS isn't announcing them
<jugglinmike> Matt_King: Maybe the values are changing on my system, and it's just that JAWS isn't reporting the changes
<jugglinmike> MarkMcCarthy: I'm not sure what role you would give to these, though
<jugglinmike> Matt_King: It seems like you could make a slider that changes two different values, but not three different values. ARIA doesn't support that
<jugglinmike> MarkMcCarthy: JAWS-test has covered everything I can think of
<jugglinmike> Matt_King: ARIA might already have an open issue for a two-dimension slider, but if not, it seems reasonable for ARIA to support it.
<jugglinmike> Matt_King: I think it would mean a new role
<jugglinmike> Matt_King: Or maybe a new value for aria-orientation
<jugglinmike> Matt_King: Then again, you can achieve this with two sliders
<jugglinmike> jugglinmike: But with two sliders, you can't change both dimensions simultaneously--you have to tab back and forth between them
<jugglinmike> MarkMcCarthy: Yeah, supporting that "free movement" would require something new from ARIA
<jugglinmike> Matt_King: So this could re-use the "slider" role, but maybe a new value for aria-orientation like "both"
<jugglinmike> Matt_King: That's an ARIA problem, though. Here in APG, there's not a great solution right now, other than offering two sliders. They just need to make sure their inputs have the "slider" role
<jugglinmike> RRSAgent, end the meeting
<RRSAgent> I'm logging. I don't understand 'end the meeting', jugglinmike. Try /msg RRSAgent help
<jugglinmike> Zakim, end the meeting

[Ennoriel]

Before trying the first option "split on two one-dimensional sliders.", I am implementing a simple slider and ran into something that I don't understand.

• The slider pattern says: The element serving as the focusable slider control has role slider.
• The slider multi thumbs says: Each element serving as a focusable slider thumb has role slider.

I thought that in the first case, a wrapper serving as the slider should have the role slider (and all aria-* attributes) and in the second case, both slider thumbs.

But the two first examples of the (single) slider pattern are implemented differently:

• RGB sliders: the role is set on the slider
• temerature slider: the role is set on the thumb

Setting the role on the thumb makes it much easier to implement a single component with eather one or two thumbs.

What is the final recomandation?

[JAWS-test]

I don't know if the different implementation was done on purpose. I think it doesn't matter where the role=slider is located. It only matters that role=slider is at the same element that gets the keyboard focus.

• Advantage of role=slider on the whole element and not only on the thumb is that there is also a correct output on mouseover (e.g. when using a screen magnifier or other speech output used in conjunction with mouse operation).
• The advantage of role=slider on the thumb could be that the thumb could be displayed automatically in the visible area more easily at large zoom levels (see WCAG 1.4.4 and 1.4.10) when using the keyboard (unfortunately, this is not currently the case for both examples from the W3C).

[Ennoriel]

After some time, I came up with a new slider component library and made a new version (in beta at the moment) of my color picker library. I used 2 sliders for the picker region, one vertical and one horizontal. On both documentation sites, there are examples and I would be glad to discuss with you if every requirement is met.

In addition, about this advice:

• for blind users the exceeding of a limit value concerning AA or AAA WCAG contrast requirements can be transmitted e.g. via Live Region

I am not sure to know what it means. Could you please explain it?

[JAWS-test]

I am not sure to know what it means. Could you please explain it?

When the slider is operated, the system automatically displays whether the WCAG contrast requirements are met. This is not perceptible with a screen reader. A live region can therefore be used: https://w3c.github.io/aria/#aria-live

[JAWS-test]

At https://svelte-awesome-slider.vercel.app/ the contrasts of the slider bar are not sufficient. e.g. first example: left light blue to white 1.3:1, right 2.1:1.

When operating the slider with page up/down or Pos1/End, the page is scrolled and the slider is no longer visible

[JAWS-test]

At https://svelte-awesome-color-picker-git-v300-ennoriel.vercel.app/ the contrasts are also insufficient (e.g. white text on orange for insufficient contrast has only 2:1; form fields do not have sufficient contrast)

If the pop-up is opened with the colour picker, the focus is not set in the pop-up. In addition, the keyboard focus does not remain in the pop-up.

The buttons to change the colour model are well labelled for blind people, but visual labels do not match, which is a violation of WCAG 2.5.3

Transparency is not taken into account when calculating WCAG contrasts, so that incorrect results are displayed

[Ennoriel]

Thanks for all the feedbacks!

I took them into account for both libraries:

• https://svelte-awesome-slider.vercel.app/
• https://svelte-awesome-color-picker-git-v300-ennoriel.vercel.app/

Don't hesitate to let me know if I implemented them correctly or if you find something else that could be improved!

However, I did not understand how to use aria-live:

When the slider is operated, the system automatically displays whether the WCAG contrast requirements are met. This is not perceptible with a screen reader. A live region can therefore be used: https://w3c.github.io/aria/#aria-live

Would you have an example of how to use it?

[JAWS-test]

Don't hesitate to let me know if I implemented them correctly or if you find something else that could be improved!

I won't look at the examples again, firstly I don't have time for that, secondly this is not the place for individual advice and thirdly you might get too one-sided a picture if only I comment - actually others should take part in the discussion

[JAWS-test]

Would you have an example of how to use it?

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions

Important for live regions: The (usually empty) live region must already be in the DOM (e.g. <div aria-live=polite></div>). A short text is then inserted into the live region using JavaScript ("Contrast too low", so that the DOM then looks like this: <div aria-live=polite>Contrast too low</div>). If further changes are made, the same live region (which now already contains text) can be used to have new messages output by the screen reader. The new text is inserted using JavaScript and the old text is removed. However, it is important to avoid filling the live region with text every time a value is changed in the colour picker, as long as the text does not change (e.g. repeatedly inserting "Contrast too low", because every operating step would then be associated with unnecessary screen reader output). The live region is only filled with text when the status changes (from too low to sufficient or from sufficient to too low)

[Ennoriel]

Thanks for the documentation and the many advice you gave me.

I am not an expert with this at all. Working with live regions is tough. I'm not very confident about how I should implement it. With one of the speaker I've installed, the live region is sometimes announced before the value change, and sometimes after and I didn't succed to find a way to announce not too much change and not too little by still being clear about what is meant by one of the contrast too low / good enough.

I'm still thinking...

[JAWS-test]

Yes, live regions do not work very reliably and consistently. Then simply leave out the live region and offer a way of using the screen reader to see in text form which WCAG thresholds are not met