Jest-dom: Add .toBeInvalid and .toBeRequired

[hiwelo]

Describe the feature you'd like:

I was wondering if we could add toBeRequired and toBeInvalid as tests based on the same logic as toBeDisabled.

The toBeRequired test could be based on either having:

• a required attribute;
• an aria-required attribute.

The toBeInvalid test could be based on having:

• an aria-invalid attribute.

For accessibility reasons, I am writing a lot of tests using these requirements and it would be way cleaner if I could use the same kind of syntax as toBeDisabled.
What are your thoughts about that?

Describe alternatives you've considered:

At the moment, I am using .toHaveAttribute('aria-invalid') or similar.

[hiwelo]

Just one more information, this would be really interesting for me especially for the .toBeRequired because it could avoid having two different lines for the same test. 👍

[gnapse]

This sounds interesting.

Although I'm a bit skeptical in general given the simplicity of the alternative, especially in the case of the .toBeInvalid, where you can do this with a single line. However, on a deeper check of the documentation of this attribute, it's not as simple as checking if the attribute is present, because it could be present with a value of false, which means the element is not invalid.

And as you said, .toBeRequired is a bit more justified, given that it needs to check for the presence of two different attributes. Also in this case, aria-required can be false, which means is not required.

So overall, yes, I think this would be a good addition to the set of matchers in this library. I'll link here to the spec of these attributes so that all the rules are kept in mind when developing this:

• aria-invalid
• aria-required
• required (this one has quite a few caveats where the attribute does not apply or does not have the intended effect)

Another thing to keep in mind is what's the precedence of required and aria-required? What happens if both are present and indicating opposite things? (regardless of which comes first, we should issue a warning in those cases).

And regarding .toBeInvalid, I'm not sure if we should call it toBeValid instead 🤔. I think the same question came up around .toBeDisabled and why not .toBeEnabled instead. So we ended up providing both, so maybe we should do the same in this case.

Having said all this, are you up to contribute this yourself @hiwelo? I may get to it, but maybe in a couple of weeks.

[hiwelo]

Quick answer for the precedence of required vs. aria-required: the value of required is read over aria-required. This is mainly due to the fact that required is a read-only property, so not requiring/accepting value.

The only case of opposite indications could be: required aria-required="false".
In this case, the Accessibility API is having required as state for the input.

For the self-contribution: Yes, I can give it a try and let you know if I am stuck. 🙂

[hiwelo]

I did a first PR for the .toBeRequired() and .toBeOptional().
I will do it later for .toBeInvalid() because I would like to check before if aria-invalid is the only way to check the _invalidity_ of a form element.

[hiwelo]

PRs #109 (toBeRequired) and #110 (toBeInvalid) merged. I think all topics discussed here are now part of jest-dom. I'm closing the issue 👍

[franciscop]

I was learning about aria-required and it seems that it is not needed anymore (answer from 2016):

https://stackoverflow.com/a/37975985/938236

[hiwelo]

I agree, aria-required is not needed anymore since HTML5, but it is still part of the WAI-ARIA spec. It is not deprecated at the moment.

So I would definitely not advertise its usage, but I would keep it part of the toBeRequired custom matcher. Because if someone is using it, it is still supported by most of the assistive technologies and standard.