Character count

[govuk-design-system]

Use this issue to discuss the character count component.

[fofr]

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:

[tombye]

@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.

[fofr]

@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.

[timpaul]

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?

[stevenaproctor]

@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?

[nubz]

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?

[fofr]

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.

[alex-ju]

valuable found @fofr. thanks a lot for sharing it with us.

[hooperstu]

Has anybody tested this with screen readers yet?

[alex-ju]

@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.

[stevenaproctor]

@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?

[alex-ju]

@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.

[alex-ju]

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.

[stevenaproctor]

@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?

[alex-ju]

@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

[stevenaproctor]

@alex-ju Definitely. We tend to use something like "You can enter up to 200 characters".

[amyhupe]

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

• 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
• 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
• Get content peer reviewed before publication
• Explain why both the count message and a validation error message appear when an error occurs.
• Provide a default, non-dynamic message explaining the character or word limit for when JavaScript is not available
• 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

[alex-ju]

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.

[edwardhorsford]

Great job team!

Credit also to @alex-ju, Per, @hannalaakso, @alicenoakes and everyone else on the patterns team.

[davidjamesstone]

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.

[joelanman]

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.

[davidjamesstone]

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.

[timpaul]

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.

[stevenaproctor]

@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?

[alex-ju]

@stevenaproctor sounds good, thanks. will look into it and raise a PR for that.

[edwardhorsford]

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.

[stevenaproctor]

@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.

[edwardhorsford]

@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.

[stevenaproctor]

@edwardhorsford I have seen users not realise a textarea has stopped taking what they enter or that what they have pasted is truncated. This was in a textarea without any character counter functionality and they did have to guess how much they needed to remove. I agree it is about weighing up the risk of what to do in a non-js situation.

[joelanman]

Suggestion for non-js:

• Clear messaging up front about the character limit (this gives the user the option to use another tool to count characters, like Word)
• No hard limit in the field - agree with @stevenaproctor that people can well not realise truncation has happened
• Server-side validation which tells the user the content is too long, maybe message where the content passes the limit ('This goes over 200 characters at "example text here"')

[stevenaproctor]

@joelanman 👍

Even in the js version, we do not tell people where to start in the textarea. We could definitely add a new error message to the documentation, but it could complement the 'You have 40 characters too many' error you get in the js version. Something like 'Summary has 40 characters too many'.

What do you think?

[HughePaul]

Is there a way to customise / localise the text? i.e. How do we get it in welsh?

[36degrees]

Hi Paul,

Unfortunately customising the text used by the character count isn't currently possible. In the meantime, we suggest copying the JavaScript into your own project and making the changes to the text there.

I appreciate this isn't ideal – internationalisation / localisation is on our roadmap as something we want to support soon.

(This was previously raised in alphagov/govuk-frontend#1038)

Thanks,

Ollie

[timpaul]

Related issue: alphagov/govuk-frontend#1364

[chrimesdev]

Hey all, we're going to be looking at implementing the Character count into the NHS Digital service manual. We're currently gathering feedback from teams using the GOV.UK character count component in NHS services. So will feedback anything we find :)

nhsuk/nhsuk-service-manual-community-backlog#172

[jamiehumphries]

Hi Paul,

Unfortunately customising the text used by the character count isn't currently possible. In the meantime, we suggest copying the JavaScript into your own project and making the changes to the text there.

I appreciate this isn't ideal – internationalisation / localisation is on our roadmap as something we want to support soon.

(This was previously raised in alphagov/govuk-frontend#1038)

Thanks,

Ollie

@36degrees, I understand that special casing the Welsh language here is not something that you want to do because of roadmap plans for internationalisation / localisation in general.

Would you instead accept a pull request that made the character count text entirely customisable, with placeholders for replacement?

I was thinking an optional property like:

{{ govukCharacterCount({
  …
  messages: {
    base: "You can enter up to %count% characters",
    remaining: {
      singular: "You have 1 character remaining",
      plural: "You have %count% characters remaining"
    },
    tooMany: {
      singular: "You have 1 character too many",
      plural: "You have %count% characters too many"
    }
  }
}) }}

This would allow logic in Nunjucks to switch between English and Welsh, say, but without having to make Welsh an explicit special case.

If this approach sounds acceptable, I am happy to make a pull request along these lines.

[terrysimpson99]

Our use of the character count was challenged by DAC. It said:
"When navigating the confirmation page, there was a remaining character limit present underneath the ‘How can we improve this service?’ form field. When navigating the page, with the use of screen reading software the character limit was not announced to screen reader users."
[...]
“The ‘How can we improve this service’ edit field possessed a character count. This feature did not follow the GOV.UK Design System as when I entered characters, I was not given an audio prompt to alert me the character count had changed. I further found that important information such as not entering personal information was contained below the edit field and was therefore not located until after I had entered the information. The example given in the GOV.UK Design System suggests this important information should be situated between the label and the edit field. Ensuring that the character count clearly alerts me when the character count has changed, with the additional important information relating to what not to enter appears above the edit field will ensure I can access this feature easily.”

I don't know if the latest version of character count resolves this issue but we took the decision to remove the character count component.

[MalcolmVonMoJ]

Our service also has a character count (with Welsh support). We recently passed a DAC assessment, and the character count was not flagged up as an issue.
Our HTML is:

<div class="form-row ">
   <textarea class="govuk-textarea" data-character-count="4000" id="extra_notes" name="extra_notes" rows="7"></textarea>
   <div class="govuk-character-count__message govuk-hint" aria-live="polite">
      4000 nodau ar ôl
   </div>
</div>

[edwardhorsford]

@terrysimpson99 that doesn't sound like your version of the character count component was working or was using the correct component - the component was tested extensively in various AT to ensure it read out correctly. In fact in research it worked better for users of screen readers than for sighted users.

[terrysimpson99]

It doesn't surprise me. The codebase was several versions behind the current one.

[terrysimpson99]

@hannalaakso In response to comments from Malcolm and Ed, please remove the 'awaiting triage' status.

[terrysimpson99]

For information:

We investigated how many characters users actually submit.

The service was https://www.gov.uk/send-rent-lease-details. It had a post-submit feedback question 'How can we improve this service' with a text field that allowed 1200 characters and a character count component.

From 10,000 instances of user responses: 99% of users entered 632 characters or fewer; 99.8% entered 1000 characters or fewer.
Based on that evidence, we removed the character count component. It had been causing us grief at the time - the version we were using had been deemed not accessible and it showed english text on welsh pages.

Make of that what you will.