FreedomScientific / standards-support

Contains documentation for Vispero software support of Web standards
https://freedomscientific.github.io/standards-support/
GNU General Public License v3.0
110 stars 12 forks source link

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

Closed joe-watkins closed 1 year ago

joe-watkins commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@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 https://github.com/w3c/aria-practices/issues/78).

JAWS-test commented 1 year ago

Related: https://github.com/w3c/aria/issues/1216

joe-watkins commented 1 year ago

@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 commented 1 year ago

Also related: #287

stevefaulkner commented 1 year ago

@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.