Accessibility

[Nettsentrisk]

For use in Europe, the picker needs to be accessible.

A standard input[type=color] should maybe be polyfilled with the functionality provided, and WAI-ARIA used to tell screen readers what's going on. It also needs to be keyboard accessible.

:)

[simonwep]

Seems important and should be. Good idea! I will, relating to "keyboard accessible", add some shortcuts to picking, saving etc. But could you please provide some information where placing aria tags would make sense? I'm unfortunately not familiar with this and don't want to place some nonsense.

[Nettsentrisk]

Keyboard shortcuts are by and large not considered very accessible, since the user would need to learn them to use them.

If you use an input[type=color] as the base element, and polyfill the functionality onto it, then keyboard will be able to focus on the element, and open the color dialog via the click event.

As far as accessible dialogs and ARIA are concerned, this might be of help/inspiration: https://github.com/edenspiekermann/a11y-dialog

[simonwep]

@Nettsentrisk I'm currently trying to improve the tabbing sequence which seems fine to me. Every swatch / button is accessible / focusable and can be clicked via enter. Currently I'm working on adding aria-labels. Are there any more things which need to be done to cover everything (or almost everything) which is required to be accessible?

[Nettsentrisk]

Any reason you don't base it off the input[type=color] element? I assume you can restyle that to however you want using appearance: none etc. That would allow it to function in a standards-based manner, and then you're progressively enhancing the experience with your code on top of that.

aria-controls and related aria attributes should probably be added when the component is initialized to tell screen readers about the dialog being opened to allow them to pick the color.

[sebastian-marinescu]

The color-picker-overlay itself seems like a dialog which would bring more aria-implications, like:

• aria-hidden="true" while it is hidden
• aria-hidden="false" while it is visible
• role="dialog and maybe aria-modal="false" (because user can interact with background)
• aria-labelledby="headerElement" or aria-label="Color Picker"

Sources:

• https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/dialog.html
• http://accessibility.athena-ict.com/aria/examples/dialog.shtml

[simonwep]

@Nettsentrisk The appearance attribute is only available with a vendor-prefix which I try to avoid since the behavior may differ. Basing it now on top of existing HTML5 would need refactor quite a lot and I also cannot style it exactly how I want. I'd rather add missing aria labels etc. I can for now add these which got mentioned by @sebastian-marinescu But I'm not an expert in this, any help is highly appreciated! :)

[Nettsentrisk]

You could progressively enhance the control by it first being input[type=color] and then when the script runs, you change it to whatever and style it however, so that if anything goes wrong with scripts on the page, at least you're falling back to an HTML standard input type.

As fas as using the appearance property in CSS, libraries like Bootstrap use this so it is widely used. The browsers that don't support it don't support input[type=color] either, so those would nonetheless default to showing a regular text input field when they don't understand the input type.

As far as whether to see it as a dialog, I would warn that this is the definition used in the HTML spec:

A dialog is a window overlaid on either the primary window or another dialog window. Windows under a modal dialog are inert. That is, users cannot interact with content outside an active dialog window. Inert content outside an active dialog is typically visually obscured or dimmed so it is difficult to discern, and in some implementations, attempts to interact with the inert content cause the dialog to close.

That would not seem to apply here, as you're not making the content under/around the color picker inert, thus it would not be seen as a dialog. I erred in using the term "dialog" earlier, but I meant the little box that pops up when you are using this control. You can still get inspiration for how to use ARIA when it comes to dialogs, as some of the same concerns apply.

[sebastian-marinescu]

I concur with the input[type=color] suggestion, as progressive enhancement of websites and their controls is a very good thing. Also it would make pickr more usable in a standard form and as a drop-in-replacement/-enhancement for legacy input[type=color]-color-pickers...

Regarding the dialog, I was reading the dialog-role definition on MDN:

Dialogs are generally placed on top of the rest of the page content using an overlay. Dialogs can be either non-modal (it's still possible to interact with content outside of the dialog) or modal (only the content in the dialog can be interacted with).

That's how I got the misconception. So for now definitely aria-hidden and some aria-label are safe to use, as the dialog might continue...

[NateSeymour]

Hello, my name is Nathan and I have been assigned to fix and close this issue. As I see, there are two types of impairment that we need to be concerned about:

1. Visual Impairment
2. Physical Impairment

For visually impaired users, we simply need to make sure that the user is able to correctly identify the the button element to open/close pickr and the pickr "dialog" when it is open while using a screen reader. We should be able to accomplish this using ARIA attributes.

For physically impaired users (i.e. users that are unable to operate a mouse), we need to make sure that the tab order is setup correctly.

As for progressive enhancement, I currently see no worthwhile benefit to using input[type=color] polyfills and they would add unnecessary bulk to the application, but anyone is welcome to try and change my mind :)

[NateSeymour]

In 4a9e3ca I have added enough ARIA support, tabindex and keyboard integration (not keyboard shortcuts, standard keyboard functionality like being able to use the arrow keys on the selection palettes), that pickr is able to be navigated and understood by anyone using a screenreader and operated by anyone unable to use a mouse.

If you have any other questions/comments/concerns, please let me know :)

Otherwise this issue is closed.

[brianteeman]

that pickr is able to be navigated and understood by anyone using a screenreader and operated by anyone unable to use a mouse.

Yes you are able to move around with keyboard and there is some indication of where you are for the screenreader but there is no indication of what colour you have selected so it cannot be understood. Below is an animated gif recording of navigating with a keyboard and the text that will be announced by a screen reader.

Hopefully you will see the problem

For comparison here is a super basic picker where you can see that the selected color is announced

[brianteeman]

A super quick idea that would be worth investigating is to add aria-live="polite" to the pcr-result https://github.com/Simonwep/pickr/blob/4b030b05a447d25a86fdcc0d7bda8c3cd5c6a1f9/src/js/template.js#L37

This would have the effect of announcing the color code every time the content of that input changes.

However there is a caveat. Assistive technology will initially scan the document for instances of the aria-live attribute and keep track of elements that include it. So you can update it but not create it with JS

A better and more detailed explanation of that can be found here https://bitsofco.de/using-aria-live/

Javascript is not my thing so you probably dont want me diffing into your code ;)

Hope this helps

[simonwep]

@brianteeman Thanks for your time looking into it! I'll take a closer look at it in the next days :)

[adityatoshniwal]

<input :ref="result" class="pcr-result" type="text" spellcheck="false" ${hidden(c.interaction.input)}> also need to have aria-label. If you say I can raise pull request for this.

[simonwep]

@adityatoshniwal That'd be awesome :)