[html-aam PR 395] add validity IDL

[pkra]

Moved from w3c/html-aam#395

WIP for #394

The following tasks have been completed:

• Modified Web platform tests (link to pull request) - There are not CORE-AAM tests

Implementation commitment:

• WebKit (https://bugs.webkit.org/show_bug.cgi?id=252549 | [@rahimabdi edited on May 6 2025]
• Chromium implemented
• Gecko implemented

[pkra]

Now pointing to main.

[jnurthen]

@scottaohara is this ready for merge if we get a reviewer or is it waiting for implementations?

[scottaohara]

@stevefaulkner you didn't happen to make test files for this, did you?

[spectranaut]

We don't have tests for html-aam in WPT right now.

But this PR was never reviewed, so I added the reviewers from the original PR to this one -- @scottaohara @cookiecrook @cyns can you please take a look?

If reviews are positive, lets open an issue on WebKit and merge.

[cookiecrook]

I think el.ariaInvalid would stilll need to be exposed… in part because I don't know how to remove it with a HTMLInputElement ILD override, so we could leave it and expose as null. @rahimabdi @annevk what do you think?

[annevk]

It's not entirely clear to me what the requirement here is.

It's also not clear to me why tests couldn't be written for this.

Is the idea that if the form element is considered valid per HTML's requirements, aria-invalid is to be ignored? I think that should happen on the AT layer and attribute reflection shouldn't really be involved in that. (Thus if you set the aria-invalid attribute, the ariaInvalid getter will still reflect that, even if it's valid.)

[rahimabdi]

The validity IDL override is already implemented in WebKit: https://bugs.webkit.org/show_bug.cgi?id=252549. I've updated the original issue comment as well.

Also noting that, per @cookiecrook's comment, it's not possible for user agents to only expose validity as el.ariaInvalid reflection is separately computed and should remain unaffected. To @annevk's point, the value of aria-invalid could be conveyed using validity as a downstream AT consideration, and it may be more accurate to reference the source of the invalid state which is the :invalid CSS pseudo-class (since the validity IDL attribute reflects CSS :invalid).

I would propose updating the html-aam spec to state something to the effect of:

“Assistive technologies must expose the state of the :invalid CSS pseudo-class (i.e., validity IDL attribute).

Note: The indeterminate IDL html-aam mappings should align in language as well: w3c/html-aam#582.

Tracking related issues:

• Ensuring that el.validity/:invalid does not impact el.ariaInvalid reflection: Add IDL reflection tests for enumerated ARIA attributes web-platform-tests/interop-accessibility#177
• Testing aria-invalid value conveyed to AT when :invalid is matched (i.e., validity IDL attribute is set): Write tests for aria-invalid AT value (when validity IDL is set) web-platform-tests/interop-accessibility#187

[annevk]

I did not mean to suggest to define it in terms of the :invalid pseudo-class. But rather, to define it in the same terms the :invalid pseudo-class is defined in (and perhaps abstract that set of terms into a shared abstraction). The :invalid pseudo-class, much like the validity IDL attribute, is public API, and is best not relied upon in algorithms.