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

Add level filter for treeitem #980

Open
lindapaiste opened this issue Jun 15, 2021 · 3 comments · May be fixed by #1088
Open

Add level filter for treeitem #980

lindapaiste opened this issue Jun 15, 2021 · 3 comments · May be fixed by #1088
Labels
enhancement New feature or request

Comments

@lindapaiste
Copy link

Summary

@testing-library/jest-dom explicitly disallows the use of the level property in getByRole for all roles except heading.
This needs to be broadened as W3 also supports this property on the treeitem, listitem, and row roles.

Relevant code or config:

  • "@testing-library/jest-dom": "^5.14.1"
  • "@testing-library/react": "^11.2.7"
test("Can select by role treeitem with level", () => {
  render(<Hello />);
  expect(
    screen.getByRole("treeitem", { name: "project-3B.docx", level: 3 })
  ).toBeInTheDocument();
  expect(
    screen.getByRole("treeitem", { name: "project-3B.docx", level: 1 })
  ).not.toBeInTheDocument();
});

What you did:

I am trying to select an element with role="treeitem" based on its level. In my actual app I have the same names appearing as both a parent and a child.

What happened:

The test cannot be executed due to an error:

Role "treeitem" cannot have "level" property.

at queryAllByRole (node_modules/@testing-library/dom/dist/queries/role.js:72:13)

at node_modules/@testing-library/dom/dist/query-helpers.js:87:17

at node_modules/@testing-library/dom/dist/query-helpers.js:62:17

at getByRole (node_modules/@testing-library/dom/dist/query-helpers.js:111:19)

at Object. (src/components/bubbles/BubblesScreen.test.tsx:24:28)

Reproduction:

Created a CodeSandbox

Problem description:

The aria-level attribute and implicit levels are supported by W3 for multiple roles, as seen here:

  • heading
  • listitem
  • row
  • treeitem

However @testing-library/dom does a validation check which only allows for level to be used with the heading role.

The problematic code appears on lines 67-72 of /src/queries/roles.js:

if (level !== undefined) { 
   // guard against using `level` option with any role other than `heading`
    if (role !== 'heading') {
      throw new Error(`Role "${role}" cannot have "level" property.`)
    }
}

Suggested solution:

The code section above needs to be modified to prevent throwing the error.

The actual computation of the level property happens here. The current code will work on treeitem elements which use the explicit aria-level attribute. The implicit level is based on the current item's position in the tree, so additional work needs to be done to compute the implicit level. heading levels can be computed just from the tagName but treeitem levels cannot. It would require some sort of querying of the parents and the tree.

@eps1lon eps1lon changed the title Error: Role "treeitem" cannot have "level" property. Support filtering by aria-posinset Aug 25, 2021
@eps1lon eps1lon changed the title Support filtering by aria-posinset Error: Role "treeitem" cannot have "level" property Aug 25, 2021
@eps1lon

This comment has been minimized.

@eps1lon eps1lon added the enhancement New feature or request label Aug 25, 2021
@MatanBobi

This comment has been minimized.

@eps1lon
Copy link
Member

eps1lon commented Jan 7, 2022

Not sure anymore why this was an issue.

But we definitely would need to add support for computing implicit level of a treeitem

@MatanBobi MatanBobi linked a pull request Jan 15, 2022 that will close this issue
4 tasks
@eps1lon eps1lon changed the title Error: Role "treeitem" cannot have "level" property Add level filter for treeitem Aug 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants