-
Notifications
You must be signed in to change notification settings - Fork 14
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
Comments
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. |
@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 |
@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). |
Related: w3c/aria#1216 |
@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. :) |
Also related: #287 |
@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. |
Summary
Hello :)
When injecting live region with
role="status"
into the DOM with JavaScript, the live region is not announced, but it is announced whenrole="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 thanrole="alert"
- they also feel this would be a better screen reader experience. At this time, most Toast Notification plugins are usingrole="alert"
because it works (announced by popular screen readers), but I'm not certain that is ideal in all cases and I am hoping thatrole="status"
(as well asaria-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 JavaScriptdocument.createElement()
to create a Live Region withrole="status"
and stagger presentation withsetTimeout();
to inject the live region, which is not ideal.Steps to reproduce:
Actual behavior:
role="status"
that is introduced to the page.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.
Expected behavior:
Example
https://cj53kj.csb.app/
JAWS version and build number
2023.2210
Operating System and version
WIndows 10
Browser and version:
Chrome 109
The text was updated successfully, but these errors were encountered: