govuk-design-system-backlog
govuk-design-system-backlog copied to clipboard
alphagov
Character count
We've been trialling the word count aspect of this pattern on a DfE service for managing teacher training courses.
In user research we’ve found that the word counts are clear and obvious and that users respond to them well, editing down their text to keep only what's most important.
Example screen from the prototype:
@fofr does your implementation include messaging for when users go over the number of words?
Curious because I've had that in previous projects but not sure it was ever validated as a need.
@tombye Yes, we've used the messaging that was in the original repo by @alex-ju. The messaging has worked well when users have pasted in text that was too long from another document.
We're thinking about the possible error states for this component. In particular, how the 'You have 26 words too many' error should be represented in the error summary component that can appear at the top of a page.
Just repeating that message wouldn't give context about which form field the error related to. As the example above from @fofr shows it's quite possible to have multiple character count components on a single screen - so, should the error be adjusted to include information about the specific field. For example "Interview process summary has too many words".
However, if we only adjusted the error message in the summary then this would go against our advice to keep them the same.
@stevenaproctor - do you have a take on this?
@timpaul You could use the standard too long error message ‘[whatever it is] must be {x} [characters or words] or less’. Or, if it is available, you could use the number of characters you are over in the error message ‘[whatever it is] has {x} [characters or words] too many’.
For the example, this would give you the errors:
- Interview process must be 250 words or less
- Interview process has 26 words too many
What do you think?
We have a need for a character count component in one of our services at HMRC. I noticed the github readme does not recommend using this component as-is in production - does anyone know what the blocker to recommendation is?
Something new that we've observed in user research:
We asked users to prepare content before our service was available. We gave them word count limits. We've found that users wrote their content in Word and used Word's word count feature to check the length. When they’ve then copied that content into our tool there's been a disparity between the two counts: ours is a little stricter and users have had to edit their content to reduce by 1 or 2 words. This has caused frustration, especially when the previous word document has been reviewed/approved.
Presumably the logic for word counts in Word is a little more complex than the regex used in https://github.com/alphagov/ds-character-count. I doubt that there is consistent logic between different word processors, I like the simplicity of the regex used. (It's complicated a little by our use of markdown, where * list item counts as three words while if you type that in Word the asterisk gets converted to a bullet point and isn't counted.)
We still need to investigate the cause more thoroughly, but wanted to share this gotcha first.
Edit: When we implemented server side word counts, we reused that regex so that frontend and backend would be consistent.
@hooperstu it was tested with screen readers and had a few user research rounds: https://github.com/alphagov/govuk-design-system/wiki/Character-count-testing-and-user-research
The only issue I'm aware of is with JAWS who repeats field's label every time the count message is played.
@alex-ju I tested it today with NVDA and Firefox and the remaining characters information was read out twice, which I did not expect.
For example, when I entered the box and typed 'a' I heard 'You have 199 characters remaining' twice. When I deleted the 'a', I heard 'You have 200 characters remaining' twice as well.
Any ideas?
@stevenaproctor: thanks for reporting it. The prototype doesn't seem to have this issue. I will try to investigate what's causing the issue and get back to you.
Hi @stevenaproctor, I did a bit of investigation around the NVDA issue, which seemed to be caused by the polling events. Updated the code in the Design System branch and tested again on NVDA. Please let me know if now is working as expected and thanks again for reporting it.
@alex-ju It is working as expected, thanks for taking a look.
If JavaScript is not available, is it possible to show "You have 200 characters remaining" rather than nothing?
@stevenaproctor having a default message for non-JS experience sounds like a good idea; I'll look into it. But in this case the message should maybe mention the limit instead of the remaining characters
@alex-ju Definitely. We tend to use something like "You can enter up to 200 characters".
Working Group Review
This proposal was reviewed by a panel of designers from GDS, HMRC, DWP, EA and Home Office on Wednesday, 26th September 2018
The panel agreed that the pattern should be published in the GOV.UK Design System.
The panel also made the following recommendations:
Pre-publication
- [x] Update component description to clarify that it doesn’t set the limit, but exposes the limit to users and lets them type over it before submitting
- [x] Add guidance to explain why the count message appears below the textarea Say that this component shouldn’t be used to enforce limits that stem from technical constraints
- [x] Get content peer reviewed before publication
- [x] Explain why both the count message and a validation error message appear when an error occurs.
- [x] Provide a default, non-dynamic message explaining the character or word limit for when JavaScript is not available
- [x] Fix behavioural issue that occurs when using component with NVDA and Firefox
Future work
- [ ] Consider making the count rules closer to the Microsoft Word count (see this issue for a fuller explanation)
- [ ] Add more information about research with users with access needs as it becomes available
- [ ] Look into fixing JAWS screen reader bug
- [ ] Explore how this works for users with low reading ages
Thank you all for all the help to get this done, from research, code to guidance. As I mentioned in the working group, most - if not all - the credits for this work should go to @edwardhorsford.
Great job team!
Credit also to @alex-ju, Per, @hannalaakso, @alicenoakes and everyone else on the patterns team.
Congrats to all involved in this. It's a nice, useful feature.
I do have some concerns about the following advice though:
"Do not impose character limits unless there is a user need" and "do your best to remove the limit in backend systems"
IMO every text field/text area field should have a character limit. (Whether you choose to display that limit using this character count component is a different matter of course)
Why? I don't want users entering war and peace into field that is meant for a full name. I don't want an essay when a short description is expected.
The 'maxlength' attribute is your first line of defence against this kind of behaviour (which of course should be backed up with server-side validation ideally at both the route endpoint and database schema level).
To say otherwise, and even suggest backend system remove these constraints is dangerous advice IMO.
Personally I would rather GDS come up with a set of recommended max length constraints for common fields.
E.g.
Full name -> 150 Email address -> 200 Telephone -> 15 Nat Ins. No. -> 10
I don't mind if the limits proposed are well above what would be expected, just so long as there are limits.
I think there's always a need for maxlength - database integrity. While there are physical limits of what text areas/input boxes can accept (IIRC it differs between browser vendors), these limits should not be relied upon.
Similarly for file upload - users should be recommended to apply appropriate file size limits in their backend to protect against malicious users POSTing a 100GB file and bringing services down.
Many thanks
When I worked on this component we saw it as something intended for text areas and other paragraph-like responses from users. Not suitable or intended for short fields like full name, email, etc, which I'd argue is a different pattern and need.
I'd agree with @davidjamesstone that there are often cases where it's entirely appropriate to have a limit - though I'd say that's covered by the requirement that limits have a user need.
Character limits for fields where the data is of a known length is arguably a different pattern. It may be appropriate there - though you'd want to allow enough extra space to support people entering spaces or editing down - eg credit card numbers with spaces between each group of four characters.
Just to clear up, I wasn't suggesting this new component be used with anything other than a text area. I just think the line:
"Do not impose character limits unless there is a user need"
Could be misinterpreted a meaning you shouldn't use maxlength. My advice would be to always use it for all input types that support it (which are inputs & textareas AFAIK). It will be one of the the first thing a penetration tester trying to break your site will look for.
"if there is a limit set by a legacy backend system, do your best to remove the limit instead of using a character count."
I'm not sure why the word "legacy" is used here. Both new and old backend systems/database will offer some kind of support for data constraints like max field length and it's good practice to use them. Doing your best to remove them is not good advice. A data architect/developer will have put them in for good reasons of data quality and integrity etc. They won't be looking at it from a end user perspective). The front end should honour these constraints rather than seek to remove them.
I think it's valid to say limits are needed on the back end, but that they are set to be large enough that users never normally experience them (unless there's a need to, as per the guidance).
I'm not sure it's that useful to set these large limits on the frontend, since that's no defence against a server receiving a large request - that can be done anyway, regardless of what we put in our front end. A maxlength in the frontend is a poor user experience as the user receives no error message (without javascript, and we have no-javascript progressive enhancement as a requirement). Handling it in the backend and returning an error is a better user experience.
Handling it in the backend and returning an error is a better user experience.
Yeah @joelanman. Avoiding maxlength attributes and just relying on sensible limits in the backend error handling (using the error message + summary components) now sounds like the best overall solution to me.
Thanks @davidjamesstone and @edwardhorsford for the feedback - this has been a really useful discussion. We'll review the current guidance and make sure that it's as clear as it needs to be.
@alex-ju I was testing this using NVDA and Firefox and noticed if you switch off JavaScript, the aria-polite="live" did not seem to work.
This means a screen reader user will only hear the 'You can enter up to 200 characters' when they leave the textarea using the down arrow. I am not sure what the experience is for other screen readers.
If we changed the textarea we could let people know the limit when they enter it. For example:
<textarea class="govuk-textarea js-character-count " id="with-hint" name="with-hint" rows="5" aria-describedby="with-hint-hint with-hint-info"></textarea>
This means people would hear the label, hint text and limit . This should also work if JavaScript is off.
What do you think?
@stevenaproctor sounds good, thanks. will look into it and raise a PR for that.
I'm hoping to add this to my service shortly.
There's two things I'd like to suggest / query.
Include a max-length for non js
Should the default html include a hardcoded limit which the js then removes? This is what we had whilst developing the service.
A hardcoded limit is not ideal, but I think it's probably better to limit to x characters being typed at all than to let anything get typed and then throw an error. Even if the error is clear, there's no effective way for the user to cut down the text to under 200 characters.
Allow the threshold to specify a unit in absolute characters
We originally did the threshold in percentages, but I now feel an absolute number might be better. I basically want the limit to appear near the end of the field. In many cases I think this is probably easiest to specify as x characters from the end - otherwise we're going to have to vary the limit as a proportion of the total amount of characters allowed.
@edwardhorsford People may not notice a hardcoded limit when they are typing or pasting in content. Letting them go over the limit and giving an error would mean they have the chance to edit what they entered or paste.
@stevenaproctor this is only in the non-js case. In the js case, we let them go over and edit down.
It's weighing up the risk of someone pasting in and not realising it's truncated (or a AT user not knowing), or frustration of letting users type whatever, telling them it's wrong, but making them guess how much they need to remove.
Without any limit, they have to guess when they're at the limit - essentially delete some text, submit, delete some text, submit, delete some text, submit - a frustrating process. They have no way of knowing when they're at the limit.