CDK LiveAnnouncer region not hidden from screen reader #11991
Assignees
Labels
P3
An issue that is relevant to core functions, but does not impede progress. Important, but not urgent
Comments
|
This needs to be fixed. Perhaps an auto 'removal' of message string after a 'Configurable' timeout would help. |
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
Jun 30, 2018
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
added
P3
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
Jun 30, 2018
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
added a commit
to crisbeto/material2
that referenced
this issue
Jun 30, 2018
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.
jelbourn
pushed a commit
that referenced
this issue
Jul 11, 2018
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 #11991.
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
Jul 28, 2018
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
added a commit
to crisbeto/material2
that referenced
this issue
Aug 1, 2018
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
added a commit
to crisbeto/material2
that referenced
this issue
Aug 6, 2018
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.
jelbourn
pushed a commit
that referenced
this issue
Aug 23, 2018
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 #11991.
jelbourn
pushed a commit
that referenced
this issue
Aug 25, 2018
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 #11991.
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
Oct 9, 2018
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.
vivian-hu-zz
pushed a commit
that referenced
this issue
Nov 6, 2018
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 #11991.
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
Nov 8, 2018
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
added a commit
to crisbeto/material2
that referenced
this issue
Nov 8, 2018
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.
vivian-hu-zz
pushed a commit
that referenced
this issue
Nov 9, 2018
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 #11991.
|
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. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Bug, feature request, or proposal:
Bug
What is the expected behavior?
The message text announced via the CDK
LiveAnnouncerservice should not be accessible to screen reader users except when it is being announced.What is the current behavior?
Once a message has been announced the aria-live element is visible to a screen reader user during normal page element navigation.
What are the steps to reproduce?
=> After pressing the arrow key several times the element containing the message text "Hello world!" is read by the screen reader.
What is the use-case or motivation for changing an existing behavior?
Hearing the message from a previous aria-live announcement while navigating page elements is confusing for users.
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
Angular 6.0.6
Material 6.3.0
Is there anything else we should know?
I was able to reproduce this issue with both NVDA and JAWS.
The text was updated successfully, but these errors were encountered: