standards-support
standards-support copied to clipboard
JAWS not reading with aria-live field when the content exceeds 4000 characters
Summary
When an aria-live field has more than 4000 characters in it, JAWS is not reading the content added to aria-live. However, when the character counts falls below 4000, JAWS is able to read it.
To reproduce:
- Open Chrome
- Open JAWS
- Go to https://codepen.io/dedrabb1t/pen/zYeLOrg
- Navigate to the 'Add 4000 chars to live field' button using tab and press enter.
- The aria live field(the span) gets updated with 4000 chars, however JAWS doesn't read it.
- Now navigate to the 'Add 10 chars to live field' button using tab and press enter.
- The aria live field gets updated with 10 chars and JAWS reads it correctly.
Expected result
On pressing 'Add 4000 chars to live field' button, JAWS would read the aria-live field.
Actual result
On pressing 'Add 4000 chars to live field' button, JAWS doesn't read anything.
Example
https://codepen.io/dedrabb1t/pen/zYeLOrg
Additional Information
JAWS version and build number
JAWS 2023 2023.2303.144
Operating System and version
Windows 10
Browser and version:
Chrome 119 Edge 119
@dedrabb1t what is the use case for a 4000 character live region?
what is the use case for a 4000 character live region?
@stevefaulkner We have a clipboard feature where user can select text and save it for future reference. These texts are added to a search panel type component, where user can navigate through the each of the previously saved text using the arrow keys. While navigating, we add the item to a live field so that the content of the item can be read out. Some of these texts exceeds 4000 characters.
@dedrabb1t
While navigating, we add the item to a live field so that the content of the item can be read out. Some of these texts exceeds 4000 characters.
Why can't screen readers users navigate the clipboard contents the same way other users do?
Why can't screen readers users navigate the clipboard contents the same way other users do?
They are. Only difference is that now we are adding the currently navigated item to aria-live field so that screen reader users can hear the item that they are currently on.
@dedrabb1t why can't they read it using virtual cursor navigation as they do other content? If you have an actual working demo to test that would be helpful?
@stevefaulkner Hey, apologies for the delay. I won't be able to share the demo of the actual component. However, I created a pen which kinda capture the essence of what we are trying to do. If you move your focus to the input box and then use the arrow keys to navigate through the options, you would notice that JAWS is not reading the second option( the one with long text).
What we are doing: As soon as the focus moves to the option, we are adding the inner text of the option to the live field so that JAWS can read it out.
@dedrabb1t
Your combobox is implemented incorrectly. A combobox is never made with live regions to output the options. Rather, the following is correct:
- either the option receives the focus
- or the combobox, in which the focus remains, refers to the option via aria-activedescendant
See: https://www.w3.org/WAI/ARIA/apg/patterns/combobox/
Regardless of the incorrect implementation of the combobox, the fact is that there is no limit on the length of a live region in the ARIA specification. Therefore, JAWS should output the live regions in full regardless of length, but at the same time provide an option to stop output (if it is too long).
The ARIA specification should include a note that live regions should be short. Live regions with more than 100 characters are generally not useful.
@ggordon-vispero @BrettLewisVispero @RFischer-FS would be good to get your input on this issue
Even if you COULD have more than 4000 characters, I wonder if you’ve stopped to ask if you SHOULD. I hope solid user testing is happening. I can’t think of any user that would want 4000+ characters worth of content in an aria live region. Give the user control over their content consumption (which they already have) and don’t force it down their throat. This sounds like a solution for “business” and not an accommodation for a user.