Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
getByRole() doesn't recognize header's implicit banner role
See original GitHub issue@testing-library/domversion:7.5.1@testing-library/jest-dom:5.7.0@testing-library/react:10.0.4jest:24.9.0
Relevant code or config:
import React from "react";
import { render, screen } from "@testing-library/react";
describe("getByRole", () => {
test("doens't consider a <header> as banner role", () => {
render(<header>Test</header>);
expect(screen.getByRole("banner")).toBeInTheDocument();
});
});
What you did:
The header tag has an implicit banner role. RTL’s getByRole should be able to identify this.
What happened:
TestingLibraryElementError: Unable to find an accessible element with the role "banner"
There are no accessible roles. But there might be some inaccessible roles. If you wish to access them, then set the `hidden` option to `true`. Learn more about this here: https://testing-library.com/docs/dom-testing-library/api-queries#byrole
<body>
<div>
<header>
Test
</header>
</div>
</body>
Problem description:
From the official W3C specs:
- The HTML
headerelement defines abannerlandmark when its context is thebodyelement. - The HTML
headerelement is not considered abannerlandmark when it is descendant of any of following elements:
articleasidemainnavsection
Chrome gets this one right:
Suggested solution:
RTL should be able to identify the role correctly with respect to the above banner specs for the header tag.
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (3 by maintainers)
Top Results From Across the Web
ByRole | Testing Library
An element with the heading role can be queried by any heading level getByRole('heading') or by a specific heading level using the level...
Read more >ARIA: presentation role - Accessibility - MDN Web Docs - Mozilla
The presentation role and its synonym none remove an element's implicit ARIA semantics from being exposed to the accessibility tree.
Read more >Using the React Testing Library debug method - LogRocket Blog
test('should view implicit roles with logRoles', async () => { render(<Posts />); const postItemNode = await screen.findByRole('heading', ...
Read more >No suggestions on getByRole, queryByRole, etc
debug() I do see the entire component. So that might be? That the button from bootstrap won't work with the getByRole query. –...
Read more >React Testing Guide - Components.Guide
Most semantic HTML elements have an implicit role. ... So using them does not give us that much more confidence that what we...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
🎉 This issue has been resolved in version 7.16.3 🎉
The release is available on:
npm package (@latest dist-tag)Your semantic-release bot 📦🚀
I’ve updated
aria-queryto the latest version, but the issue still occurs, unfortunately. I’ve provided a PR.