Input

[bameyrick]

Use this place to discuss the Input Component in the ONS Design System

[jrbarnes9]

Use of autocomplete needs more work and guidance regarding its use in survey questions where the integrity of the data could suffer from pre-population

[jrbarnes9]

Raised #275

[jrbarnes9]

Resolved by #2374

[jrbarnes9]

UR reports users are often blind to input hint text, especially on auto-suggest lookups. Propose to increase font-size to base.

[jrbarnes9]

Resolved by #2259

[jrbarnes9]

Resolved by #1177

[jrbarnes9]

Resolved by #2259

[jrbarnes9]

Could we improve the way we handle number input by automatically adding separators in certain scenarios?

For example, automatically adding a comma after 4 digits are entered when asking for a number in pounds

[jrbarnes9]

Linked to #1947

[jrbarnes9]

Selecting an input prefix/suffix should show the tooltip and put focus on the input

GDS have evidence that some users try to click their input prefix/suffix. ONS input prefixes/suffixes are styled similar to a secondary buttons which would further increase the affordance and the likelihood of this behaviour. Putting focus on the input when they are selected would replicate the standard label behaviour. Additionally showing the tooltip when they are selected (if is title applicable) would also help the discoverability of the full form label for mobile/sighted users.

[jrbarnes9]

Raised #2411

[Paul-Joel]

There appears to be an issue with the interaction between accessiblePlaceholder and label>description and/or error.

accessiblePlaceholder works fine in isolation, but the text appears in the wrong location when a description is present.

When accessiblePlaceholder is used when an error is set, the input background colour goes red instead of staying white

With accessiblePlaceholder, description and error set

[daniellecorke]

Resolved by #2971

[AlanHONS]

I believe there's a small visual oversight with any Input that uses the accessiblePlaceholder option?
As the standard ONS Input placeholder text is a lighter shade of grey i.e. #707071 (see image 1) as I'd expect.

However when you use the accessible placeholder feature, like Search placeholder example the placeholder text is shown in same black #222222 as actual entered text.

Which makes it look like text is already entered into that field (see top input vs my lower modified colour input of image 2).

I believe the fix is simply to add an additional declaration of color:#707071; to existing .ons-label--placeholder ?

Initially mentioned on Slack at https://onsdigital.slack.com/archives/CR7LXCA81/p1708016794325049

[daniellecorke]

#3043 raised.

[daniellecorke]

Resolved by #3043.

[AlanHONS]

Character limit checker variant on https://service-manual.ons.gov.uk/design-system/components/input#character-limit-checker doesn't actually provide a working example of this functionality. I believe this is because that example's Nunjucks configuration doesn't actually set any of mentioned charCheckLimit related attributes. Therefore Char limit functionality is not being triggered

[AlanHONS]

Discussed with Design System team. Working example already present on Filter example

[AlanHONS]

In Design System Release 72.10.7 · ONSdigital/design-system you added our requested option for Textareas to display remaining allowed content in estimated words, rather than characters.
However please confirm latest timescales to add the same functionality to Input field Character limit checker?
As we have a journey where we'd like to consistently represent remaining length to users in words, but have both Input and TextAreas within that same user journey

[AlanHONS]

Wanted to highlight a difference in behaviour between Character Limit Textarea and Character Limit Input fields which I feel should probably be resolved.
If you specify the character limit variant of textarea then 'You have xxx characters remaining' text will display immediately and permanently under textarea field, then dynamically update it's text as the user types.
However if you do the same with an input field then the same 'You have xxx characters remaining' text will only display after the user starts to type in this field. Which results in that character count limit not being immediately visible to a user + any later page content being dynamically pushed down another line after initial page rendering.
Not currently a high priority to fix but think it would be better for Character Limit Input to behave consistently with same Textarea variant?

[MagdalenaLarge]

Thank you @AlanHONS for your suggestion.
We’ll investigate this further and let you know once we have an update.

[MagdalenaLarge]

Hello @AlanHONS
Based on the research done by our Interaction Designer, generally we should not have a similar behaviour for both components.

1. Text area (longer answers, higher risk)

• Best pattern: show character limit at all times
  Why this is the best solution:
• Users expect to write more
• Higher chance of hitting the limit
• People often plan their response length.
• Seeing “0 / 500” sets expectations immediately
  This is why your current solution for the text area makes sense.

2. Input field (short answers, low risk)

• Best pattern: show character limit on interaction (focus or first character)
  Why this is the best solution:
• Most users won’t hit the limit
• Showing limits upfront adds visual noise
• It can feel restrictive before it’s necessary.
• Users don’t need to “plan” a 20–50 character answer
  This is why showing the countdown only after typing feels lighter and more appropriate.

Additionally, Gov.uk do not have a character count for text input, only for text area.

I hope this explains our thought process behind the discrepancy in these components.
Thank you.