-
Notifications
You must be signed in to change notification settings - Fork 18
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
Notify role="dialog" requires a label #483
Comments
Core question model Bookmarking LanguagePicker Visua11y Hotgraphic, Narrative and Hotgrid Overall, I think if a property is required to enable accessibility, then those properties should be set as required. Please add any comments or suggestions below. I'll wait for feedback before raising issues/PRs for the suggestions above. |
Closing as all plugins listed now have a suitable fallback or a required property to provide an accessible dialog label. |
Subject of the issue
Notify uses
dialog
role to help assistive technologies identify the dialog's content as being grouped and separated from the rest of the page content. Addingrole="dialog"
alone is not sufficient to make a dialog accessible and must be properly labeled. See MDN ARIA: dialog role description for reference.Both NotifyPopupView and NotifyPushView use
aria-labelledby
and reference the Notify title to label the dialog however title properties aren't set as required and are sometimes removed in favour of having body text only.In the instance no title is set, the
dialog
role isn't identified and the user is unaware the content is grouped/separate from the main page content.Notify is utilised by core and plugins. See below (and please add any I've missed):
Example using MCQ feedback
When
_feedback title
is set,.notify__title
is used to label the popupdialog
. Which reads "Feedback dialog".When no
_feedback title
is set,.notify__title
is still referenced byaria-labelledby
but the element doesn't exist so the popupdialog
has no label. "dialog" isn't announced.Expected behaviour
I think most content authors won't be aware of the accessibility implications by not setting a title so either highlighting this in the instruction/help text, setting titles as required or providing a fallback should prevent this.
The text was updated successfully, but these errors were encountered: