1833079 - [CTW] Firefox no longer marks required inputs of a non-simple type that become valid as such for assistive technologies, and doesn't properly update the cache accordingly.

Status: RESOLVED FIXED

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

Description

[Marco Zehe (:MarcoZ)]

Steps to reproduce, with the NVDA screen reader:

1. Open data:text/html,<label for="email">Enter your email address:"</label><input id="email" type="email" required />
2. Focus the input.
   • NVDA will announce that the field is required and currently invalid.
3. Type a valid email address.
4. Press NVDAKey+Tab to repeat the focused element.
   • Expected: The field should read required, but the invalid state should no longer be announced.
   • Actual: The field is still being announced as invalid.
5. Press Escape to enter browse mode, then press NVDAKey+F5 to refresh the buffer.
6. Press CTRL+Home, then f to move to the form field.
   • Expected: Now, the field should be announced as required, but the invalid state should not be announced.
   • Actual: Even after a refresh, the field is still being announced as invalid.
7. Change the URL in the address bar so that the required field is removed, and repeat steps 3 through 6.
   • After step 4, the field is still being announced as invalid, so the event that tells the browser the field is now valid, is not being fired.
   • After step 6, the field is now correctly being announced as no longer being invalid.

In short, if there are two validations, through the input type and the required attribut, neither an event is fired to tell assistive technologies that the invalid state has gone away, nor the required condition has been met. Alternatively, the invalid state is being flipped twice accidentally.
If there is only one condition, like the email type being satisfied with a valid email address, or a simple text input that is required, having contents, the event is still not fired, but the cache is properly updated.

Comment 1

[James Teh [:Jamie]]

For me, the invalid state never seems to be cleared from the cache once set, even for something as simple as <input type="email">.

Comment 2

[Marco Zehe (:MarcoZ)]

It did get cleared for me for email earlier, and also for simple, merely required, inputs. But only after refreshing the buffer, never through an event.

Comment 3

[James Teh [:Jamie]]

Attachment: Bug 1833079: When notified about a dom::ElementState::INVALID change, let AccStateChangeEvent calculate whether the state is enabled.

Previously, we passed true for aIsEnabled, indicating that the state was only ever enabled, never disabled.
We could get the actual enabled value here using dom::ElementState::HasState(), but that wouldn't take aria-invalid into account if present.
Instead, we let AccStateChangeEvent calculate it by calling Accessible::State().

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f0258342b9c1
When notified about a dom::ElementState::INVALID change, let AccStateChangeEvent calculate whether the state is enabled. r=morgan

Comment 5

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/f0258342b9c1

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:Jamie, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox114 to wontfix.

For more information, please visit BugBot documentation.

Comment 7

[James Teh [:Jamie]]

Urgh. I somehow forgot to request an uplift on this. I'm guessing it's too late to do that now given we're going to rc. :(

Comment 8

[Pascal Chevrel:pascalc]

(In reply to James Teh [:Jamie] from comment #7)

Urgh. I somehow forgot to request an uplift on this. I'm guessing it's too late to do that now given we're going to rc. :(

If it's very low risk, I can still take it before the merge on Monday, please request it today though, thanks :)

Comment 9

[Morgan Reschenberg [:morgan]]

Comment on attachment 9333615 [details]
Bug 1833079: When notified about a dom::ElementState::INVALID change, let AccStateChangeEvent calculate whether the state is enabled.

Beta/Release Uplift Approval Request

• User impact if declined: Users will continue to receive inaccurate information about the validity of inputs
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): We typically use State() for this kind of information anyway, so this patch aligns AccStateChangeEvent's behaviour with behaviour throughout the codebase. Also, this change is scoped to invalid state only, the surface area is narrow and users are already receiving incorrect info so the potential for regression is also low.
• String changes made/needed:
• Is Android affected?: Yes

Comment 10

[Pascal Chevrel:pascalc]

Comment on attachment 9333615 [details]
Bug 1833079: When notified about a dom::ElementState::INVALID change, let AccStateChangeEvent calculate whether the state is enabled.

Approved to land on the beta branch before Monday merge to mozilla-release for our RC build, thanks.

Comment 11

[Pascal Chevrel:pascalc]

https://hg.mozilla.org/releases/mozilla-beta/rev/80ff5cb3f9a6