Experimental Design for Character Counters on Text Fields

[davidmpickett]

What

Some text input fields in the Drupal CMS have a maximum character limit. The Character Counter lets users know what this limit is. It can appear on both the simple textfield widgets and the larger textarea widgets.

Purpose

AS A Drupal CMS editor
I NEED real-time feedback while typing in a text field
SO THAT I can stay within the character limits

Usage

As of Jan 4, 2024:

• 132 of 921 total fields (14%) in the Drupal CMS are text fields that must have character limits
• 226 of 921 of total fields (24%) in the Drupal CMS are text fields that could have character limits
• ??% text fields that have character limits are displaying a character counter
  • This is unknown because there's not currently a good way to audit this
  • The discrepancy arises because string & text fields always have a character limit, but Site Builders can choose a widget that doesn't show a chracter counter
  • On the other hand string_long, text_long, & text_with_summary fields can only have a character limit if they use the "with counter" widget variant.

Field type	Machine name	Character count rules	Widget	Current # of fields
Text (plain)	string	255 max (but can impose a shorter limit)	Textfield with counter	131
Text (plain, long)	string_long	Optional	Text area (multiple rows) with counter	43
Text	text	255 max (but can impose a shorter limit)	Textfield with counter	1
Long Text	text_long	Optional	Text area (multiple rows) with counter	48
Long Text with Summary	text_with_summary	Optional	Textarea with a summary and counter	3

Behavior

Current behavior

The character count updates to indicate how many characters are remaining.

When the user is between 5 and 0 characters remaining, an orange warning border is applied to the text field.

When the user goes over the character limit, a dark red border is applied to the text field.

\

Desired behavior

State 1 - User has not entered any characters

• Display the message "@maxlength characters allowed"

State 2 - User has entered more than zero characters and <= character limit

• Display the message "@remaining_count characters remaining"

State 3 - User has entered more characters than the character limit

• Display the message "@overlimit_count characters over limit"
• Change the styling of the text to bold and red

No border should be applied to the text field in any state (aside from existing focus border).

Examples

We would like this to function the same as the USWDS character counter

Drupal Modules

Character counters are controlled by the Textfield Counter module.

The module currently only allows for one status message to be displayed. I have drafted an upstream issue to request the module be updated to allow the status message to change based on the current state.

Accessibility

See USWDS notes

Guidance

General guidance for "with counter" widget settings

• SHOULD set Counter position to After so the counter displays below the text area
• SHOULD check Add javascript validation
• SHOULD set status message to <span class="remaining_count">@remaining_count</span> characters remaining
• CONSIDER that you can have fake character limits. That is, you can display a character limit here without enforcing it. This is set with Count only mode (no validation)

Field Type guidance

Text (plain)

• SHOULD use the Textfield with counter widget. Since this field always has a character limit, we should always make users aware of that.
• EXCEPTION: fields that are only used for data migration and not editable by users don't need to show a character counter
• CONSIDER these standard character limits: 70, 100, 255

Text (plain, long)

• SHOULD NOT be used for text input that will always be less than 255 characters. Use Text (plain) instead
• CONSIDER these standard character limits: 300, 500, 1000

Text

• SHOULD NOT use this field type. It doesn't offer any unique advantages.
• CONSIDER Text (plain) or Long Text instead
• If you decide to use this field type anyway, you SHOULD use the Textfield with counter widget. Since this field always has a character limit, we should always make users aware of that.

Long Text

• SHOULD only use this field if you want to allow editors to add formatting (Rich Text or Limited Rich Text)
• CONSIDER these standard character limits: 300, 500, 1000

Long Text with Summary

• SHOULD only use if you know why you need a summary
• CONSIDER these standard character limits: 300, 500, 1000

CMS Collab Cycle

This pattern came out of feedback from the VBA Regional Office CMS collab cycle.

Research (optional)

Depending on timing, we may be able to investigate this during #15976

Next steps

Send a message in the #cms-design channel letting the CMS team know that this request has been submitted and include a link to this ticket.
A designer on the CMS team will review this request and will reach out to you if they have questions/comments/concerns.
If your request is approved, you can add your component or pattern to the system.
If you have any questions on how to add your component or pattern to the system, please reach out in the #cms-design channel.

[swirtSJW]

I think this looks like great research and is a plan for an ideal character counter. However I do not think the improvement is worth the investment it will take. If we had good data showing our editors are confused by our character counter, then maybe we could make the case for it. But this would be an expensive task to merely get an editor facing interface to meet USWDS. Veteran facing impact would be nill.

[davidmpickett]

Additional cross-team wrinkle. In order to make the character count status messages on VBA Centralized Content consistent with the new guidance here, we would have to update the widget settings on a paragraph type that is primarily used on Public Websites. It's a small config PR, but doesn't make sense for Facilities to merge without Public Websites approval.

cc @jilladams

[davidmpickett]

On the other hand, this change to a character counter on Centralized Content might be okay for Facilities to do without additional CMS team review. I think we previously established that we are the primary users of Centralized Content.

[jilladams]

In this case CAIA are the main editor base for the listed products, and I have absolutely no concerns about the change proposed in #16805, if we opt to go that route.

[davidmpickett]

@Agile6MSkinner I removed the facilities and sitewide tags since any remaining work would be the purview of the CMS platform team