CharacterCount doesn't render or initialise properly if maxlength or maxwords is not passed to the macro

[romaricpascal]

What

It's a two part thing:

First is the HTML part, before JS kicks in: if omitting the maxlength or maxwords option when calling the govukCharacterCount macro, the HTML rendered displays a "You can enter up to undefined characters" message.

Second is the JavaScript part: When initialising the component with a JavaScript maxlength or maxwords config, the message disappears, but doesn't get replace by a count of the remaining character.

This will be problematic for people looking to use the JavaScript configuration to set a blanket setting accross their service. For that to work, we need to render the component without a data-maxwords or data-maxlength attribute and fix the HTML part.

And then once that's through, we need to make sure the component initialises OK with a missing length.

Who needs to work on this

Developers

Who needs to review this

Developers

Done when

• Library users can get a clean render of the count message when no maxwords or maxlength are provided
• JavaScript initialises properly when running over a HTML generated by the macro without maxwords or maxlength

[romaricpascal]

This happens with the current version of govuk-frontend, in Firefox. Latest version's JavaScript handles things OK in terms of replacing the message 🥳

However the macro still outputs an untidy text and we could either hide it as I initially suggester (using govuk-visually-hidden like the JS does), or replace the default to "You can enter a limited number of characters".

[36degrees]

Yeah, unfortunately I think this has been around a while – see also #1725. I think it'd be nice to fix this in v4.4.0, but I don't think this is a regression.

[romaricpascal]

That was just something I noticed while preparing my demo yesterday juggling between the 4.3.1 and main versions, but I prefered flagging to keep track of it.

For the JavaScript bit, thinking about it, without any default for maxlength removing the message is probably fine. We can't really set a default anyway for that maxlength as a "generic number of charaters to limit a textarea" feels quite arbitrary.

Regarding the HTML from the macro, thanks for linking to the old issue. I think with the introduction of fallbackHintText for that component, that may solve the final user experience when the field is initialised without a maximum, letting developers provide a custom message..

[querkmachine]

As a quick bit of background, we did some changes to the character counter functionality earlier this year to fix bugs and improve the screen reader experience in a number of browsers and technologies (see PR #2577 for the long read).

Consequentially, the counter is a bit of a complex web of visible (sometimes) and hidden (sometimes) elements. It may be best to avoid any solution that involves changing the visibility of elements, as this may have repercussions on those past changes, requiring some extensive re-testing!

[romaricpascal]

Cheers, that's some handy stuff to be aware. I had noticed the separate visible and debounced screen-reader feedback in the JavaScript side. I think that part should be left alone indeed: no maxlength, no maxwords -> no extra feedback if you don't set one when configuring JavaScript sounds a fine way to do.

Regarding a HTML cleanup, I think there's all the options for whatever people want to do:

• fallbackHintText lets you set some text
• countMessage.classes lets you add a govuk-visually-hidden on the .govuk-character-count__message element, similarly to what the JS would do when it kicks in if you really want an empty area. You probably don't, though, to avoid a layout shift when the JS kicks in so we may not want to shout too much about that one. And if you never show a count message, might as well just use a plain textarea 😄