-
-
Notifications
You must be signed in to change notification settings - Fork 32.5k
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
[Dialog] DialogTitle
should use h1 instead of h2
#34250
Comments
DialogTitle
should use h1 instead of h2
@hbjORbj please tag with |
Thanks for the heads up @paulschreiber! I wonder if we really should do this, though. If the dialog's title is an h1, wouldn't that confuse users leaning on screen readers, given that it could give the impression that they have navigated to a different page altogether, which is not totally the case? A few benchmarks I've collected quickly:
|
IMHO, this issue is a duplicate of #16569. Also, +1 to keep h2 until a supporting material is provided to justify why h1 would be better. |
Hello all; for context I represent PAC, the team of accessibility consultants who recommended that this change be made within a product managed by @paulschreiber. Hopefully I can shine a light on this suggestion. A modal dialog is considered to be a distinct area from the main page, and hence the heading hierarchy can and should be reset. An
To address the specific question by @danilo-leal:
I really appreciate the attention to detail and user experience implied by this query. However, screen readers will convey the fact that the user's new context is a modal dialog (assuming that everything else about the dialog is coded correctly). These announcements are quite distinct from those triggered by a page load, and hence there should be no confusion. In terms of resources, you can observe this recommended approach within a Simple Dialog example from Deque, an Accessible Modal Dialog example by Paul J. Adam, the A11y Dialog library by @KittyGiraudel, among others. The WAI-ARIA Authoring Practices (APG) linked earlier in this thread is not a spec or published standard; they've chosen to be opinionated about the use of an Hope this helps. |
Thanks, @jscholes, appreciate the thorough answer! All of that makes sense to me and seems enough to allow the change to move forward. @oliviertassinari any objections or thoughts? We might want to enrich documentation about this, I think, given that it has come up again. |
I had a look at why it's an h2 in https://www.w3.org/WAI/ARIA/apg/example-index/dialog-modal/dialog.html see w3c/aria-practices#551
I think both can work, I have no specific recommendations. |
I think we should have a valid evidence that |
I asked @xurxe for some perspective on this issue during our last call. It seems that there are use cases for both, so I suspect that updating https://mui.com/base/react-modal/#accessibility with guidelines could be enough to close this issue. |
Hi everyone! I just wanted to hop into this very interesting discussion and add my two cents, as a web developer and IAAP-certified accessibility specialist (CPACC, WAS, CPWA). TL;DR
Definitions and backgroundAs @jscholes mentioned, we should refer to the applicable spec or standard, which is in this case is ARIA 1.1. There's three key definitions we should look at.
In the context of HTML, a dialog is a nested, secondary window that opens up within the page. A dialog can be modal or non-modal i.e. modeless. A modal dialog or window launches a special mode of operation, during which the user must interact with it in one of the "approved" ways before being allowed to return to the primary window. Such approved ways may or may not include: activating a Close button, entering text into an input field and activating an OK button, etc, depending on the situation. A non-modal dialog or window does not launch a special mode of operation, and users are free to switch between it and the primary window. These are not so commonly used in web applications, but could be something like... a color utility in an online design application (as long as it actually follows the non-modal dialog pattern, rather that being implemented as a tooltip or something else). I also want to point out that there is conflation / confusion between dialogs and modal dialogs, both in this discussion and in the MUI Dialog documentation. Additionally, the MUI Modal documentation has some inaccuracies as well. Addressing these issues goes beyond the scope of this discussion, but in spite of that I'd like to say that the MUI Dialog component constitutes a fairly successful implementation of the modal dialog pattern. My take on the heading levelAfter much consideration, I do think that
|
@xurxe Thank you for taking the time to write this out. Unfortunately, the conclusions seem to revolve around assertions which themselves are not standardised or evidence-based, rather than on the nuances of end-user and developer experience. Specifically:
In other words: what we have is a window on top of some other content, which precludes access to that content, and should be treated as a separate bounded context. The window is a descendant, but this is mostly a technical concern, and only relevant to users from a wayfinding perspective as they navigate into and out of the dialog. Note that I'm only considering modal dialogs here; non-modal dialogs are a completely separate topic and not in scope. However, you then assert that:
For the purposes of usability and structured understanding, there should only be a single This is also why each dialog doesn't need to have a uniquely named "Close" button, for example, because the user should never be interacting with multiple modals at once. Suggesting that every modal dialog must participate in the same constraints as the parent page is not scalable nor user-friendly.
I've already covered why I believe the first part of this statement, about the participation of the modal content within the parent page's constraints, to be suboptimal. However, I want to call out the following suggestion:
... as something which I don't understand. When developing a heading hierarchy that truly reflects the structure of the underlying content architecture, the most sensible heading level will differ based on context. There is no such thing as a heading level which is the "most sensible level in most situations". To follow this logic through to its conclusion, though: if a modal dialog does need to participate in the page's overall hierarchy, why is hardcoding an To be clear, I'm not suggesting that this should be the case; I think I've been pretty unambiguous up to this point about my support for an So, with that in mind, I'm struggling to see
I'm not sure what you're basing this on, but the primary indication that the page has changed is a new page title, which in a standard multi-page app is announced by a screen reader automatically. The Similarly, when a dialog is invoked, and focus is placed e.g. on the "Close" button, a screen reader will inform the user of that context. They will know that they are inside a dialog, assuming that it is named and marked up correctly, and the
In theory, yes. In reality, most screen reader/browser combinations don't support this approach, and will either fall back to I don't think it should make any difference as to whether or not my advice is taken on board. But for what it's worth, I speak not only as an accessibility professional, but a screen reader user myself. I've enumerated my reasoning twice at this point, but in essence we have a 50/50 split between two people working in the accessibility industry. I will continue to advise clients to use an |
Thanks @jscholes for your thoughtful reply! What I understand from this conversation is that we both agree on our interpretation of ARIA 1.1 (side note: when I quoted the spec it was just for the benefit of the non-specialists reading, since I gathered you were already familiar with it), but we have different opinions regarding what's not directly said in the ARIA or HTML specs, especially in terms of how a modal dialog relates to the primary window / application. And it seems like we're not alone in that, judging by the different implementation examples that have been discussed in this thread. I also wasn't very clear on what I meant by "
In most examples I could think of, if I was to use a heading element at all, I would have chosen I did however come up with some cases where I could see a lot of value in using I think a reasonable compromise would be to let developers customize the level of |
Typically one h1 on a page helps create a navigatable structure. There Is No Document Outline Algorithm. https://adrianroselli.com/2016/08/there-is-no-document-outline-algorithm.html#Update10 But I wasn't sure what the right answer is now we have `aria-modal` that can trap focus and mark other elements as inert, and went on a little side quest. Turns out W3C's APG Task Force (ARIA Authoring Practices Guide) discussed this in a meeting a few years ago. w3c/aria-practices#551 (comment) They concluded: - It is helpful if there is a consistent approach across dialogs in an application. - There is not necessarily a need for the APG to prescribe a specific approach. So, I guess provided you're in a modal either h1 or h2 is fine. APG continue to use h2 in their example and Material UI are undecided, with some interesting back and fourth on when a h1 or h2 might be a better experience. mui/material-ui#34250 Probably, it's not a big deal either way. If I had to pick a global rule based on the above and no access to direct user testing for this, I'd go with h2. Here it is. A quick PR to switch to a h2. This was prompted by a user question in the support Slack channel. https://financialtimes.slack.com/archives/C02FU5ARJ/p1696242420071219
Typically one h1 on a page helps create a navigatable structure. There Is No Document Outline Algorithm. https://adrianroselli.com/2016/08/there-is-no-document-outline-algorithm.html#Update10 But I wasn't sure what the right answer is now we have `aria-modal` that can trap focus and mark other elements as inert, and went on a little side quest. Turns out W3C's APG Task Force (ARIA Authoring Practices Guide) discussed this in a meeting a few years ago. w3c/aria-practices#551 (comment) They concluded: - It is helpful if there is a consistent approach across dialogs in an application. - There is not necessarily a need for the APG to prescribe a specific approach. So, I guess provided you're in a modal either h1 or h2 is fine. APG continue to use h2 in their example and Material UI are undecided, with some interesting back and fourth on when a h1 or h2 might be a better experience. mui/material-ui#34250 Probably, it's not a big deal either way. If I had to pick a global rule based on the above and no access to direct user testing for this, I'd go with h2. Here it is. A quick PR to switch to a h2. This was prompted by a user question in the support Slack channel. https://financialtimes.slack.com/archives/C02FU5ARJ/p1696242420071219
Bootstrap had the same conversation, and the a11y expert (Patrick H. Lauke) said that a H1 for a modal title should be the best: "as modal dialogs create their own little world/document/structure, it would make sense that the title is the primary heading in this new "island" of content. particularly if the underlying page is hidden from AT"... Thanks! |
This comment is convincing: mui/material-ui#34250 (comment)
Current behavior 😯
Dialog and DialogTitle generates this HTML
Expected behavior 🤔
Steps to reproduce 🕹
Context 🔦
Dialogs should have their owner heading hierarchy, starting with h1. This is important for screen readers.
Your environment 🌎
npx @mui/envinfo
The text was updated successfully, but these errors were encountered: