Character count

[govuk-design-system]

Use this issue to discuss the character count component.

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