-
Notifications
You must be signed in to change notification settings - Fork 124
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
Consider discussing aria-describedby and aria-modal in dialog prose #1195
Comments
Thanks for starting this @carmacleod Definitely want to help out with this one :) |
Just to mention @accdc Whatsock Roles Matrices has a description for dialog that seems to meet everything I have read in this discussion. |
Thanks, @LaurenceRLewis! There are some words in there that we can use. |
Extending the scope here slightly, I wonder if there is opportunity in #2054 to provide further clarity on the expectation of assistive technology for announcing a dialog’s accessible role and name in addition to the new clarification of announcing description? @scottaohara has added:
Could/should this be extended to include “accessible role, name, and descriptions”, or is role and name information nominally included in the definition of “descriptions”? I have not tested extensively, but we appear to have precedent in at least NVDA and VoiceOver for MacOS for announcing this detail when an element contained within a dialog is brought to focus. There is prior art for describing the expectation this way, see MDN:
At the moment it is not clear from the spec (I might be missing something) what the full intended purpose of providing an accessible name via Beyond the standard use-case, presumably it is to address the nature of assistive technology announcing the dialog information upon focus of one of it’s child elements with a fallback of announcing the entire contents, but this is not stated explicitly. There are hints that this is the generally understood behaviour in the community:
REF: #1799 (comment) Let me know if this is better placed on the PR or a new issue! |
Reading through the definition of dialog role, the prose feels "pretty skimpy". (Take a quick look at combobox for comparison.) Dialog is a complicated role, and authors often get it wrong. The spec could help by pointing out some things to take note of.
Stronger normative language for dialog label will be added when #1180 is merged. That's a great start, however I'd like to also add some words to draw attention to
aria-describedby
andaria-modal
on dialog elements.Description
Since
aria-describedby
(and the newaria-description
) are global attributes, they hide in the list of inherited attributes unless they are called out in the prose. We could even consider some normative language aroundaria-describedby
, such as perhaps:Modal
Currently, the only thing the dialog spec says about the concept of "modal" is that:
There's also a vague statement about:
...which may or may not mean trapping tabs and/or making content outside of the dialog inert, i.e. it's very unclear. I'm not even certain that "manage focus" is the correct phrase, because I think authors are unlikely to use the aria-activedescendant or roving tabindex strategies for managing focus that are described in the Managing Focus section of the spec.
Adding a sentence that links to the aria-modal definition will give authors a place to read more information about what it means to be "modal". It will also draw attention to
aria-modal
, which is also hidden in the list of inherited properties becausedialog
inherits it fromwindow
.aria-modal
is useful because it tells the user the dialog is modal, so they know they're in a place where reading and tabbing "should" be limited to content within the dialog. Of course, content outside of the dialog may or may not be removed from navigational shortcuts, but at least the user can decide whether to intentionally use those.We could consider adding some normative language around
aria-modal
, while admitting that some authors prefer to use an inert polyfill:ARIA Practices Guide
The APG does have a section on dialog, and some examples.
This is great, however I still think the spec needs to step up and make some assertions, because:
The text was updated successfully, but these errors were encountered: