-
Notifications
You must be signed in to change notification settings - Fork 86
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
fix: aria role behavior #2171
Merged
Merged
fix: aria role behavior #2171
Changes from all commits
Commits
Show all changes
9 commits
Select commit
Hold shift + click to select a range
49c7cb2
fix: aria role behavior
a848629
style: format
ee7bf06
fix: use slot for heading, implement a11y workaround for role=status
0faf96b
test(visual): update snapshots (#2172)
github-actions[bot] e81901b
style: format
c57080d
fix: a11y remove unnecessary custom workaround
7ee93be
fix: implement change requests
93d5169
style: format
6c42d60
docs: document prop change
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it still guaranteed that notifications which are not initially opened are not announced by screen readers immediately? Since the default value of
this.innerRole
is'alert'
even closed notifications would initially be rendered withrole="alert"
if not specifyinginnerRole
andinnerAriaLive
. So, if the element with that role is part of the accessibility tree it would be announced right away. Could be the element is hidden via CSS in a way that detaches it from accessibility tree. Otherwise, we might need a workaround for that. I don't know if settingaria-hidden="true"
ifthis.isOpened === false
could help.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry if that comment is confusing. I mixed two things up:
Announcement while being closed should not be an issue because this seemed to work before. If attribute
opened
is not set the inner role was'alert'
before and that seemed to work fine.The change with this code deletion is that notifications which are initially opened will be announced because they have
this.innerRole === 'alert'
by default. If preventing initial announcement of visible notifications is desired by some projects they could setinnerRole
to something other than'alert'
or'status'
to prevent the ARIA live region. Maybe setinnerRole="note"
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so, since they have
display: none
in css, so it should not be read out at all, even if it has a status of alert.Yes that is one effect, and the difference between
alert
andstatus
is thatalert
will interrupt anything else that is being read by the screenreader, whilestatus
should wait until the screen reader is idle.The current implementation seems to work when
inner-role="status"
andopened=true
(the element has display:flex, role=status, headline is read out).THIS WORKS:
However when dynamically opening a notification with
inner-role="status"
, it will not be read out - as far as i understand it's because when scale-notification goes fromdisplay:none
todisplay:flex
it already has its text content (heading and text slots).DOESN'T GET ANNOUNCED:
I found that one way around it, though not ideal, is to first set
opened=true
and then set/change the text contents, that will trigger the screen reader (role="status" only reads when some content changes are detected).HACKY WORKAROUND:
this is what i tried to do previously, in the component itself, but without any good result
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we use such "delayed text insertion" in our project in another ARIA live region with
aria-live="polite"
to have NVDA read that text right after component render. Very unintuitive, but well... alright.