-
Notifications
You must be signed in to change notification settings - Fork 389
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
feat: Add toHaveRole matcher #572
feat: Add toHaveRole matcher #572
Conversation
I wouldn't worry about this part too much. dom-accessibility-api is the natural fit but we don't want to use aria-query in there so it's not just about copying over impl but getting rid of aria-query entirely. |
Did you file a docs PR yet? |
I made the changes to README.md in this PR. Is there some other place to change for the docs, or should I split the docs and feature into two PRs? |
@fpapado thanks a lot for taking care of this. Very thorough PR, BTW. About this:
I had not taken a look at both implementations closely enough before, but I did now. I must say that I prefer the one in dom-accessibility-api for two reasons:
However, I do sympathize with the idea of the shared implementation. I wonder why |
Thank you 😌
My gut feeling is that For invalid So I can see some value in not being strict about them, but I agree that matchers can make different decisions than the browser 😅 |
Historicaly reasons. A rewrite would not use aria-query. Ideally we'd move everything into dom-accessibility-api (the interface not the implementation) and use that everywhere. |
🎉 This PR is included in version 6.4.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
@all-contributors please add @fpapado for code, docs, test |
I've put up a pull request to add @fpapado! 🎉 |
What:
This PR adds the
toHaveRole
matcher described in #143.Why:
Sometimes, it is desirable to make assertions about the accessible role of an element. While the prioritites in testing-library encourage querying an element by its role, there are times when you already have access to an element, and want to run assertions, without changing the query itself. For example, some codebases prioritise test ids over role queries. This enables more robust accessibility checks for these scenarios :)
How:
In large part, I am porting over dom-testing-library's role helpers to this one.
Under the hood, the role helpers use aria-query which gives programmatic (and auto-updating) access to the ARIA specification and its HTML mappings.
The helpers then compile the different conditions (attributes, DOM tree relationships) into a CSS selector, and provide a function to match an element via the
HTMLElement
matches()
method.Checklist:
Questions for the maintainers
I have two main questions, that I would want the maintainers to clarify:
aria-query
mappings)dom-testing-library
, I have a gut feeling that we could move these helpers to a shared package. I noticed that @eps1lon's dom-accessibility-api also has agetRole function
, albeit with a different implementation. I have not looked enough into it, to evaluate which one is more fit for this use-case. Do you have any preferences?Question 1. is more imminent for this PR, I suppose 😁 Question 2. can be an implementation detail, that we can tackle in a follow-up. I leave it up to you.
Please let me know if there is any other information that I can provide!