[dialog] Consider using h* tag for the title element

[DiegoCardoso]

The title property was introduced by #3623 and, when set, the Dialog creates an element to attach it to the title slot. Currently, it creates a span element.

span doesn't feel quite right for this purpose, so checking some component libraries, the ones found use <h2> for the dialog title.

Examples:

• https://www.material.io/components/dialogs
• https://www.radix-ui.com/docs/primitives/components/dialog

In the other hand, there's a similar discussion about the heading level on Confirm Dialog, and the use of a hard-coded h* tag was discourage here.

Originally posted by @DiegoCardoso in #3623 (comment)

[web-padawan]

Related issues for other components:

• details: heading level cannot be specified for elements with heading role #90
• login: incorrect heading levels #98
• [confirm-dialog] Minor accessibility enhancements #467

[knoobie]

Just a note from me: before you over-engineer something around the usage of h*; go for an educated guess as e.g. above with dialogs of other design systems and use a h* by default inside the header.

The rendering function allows people to overwrite the whole header anyway, which is probably used the most to add more content like close button so they have full access for the header anyway and can set the appropriate h* if needed.

Edit: if login and confirm extends the dialog (flow side) the same would apply there as well.

[rolfsmeds]

In addition to Material and Radix mentioned above to use H2, SAP UI5 also uses H2 and Carbon seems to use a combination of H2 and H3 (they have some kind of dual-title setup in their dialogs).

The ARIA Practices Modal dialog example also uses H2 (even though it's opened from an article H2 section).

The minutes of an ARIA Authoring Practices Group meeting discussing this dilemma doesn't reach a consensus, but one member is in favor of H1/H2 and others point out the importance of consistency over specific heading level recommendations.

[rolfsmeds]

We've also discussed (elsewhere) to provide API for overriding the default heading level. I'm not sure if it's feasible to change the element's type to another H* that way, and if not, perhaps aria-level would be more feasible. In that case I presume it would be better to use a with a default aria-level="2" than to override the level of a H2 to H-something-else?

[rolfsmeds]

In any case, based on the above I think H2 / aria-level="2" is a good default, whichever way it's implemented, and that we can postpone the implementation of the overriding API for a later version. Just need to implement the default now in a way that can be overridden later.

(And yes, those other components that use or extend Dialog, they should at some point be refactored to use the new header and footer, and thus also whatever the new default heading level is, but that's of course outside the scope of this feature.)

[knoobie]

In that case I presume it would be better to use a with a default aria-level="2" than to override the level of a H2 to H-something-else?

Over writing an attribute is probably easier than replacing an element; so this sounds good

Just need to implement the default now in a way that can be overridden later.

Luckily the new header is already completely overwrite able if used without title set :) so it's fine for me as well

[rolfsmeds]

As we now have a separate slot for the title element, it would make sense to use <h2> for the default generated title element, since developers can provide their own through the slot if h2 is not an appropriate heading level in their case, and a semantic html element is generally preferable over aria attribs.

[knoobie]

Totally agree! My concerns are gone now :)

[knoobie]

@rolfsmeds probably something interesting for the discussion here https://twitter.com/htmlstandard/status/1542725809848434688