1456461 - Form validates in screen readers despite 'novalidate' attribute

Status: UNCONFIRMED

(Core :: Disability Access APIs, defect, P3)

Description

[Anika Henke]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Steps to reproduce:

1. Open http://jsbin.com/fiqevot in Firefox (which includes a form with a 'novalidate' and some inputs with a 'required' attribute)
2. Open a Firefox-compatible screen reader (tested in NVDA and JAWS)
3. Navigate to an input (either via tabbing to it or other means)
4. Listen to the screen reader output


Actual results:

NVDA and JAWS both do an inline validation and immediately announce "invalid entry" when tabbing to a required input.


Expected results:

Screen readers shouldn't announce that the entry is invalid as there is nothing to validate when the 'novalidate' attribute is present on the form.

This does not happen when testing the same page with NVDA or JAWS in IE11 (or with VoiceOver in Safari).

Comment 1

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 2

[alexander :surkov (:asurkov)]

Marco, do you have any thinking and/or references on how @required attribute should be exposed to AT, when @novalidate and/or @formnovalidate attributes present? Does those basically mean that @required attribute has no semantics?

Comment 3

[Marco Zehe (:MarcoZ)]

(In reply to alexander :surkov from comment #2)
> Marco, do you have any thinking and/or references on how @required attribute
> should be exposed to AT, when @novalidate and/or @formnovalidate attributes
> present? Does those basically mean that @required attribute has no semantics?

Neither spec [1][2] says so for the aria-required or required attributes. However, the chapter about novalidate[3] says that the fields are still required, and that form submission is only not prevented in a particular case when the fields aren't filled out. See the example of how these attributes play together.

I think we are still doing the right thing. Especially considering the given example, the AT user still has to know whether the field is required (and valid) when they want to hit the Submit button, not the Save button.

I didn't find anything in the core-am spec, especially not on the non-aria version.

[1] https://www.w3.org/TR/wai-aria-1.1/#aria-required
[2] https://www.w3.org/TR/html5/sec-forms.html#the-required-attribute
[3] https://www.w3.org/TR/html5/sec-forms.html#element-attrdef-form-novalidate

Comment 4

[Anika Henke]

At least the bits in the specs linked above don't seem to say anything about what to do with 'novalidate'/'formnovalidate' *before* submission of the form or in any AT.

> the AT user still has to know whether the field is required (and valid) when they want to hit the Submit button, not the Save button

The case we are talking about here is the equivalent of the Save button, so something that was marked up to not be validated. And that AT users should know when a field is required is also not disputed. This is about whether they should be told it's invalid. And especially, if they should be told it's invalid the moment they tab into the field.

Why would a field only need to be validated for screen reader users but not for other users? Shouldn't we try to give both as equal an experience as possible?

If this is what the spec says should happen, I'm happy to raise a bug report with the W3C.

Comment 5

[Anika Henke]

I have just re-tested and found this is still an issue with Firefox, although it's also an issue with Chrome, both while using NVDA and JAWS. So, not sure if this is a Firefox and Chrome bug or an NVDA and JAWS bug.

Evidence that this behaviour is not as intended (or at least inconsistent) is that when you use aria-required instead of required, the screen reader does not announce "invalid entry" like it wrongly does with required.

See https://jsbin.com/tijewij to test the same form but with aria-required.

Comment 6

[Jer Hea]

It seems that you're facing an issue where a form is still being validated by screen readers despite the presence of the 'novalidate' attribute. The 'novalidate' attribute is meant to disable browser validation for form fields, but it might not affect how screen readers interact with the form.

Screen readers can have their own mechanisms for validating and interacting with web content, which might not be affected by the 'novalidate' attribute. It's also possible that the screen reader is picking up validation cues from other HTML attributes or labels associated with form fields.

To address this issue, you could consider the following steps:

Check Screen Reader Behavior: Test the form with different screen readers and browser combinations to ensure the issue is consistent across different setups. This will help you confirm whether it's a widespread problem or specific to certain configurations.

Aria- Attributes:* Utilize ARIA (Accessible Rich Internet Applications) attributes to provide more explicit instructions to screen readers. For example, you can use aria-invalid to indicate whether a field's value is valid or not. Make sure that these attributes are consistent with the 'novalidate' attribute.

Validation Messages: Ensure that any validation messages associated with form fields are appropriately marked up using ARIA roles and attributes. This will help screen readers identify and announce the error messages accurately.

Testing Tools: Make use of browser developer tools and screen reader testing tools to simulate the experience of users with disabilities. This can help you identify what the screen reader is picking up and how it's interpreting the form's behavior.

User Testing: Engage with users who rely on screen readers to navigate the web. Their firsthand feedback can provide insights into how your form is being perceived and used.

Consult Accessibility Guidelines: Refer to the Web Content Accessibility Guidelines (WCAG) to ensure that your form conforms to accessibility standards. These guidelines provide detailed recommendations for making web content usable for people with disabilities.

Consider Expert Help: If the issue persists, consider reaching out to experts in web accessibility or conducting an accessibility audit to identify any underlying problems in your form's markup.

Remember that web accessibility is an ongoing process, and it's important to continuously test and refine your forms to ensure they are usable by everyone, including those who rely on screen readers.
https://0123fmovies.com/

Comment 7

[Anna Yeddi [:ayeddi]]

Removing an access keyword, since the bug is already in the Disability Access APIs component and has severity set.