Add guidance on what error message to show for a text input if the input uses characters that are not allowed and the set of allowed characters is very large

[lfdebrux]

From comment on text input backlog by @terrysimpson99

An issue was recently raised on slack that has cropped up before. The guidance says "If the input uses characters that are not allowed and you do not know what the characters are. Say ‘[whatever it is] must only include [list of allowed characters]’."

Challenging example 1: A designer pointed out that following guidance would result in "Business name must only include letters, numbers, hyphens, spaces, apostrophes, exclamation marks, commas, quotation marks, ampersand, underscore, full stop, round brackets and forward slash". The consensus appeared to be that it was not desirable.

Challenging example 2: A service I worked on allowed ~180 char (it was the entire ISO-8859-15 char set). We also believed that listing the characters as per guidance wasn't desirable.

In both examples, the conclusion was to use the example from guidance ‘[whatever it is] must only include letters a to z, hyphens, spaces and apostrophes’.

This scenario is likely to happen again. Can the guidance be updated to indicate that this is acceptable, or suggest a different approach?

Related documentation

Guidance on error message if the input uses characters that are not allowed and you do not know what the characters are, in the file src/components/text-input/index.md.njk

Suggestion

Add guidance on what to do if the set of allowed characters is very large and/or difficult to show to the user.

[EoinShaughnessy]

Challenging example 1: A designer pointed out that following guidance would result in "Business name must only include letters, numbers, hyphens, spaces, apostrophes, exclamation marks, commas, quotation marks, ampersand, underscore, full stop, round brackets and forward slash". The consensus appeared to be that it was not desirable.

Challenging example 2: A service I worked on allowed ~180 char (it was the entire ISO-8859-15 char set). We also believed that listing the characters as per guidance wasn't desirable.

In both examples, the conclusion was to use the example from guidance ‘[whatever it is] must only include letters a to z, hyphens, spaces and apostrophes’.

Re example 1 and its solution - does this mean users ended up being told they couldn't include numbers, exclamation marks, etc., even though they could have?

[lfdebrux]

@EoinShaughnessy it does seem that way.

I wonder though if validation was done to 'artificially' limit the characters, even if the backend could have handled it 🤔

@terrysimpson99 do you recall whether, in either of the examples you gave, the service ended up showing an error for characters like the exclamation mark that were allowed but not mentioned in the hint text or error message?

[terrysimpson99]

If I recall correctly:
In our free text boxes we allowed any ISO-8859-15 character except a few characters such as angle brackets. Thus an exclamation mark was allowed. The user would not see a message if it was an allowed character. Thus they would not see the error message if they used an exclamation mark.

If they used a character that was not allowed they would see the error message. Thus an angle bracket would result in the error message. We knew that the error message was wrong but we thought giving an incomplete list was better than a complete list. Our discomfort with giving a wrong message is why we raised it here.

Expanding the scope of allowed characters fit with my recommendation of 'Everything is allowed unless it's forbidden' and that would massively reduce the instances of the user being blocked by validation.

We debated variations from ‘[whatever it is] must only include letters a to z, hyphens, spaces and apostrophes’ that would be less wrong. A decision was made to use the exact wording in the guidance as the least bad solution.

[leona-creator]

We've had the same issue. We don't have a definitive list of characters users cannot enter but the list of characters they can enter is extensive.
We've handled it using the following:

‘[whatever it is] must only include numbers, letters a to z, and special characters such as hyphens, apostrophes and brackets'

Our hope is that 'such as' will at least indicate the list is non-exhaustive.

[EoinShaughnessy]

@terrysimpson99 Thanks for the context - it really helped with understanding this issue!

@leona-creator Thanks for sharing your solution! We've updated our guidance to suggest a similar approach.