Fix typo in input placeholder color class

[acelaya]

Part of hypothesis/client#6866

This PR does two things:

1. Fix two typos in Input tailwind classes around placeholder text color.
2. Consolidate Input and Textarea text color and placeholder color, following the changes in Improve contrast ratio in annotation textarea client#6966

Inputs were previously inheriting the text color from the page, having inconsistent values. Now we settle to grey-8

The previous placeholder color (even though it was not working due to the typo mentioned above) was too light in contrast with white background. Now we settle to grey-6, which has more than 4.5 contrast, as required by accessibility guidelines.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (fa1617d) to head (9f84354).
Report is 11 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##              main     #1940   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           70        70           
  Lines         1316      1316           
  Branches       486       486           
=========================================
  Hits          1316      1316           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[robertknight]

Inputs were previously inheriting the text color from the page, having inconsistent values. Now we settle to grey-8.

Are there any cases where we do want to inherit the color that you can think of? For example input fields that set the text to red if there is an error or something. Do we have a mechanism to do that if needed?

[acelaya]

Inputs were previously inheriting the text color from the page, having inconsistent values. Now we settle to grey-8.

Are there any cases where we do want to inherit the color that you can think of? For example input fields that set the text to red if there is an error or something. Do we have a mechanism to do that if needed?

Our existing feedback capability only changes the border color ATM.

I can't think on any case where we currently need to change the text color, but I think it would be reasonable to just set the placeholder text and continue inheriting the main text color.

I would in that case do the same in hypothesis/client#6966, for consistency.

[acelaya]

I just checked that, in LMS, client and via, all usages of Input and Textarea inherit the grey-9 text color. The only place where we were setting a different color was the annotations textarea.

So we could just keep grey-9 for all, via inheriting the page color.

[robertknight]

So we could just keep grey-9 for all, via inheriting the page color.

This makes sense as an incremental step. In future we should consider whether we want to harmonize the text color between the client, LMS and other apps.

[acelaya]

Neither text-color-grey-5 or color-grey-6 were valid tailwind classes, but even if they were, grey-5 is too light in contrast with white.

[robertknight]

We really ought to have a lint to check validity of classes. I suspect there was confusion here because we do have some custom text-color-* properties.

[acelaya]

I suspect there was confusion here because we do have some custom text-color-* properties.

Yep, that was also my thinking.

[acelaya]

So we could just keep grey-9 for all, via inheriting the page color.

This makes sense as an incremental step. In future we should consider whether we want to harmonize the text color between the client, LMS and other apps.

@robertknight can you take another look? I have reverted the text-grey-8 class, and just addressed the typos and too low contrast for the placeholder color.

[robertknight]

This change seems like the most straightforward way of addressing the accessibility hazard with placeholder text. It does however mean that contrast is a weaker cue than before that text in an input field is a placeholder. This raises the importance of adding other cues such as adding an ellipsis at the end.

GitHub recently made a similar change across their input fields and it runs into the same challenges.

(Edit: We're having second thoughts on the ellipsis suggestion here: https://hypothes-is.slack.com/archives/C1M8NH76X/p1744210176861699?thread_ts=1744191013.167509&cid=C1M8NH76X)

[robertknight]

We really ought to have a lint to check validity of classes. I suspect there was confusion here because we do have some custom text-color-* properties.