Clarify: should <header> inside <dialog> retain role=banner? #579

The implicit-role rule for <header> (https://www.w3.org/TR/html-aria/#el-header) maps to role=banner unless the element descends from article, aside, main, nav, section, or an element with role article, complementary, main, navigation, or region. <dialog> isn't on either list, so a <header> inside <dialog> retains the banner role.

I was surprised by this when html-validate's unique-landmark rule (which applies the mapping strictly) fired duplicate-landmark errors on a fairly ordinary modal-heavy template:

<body>
  <header>…page banner…</header>

  <dialog id="add-resource">
    <header>…dialog title bar…</header>
    …
  </dialog>

  <dialog id="preview">
    <header>…dialog title bar…</header>
    …
  </dialog>
</body>

Under the current mapping, all three <header> elements expose role=banner — so the rule reports the second and third as duplicates of the first. The pattern is common in modern apps that use <dialog> heavily, so the resulting error volume feels like a false positive even though it follows the spec.

A different interpretation has shown up in tooling: eslint-plugin-ember's template-no-duplicate-landmark-elements rule treats <dialog> (and elements with popover) as scope roots — landmarks inside a dialog don't collide with those outside it or in sibling dialogs. The rationale was that a modal context presents its own landmark hierarchy.

In addition to <dialog>, the case may also be relevant for <div role='dialog'> and/or <div popover>.

Questions:

1. Is the current behavior (<header> inside <dialog> = banner) intentional, or has the dialog/landmark interaction simply not been addressed yet?
2. If revisited, would the WG entertain adding <dialog> (and arguably the popover attribute) to the banner-stripping ancestor list, with analogous treatment for <footer> / contentinfo?
3. Or is "modal context resets landmark scope" better expressed as a separate mechanism, parallel to (rather than folded into) the implicit-role mapping?

Disclaimer: I have not tested actual AT behavior to see whether screen readers in practice announce a dialog's <header> as a page banner.

Thanks!