Implement accessibility based on ARIA practices

[web-padawan]

Hello 👋
I've been thinking about making the color picker accessible, and I would like to discuss the related changes.

It looks like for Hue and Alpha sliders we can follow WAI-ARIA authoring practices. See also the example.
I'm not an expert, but presumably the same approach should work for Saturation as well.

There are following open questions that come to my mind:

1. Implementing this would require to figure out what the proper step value per arrow key press should be.
   Should we make this step configurable? Maybe not as pubic property, but a protected one.

2. Note that Page Up and Page Down allow to change value by multiple steps (10 steps in the example).
   Should this be configurable as well?

3. Proper support for screen reader announcements would require to provide a way for setting aria-label on the pointer elements. It could be done either with individual props or by passing an object with the following structure:

i18n: {
  alpha: 'Alpha',
  hue: 'Hue',
  saturation: 'Saturation'
}

I'm going to prototype some of these changes in vanilla-colorful so I will create an issue there as well.

[omgovich]

Hi @web-padawan! I started working on that few days ago. So I'm glad that we're on the same page =)

I already added tab-based navigation (tabindex="0" and :focus styles) and additional attrs like role="slider" and aria-valuenow="0" things.
Going to add keyboard navigation soon.

I'm still not sure what should I use for the Saturation area (I mean role="slider" or something else). I'm also not a pro in terms of a11y.

P.S. I'm using this picker as a reference, but not sure that the author has done everything right there.

[omgovich]

Regarding aria-label values: we could make them static at first.
I think it would be easier to release a11y features one by one.

P.S. Our primary component's name is saturation, but probably that's not a proper name for that because users don't choose saturation only there, but a brightness as well.

[omgovich]

Note that Page Up and Page Down allow to change value by multiple steps (10 steps in the example).
Should this be configurable as well?

10% shift per click sounds good I think.
Also, I liked the thing that Vadim mentioned during the podcast — we should move it by ~1% if the user keeps the option pressed. Let's keep that in mind.

[web-padawan]

I checked some of the existing color pickers and found the following alternatives:

Link with assistive text

Used by Lightning design system: https://www.lightningdesignsystem.com/components/color-picker/#Open

<p id="color-picker-instructions" class="slds-assistive-text">Use arrow keys to select a saturation and brightness, on an x and y axis.</p>
<div class="slds-color-picker__custom-range" style="background:hsl(220, 100%, 50%)">
  <a class="slds-color-picker__range-indicator" style="bottom:45%;left:46%" href="#" aria-live="assertive" aria-atomic="true" aria-describedby="color-picker-instructions">
    <span class="slds-assistive-text">Saturation: 46%. Brightness: 45%.</span>
  </a>
</div>

Slider with aria-valuetext

Used by Shoelace: https://shoelace.style/components/color-picker?id=inline

<div part="grid" class="color-picker__grid" style="background-color: rgb(255, 0, 0);">
  <span part="grid-handle" class="color-picker__grid-handle" role="slider" aria-label="HSL" aria-valuetext="hsl(0, 100%, 90%)" tabindex="0" style="top: 10.5%; left: 100%;"></span>
</div>

Tested both examples on VoiceOver in Safari and they work (the one by Salesforce has no JS to handle arrow keys).
It would be nice to also test on a Windows device using NVDA.

[omgovich]

Hey @web-padawan. I finished the first draft. See #63

[web-padawan]

@omgovich I'm currently looking into the implementation and so far it looks good to me 👍

The only note is that Page Up and Page Down are not supported. IMO it would make sense to use those keys with a bigger offset at for Hue and Alpha sliders, and use 0.01 for arrow keys. This would need some refactoring.