Closed brtrick closed 1 year ago
Hi @brtrick, thanks for the detailed report :) We're here if you need any help.
Thanks. I finished the pr, but the codebase had 15 failing tests before I did anything (including a couple related to other issues in role-helpers.js), and now it doesn't want to let me commit because of the failed tests. Should I bypass verification and submit the pr anyway? Not sure how best to proceed...
Thanks. I finished the pr, but the codebase had 15 failing tests before I did anything (including a couple related to other issues in role-helpers.js), and now it doesn't want to let me commit because of the failed tests. Should I bypass verification and submit the pr anyway? Not sure how best to proceed...
Hmm, the codebase shouldn't have failing tests, as you can see in the commits, the latest commits passed ci. Which version of node are you using? You can skip the verification to see if it passed in ci :)
Using Node 16.17 locally, but I get the same failures in all ci Node versions that I got locally. Tried cloning the repo directly for a fresh install; gives me the same 15 failures out of the box.
@brtrick This might be related to the new aria-query
release, can you please see what's the version of aria-query
you have installed?
@eps1lon Heads up about this, it looks like the aria-query release broke a few use cases for us.
Confirmed. I was using the new aria-query 5.2.1 that was released yesterday. When I reverted to 5.1.3, everything passed.
@brtrick After consulting with @eps1lon, we're pinning the version for now so we'll be able to work on it properly because it looks like these changes might be big.
Sleuthing through the aria-query changes, although the suggested change works around the issue it looks like there are potentially wider considerations may be needed.
In https://github.com/A11yance/aria-query/pull/447 it appears all constraints
associated with attributes
were removed. E.g. see https://github.com/A11yance/aria-query/pull/447/files#diff-10f57900798ab6f135687081ccc9acafbb0a469d71355baddd128ba1b2b45399L3377 where the constraint that the alt
must either be set or not set at all (for the two cases) in order the the img
tag to have the img
role were removed.
Consequently the check for "undefined"
in the constraints
array in the role-helpers.js
will now never be truthy. See https://github.com/testing-library/dom-testing-library/blob/main/src/role-helpers.js#L84
A naive search suggests there are potentially 9 scenarios where this constraint is no longer present in the latest version(s) of aria-query
, impacting the following scenarios:
combobox
role when multiple
and size
are undefined
for the select
elementcombobox
role when multiple
is undefined
and size
is 1
for the select
elementimg
role when alt
is undefined
for the img
elementsearchbox
role when list
is undefined
and type
is search
for the input
elementtextbox
role when list
is undefined
and type
is undefined
for the input
elementtextbox
role when list
is undefined
and type
is email
for the input
elementtextbox
role when list
is undefined
and type
is tel
for the input
elementtextbox
role when list
is undefined
and type
is text
for the input
elementtextbox
role when list
is undefined
and type
is url
for the input
element
@testing-library/dom
version: 9.3.0The Issue
If an
img
tag has analt
attribute, its role shows up aspresentation
instead of asimg
. So, e.g., this test:produces this result:
ARIA Background
According to the ARIA docs an
img
should only default to the role ofpresentation
if it has analt
attribute equal to "":Source of the Problem and Proposed Solution
The problem arises when the selector is being made in
role-helpers.js
:https://github.com/testing-library/dom-testing-library/blob/d09b3c25b07486c17603317f4c5a0320c188cbed/src/role-helpers.js#L80-L94
Because a value of
""
resolves to false in line 87, the selector for a presentationimg
ends up returning[alt]
instead of[alt=""]
as its characteristic attribute, meaning that anyimg
with analt
attribute will be marked with apresentation
role. Simply adding an explicit check forvalue === ""
on line 87 fixes the issue. (The check could be made more specific if that is needed.)I will submit a PR with the proposed fix and updated tests.