header/footer elements incorrectly inferred with banner/contentinfo role when nested in section

[matt-pawley]

• @testing-library/dom version: 10.4.0
• Testing Framework and version: Jest
• DOM Environment:

Relevant code or config:

    <header>Header</header>
    <main>Main</main>
    <section>
      <header>Section header</header>
      <footer>Section header</footer>
    </section>
    <footer>Footer</footer>

What you did:

Expected that only header/footer elements that are decedents of section elements don't have roles of banner / contentinfo as per the MDN docs:

By default, the HTML's

element has an identical meaning to the banner landmark, unless it is a descendant of , , , , or

, at which point exposes a generic role, and not the equivalent of the site-wide banner.

When it is an immediate descendant of the using the

element will automatically communicate a section has a role of contentinfo (save for a known issue in VoiceOver). If at all possible, prefer using instead. Note that a footer element nested within an article, aside, main, nav, or section is not considered contentinfo.

What happened:

Elements have the aforementioned roles.

Reproduction:

https://codesandbox.io/p/sandbox/react-testing-library-bug-reproduction-sw7zzf?file=%2Fsrc%2FApp.js%3A4%2C1-12%2C6

Problem description:

Conflicts with the MDN docs/browser accessibility tree.

[MatanBobi]

Hi @matt-pawley!
Thanks for opening this one.
Any chance for a reference to the spec you've used here?
Also, this should probably be an issue in https://github.com/A11yance/aria-query, but let's try to see it's indeed a bug first :)

[cmorten]

Some spec links:

https://www.w3.org/TR/html-aria/#el-footer

If not a descendant of an article, aside, main, nav or section element, or an element with role=article, complementary, main, navigation or region then role=contentinfo

Otherwise, role=generic

https://www.w3.org/TR/html-aria/#el-header

If not a descendant of an article, aside, main, nav or section element, or an element with role=article, complementary, main, navigation or region then role=banner

Otherwise, role=generic

—

It is worth noting that aria-query already somewhat has this detail through its constraints, see https://github.com/A11yance/aria-query/blob/main/src/etc/roles/literal/contentinfoRole.js#L18 and https://github.com/A11yance/aria-query/blob/main/src/etc/roles/literal/genericRole.js#L68 for pertinent code.

The difficulty is that the interface isn’t particularly consumer friendly and dom-testing-library does not consider these specific constraints as-is. It could be updated to do so, but feels like a fragile interface to couple to… an issue could be raised to see if something else could replace it in a breaking change?

dom-accessibility-api also does not cater to this requirement either as-is (so can’t pivot to that lib given it’s already consumed without changes made upstream).

I have recently been shown https://github.com/drwpow/html-aria which can cater to these requirements (I have passing web platform tests in a separate repo using this) which @drwpow has put together. Appreciate worthy of a separate issue, but worth exploring whether it stands as a more spec accurate drop-in replacement for aria-query for “context” based role calculation?

—

Though also worth asking the question whether dom-testing-library can/should support DOM context based roles. Depending on how it is consumed the library may not even be able to provide the correct role even with this logic - e.g. if composing components in separate units then very possible that a footer element is rendered in isolation and would yield a different role to if the entire DOM was rendered together.

[jrnail23]

FWIW, I just reproduced this bug I reported back in 2021, using latest versions of testing library: #997