feat(live-announcer): add ability to clear live element #11996
Conversation
crisbeto
added
needs: discussion
crisbeto
requested review from
devversion,
jelbourn and
josephperrott
as code owners
googlebot
added
the
cla: yes
|
Setting this one as "needs discussion" since I'm open to alternate ways where we could do this automatically. Otherwise if we agree on the approach, it's good to go. |
| @@ -19,6 +19,6 @@ export class LiveAnnouncerDemo { | |||
| constructor(private live: LiveAnnouncer) {} | |||
|
|
|||
| announceText(message: string) { | |||
| this.live.announce(message); | |||
| this.live.announce(message, undefined, 1500); | |||
There was a problem hiding this comment.
Should we try having a method overload? That way we can have a nicer API.
this.live.announce(message, 1500)
this.live.announce(message);
this.live.announce(message, 'polite', 1500);
this.live.announce(message, 'polite');We did the same for the MatRipple launch method.
There was a problem hiding this comment.
Good idea. I'll add it once we agree on whether this is the way to go.
| * @param politeness The politeness of the announcer element | ||
| * @param message Message to be announced to the screenreader. | ||
| * @param politeness The politeness of the announcer element. | ||
| * @param duration Time in milliseconds after which to clear out the announcer element. |
There was a problem hiding this comment.
I think it would be good to mention that this duration is being taken into account once the 100ms timeout finished.
|
Sounds good. From my perspective, the API and behavior looks fine. I think it's right to not assume that there is a perfect time to automatically clear the message. We never know how long the screenreader takes to announce the actual message. |
crisbeto
force-pushed
the
11991/aria-live-clear
branch
2 times, most recently
from
2a35827
to
d88eb6f
Compare
|
I see that you just added the If you want your PR to be merged, it has to pass all the CI checks. If you can't get the PR to a green state due to flakes or broken master, please try rebasing to master and/or restarting the CI job. If that fails and you believe that the issue is not due to your change, please contact the caretaker and ask for help. |
jelbourn
removed
the
needs: discussion
crisbeto
force-pushed
the
11991/aria-live-clear
branch
from
d88eb6f
to
4551a0a
Compare
|
Hi @crisbeto! This PR has merge conflicts due to recent upstream merges. |
crisbeto
force-pushed
the
11991/aria-live-clear
branch
2 times, most recently
from
15e4549
to
22a3a69
Compare
crisbeto
force-pushed
the
11991/aria-live-clear
branch
from
22a3a69
to
dd52f76
Compare
crisbeto
force-pushed
the
11991/aria-live-clear
branch
from
dd52f76
to
1bafaee
Compare
|
@crisbeto need to rebase again. |
Currently when we announce a message, we leave the element in place, however this can cause the element to be read out again when the user continues navigating using the arrow keys. These changes add an API where the consumer can clear the element manually or after a duration. Doing this automatically is tricky, because we'd have to make a lot of assumptions that might not be correct in all cases or may break some screen readers. These are some alternatives that were considered: * Removing the element from the a11y tree via `aria-hidden` after the screen reader has started announcing it. This works, but because of the politeness, we can't know exactly when the screen reader will announce the text, which could end up hiding it too early. * Clearing the element on the next `keydown`/`click`/`focus`. This could be flaky and might end up interrupting the screen reader when it doesn't have to (e.g. clicking on a non-focusable element). * Moving the element to a different place in the DOM (e.g. prepending it to the `body` instead of appending). This works, but we'd have to keep moving the element based on the focus direction. Fixes angular#11991.
crisbeto
force-pushed
the
11991/aria-live-clear
branch
from
1bafaee
to
bcbe6ac
Compare
|
Rebased. |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Currently when we announce a message, we leave the element in place, however this can cause the element to be read out again when the user continues navigating using the arrow keys. These changes add an API where the consumer can clear the element manually or after a duration. Doing this automatically is tricky, because we'd have to make a lot of assumptions that might not be correct in all cases or may break some screen readers. These are some alternatives that were considered:
aria-hiddenafter the screen reader has started announcing it. This works, but because of the politeness, we can't know exactly when the screen reader will announce the text, which could end up hiding it too early.keydown/click/focus. This could be flaky and might end up interrupting the screen reader when it doesn't have to (e.g. clicking on a non-focusable element).bodyinstead of appending). This works, but we'd have to keep moving the element based on the focus direction.Fixes #11991.