mismatch between native and custom required controls

[stevefaulkner]

The normative statements around when to apply aria-invalid=true on an aria-required=true control is different from the observed state exposed by native control which has a required attribute

ARIA

When the user attempts to submit data involving a field for which aria-required is true, authors MAY use the aria-invalid attribute to signal there is an error. However, if the user has not attempted to submit the form, authors SHOULD NOT set the aria-invalid attribute on required widgets simply because the user has not yet entered data.

in HTML if the required attribute is set the state of an empty input control is one of suffering from being missing

So for native HTML controls if the required attribute is set the invalid state is also set in accessibility APIs, until the control is no longer suffering from being missing, the opposite is true for aria-required and normative statements in the ARIA spec advocate advocate the opposite of native HTML behaviour

This mismatch was raised 10 years ago at the time an implementer was against aligning/changing the HTML behaviour.

Is it time the ARIA spec aligned with the HTML spec on this? Rather than advising the opposite.

[trumbitta]

A blind (I'm sorry, not a native English speaker + not sure what his real condition is) person calling it "not a bug" is something else.

I have no sight issues apart from the need of light glasses, and the browser behaving like this bugs me to no end.

But I get it, and FWIW, I agree that after 10 years the softer end (ARIA) should adapt to the behavior of the barely touchable elephant (HTML spec and implementation).

[patrickhlauke]

there used to be discussions about not exposing the invalid state (for the native HTML case) if the field was "untouched"/"not dirty" (i.e. on page load before the user even got a chance to interact with the field). can't remember if that went anywhere

[JAWS-test]

Related: #1470

[jnurthen]

Would aligning this make things better for users or worse?

[jnurthen]

My view on this is that the browsers have all realised that having required fields appear in an error state when a page is loaded is terrible UI - so even though the spec states that these are invalid the browsers have all chosen to ignore the spec and not render a field as invalid (visually). Why would we want to do anything different for a screen reader?

If anyone is using required i'd generally advise them to supplement this with aria-invalid="false" until the user has touched the field - as @scottaohara notes at https://www.tpgi.com/required-attribute-requirements/

[patrickhlauke]

while this is about CSS, worth noting https://drafts.csswg.org/selectors-4/#user-invalid-pseudo

[stevefaulkner]

My view on this is that the browsers have all realised that having required fields appear in an error state when a page is loaded is terrible UI - so even though the spec states that these are invalid the browsers have all chosen to ignore the spec and not render a field as invalid (visually). Why would we want to do anything different for a screen reader?

Seems like there is a good case to ask browser implementers to align the state exposed in the acc layer with the visual state.

[patrickhlauke]

it's a bit of an odd one because the state, when you query it, should tell you whether the constraints of the field are met or not. it's only when the field is in limbo as it were that it should have a flag of "yes, it doesn't satisfy the constraints, but the user hasn't even had a chance to touch this field yet". kind of a schroedinger's cat situation.

conversely, there may well be situations where even on page load, you want to explicitly denote that a field is invalid - for instance, if the page is reloaded after a failed submission. so it's one of those "damned if you do, damned if you don't" situations.

[joe-watkins]

It boggles my mind that this is the case in Chrome's Accessibility Inspector's computed properties for a text field.

1. Native required attribute on a text field: Invalid user entry: true
2. ARIA aria-required="true" attribute on a text field: Invalid user entry: false

The mismatch in specs leads to inconsistent support and even questionable guidance towards ARIA misuse in an effort to try bend things to meet expectations.

-> feels very dark

The result here is, be sure to respect the 1st Rule of ARIA except when it comes to the required attribute because it's totally muffed up and serves dual purpose around required-ness and validity.

Which camp is right? Is a field that is "suffering from being missing" invalid regardless of user entry? If yes, why doesn't aria-required="true" compute as such?

Side note: From a CSS perspective, yes, every browser I've tested also thinks a field with the required attribute present and that is empty is invalid as the :invalid pseudo selector is triggered. (regardless of the presence of the novalidate attribute).

But it feels like most users, designers, devs, and folks in the accessibility industry agree that a form on landing without user entry loaded with errors both visually and in the code isn't a great experience.

Is there a missing HTML attribute here (valid or invalid) that we are currently using ARIA for as a Polyfill while HTML catches up?

[patrickhlauke]

Which camp is right? Is a field that is "suffering from being missing" invalid regardless of user entry? If yes, why doesn't aria-required="true" compute as such?

because when you go with ARIA, you as developer are responsible for exposing the invalid state as well - required doesn't just signal that the field is required, but also triggers the browser's own computation that then populates the valid/invalid property. whereas with aria-required="true", no extra processing happens by the browser, so you as developer need to explicitly set aria-invalid as well.

[joe-watkins]

@patrickhlauke tnx!!!

I'm assuming the aria-required attribute's native HTML counterpart is the required attribute. If that is the case, then to emulate how the native HTML attribute behaves (which is typically what we'd want to do with ARIA) we'd need to define the state of validity on landing before user interaction, thus misusing ARIA per the normative guidance that Steve calls out in this issue.

However, if the user has not attempted to submit the form, authors SHOULD NOT set the aria-invalid attribute on required widgets simply because the user has not yet entered data.

Here are our options:

1. Use native HTML at the cost of what could be considered an unequal/poor experience for screen reader users due to "invalid data" announced on fields they've not interacted with. .
2. Mix native HTML with ARIA misuse to bend native HTML's experience to what we think a better experience is contradicting the HTML spec/behavior.
3. Misuse ARIA to mimic the behavior of native HTML.
4. Redundantly use ARIA with native HTML with no payoff.
5. Use ARIA correctly and take advantage of how the browser defaults to Invalid user entry: false in the name of a better experience for screen reader users but while moving away from how the native HTML attribute works. .

At this stage, it's very tempting to encourage developers to not use the required attribute per specifications because it's announced as invalid to screen reader users without interaction and that experience isn't great. It is difficult to reconcile ARIA misuse as an alternative.

Is the devil in the details of the word "SHOULD" is present instead of "MUST" in the ARIA guidance?

Is this a browser manufacturer, ARIA, or WHATWG thing? Is alignment possible?

[JAWS-test]

Is this a browser manufacturer, ARIA, or WHATWG thing? Is alignment possible?

I think the easiest way to fix the problem is through screen readers. The HTML specification defines when a field is in invalid state. Visually the browsers do not show this, but they have a tooltip with a corresponding error message. The screen readers do not output this tooltip, but only that the field is incorrect. It would be better if the screen readers would output the tooltip. This is not only true for required, but also for pattern or type=url, type=email and all other forms of form validation (see w3c/wcag#961).

Of course, the screen readers can only do this if the browsers pass the error message in the tooltip to the Accessibility API of the operating system in the same way as aria-errormessage (see https://www.w3.org/TR/core-aam-1.2/). This is obviously not the case at the moment. In this respect, a ticket would have to be set for the browsers and the screen readers.

[joe-watkins]

@JAWS-test HA! Thanks for your insight :)

I had no idea the tooltip was even a thing! I knew that, as a result of submission, the browser's validation message would appear, but not that on landing a secret tooltip is present. This cracks me up even more.

[JAWS-test]

Filed a bug for JAWS: FreedomScientific/standards-support#621

[stevefaulkner]

@JAWS-test

but they have a tooltip with a corresponding error message

as per the HTML spec it is not an error message per se and should not be phrased as an error:

UAs may still show the title in non-error situations (for example, as a tooltip when hovering over the control), so authors should be careful not to word titles as if an error has necessarily occurred.

https://html.spec.whatwg.org/multipage/input.html#attr-input-title

[JAWS-test]

@stevefaulkner

In my explanations and example, I am not referring to the title attribute, but to the automatic error messages generated by the browser. These are clearly error messages, since they

• are only displayed if the state of the field is invalid
• explicitly indicate an error (e.g. "Use at least 2 characters, you are currently using 1 character" if minlength=2).

It is correct that the browser error messages are no longer displayed if there is a title attribute. The title attribute is always displayed even if there is no error. The fact that browsers no longer display error messages when the title attribute is used seems to be a bug in the browsers. The WHATWG example, on the other hand, suggests combining the input hint in the title with the error message from the browser:

A part number is a digit followed by three uppercase letters. You cannot submit this form when the field is incorrect.

[joe-watkins]

Joe's opinion here, I actually prefer how ARIA handles this and how browsers interpret the ARIA approach and have created an issue w/WHATWG for consideration. What I don't prefer is to encourage engineers to use native HTML for all the things, except required form fields because that is a mess for screen reader users.

Will such madness be met with open arms?

[MelSumner]

I think that ARIA does the right thing here and I think that HTML does not. Should we consider this an ARIA issue? @stevefaulkner WDYT?

[stevefaulkner]

I think that ARIA does the right thing here and I think that HTML does not. Should we consider this an ARIA issue? @stevefaulkner WDYT?

Not an ARIA issue per se, but a HTML AAM issue, I agree that it would be good to specify that the accessibility tree does not expose a required control as invalid until form submission has been attempted or until a control has been actively interacted with (data input or state change other than focus). What is required is a reliable method of doing this based on DOM property values that can be used to convey submission attempt events to the accessibility tree.

[scottaohara]

PR created in July - w3c/html-aam#429

[pkra]

Should we transfer this issue to html-aam (which already has w3c/html-aam#394)?

[scottaohara]

Seems like it’d be duplicative to me. I’d close this one

[MelSumner]

y'all read my mind, tysm! 🎉