1870157 - Highlighted fields on the Address capture doorhanger should communicate their state programmatically too

Status: RESOLVED FIXED

(Toolkit :: Form Autofill, defect, P3)

Description

[Anna Yeddi [:ayeddi]]

Actual:

When the autofilled address is edited, the Address capture doorhanger appears with the fields that were changed being highlighted. This is not communicated to an assistive technology because it is marked up as <span>

Expected:

When <mark> for highlights/edits OR <ins> for additions and <del> for removals would be appropriate and would be communicated to the assistive technology, so the information is available not only visually and screen readers would be able to announce it

STR:

Set the following preferences:
browser.search.region = US/CA
extensions.formautofill.addresses.capture.v2.enabled = true
extensions.formautofill.addresses.supported = on

Go to https://luke-chang.github.io/autofill-demo/basic.html and enter your Name, Street Address, and Email. After clicking the submit button, the address save doorhanger should appear.
To trigger the address update doorhanger, first save an address (either via the doorhanger or through about:preferences). Then, submit the form with the saved address and any other fields not previously saved.

Comment 1

[Anna Yeddi [:ayeddi]]

Attachment: Bug 1870157 - Provide programmatic highlighting to Highlighted fields on the Address capture doorhanger

When the autofilled address is edited, the Address capture doorhanger appears with the fields that were changed being highlighted. This is not communicated to an assistive technology because it is marked up as <span> that has no programmatic meaning/role.

Comment 2

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

The severity field is not set for this bug.
:serg, could you have a look please?

For more information, please visit BugBot documentation.

Comment 3

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

The severity field for this bug is set to S3. However, the accessibility severity is higher, .
:ayeddi, could you consider increasing the severity?

For more information, please visit BugBot documentation.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6df5e64d0de1
Provide programmatic highlighting to Highlighted fields on the Address capture doorhanger r=dimi

Comment 5

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/6df5e64d0de1

Comment 6

[Anca Soncutean, Desktop QA]

I've reproduce this issue on Fx 123.0a1 (2024-01-02) with Windows 10. The edited highlighted text was not read by NVDA. It is now with the latest Nightly 124.0a1 (2024-02-11) but the edited text, that is strike-through, although mentioned by the narrator, there is no indicator that is strike-through? is this expected?

Comment 7

[Anna Yeddi [:ayeddi]]

(In reply to Anca Soncutean, Desktop QA from comment #6)

I've reproduce this issue on Fx 123.0a1 (2024-01-02) with Windows 10. The edited highlighted text was not read by NVDA. It is now with the latest Nightly 124.0a1 (2024-02-11) but the edited text, that is strike-through, although mentioned by the narrator, there is no indicator that is strike-through? is this expected?

Thank you for confirming this, Anca!

The NVDA has, by default, disabled the announcement of the styling (this is done to reduce the verbosity out of the box) in the Settings. You could also check the behavior with the following URI (to confirm the announcements are similar to the doorhanger for the following accessible roles): data:text/html,<del>role of deletion</del> and <ins>role of insertion</ins> and <mark>role of mark</mark>

Comment 8

[Anca Soncutean, Desktop QA]

Apologise for my late reply, I was caught up with some pressing tasks. I think I confused previously the behaviour here and I was caught in a confirmation bias while having two different nightly builds side by side on a small screen.

Windows - So, for NVDA with its default configurations, the edited strings are not read at all on the latest build Fx 124.0a1 (2024-02-15), whereas they were read on an older, affected build Fx 122.0a1 (2023-12-14).
When comparing the provided URI, where the narrator properly acknowledges deletion, insertion and highlighting attributes, I would expect similar behavior on the Update Address Capture doorhanger, but the narrator skips over the highlighted text and proceeds to the following line, disregarding reading the changes.

macOS - Voice Over reads the highlighted text inside the Update Address Capture doorhange if that text is selected through the screen reader itself. Otherwise the text can’t be reached by the narrator.

Ubuntu - Orca appears to have restricted functionality when it comes to accessing specific text strings within a doorhanger. I'm only able to navigate to the buttons contained within the doorhanger interface.

Comment 9

[Anca Soncutean, Desktop QA]

Anna, can you help us with an answer regarding this issue and what is the correct behavior? Here is a screen recorder (with audio) on the latest Nightly, on Windows, with the latest NVDA. The the narrator skips over the highlighted text and proceeds to the following line inside the Update doorhanger.

Comment 10

[Anna Yeddi [:ayeddi]]

(In reply to Anca Soncutean, Desktop QA from comment #9)

Anna, can you help us with an answer regarding this issue and what is the correct behavior? Here is a screen recorder (with audio) on the latest Nightly, on Windows, with the latest NVDA. The the narrator skips over the highlighted text and proceeds to the following line inside the Update doorhanger.

Anca, thank you very much for the video and the details. I agree, since the test sample in-content is announced as expected, this would be the expectation for the panel itself. I've got a feeling that the panel itself is missing role=document that would allow the screen reader to access the text in the browsing mode (with Up/Down arrows for NVDA). I'll keep the NI for now so I could debug it on Windows machine and check this theory.