Update Placeholder styles so that contrast ratio passes guidelines

This issue is in, see this commit

Placeholders

Color contrast

The placeholder text color does not meet the 4.5:1 minimum color contrast specified by WCAG 2.0 AA guideline 1.4.3.

Recommendation:

Use #757575 or darker for placeholder text.

Data type for input

The placeholders on the fields should hint at the type of data: plain text, dates, phone numbers, postal codes, using either X or as the placeholder character.

Examples

MM-DD-YYYY
(999) 999-9999
99999-9999
Also, the data type should be specified whenever possible to make data entry easier on handheld devices.

Disabled form fields

Color contrast in disabled form fields is too low with white background.

Recommendations:

The input label text should be equivalent to #757575 or darker on white to have required 4.5:1 color contrast.
The disabled border should have a minimum 3:1 color contrast with the background. An alternative would be to use a darker color with dotted or dashed borders for disabled fields in the visual language.

Focus states

Outlines should be wider to provide more visual contrast for low vision users.

Moving back to active based on recent feedback from @modulist.

Crediting @modulist for the accessibility review. Thank you!

#7 I cannot agree. If the placeholder color is too close to the real input text color, I cannot distinguish which inputs I filled and which ones not. And – IMHO – thats a bigger usability error.

#8 I used a really basic test project to be able to automate screenshot creation. If this is a real issue, that it's a core issue. We won't change placeholders or add new ones in this project as I know right now.

#10 The style that checkboxes or radios have could work? Screenshots here.

Example for #7 from seven: the input in the table is empty, what you see there is the placeholder text.

@huzooka I understand your reservations on placeholder colors from a UX point of view, and I felt them as well when I first started working with accessibility. However, they do present a readability issue for users with low vision or even fully-sighted users looking at a low-contrast screen (like a smartphone in broad daylight).

The minimum contrast success criterion (1.4.3) applies to text in the page, including placeholder text and text that is shown when a pointer is hovering over an object or when an object has keyboard focus. If any of these are used in a page, the text needs to provide sufficient contrast. - WCAG 1.4.3 success criteria

The WCAG standards are what they are, so having insufficient contrast will be a recurring weak point and easy point of attack on Drupal's accessibility.
Seeing as how we are building an authoring tool to be used by millions, we need to play it extra safe with WCAG and ATAG compliance.

We should think out of the box in terms of how we make placeholder text look different from user-submitted input. We have a blank canvas to try out location, border width, icons, an asterisk or arrow preceding the placeholder.

Here is an article that explores some of the more conservative alternatives:
https://uxdesign.cc/alternatives-to-placeholder-text-13f430abc56f

@modulist as far as I understand the WCAG guidelines and also got feedback from my local Accessibility community – if there is a label which clearly states what the user can input then it can/will be considered as incidental.

1.4.3: Contrast
Incidental
Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.

Would you agree?

Btw the contrast currently used is 3.12:1. Thanks for another feedback :)

@modulist the issue I described in #13 about the placeholder color affects low vision users the best.

I totally understand your point (following WCAG), but I still think that we may and should reconsider the outcome.

My personal opinion is that the goal here is not (just) following the guidelines, but provide the best possible accessibility level.

This patch is a possible way to address the accessibility issues mentioned above. Fully aware that these changes aren't in the spec - providing them to be looked over here and if they seem like a good approach the conversation can continue in the appropriate places.

Here's a summary:

For placeholder text (#8), the color was changed to #757575 to get the necessary contrast. To better distinguish it from user input, the text is italicized and the size reduced by 10%

For focus states (#10), the border width is increased from 1px to 2.5px.

For disabled fields (#9), the border is dashed and color is an adequate-contrast achieving #757575, the label is also #757575. The field background color is #f2f2f3 and the form value color is #6e6e6e, which has a ratio of 4.55:1

Is this still an issue? What needs to be done to set this as Fixed?

Yes, currently placeholfers are using #8e929c and it doesn't have enough contrast.
As @modulist pointed on comment #15 WCAG 1.4.3 success criteria of 4.5:1 contrast ratio applies to placeholders too (it's clearly specified on WCAG specification he linked to).
So moving this to Needs design&Needs work since we need to come up with a better solution for placeholders, where we need to take into account comment #16 by modulist and the proposal by @bnjmnm on comment #19.

Changing the title to better reflect the current requirements of this issue. The issue summary should be changed too.

I've updated the input component accordingly. We're using now:
Placeholder: italic, #6E727B (new color: $color-disabled-text)
Filled: text #222330
Disabled: 1px dotted $color-gray-blue, text color: $color-disabled-text, also the label is now $color-disabled-text

See https://www.figma.com/file/OqWgzAluHtsOd5uwm1lubFeH/Drupal-Design-system...

This change should be reflected for inputs, textarea, selects, radio and checkbox (so all input elements).

Added a "updated" flag to indicate the change

Shouldn't we create a new follow-up for this instead of changing the title, the summary and the scope of this issue?

+1 to a follow-up. +1 to continuing discussion here based on Slack conversation 😂

We discussed a bit more about the color to use for the placeholder and we got to use the #727780. Here's the normal screenshot:

And one for the disabled version. Would this be OK on an accessibility point of view?

Updated it in the design system accordingly.

Updated the values in the frontend accordingly. :) Since Claro is in core I didn't provide a patch. Hopefully, I'm doing it right and this patch works as expected.

We still need design for the placeholder of disabled fields. Figma has example only for a disabled input with some value.

@huzooka The placeholder for disabled should be the same as the default placeholder (color disabled-text)

+++ b/core/themes/claro/css/base/variables.pcss.css
@@ -12,13 +12,16 @@
+  --color-lightgray-o-30: rgba(212, 212, 218, 0.3);
   --color-grayblue: #8e929c;
   --color-oldsilver: #82828c;
+  --color-oldsilver-o-50: rgba(130, 130, 140, 0.5);

@@ -88,9 +91,9 @@
+  --input--disabled-bg-color: var(--color-lightgray-o-30);
+  --input--disabled-border-color: var(--color-oldsilver-o-50);

I know these have opacity in Figma, but they really should be the hex code of whatever color they happen to be when they're on a white background. The screenshot in #29 suggests that was the intent. If the inputs aren't on a page with a #FFF BG, the results are often unreadable and/or very strange looking.

Also, if the link in Figma is the agreed design, could the issue summary be updated with a link to that and "Determine the new design solution" crossed out?

Has anyone an idea what these hex colors values should be (or where they're defined)?

The top answer here provides a good explanation if anyone is curious, and these are the values:
rgba(212, 212, 218, 0.3) on white is #f2f2f3
rgba(130, 130, 140, 0.5) on white is #c0c0c5

Thanks for tip!
I've updated the values.

After some tests it looks good to me. The latest change converts the rgba() colors to hex values in case of consistency. Also remove tag because accessibility review is done. Setting it to RTBC

Thanks for working on Claro's accessibility!

It looks like the patch no longer applies, so needs a reroll (again).

I have added re-roll of patch #41.

Verified and tested by applying the patch #47.Attached the accessibility report as well.

After Patch UI -

After Patch Accessibility report -

After Patch Accessibility report -

After Patch Style values -

Moving this to Needs works after #3154539: Implement new Gray scale on Claro has made it. The patch needs re-roll and the colors updated.

This would need to change the current color defined in variables.pcss.css from --input-fg-color--placeholder: var(--color-gray-500); to --color-gray-700, with a contrast ratio of 4.53:1.

Changed the variables.pcss.css file as per #57 and the ran yarn run build:css inside core to get this path.

I'm not sure why the tests failed for patch #58, so I just queued them to run again.
I was able to apply this patch cleanly. It updated the input placeholder color to --color-gray-700 (#75767b) and Wave reported no color contrast errors.
Marking RTBC.

thanks for the patch! i've also successfully applied the patch on a Drupal 9.4.x-dev install on MacOS 10.13.6. I've tested with Safari 13.1.2 and the latest Firefox, Chrome and Edge. Looks good in all of them except Firefox (Version 99.0.1) but i honestly don't know why.

the color value for the placeholder text looks correct with #75767b as well as the computed value with rgb(117, 118, 123) but if you compare the visual output of the placeholder text with the one for example in chrome then it is significantly lighter? :/ (* and i've cleared the caches several times in Firefox)

@rkoller Firefox sets an opacity less than 1. So it can be fixed with opacity: 1;

Changed the patch from #58 to include the opacity: 1; for ::placeholder and adding the changes to the source files which was missing.

thanks for the explanation in regards of the behaviour of Firefox @saschaeggi ! i've retested in Firefox and the visual representation is on par with the other browsers i've also retested.

and tests are green as well so i'll set the issue back to RTBC

Committed 3bcfafc and pushed to 10.0.x and 9.4.x. Thanks!