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.

[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: alphagov/govuk-frontend#2577

Problems we wanted to solve for screen readers

Announcing twice

alphagov/govuk-frontend#2485
The character count message was being announced twice by screen readers, for every keystroke.

Announcing hint text with the character count

alphagov/govuk-frontend#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

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

Announcing old queued-up counts

alphagov/govuk-frontend#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: [chrome/Edge + Jaws2022] When text area contains value, JAWS does not read the text linked to the textarea via aria-describedby. FreedomScientific/standards-support#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):

characterLimit.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: alphagov/govuk-frontend#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)<nhsuk/nhsuk-service-manual-community-backlog#172> Regards Stephen Joseph McNeill Hi @stephenjmcneill1971<https://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#1104<alphagov/govuk-frontend#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 GitHub<#67 (comment)>, or unsubscribe<https://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. ***************************************************************************

[querkmachine]

This mismatch is, basically, the result of a difference in the specifications for HTML and HTTP. 
 
In the current specification for HTML, new lines within a textarea are represented by a single code point, LF (line feed), aka POSIX/Unix style, \n, or U+000A.
 
However, in the specification for HTTP, new lines are represented as two code points, CR (carriage return) and LF (line feed), aka Windows style, \r\n, or U+000D U+000A.
 
This is why one code point on the front-end becomes two on the back-end. It's basically 'transformed' in the HTTP transmission process.

As our component only counts code points, and HTML/JS will only ever see one code point, we will always have a mismatch between what we have and what the backend actually receives when it comes to new lines.

I don't think the solution is to change the character count component, however.

• We currently, strictly, only count code points. As much as this might seem weird in some circumstances (e.g. emoji), it's simple, predictable, consistent, and technically correct (the best kind of correct).
• Having a new line equal 1 character aligns better to a user's mental model than it equalling 2 characters.
• Ideally we want to move to counting graphemes, rather than code points, at some point in the future. New lines aren't considered a character at all when counting graphemes, so if anything we want to move towards new lines equalling 0 characters, rather than equalling 2.
• Most modern word processors already count using graphemes and don't include new lines when reporting character counts. Ideally we want to align our behaviour as closely as possible to word processor software to avoid unpleasant surprises if a user is copying from a word processor, only to find their perfect 300 character response is suddenly 306 characters.

This does, unfortunately, leave the onus of how to validate all of this on the backend.

As an interim solution for new lines specifically, it might be possible to detect and remove the carriage return characters from the received value before performing length validation. This would no longer suffice if we move to grapheme-based counting, however.

[frankieroberto]

Our service has a "personal statement" section where candidates have to write a longish (up to 600 words) statement about why they'd make a good teacher.

We use the Character count component for this (but set to a word limit not a character limit).

However we are noticing that quite a lot of users still submit the form with the personal statement over the word limit.

Our assumptions are that one (or both) or the following might be the cause:

• they didn't spot the as-you-type word count – maybe because they pasted the content from elsewhere?
• they know it's over the word limit but want to save it and edit it down later

We’re currently exploring ways to potentially mitigate this.

[stevenjmesser]

Sounds good, @frankieroberto, let us know what you find!

[andythenorth]

Hi (also hi @stevenjmesser ) we're not Design System users here at Delib, but we use it as reference for Citizen Space UI.

We have recently run into the same issues with character counts, and have had a crash course in graphemes. Watching with interest.

[L-e-a-n-n-e-H]

We’ve come across an issue whereby when someone types into the text area box if there is a delay of about 1 second before they type another character in, the screen reader will read out the remaining character count, this continues to happen for the entire sentence they are writing.
This can be a bit excessive for people who do not type or can type quickly and use a screen reader. Has anyone set the character count to more than 1 second, is this achievable? Or does anyone know of an optimal length of time before the character count starts to read out on a screen reader? Thank you :)

[dav-idc]

Hi @L-e-a-n-n-e-H, thanks for providing this feedback! I have a couple clarifying questions on the specific scenario, if you're able to provide more info. It's alright if you don't have answers for all the questions though. 👍

• Which screen reader was in use, with which browser, and on what operating system / device?
• Do you know approximately how fast the person was typing when the encountered the repeated character count announcements? The 1 second delay timer was based on the assumption that in a normal typing scenario, the typing speed would be greater than 60 characters per *minute (the general rule-of-thumb average typing speed is around 190 characters per *minute, more than 3 times quicker).
• Do you know what version of GOV.UK Frontend is being used? The screen reader announcements were much more intrusive and frequent before we made the updates. The updated character count component was released in version 4.1.0 in May 2022.
• Is the person pausing after typing each character, or is the issue that they're typing long strings of characters and the screen reader is announcing the character count message while they're still typing at a normal pace?

[L-e-a-n-n-e-H]

Hi @davidc-gds , many thanks for the quick reply, much appreciated!

• We had an accessibility audit that picked it up on the web browser of the NHS App (desktop) they were using a Mac, with NVDA on Firefox.
  I’ve tried with the Chrome extension and it does the same.

• And relates to the text box prior to booking a GP appointment, in a texarea box that is mandatory.

• The person would have long pauses, and is most likely with someone who needs to take their time; has dexterity issues, unable to touch type, needs longer processing time to move between letters/characters and articulate what they want to get across (we're awaiting data/analytics to probe further).

In the meantime we were looking at what would be a good 'pause' length from the current 1000ms (1 second) and if anyone had any suggestions for this?

Thank you!

[CharlotteDowns]

We ran an external accessibility audit for some of the components and patterns in GOV.UK Frontend in May 2023. In that audit, we included an example of the Character count component. We’re adding results from that audit here so that we can:

• document, discuss and address the findings
• inform future contributors of the findings

One usability accessibility issue raised

The hidden character count only pops up when you approach threshold is strange usability-wise.

The character count for the text area ‘What were you trying to do?’ does not appear until the user reaches fifty characters. It can be beneficial to display this from the start and the max characters to allow users to understand this restriction before entering data.
This means that when the user reaches 50 characters, and are made aware, they then do not have to amend what they have already entered in order to not exceed the 100 limit.

More detail in this issue:

• #3689

[joelanman]

Just to note the threshold is an optional feature. We designed it with the aim that most fields would be large enough to accept most input, and not make the user have to think about the character/word limit. In the minority case where users might hit the limit, the threshold option allows those users to know they are near the limit.