Use color input type in the color.module

Thanks _nod! We're also going to be able to remove the "custom" validation and conversion from the color module. We also have to check the preview correctly keeps updating in browsers that *do* support the color widget. Maybe we should also disable the color picker in that case.

The common way to do feature detection here would be $("<input type='color' />")[0].type === "color".

It's in, it's in!

Maybe we should reconsider having color objects with state. Just something like Color::createFromRgb(), Color::parseHex(), Color::createFromHsl(), Color::getRgb(), Color::getHsl(), Color::__toString() would buy us all permutations.

$hsl = Color::createFromRgb(240, 1, 56)->getHsl();

However I already had a lengthy argument about this, with sun. I should probably ask him what he thinks.

My stance is still the same ;)

1) We introduced the custom Utility\Color class, because there is no simple generic utility class anywhere out there. For the Form API element, we did not want to move these rarely used functions to form.inc, common.inc, or a new color.inc. Thus, we added some simple helper/conversion methods to a PSR-0 class that can be autoloaded on demand. (Some sites might never load this.)

2) For Color module, I can see a point in that it might need a full-blown classed Color object. In fact, the module passes some $color variables around within its code that actually are pristine typed variables/objects. But when reaching the point in that we need more powerful and stateful Color class objects, we should immediately stop to think about writing own code. That would only re-invent the wheel; there are a couple of Color classes out there.

It might even make most sense to collaborate with the #1561832: Replace Image toolkit API with Imagine idea/effort — and apparently, Imagine has a dedicated Color class, too:
http://imagine.readthedocs.org/en/latest/usage/introduction.html#color-c...

(Note: I'm not necessarily saying that we should use this particular Color class. That's just one out of many implementations that can be found on the net. Just google for "php color class." There might be better ones. Just saying that there is a chance that we'll replace image toolkits with Imagine and it has one; but then again, there also hasn't been any progress on that issue yet.)

Triggering bot, will probably need a re-roll though.

Per @Mark Carver : the "color" input type isn't supported by most browsers yet, so postponing this on #1957400: Improve Color's admin interface on touch devices

Updated issue summary.

Updating format.

Updated issue summary.

I am pretty sure it's now supported on FF 29. Just nudging this along, but this might need to be moved to D9 anyways.

In my opinion, having a simple text box where you can type in a hex value is an perfectly accessible fallback, the colour picker is an enhancement. We could decide to implement the colour input type and then decide on a polyfill in a follow up.

Triggering testbot

http://caniuse.com/#feat=input-color

Still less than 50% support (only FF and Chrome).

Also, this is still a feature request (want), not suitable for 8.x at this point.

As @Bojhan mentioned in IRC, we can possible roll this out in 8.1+ once we get more support for this input type in most browsers. Leaving postponed until then.

Opera & Android support it now too.

This is now available to 93% of users so I think we can un-postpone?

https://caniuse.com/input-color

Reroll from #10.

Removing custom validation for color_scheme_form

Also, just realized that color.js was edited directly in #32

The code looks great but I think this could do with some screenshots in different browsers so we can confirm that it looks usable everywhere.

Manual testing surfaced some issues:

• There are styles applied to the inputs that now don't look right
  
• Color inputs trigger a native color picker, yet a now-useless Farbtastic picker is still present. This will likely confuse users
  
• The "lock" functionality does not currently work with these as color inputs.

Addressing the above would likely require some pretty complex conditional logic to apply different styles and lock behavior based on native support vs Farbtastic. However, https://caniuse.com/input-datetime shows that the only browsers that don't support native color pickers are IE11 (which we're looking into getting rid of for 11) and Opera Mini (which I suspect is rarely used to interact with the color module)

My proposed solution is for the color module to stop using Farbtastic and have IE11 and Opera Mini use text inputs instead of color. A similar solution was implemented on date inputs here: #3072906: Deprecate and remove jQuery UI datepicker. In that issue, browsers that don't support native date inputs now use a text input. Seeing how this was acceptable for ALL date fields in Drupal, I think it's acceptable to do something similar to a handful of inputs provided by the color module, particularly since there's wider browser support for color than there is date.

I suspect a release manager would need to approve this proposed solution, so tagging accordingly.

I am removing the Novice tag from this issue because there isn't anything actionable to do until @bnjmnm's proposed solution for browser compatibility is reviewed.

Adding the "remove jQuery from Drupal" issue as a parent issue since Farbtastic is a jQuery library that needs to be removed/replaced as part of those efforts.

We discussed this today at the Weekly Usability meeting and we didn't see any concern with removing the color picker option for IE11 users because they still could add the color manually as a fallback, and even more if a note is added as @bnjmnm mentioned. So +1 to this.

Changes in this patch

• Removes all Farbtastic functionality from color-related JavaScript (Farbtastic itself hasn't been deprecated and removed from library definitions yet, though.)
• Refactored "lock" and preview functionality to work with native color inputs.
• Adds a warning to IE11 users, the only supported browser that doesn't support native color pickers. IE11 users will need to enter hex values into text inputs. The "lock" functionality and preview still work, and the hex values are validated on submit.
  
• Added a Drupal.colorUtils object with utilities for converting values such as HSL to Hex. Most of these functions are taken from Farbtastic and updated to meet Drupal CS.

Among the tasks that still need to be done:

• Deprecate farbtastic and remove from all library definitions. This includes some test libraries, so tests may need to be updated to reflect these changes too
• JS needs updated docblocks and comment to reflect the changes made.
• Add license info to make it clear that Drupal.colorUtils is based on Farbtastic utility function.
• Add some content to the change notice
• Update issue summary.

Updated the issue summary. Not sure if we should deprecate Farbtastic here or defer that to a followup, as it is used by a handful of tests and maybe that is better off unpicked elsewhere.

It just needs to make color picker form element to apply different library behaviour

The HTML colour input type (like many of the new HTML5 input types) has poor accessibility support.

Accessibility has barely been mentioned in this issue. Lewis mentioned it back in comment #11 7 years ago:

In my opinion, having a simple text box where you can type in a hex value is an perfectly accessible fallback, the colour picker is an enhancement.

That sounds OK... kind-of, but it contains some false assumptions: (1) that there is a text box you can type in, and (2) that you can just use the text box and avoid having to use the colour picker. This turns out NOT to be the case in some user-agents.

e.g. Chromium on Android with Talkback (I tried Chrome and Edge on Android 9):

• Test page: https://a11ysupport.io/tests/html/html/inputs.html
• The colour input can be focused by swiping to it. GOOD.
• The input type is announced: "colour picker". GOOD.
• The current value is announced as a hex value, including the hash sign: "#E66465". GOOD... however see later for a UI mismatch.
• Activating the input brings us to a pop-up box....
• The name of the pop-up is announced: "select colour". GOOD
• The fact that it's a pop-up isn't announced, i.e. it doesn't convey a "dialog", "listbox" or whatever. MEH, not a complete disaster.
• High weirdness now starts...
• When the pop-up appeared, it also announced "Red, 1 of 2, in list, 2 items".
• But I can actually see that seven colour swatches are shown (in 2 rows). I can swipe through them too, hearing announcements of "cyan", "blue", "green", .... So the "1 of 2" is very confusing.
• Note that "red" ISN'T the current value of the input, it's just the first swatch.
• When I get to the 5th colour swatch it announces "magenta, 2 of 2". Huh? This is the 5th colour! Turns out the list items represent the 2 visible rows of colour swatches, not the 7 colour swatches. This seems like a bit of a WTF for orientation.
• Note the mismatch between the format that the colour was first announced in (a hex code) and the human-readable names in the colour swatch.
• After the 7 visible colour swatches, I hear "white". Oh, there are actually 8 colour swatches! That's not obvious visually, because the background of the whole pop-up is white. MEH, that might confuse a sighted speech control user.
• After the colour swatches, there is a "more" button. Activating it changes the content of the pop-up to show 3 range sliders, for hue/saturation/value. Note the format mismatch again. We were told a hex code when we first focused the input, before activating the pop-up. Hex codes are really RGB using hex instead of decimal. But now we're in a HSV which is a different colour model. That might be nice for designers, but RGB would be more familiar to mainstream users. BAD.
• When I move to the hue range slider, it is reported as a percentage. A blind user may have no idea what sort of colour the percentage relates to (e.g. the cyan portion is around 55%). Besides, HSV are normally conveyed as decimal from 0-255. Percentages don't seem right here. BAD.
• The saturation/value components are percentage sliders too. This isn't so bad, but it does assume you know which end of the scale is which.
• There are no text inputs anywhere in this colour picker. So if I happen to know the colour I want as a hex or RGB, or even HSV, then I can't input it. I'd have to figure out what my colour is as a HSV percentage. So it doesn't meet Lewis's criterion from comment #7. BAD BAD BAD.

And that's just one browser/AT/OS combination.

Detailed manual test results of the colour input from 2019 paint a poor picture for lots of other common browser/AT/OS combinations. It's looking dire for speech control users.

None of this is Drupal's fault, but it is our problem.

Replacing an old library is an understandable motivation, but replacing it with something which has poor accessibility is doing a diservice to our users, and doesn't meet our values.

I'd urge extreme caution here (i.e. exercise a veto). The HTML colour input is NOT fit for purpose (per WCAG's "accessibility supported" conformance requirement). "Works on Safari/Voiceover" won't suffice. If we want to ditch our old library, we need to replace it with a better one, not just foist the HTML colour input on users.

Diving into this a bit (we’re hoping to implement color-choosing within Olivero).

A good deep dive on color picker accessibility is at https://css-tricks.com/color-inputs-a-deep-dive-into-cross-browser-diffe...

Reading through and testing these, @andrewmacpherson, I agree that it’s not accessible enough.

However in some browsers, the color picker does seem to be accessible and provides decent utility to keyboard users.

How the Color module works

The color module provides simple text inputs, which JS grabs ahold of and generates the color picker. The color picker itself is not focusable. The text inputs are.

Proposed solution

I propose that we keep the primary form control to be a text input. However, I also propose that we use vanilla JS to create a HTML5 native color input. Both the text inputs and color inputs would have `input` events bound to each other so they would always stay synchronized. We could also add form validation to ensure that the hex value is valid.

This solution would enable the current accessible utility of how the color module works. However it would remove farbtastic, and rely on the native color picker (which seems to be accessible in certain browsers) for color picker functionality.

Here is a quick and dirty example of what that could look like (note this has no form validation, which would need to be added):
https://codepen.io/mherchel/pen/poWZZPK

Especially considering that Farbtastic is now read only (unsure when that happened), I think some form of the solution in #56 should be added to core. The value can still be updated via text input, so there's no regression in that respect, and it's very unlikely that native inputs are somehow less accessible than Farbtastic, despite their well-documented shortcomings.

There is a use case I'd like figured out:
It seems beneficial for the native color picker to be focusable, but that means there are two focusable elements for updating a single field. Visually, this relationship is clear (as evidenced by the Codepen in #56). I'm not sure how to best convey this relationship to AT. It's possible there's is a common pattern that I've forgotten.

It may also be worth looking into a visually hidden bit of help text making AT users aware of the accessibility limitations of datepickers, and recommending the text field be used instead.

I think if these are taken into consideration, it will offer equivalent-at-worst accessibility, with the added benefit of native color pickers improving in the future without Drupal having to do anything vs. Farbtastic being frozen in time.

@bnjmnm - would the correct version simply be to have a label element without the 'for' attribute and use aria-labelledby on the inputs?

https://stackoverflow.com/a/31274644

I like the idea of the move. Native support is usually more accessible.

Is there a link to the Chrome bug. Always useful to have links to and from Drupal to upstream barriers.

I'd have to see how the focus is set to see if it is a problem. Definitely want it to be intuitive for keyboard only users.

I reopened the discussion to deprecate Color today. (Even if it does move to contrib, I think this issue is still the right path forward for the contrib module, but it's less of a hard D10 blocker if we end up deprecating the whole module.)

Color has been removed from core, #3270899: Remove Color module from core.

The parent issue is in core and that doesn't really makes sense since this is in contrib. Moving that parent to related to help retain the history.