Multiple outdated announcements can be made when the user stops typing into the character count.

[36degrees]

Description of the issue

Multiple count messages can get 'queued up' and announced when the user stops typing into the character count. Some of these messages will be outdated, and do not reflect the latest 'count'.

Screen.Recording.2021-12-22.at.16.41.26.mov

Steps to reproduce the issue

1. Go to https://govuk-frontend-review.herokuapp.com/components/character-count/preview
2. Type multiple characters into the box quickly, then pause

Actual vs expected behaviour

Expected behaviour: Only one count message should be announced, and it should reflect the current number of remaining characters in the textarea.

Actual behaviour: Multiple count messages are announced in:

• JAWS 2021.2103.174 / Chrome 96
• JAWS 2021.2103.174 / Firefox 95
• NVDA 2021.2 / Chrome 96

This also happens occasionally in JAWS 2021.2103.174 / IE 11 and with VoiceOver / Safari 15.2 (macOS Big Sur).

It did not seem to occur with NVDA 2021.2 / Firefox 94 or VoiceOver / Safari (iOS 15.2).

Environment (where applicable)

• Operating system: As above
• Browser: As above
• Browser version: As above
• GOV.UK Frontend Version: v4.0.0

[36degrees]

I think this is also related to, and compounded by, #2485.

[querkmachine]

I've looked at this as part of #2539 and made some attempts to debounce the update of the counter until after the user has stopped typing for a short period of time.

Unfortunately this is being undermined by the bugfix we have in place for Dragon Naturally Speaking, which forces an update to happen every one second if the textarea value has been changed. This plus debouncing does reduce the number of announcements being queued up, but it doesn't resolve it completely or prevent stuttering in the readout.

[36degrees]

Unfortunately this is being undermined by the bugfix we have in place for Dragon Naturally Speaking, which forces an update to happen every one second if the textarea value has been changed. This plus debouncing does reduce the number of announcements being queued up, but it doesn't resolve it completely or prevent stuttering in the readout.

Could we keep a timestamp of the last time the count message was updated because of a key event, and then only trigger an update from the one second interval if that timestamp is more than one second ago? That way the interval timer should be a no-op if the keyboard events are firing as you'd expect when Dragon isn't involved… I think?