Character count component reads out hints in an unintuitive order when initially focused

[stephenjmcneill1971]

When a the character count is rendered on a text areas the aria-describeBy attribute lists the ID (suffixed with "-info") of the character count text and the ID of the hint text of the textarea (suffixed with "-hint") in that order.

example:
aria-describedby="char-count-info q-textarea-hint"

This means that screen readers read the information referenced by those ID's in that order.
Character count info read 1st
Textarea hint read 2nd

What

Need to have configuration so that the "-info" ID is appended after the textarea "-hint" ID.

Why

When using a screen reader the character count below the textarea is read out first before the hint/description text above the textarea. This is counter intuitive to the page it should be read in order of appearance to help those needing to use screen readers

[querkmachine]

As an initial, untested thought: Is this so that things are read out in that order as the user is typing into the textarea?

In that context, hearing the updated character count would be of a higher priority than a repetition of the hint text, and the user is likely to want to hear that take place more frequently.

I'm unsure if that's actually the case, as I believe typing announcements are actually spawned from a visually-hidden live region, but something to confirm.

(Note: I'm also going to move this into the govuk-frontend repo, as this would appear to be a bug report for a Frontend component.)

[github-actions]

Uh oh! @stephenjmcneill1971, the image you shared is missing helpful alt text. Check your issue body.

Alt text is an invisible description that helps screen readers describe images to blind or low-vision users. If you are using markdown to display images, add your alt text inside the brackets of the markdown image.

Learn more about alt text at Basic writing and formatting syntax: images on GitHub Docs.

[stephenjmcneill1971]

As an initial, untested thought: Is this so that things are read out in that order as the user is typing into the textarea?

In that context, hearing the updated character count would be of a higher priority than a repetition of the hint text, and the user is likely to want to hear that take place more frequently.

I'm unsure if that's actually the case, as I believe typing announcements are actually spawned from a visually-hidden live region, but something to confirm.

(Note: I'm also going to move this into the govuk-frontend repo, as this would appear to be a bug report for a Frontend component.)

No this is just what is on the page when rendered. Once you click into the textarea a screen reader will read out aria-describeBy values in sequence so in this case the "you have 2000 characters remaining" will be read before "You can add details that may not be included on the crime report". The screen reader should read out a page in the order that it's rendered.

[36degrees]

It looks like this is a limitation of the way the character count wraps the textarea component.

The textarea component accept a describedBy option, which it then appends to to if a hint and/or error message are also passed. There's no way to pass in IDs of other elements that should go after the hint or error message or to otherwise customise the order – anything passed through describedBy will always come first.

A few options…

1. Do nothing and accept that the screen reader ordering and the visual order are out of sync (and, arguably, not in order of importance)
2. Further extend the textarea API to make it possible to pass additional IDs to add to aria-describedby at the end. Either adding a new describedByAfter option or providing a way to indicate where the hint and error message should appear in describedBy through a placeholder or similar.
3. Decouple the character count and textarea component so the character count does not use the textarea Nunjucks – this would allow more flexibility but risks the two getting more out of sync with each other whilst continuing to share CSS (unless we decouple them entirely, which results in lots of duplication)
4. Merge the character count functionality into the textarea component
5. Something else.

It'd be useful to understand how much of an issue this would cause for a screen reader user, and whether we think it fails any WCAG 2.2 success criteria – @selfthinker would you have any capacity to look at this?

I'm not sure this is the simple fix we thought it was – it'd be good to understand how much of an issue this is but let's not spend too much energy trying to fix this in this cycle.

[selfthinker]

The closest WCAG criterion here would be 1.3.2 Meaningful Sequence, which says:

When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.

I don't think it fails because, although the sequence might be different than expected, the meaning is not affected.

Also, the text suffixed with "-info" that is read out is actually never visible on the screen.
Although that can be confusing because it is similar to the text on the screen.

I cannot imagine that this will be an issue for anyone.
But, as always, it would be good to hear from people who have done user research with this component, if any screen reader users found the sentence "You can enter up to 200 characters" to be confusing to come before the other hint.

To clarify, the way the issue has been presented is slightly wrong.
Here is what the (simplified) code looks like:

h1 > label
div class=hint id=hint
textarea aria-describedby=hint info
div class=hidden id=info "You can enter up to 200 characters"
div class=hint aria-hidden "You have [number] characters remaining"
div class=hidden aria-live "You have [number] characters remaining"

Here is what happens when using a screen reader:
When tabbing, arrowing or using a shortcut to get to the textarea, a screen reader will read first the label, then the hidden info, then the hint (and sometimes the type of input after the label or at the end).
The visible "You have X characters remaining" is never read by screen readers, but the hidden duplication of it is read by screen readers whenever something gets typed into the textarea. But it is not read out when you first focus on the textarea.

(I wasn't in the team when this component was developed, so don't have any context of its history. But I assume the text is duplicated to only alert screen readers when you pause to not get too verbose and disruptive but always update the visible text with every key stroke.)

One thing I have noticed, though, is that both sentences are read out together without a pause. Like "you can enter up to 200 characters do not include personal or financial information like your National Insurance number or credit card details."
I'd suggest to add a period at the end of the hidden text (and maybe, for consistency's sake, the other two texts as well?).

[querkmachine]

(I wasn't in the team when this component was developed, so don't have any context of its history. But I assume the text is duplicated to only alert screen readers when you pause to not get too verbose and disruptive but always update the visible text with every key stroke.)

Your assumption is absolutely correct.

The component didn't work like this originally, we introduced this way of it working in early 2022 to fix various issues around screen reader announcements. #2577