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
Potential Live Region Issues with Alert Component (amongst others) #1359
Comments
Hey, sorry for the late reply! We'd love a hand with this. What are you proposing as a workaround? Note that I'm looking forward to your thoughts on this one! |
Hey @claviska, Live Region ContainerThe approach I was thinking of is having a live region available in the DOM as the page loads. You could add this whenever an An example that is similar in approach is the magenta11y alert component demo, or even the APG Alert example where the live region is available beside the show alert button. Although magenta11y are using "inert" when the role="alert" is not open which may cause issues also. Severity of AlertsSome people might not consider a success message an alert, and depending on context, info and warning might not be either. So you might need both a role="alert" (assertive), and role="status" (polite) nodes available in the DOM on page load. Focus ManagementIn the scenario where users have alerts/toasts auto-focused, I'm not sure if we allow for that in the component or why we would want that, but if that did happen it would then cause duplicate announcements (from the live region and then the focused element). We would not want duplicate announcements so we would need a way to turn them off in this scenario I think. ToastsToast accessibility can be tricky so I'm going to defer to these post on accessible toasts by Scott O'Hara and defining toast messages by Adrian Roselli. Both makes some really good points. We mentioned already about the status message. Toast is a good candidate for having a status container.
There could be a potential WCAG 2.2.1 Violation in how you hide toasts after a few seconds.
Our toasts have an action button to dismiss which complicates things also. |
Apologies for the delay. We currently use the toast stack to group alerts when they're emitted as toasts. The logic is quite simple, but it's worth noting that the stack gets created only when a toast is first emitted and destroyed when the last toast is dismissed. What do you suggest for handling both of these use cases?
Side note — we probably need to add more guidance as to how and when to use alerts. Despite them being closed by default, I think a lot of people confuse them for inline banners. 🤔
It sounds like we probably won't be able to guess the correct role here, so we may want to expose this for users. What would you recommend as a default, and what other options should we let them opt into? If we're able to simplify and abstract this, I'm thinking it might be better to default to polite and allow them to use an attribute to make them assertive as needed. Does that feel reasonable?
We're not currently doing this, but I guess people could slot in some buttons and force focus on their own. In your opinion, could we be clever about it and listen to focusin/focusout and turn it off based on that? Or do you think this will come back to bite us later on? I'm trying to avoid putting more work on end users, because that tends to lead to a worse experience and folks not doing the right things at the right times. If we can be smart about these things, users won't have to bear those burdens.
Got it. We only allow this when toasts don't require acknowledgement. This is called out in the docs. Should we change anything here, or is that OK for this specific use case? |
Hey @claviska
I am not sure how to answer this to be honest. To me this kind of feels like it might fall into more of an error summary and inline validation type of component. Kind of like what the GDS UK have done, which tends to perform good. This would also include inline validation messages for each form element, linked with aria-describedby. See an example form for GOV UK Account Creation. There is also a backlog/discussion issue for the error summary componenton Github. Would love your thoughts on that. Joe Lanman from the GDS UK team mentioned that numerous projects across various government teams exist, but they do not all get built the same.
Hmmm, yeah this is tricky. What if the stack container was present in the DOM on page load? Or a recommendation that it should be? Some interesting notes I found on the salesforce alert component:
I believe if you fire multiple role="alert" messages at the same time can cause JAWS to cut itself off and only read one message, rather than queueing the messages, hence why they use role="status" for multiple alerts.
I do think this would require an update to the docs to mention the potential violations with doing this. If you follow the pattern where they alerts automatically dismiss (go away) after a few seconds, then you are in violation of 2.2.1. In the docs under duration you have "This is useful for alerts that don’t require acknowledgement". It should not matter if the toast requires acknowledgment or not, if they auto-dismiss they are in violation of that success criterion. There is a lot to digest here, but happy to discuss with you on a call, or on discord if you prefer. |
Describe the bug
Hey, I was looking at the Alert component and I noticed it added an ARIA alert role to the component base in the shadow DOM. This component becomes hidden from the accessibility tree with
aria-hidden="true"
and also styled withdisplay: none
via thehidden
attribute.Scott O'Hara talks about live regions in a post called are we live.
Hopefully this helps, and I'm happy to help with a potential solution.
The text was updated successfully, but these errors were encountered: