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

• [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

[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]

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

[edwardhorsford]

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.

[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 https://github.com/alphagov/govuk-frontend/pull/1038)

Thanks,

Ollie

[timpaul]

Related issue: https://github.com/alphagov/govuk-frontend/issues/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 :)

https://github.com/nhsuk/nhsuk-service-manual-backlog/issues/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.

[dav-idc]

We’ve updated the character count component

We’ve released an update for the character count component that fixes several accessibility issues.

Visually, this updated character component looks identical. However, it improves the experience for people using screen readers.

Here’s the updated component guidance: https://design-system.service.gov.uk/components/character-count/ And here’s the Github pull request for the update: https://github.com/alphagov/govuk-frontend/pull/2577

Problems we wanted to solve for screen readers

Announcing twice

https://github.com/alphagov/govuk-frontend/issues/2485 The character count message was being announced twice by screen readers, for every keystroke.

Announcing hint text with the character count

https://github.com/alphagov/govuk-frontend/issues/2486 Screen readers would read out the entire hint text each time the character count was announced, despite there being no changes to the hint text.

Announcing below the threshold

https://github.com/alphagov/govuk-frontend/issues/2487 Character count messages were being announced by screen readers, even when the count was below a set threshold.

Announcing old queued-up counts

https://github.com/alphagov/govuk-frontend/issues/2488 Multiple count messages would get 'queued-up' and announced at the same time when the user stopped typing into the character count. Some of these messages would be outdated, and wouldn’t reflect the latest 'count'.

What we decided and what has changed

We decided that the character count’s screen reader experience needed to be improved. Since the initial launch of the component, both screen readers and browsers have had several rounds of updates. This has led to new behaviours that affected how screen readers announced updates to the character count, causing screen readers to provide long-winded, excessive, intrusive and sometimes out-of-date announcements.

We reworked the character count component’s code to help solve the four issues we had identified.

The biggest changes are:

• repurposing the static ‘character limit’ element to be used for two purposes, depending on whether JavaScript is available:
  • when Javascript is available, it serves as a visually-hidden element for screen readers to announce the character limit when a user focuses on the text input
  • when JavaScript is unavailable, it serves as a fallback piece of visible text which doesn’t live-update, to announce the character limit
• hiding the live-updating character count element from screen readers by adding an aria-hidden attribute
• adding a new visually-hidden character count element that handles the live-updated announcements for screen readers

We have also updated the component guidance to better align with how the updated component works and to highlight some of our new accessibility considerations.

Known Issues

1. In Internet Explorer 11, JAWS will ignore any set threshold and announce the character count, even if the user entered less than the threshold.
   • We don’t plan on fixing this at the moment. We may look at fixing this if Internet Explorer remains a supported browser by the Design System after the browser’s end-of-life in June 2022.
2. In Chrome version 99, JAWS will not announce the hint or character count of a pre-populated textarea. This is a known issue in JAWS.
   • This is a known issue in JAWS, with an open bug ticket: https://github.com/FreedomScientific/VFO-standards-support/issues/201

How you can help

We are confident that this updated character count component provides an improved screen reader experience, but the changes haven’t been tested with actual users. If you or your team get a chance to test this component within a service, we would love to hear about any results relevant to the character count.

If you come across any compatibility issues with this updated character count component, please let us know via this backlog item or through our regular support channels.

How to upgrade

Teams using the govuk-frontend Nunjucks macros do not have to make any changes.

Teams using static HTML can remove the hard-coded aria-live="polite" attribute from .govuk-character-count__message.

For backwards compatibility, custom classes that have been added to the HTML count element are copied onto the visible, injected counter. If you previously used a custom class to change the visibility of the counter outside of the existing threshold functionality, this may no longer work as expected. The screen-reader-only counter does not inherit any classes.

[ohazda]

Hey folks, awesome work on the component. I am trying to use your approach as a starting point. But unfortunately, I came across this bug or maybe feature (trying to understand why it's happening):

https://user-images.githubusercontent.com/70153084/193840386-49ad3346-80b9-47ba-826e-cabbcd4e59bf.mp4

In this particular example, the hint is getting renounced again at some point. I tried to google the issue but nothing really relates to this feature/bug. Does anybody come across it as well? Is there an explanation for this behaviour?

Tested in Chrome 105 + VO and Safari 16 + VO

I appreciate any help 🙌🏻

[stephenjmcneill1971]

I was wondering if you can help. when using the component below.

Character count – GOV.UK Design System (design-system.service.gov.uk)

A new line is only counted as one character. However when it is sent to the backend it is counted as two character CRLF instead of LF. This means the character count in the front end mis-informs the user because it says the user is within the max length when in fact they are over due to an extra character for every new line not being counted. Is there a way round this so front and back end correlate.

I saw this has been raised before but I see no resolution. Character count · Issue #172 · nhsuk/nhsuk-service-manual-community-backlog (github.com)

Regards Stephen Joseph McNeill

[dav-idc]

I was wondering if you can help. when using the component below.

Character count – GOV.UK Design System (design-system.service.gov.uk)

A new line is only counted as one character. However when it is sent to the backend it is counted as two character CRLF instead of LF. This means the character count in the front end mis-informs the user because it says the user is within the max length when in fact they are over due to an extra character for every new line not being counted. Is there a way round this so front and back end correlate.

I saw this has been raised before but I see no resolution. Character count · Issue #172 · nhsuk/nhsuk-service-manual-community-backlog (github.com)

Regards Stephen Joseph McNeill

Hi @stephenjmcneill1971, thanks for flagging this! I don't have a quick answer for this, but it does look like this other ticket is also related to the bug you're seeing: https://github.com/alphagov/govuk-frontend/issues/1104

It might be worth it to comment there around the concern of /n being considered 2 characters in the backend, but only being valued as 1 in the frontend.

[querkmachine]

Hi @stephenjmcneill1971, I'm currently writing a response to your email now. I'll copy over any relevant bits here when I'm done.

[stephenjmcneill1971]

Hi David

Thanks for updating the other ticket with my comment.

Regards Stephen

From: David C @.> Sent: 10 January 2023 15:15 To: alphagov/govuk-design-system-backlog @.> Cc: Stephen McNeill @.>; Mention @.> Subject: Re: [alphagov/govuk-design-system-backlog] Character count (#67)

I was wondering if you can help. when using the component below.

Character count – GOV.UK Design System (design-system.service.gov.uk)https://design-system.service.gov.uk/components/character-count/

A new line is only counted as one character. However when it is sent to the backend it is counted as two character CRLF instead of LF. This means the character count in the front end mis-informs the user because it says the user is within the max length when in fact they are over due to an extra character for every new line not being counted. Is there a way round this so front and back end correlate.

I saw this has been raised before but I see no resolution. Character count · Issue #172 · nhsuk/nhsuk-service-manual-community-backlog (github.com)https://github.com/nhsuk/nhsuk-service-manual-community-backlog/issues/172

Regards Stephen Joseph McNeill

Hi @stephenjmcneill1971https://github.com/stephenjmcneill1971, thanks for flagging this! I don't have a quick answer for this, but it does look like this other ticket is also related to the bug you're seeing: alphagov/govuk-frontend#1104https://github.com/alphagov/govuk-frontend/issues/1104

It might be worth it to comment there around the concern of /n being considered 2 characters in the backend, but only being valued as 1 in the frontend.

— Reply to this email directly, view it on GitHubhttps://github.com/alphagov/govuk-design-system-backlog/issues/67#issuecomment-1377425730, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A4SNKXBNU5PTMC4HOB22SH3WRV4HVANCNFSM4ELSDXBA. You are receiving this because you were mentioned.Message ID: @.***>

---

CICA LEGAL NOTICE

This email and any files transmitted with it are private and intended solely for the use of the individual or entity to whom they are addressed.

If you have received this email in error please return it to the address it came from telling them it is not for you and then delete it from your system.

As part of conducting its business, the Criminal Injuries Compensation Authority may monitor and record incoming and outgoing emails and their content.

This email message has been swept for computer viruses.

---