Notify screen reader users when character count is at or near 500

[nolanlawson]

Got a suggestion about this: https://mas.to/@norrumar/109411900076228505

The character count is currently accessible, but it doesn't notify you in real time when you're getting close to 500. Arguably we could use the aria-live=polite region for this.

[nvdaes]

Thanks @nolanlawson I reported this in the mentioned toot. My username in Mastodon is norrumar@mas.to, andmy website at nvdaes.github.io is verified in my profile, to check that nvdaes corresponds to my profile in Mastodon. I think this maybe reported, for example, at 495 characters, and later you may decide to create an option in general settings to save the preferred limit in localStorage or something. I've cloned this repo and just installed yarn for testing or contribute if needed.

[nvdaes]

cc: @mhameed

[NickColley]

Just technical thing, not all instances have a limit to 500 so this should be based on the instance's upper limit.

[nvdaes]

@NickColley , I agree. I have look at source code and I thought about the following approach, but I have problems running yarn run dev and I cannot test and so I don't know if this is right:

in routes/components/lengthIndicator.html, in the span element,

aria-live={lengthVerbosity} aria-atomic="true"

And in the script

let lengthVerbosity = (overLimit || lengthToDisplayDeferred < 16) ? "polite" : "off"

[nvdaes]

I've tested setting aria-live attribute in lengthIndicator.html component to polite and assertive, but seems not to work as expected by me. NVDA doesn't notify changes though aria-label changes when I type characters in the compose edit box. I don't know if this is related to the fact that the span text contents is not changing, just aria-label, or due to something not considered by me.

[nvdaes]

I may create a pull request today that fixes this issue for me. My approach is the following:

1. Remove aria-label.
2. When lengthToDisplayDeferred is minor than 10, lengthVerbosity variable is set to polite, else to off.
3. Screen readers are notified just to changes in the real contents of the span, without addin extra info like "characters remaining" or "overlimit", since we can listen or read in our braille displays the minus symbol before numbers, and at least for me this is less verbose, and of course easierto implement.
4. I've removed an import not used, according to the linter advice.

I have tested with NVDA screenreader, typing and deleting characters, with speech and braille, without visual feedback. In case you disagree with this implementation, please letme know.

[nolanlawson]

@nvdaes Are we removing the aria-label just to work around the NVDA bug? Maybe in that case it would make more sense to use a <span> with an sr-only class? (And aria-hidden on the other <span>?)

I'm a bit concerned about the screen reader just reading the number (e.g. "5") as opposed to a full text like "5 characters remaining." If you're just hearing "5" for the first time, it could be quite confusing. Although of course for an experienced user, they probably know what it means.

/cc @MarcoZehe @jcsteh if you have an opinion on this

[nvdaes]

Your comments make sense. I thought also about this approach and for me would be enough to hear just the number, but your aproach maybe useful for some people. Let me know if you want to fix this yourself or if I should create a PR. Thanks a lot for your wonderful work!

[nvdaes]

Also, in addition to remove the aria-label so that notifications work properly for screen readers, what about to set maxLength in the textarea to {max}? This prevents to exceed the limit even for deaf and blind people, in case someone is not able to hear notifications.

[jcsteh]

NVDA doesn't notify changes though aria-label changes when I type characters in the compose edit box. I don't know if this is related to the fact that the span text contents is not changing, just aria-label, or due to something not considered by me.

I don't know why this would be. If I do this: data:text/html,<span id="live" aria-live="polite" aria-label="5">t</span><button onclick="live.setAttribute('aria-label', '4');">Change pressing the button announces "4", which is due to the aria-label change. Is aria-relevant explicitly set?

I'm a bit concerned about the screen reader just reading the number (e.g. "5") as opposed to a full text like "5 characters remaining." If you're just hearing "5" for the first time, it could be quite confusing.

This is one of those tricky situations where balancing intuitive usage with verbosity is a challenge. I guess it could be quite confusing hearing "5" for the first time. On the other hand, as I understand it visually, you only see the number; you don't see the " characters remaining" suffix. How do sighted users figure out this is a character count?

For a screen reader user, hearing "5 characters remaining", "4 characters remaining", etc. could get quite annoying, even though it's easy enough to interrupt it. I'd argue that even if the user doesn't know what the first number means, they'll realise very quickly that it decreases by 1 every time they type a character. That said, I'm not accounting for cognitive challenges or users extremely new to screen readers, though I wonder whether the visual experience accounts for that (as above).

[nvdaes]

About aria-relevant, I didn't used it, though I'm playing with this now. aria-labelseems not to be reported due to the aria-atomic="true". Now it's reported here. Anyway, I think we can create a PR without using aria-label, which maybe verbose and distracting for screen reader users, as you say (Jamie). And, if someone requires it, this maybe added later, perhaps providing an option in settings. I'll create the pull request in a few hours, unless someone prevents me to do so. Cheers

2022-12-04 23:55 GMT+01:00, James Teh @.***>:

NVDA doesn't notify changes though aria-label changes when I type characters in the compose edit box. I don't know if this is related to the fact that the span text contents is not changing, just aria-label, or due to something not considered by me.

I don't know why this would be. If I do this: data:text/html,<span id="live" aria-live="polite" aria-label="5">t</span><button onclick="live.setAttribute('aria-label', '4');">Change pressing the button announces "4", which is due to the aria-label change. Is aria-relevant explicitly set?

I'm a bit concerned about the screen reader just reading the number (e.g. "5") as opposed to a full text like "5 characters remaining." If you're just hearing "5" for the first time, it could be quite confusing.

This is one of those tricky situations where balancing intuitive usage with verbosity is a challenge. I guess it could be quite confusing hearing "5" for the first time. On the other hand, as I understand it visually, you only see the number; you don't see the " characters remaining" suffix. How do sighted users figure out this is a character count?

For a screen reader user, hearing "5 characters remaining", "4 characters remaining", etc. could get quite annoying, even though it's easy enough to interrupt it. I'd argue that even if the user doesn't know what the first number means, they'll realise very quickly that it decreases by 1 every time they type a character. That said, I'm not accounting for cognitive challenges or users extremely new to screen readers, though I wonder whether the visual experience accounts for that (as above).

-- Reply to this email directly or view it on GitHub: https://github.com/nolanlawson/pinafore/issues/2267#issuecomment-1336539337 You are receiving this because you were mentioned.

Message ID: @.***>

[nvdaes]

I've created the mentioned PR for this issue. @nolanlawson , please let me know if I should change something or feel free to edit it. Thanks.

[nolanlawson]

On the other hand, as I understand it visually, you only see the number; you don't see the " characters remaining" suffix. How do sighted users figure out this is a character count?

@jcsteh Sighted users only see a number. But they also see a gauge that fills up as it reaches 500. They also see the color red when you go over the limit.

If you both are okay with this change, then we can just make it announce the number and not the full "over limit" / "under limit" text. It's true that the number being negative or positive already implicitly communicates this.

[nolanlawson]

Also, in addition to remove the aria-label so that notifications work properly for screen readers, what about to set maxLength in the textarea to {max}? This prevents to exceed the limit even for deaf and blind people, in case someone is not able to hear notifications.

If I understand what you're saying, you're saying to set the maxlength attribute? I think that would potentially have worse consequences since you wouldn't be able to write something long and then edit it later to make it shorter. As is, you cannot post anyway if you're over the limit, and you'll get an error message about it.

[nolanlawson]

Fixed by #2300

[nvdaes]

Thanks for your explanation. In fact my proposal was related to that attribute. Thanks for merging pr 2300.

Enviado desde mi iPhone

El 10 dic 2022, a las 19:40, Nolan Lawson @.***> escribió:

 Also, in addition to remove the aria-label so that notifications work properly for screen readers, what about to set maxLength in the textarea to {max}? This prevents to exceed the limit even for deaf and blind people, in case someone is not able to hear notifications.

If I understand what you're saying, you're saying to set the maxlength attribute? I think that would potentially have worse consequences since you wouldn't be able to write something long and then edit it later to make it shorter. As is, you cannot post anyway if you're over the limit, and you'll get an error message about it.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.