Skip to content
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

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

Open
matt-pawley opened this issue Aug 21, 2024 · 1 comment

Comments

@matt-pawley
Copy link

  • @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
Copy link
Member

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants