Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

role="status" live region not announced when injected into DOM #696

Closed
joe-watkins opened this issue Jan 27, 2023 · 7 comments
Closed

role="status" live region not announced when injected into DOM #696

joe-watkins opened this issue Jan 27, 2023 · 7 comments

Comments

@joe-watkins
Copy link

joe-watkins commented Jan 27, 2023

Summary

Hello :)

When injecting live region with role="status" into the DOM with JavaScript, the live region is not announced, but it is announced when role="alert" is used. Is this by design? Same experience in NVDA.

VoiceOver/Safari on iOS and macOS do successfully announce all live regions: role="status", role="alert", and even `aria-live="polite" when injected into the DOM, as expected.

Use Case: Author wants to present a Toast-style notification to the user so they inject a container into the DOM with role="status" because they feel that role would be more appropriate for that content than role="alert" - they also feel this would be a better screen reader experience. At this time, most Toast Notification plugins are using role="alert" because it works (announced by popular screen readers), but I'm not certain that is ideal in all cases and I am hoping that role="status" (as well as aria-live="polite") could behave the same to give authors choice.

Workaround: Must have role="status" present in the DOM at page load and update its contents OR use JavaScript document.createElement() to create a Live Region with role="status" and stagger presentation with setTimeout(); to inject the live region, which is not ideal.

Steps to reproduce:

  1. Start JAWS
  2. Open Chrome
  3. Visit this URL: https://cj53kj.csb.app/
  4. Activate the first button with the label "Toggle role="status" Notification" and listen for an announcement of the live region.
  5. Activate the next button with the label "Toggle role="alert" Notification" and listen for an announcement of the live region.

Actual behavior:

  1. JAWS does not announce live region with role="status" that is introduced to the page.
  2. JAWS does successfully announce the live region with role="alert" that is introduced to the page.

Note: Both Firefox and Chrome do appear to expose the live region in the Accessibility Tree once it is introduced into the DOM. At least it can be found in the accessibility inspectors for each browser.

Screenshot of Chrome DevTools Accessibility inspector highlighting the exposed live region, HTML code of live region highlighted as well as the content in the viewport.

Expected behavior:

  1. JAWS would announce all Live Regions that are added to the DOM.

Example

https://cj53kj.csb.app/

JAWS version and build number

2023.2210

Operating System and version

WIndows 10

Browser and version:

Chrome 109

@JAWS-test
Copy link

If I understood the principle of live regions correctly, the behavior you described would be correct for status and incorrect for alert. Because: A live region informs about changes in its content. If I insert the live region with its content into the DOM at the same time, then no change takes place. I always have to insert the live region first or already have it in the DOM and then change the content.

@joe-watkins
Copy link
Author

@JAWS-test Tnx! yes, consistency with regard to the handling of the live containers would be great either way :)

My preference would be to announce them all the way they should be announced based on their implicit assertive polite values regardless of whether they are dynamically injected or in the DOM at load/render. This shouldn't create breaking changes - I'd hope.

@JAWS-test
Copy link

@joe-watkins I totally agree with you. Consistent behavior, across browsers and screen readers, would be very desirable. However, I think this would require the ARIA specification to be clearer about live regions (see w3c/aria-practices#78).

@JAWS-test
Copy link

Related: w3c/aria#1216

@joe-watkins
Copy link
Author

@JAWS-test Oh my goodness - you've been very busy on this :) ha. Wow.

Yes, the consistency in guidance from the ARIA spec would be super nice. I could see consistency also helping with support for user settings with regards to live containers. If they behaved in a predictable fashion user settings could be built up around that foundation too. But, because there isn't fully baked ARIA spec guidance for AT it seems like, those manufacturers could do what they want and maybe all align?

I've logged the same issue over in NVDA land to see what they think too. Thank you for taking a peek at this. :)

@joe-watkins
Copy link
Author

Also related: #287

@stevefaulkner
Copy link
Contributor

@joe-watkins going to close this as NVDA have too. Once the ARIA specs are updated to clarify if JAWS behaviour not in line with specification will re-open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants