1790382 - Update Firefox View Feature Callout so that screenreaders read expected content in the proper order

Status: VERIFIED FIXED

(Firefox :: Messaging System, defect, P1)

Description

[Meg Viar [:mviar]]

Per :ayeddi

• "When the about:firefoxview is opened, the screen reader focus jumps to the onboarding callout, which is expected (I assume), but when the screen reader completes reading its content, it proceeds to read the main page content from the middle - from the Colorways section and then to the Recently closed one. This will cause users missing the top of the page, incl. the synced tabs."

• "on MacOS the dialog title is not announced by VoiceOver - the code looks good, so this is likely more general bug?"

See featureCallout.mjs for feature callout code.

Comment 1

[Punam Dahiya [:pdahiya]]

NI @vtay for feedback and if the fix is blocker for Fx106

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

I've broken out the Close button focus work into 1790651. @mviar, would you please edit comment 0 to remove it here (I don't have permission, not being the bug filer)?

Comment 3

[Meg Viar [:mviar]]

Updated, thanks Dan!

Comment 4

[Vtay]

Yes this is a P1. Refer to 1788253

Comment 5

[Negin]

I believe this is unrelated to the feature callout tour. I've set the tour to complete and used VO to tab through the content and it skips the content that has a .zap-card class (which is the synced tabs section that causes the VO to read through the content in a "random way" since it isn't reading over that section).

I believe this is happening because .zap-card is using pseudo element/:before which skips the synced tabs section because it's not focusable. I've verified this by trying to tab through the content and it's not possible to tab/focus in on that section with or without the feature tour being rendered.

I think this bug may be more suited for the firefox view team as I'm not sure how they'd like to proceed with that decorative element/how they'd like to make it more accessible?

Comment 6

[Meg Viar [:mviar]]

(In reply to Negin from comment #5)

I believe this is unrelated to the feature callout tour. I've set the tour to complete and used VO to tab through the content and it skips the content that has a .zap-card class (which is the synced tabs section that causes the VO to read through the content in a "random way" since it isn't reading over that section).

I believe this is happening because .zap-card is using pseudo element/:before which skips the synced tabs section because it's not focusable. I've verified this by trying to tab through the content and it's not possible to tab/focus in on that section with or without the feature tour being rendered.

I think this bug may be more suited for the firefox view team as I'm not sure how they'd like to proceed with that decorative element/how they'd like to make it more accessible?

Which OS / screen reader are you using? When I use the built in screen reader on Windows 11, it starts reading the Firefox View page, then switches to the callout when it appears, and then resumes reading the page where it left off (so I don't actually see the behavior described in this bug). One issue I do see is that it then reads the Feature Callout screen content a second time when it reaches it in the page after resuming reading page content.

On MacOS when tabbing through Firefox View with Voiceover the content of the tab pickup box is not read (likely for the reasons you described above @negin).

:ayeddi originally reported this issue in bug 1788253. Anna, do you recall which OS/screenreader you used when you saw the issue described in this bug?

Comment 7

[Negin]

(In reply to Meg Viar from comment #6)

(In reply to Negin from comment #5)

I believe this is unrelated to the feature callout tour. I've set the tour to complete and used VO to tab through the content and it skips the content that has a .zap-card class (which is the synced tabs section that causes the VO to read through the content in a "random way" since it isn't reading over that section).

I believe this is happening because .zap-card is using pseudo element/:before which skips the synced tabs section because it's not focusable. I've verified this by trying to tab through the content and it's not possible to tab/focus in on that section with or without the feature tour being rendered.

I think this bug may be more suited for the firefox view team as I'm not sure how they'd like to proceed with that decorative element/how they'd like to make it more accessible?

Which OS / screen reader are you using? When I use the built in screen reader on Windows 11, it starts reading the Firefox View page, then switches to the callout when it appears, and then resumes reading the page where it left off (so I don't actually see the behavior described in this bug). One issue I do see is that it then reads the Feature Callout screen content a second time when it reaches it in the page after resuming reading page content.

On MacOS when tabbing through Firefox View with Voiceover the content of the tab pickup box is not read (likely for the reasons you described above @negin).

:ayeddi originally reported this issue in bug 1788253. Anna, do you recall which OS/screenreader you used when you saw the issue described in this bug?

I was using MacOS VO, made an assumption that the bug may be specific to MacOS from this comment: "on MacOS the dialog title is not announced by VoiceOver - the code looks good, so this is likely more general bug? but it seems like there's still some funky behavior with Windows OS based on it reading the feature callout twice. I can investigate that in the meantime (would it make sense to file a separate bug for that?)

Comment 8

[Meg Viar [:mviar]]

Yes, seems like there's two things going on here. The voiceover on MacOS issue seems to be unrelated to the Feature Callout as it's reproducible without the tour being present. The issue on Windows can be it's own bug (or we can repurpose this one to address it and spin up a new bug for the Firefox View tabpickup voice over issue).

Comment 9

[Meg Viar [:mviar]]

Whoops, didn't mean to clear that NI.

Comment 10

[Anna Yeddi [:ayeddi]]

(In reply to Meg Viar from comment #6)

(In reply to Negin from comment #5)

I believe this is unrelated to the feature callout tour. I've set the tour to complete and used VO to tab through the content and it skips the content that has a .zap-card class (which is the synced tabs section that causes the VO to read through the content in a "random way" since it isn't reading over that section).

I believe this is happening because .zap-card is using pseudo element/:before which skips the synced tabs section because it's not focusable. I've verified this by trying to tab through the content and it's not possible to tab/focus in on that section with or without the feature tour being rendered.

I think this bug may be more suited for the firefox view team as I'm not sure how they'd like to proceed with that decorative element/how they'd like to make it more accessible?

Which OS / screen reader are you using? When I use the built in screen reader on Windows 11, it starts reading the Firefox View page, then switches to the callout when it appears, and then resumes reading the page where it left off (so I don't actually see the behavior described in this bug). One issue I do see is that it then reads the Feature Callout screen content a second time when it reaches it in the page after resuming reading page content.

On MacOS when tabbing through Firefox View with Voiceover the content of the tab pickup box is not read (likely for the reasons you described above @negin).

:ayeddi originally reported this issue in bug 1788253. Anna, do you recall which OS/screenreader you used when you saw the issue described in this bug?

as I recall it, the reading order behavior was buggy on both WinOS+NVDA and macOS+VO and, as you mentioned above, the macOS-specific issue was separate issue observed during testing, not related to the reading order of the callout vs the page.

Let me know if you need any additional info on the reading order behavior and/or need retesting (I'm back online)

UPD:
the reading order would be seen either by letting a screen reader keep reading the entire content of the page after opening it, or by navigating in a read-all mode of a screen reader:

• VoiceOver: shift+ctrl+option+Right Arrow aka VoiceOver + Right Arrow
• NVDA: Down Arrow to read next element OR Ins+Down Arrow to read all elements from this point on the page

Comment 11

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

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

For more information, please visit auto_nag documentation.

Comment 13

[Negin]

Currently the scope of this bug is to investigate and fix the issue with feature callout screens being read a second time through VO once it completes reading the page content on Windows (will confirm if I can repro the issue on MacOS but didn't seem to be the case).

Comment 14

[Negin]

Hi Anna, sorry for the delayed ping. I thought I was able to reproduce the voice over issue (specifically on Windows OS) but I'm apparently unable to reproduce the issue. I might be lacking some understanding with using NVDA but when I enable the narrator (Control + Alt + N) and let it auto read through about:firefoxview with the feature callout rendered, it reads through the content once and in the following order:

tab pickup section > feature callout > colorways aside > recently closed section

If you don't mind, could you share reproduction steps specifically with NVDA and anything else you might think would be helpful in debugging! I tried going through the steps manually using insert + down arrow but that didn't highlight any issues (unless I'm going about it wrong!)

Comment 15

[Negin]

And Meg, do you mind expanding on this comment (One issue I do see is that it then reads the Feature Callout screen content a second time when it reaches it in the page after resuming reading page content.) you left earlier, I'm unable to reproduce this using NVDA so if you have any repro steps that would be helpful!

Comment 16

[Anna Yeddi [:ayeddi]]

Attachment: 2022-10-17_callout_reading_order(Win+NVDA).png

(In reply to Negin from comment #14)

Hi Anna, sorry for the delayed ping. I thought I was able to reproduce the voice over issue (specifically on Windows OS) but I'm apparently unable to reproduce the issue. I might be lacking some understanding with using NVDA but when I enable the narrator (Control + Alt + N) and let it auto read through about:firefoxview with the feature callout rendered, it reads through the content once and in the following order:

tab pickup section > feature callout > colorways aside > recently closed section

If you don't mind, could you share reproduction steps specifically with NVDA and anything else you might think would be helpful in debugging! I tried going through the steps manually using insert + down arrow but that didn't highlight any issues (unless I'm going about it wrong!)

Hi Negin, the reading order is still buggy on both macOS+VoiceOver and WinOS+NVDA: while the Tab pickup section starts being announced, but it is quickly interrupted by an alert (which is an expected behavior for an alert) and the callout is being announced. Then a screen reader proceeds to read Recently closed etc, but it is never returns to the top of the page, thus, as you can see in the NVDA speech output screenshot (it reads all when a page is opened, you can re-trigger this read-all announcement by refreshing the page too), a user would never hear about the progress of the sync for the Tab pickup, unless they will decide to navigate this page backwards. I made a video from the macOS+VoiceOver behavior which does follow the WinOS+NVDA one (will attach below), but I had issues with screen capture on my Windows machine, so it's only a screenshot for now.

STR:

1. Turn on NVDA (you can also activate their Speech Viewer in NVDA menu > Tools)
2. Open a Firefox window (with pref browser.firefox-view.feature-tour set to {"message":"FIREFOX_VIEW_FEATURE_TOUR","screen":"FEATURE_CALLOUT_1","complete":false})
3. Navigate to and activate Firefox View or open about:firefoxview (you can use mouse to click on the Fx View - the result on page load should be the same)
4. Listen to the NVDA output while the screen reader announces the entire page

Ideally, the alert/callout will be announced, then the whole page will, starting from the Tab pickup down, and then when the user moves their focus through the page using a keyboard, the callout gets focus after the Tab pickup and before the Recently closed, but I assume it'll need some extra logic to be added into the code. I'd say if the alert/callout will be included in the DOM first, it should be announced first (on page load) and then the entire page would be heard too, but the keyboard nav would be funkier with callout > tab pickup > recently closed > colorways, which I think is acceptable, because the feature callout/alert is visually on the top of the page content, so it would be still logical. I hope it helps

Comment 17

[Anna Yeddi [:ayeddi]]

Attachment: 2022-10-17_callout_reading_order_macOS+VO.mov

Comment 18

[Anna Yeddi [:ayeddi]]

(In reply to Negin from comment #5)

I believe this is unrelated to the feature callout tour. I've set the tour to complete and used VO to tab through the content and it skips the content that has a .zap-card class (which is the synced tabs section that causes the VO to read through the content in a "random way" since it isn't reading over that section).

I believe this is happening because .zap-card is using pseudo element/:before which skips the synced tabs section because it's not focusable. I've verified this by trying to tab through the content and it's not possible to tab/focus in on that section with or without the feature tour being rendered.

I think this bug may be more suited for the firefox view team as I'm not sure how they'd like to proceed with that decorative element/how they'd like to make it more accessible?

Would you be able to file a bug for the callout's content and CC me in there? I noticed it with both macOS+VO and WinOS+NVDA. Using pseudo-elements for meaningful content, especially text, creates an inaccessible content that cannot be viewed by any assistive technology and it also may fail respecting users styling settings (that some users with cognitive difficulties, dyslexia, low vision may set up on their browsers)

Comment 19

[Negin]

(In reply to Anna Yeddi [:ayeddi] from comment #16)

Created attachment 9298938 [details]
2022-10-17_callout_reading_order(Win+NVDA).png

(In reply to Negin from comment #14)

Hi Anna, sorry for the delayed ping. I thought I was able to reproduce the voice over issue (specifically on Windows OS) but I'm apparently unable to reproduce the issue. I might be lacking some understanding with using NVDA but when I enable the narrator (Control + Alt + N) and let it auto read through about:firefoxview with the feature callout rendered, it reads through the content once and in the following order:

tab pickup section > feature callout > colorways aside > recently closed section

If you don't mind, could you share reproduction steps specifically with NVDA and anything else you might think would be helpful in debugging! I tried going through the steps manually using insert + down arrow but that didn't highlight any issues (unless I'm going about it wrong!)

Hi Negin, the reading order is still buggy on both macOS+VoiceOver and WinOS+NVDA: while the Tab pickup section starts being announced, but it is quickly interrupted by an alert (which is an expected behavior for an alert) and the callout is being announced. Then a screen reader proceeds to read Recently closed etc, but it is never returns to the top of the page, thus, as you can see in the NVDA speech output screenshot (it reads all when a page is opened, you can re-trigger this read-all announcement by refreshing the page too), a user would never hear about the progress of the sync for the Tab pickup, unless they will decide to navigate this page backwards. I made a video from the macOS+VoiceOver behavior which does follow the WinOS+NVDA one (will attach below), but I had issues with screen capture on my Windows machine, so it's only a screenshot for now.

STR:

1. Turn on NVDA (you can also activate their Speech Viewer in NVDA menu > Tools)
2. Open a Firefox window (with pref browser.firefox-view.feature-tour set to {"message":"FIREFOX_VIEW_FEATURE_TOUR","screen":"FEATURE_CALLOUT_1","complete":false})
3. Navigate to and activate Firefox View or open about:firefoxview (you can use mouse to click on the Fx View - the result on page load should be the same)
4. Listen to the NVDA output while the screen reader announces the entire page

Ideally, the alert/callout will be announced, then the whole page will, starting from the Tab pickup down, and then when the user moves their focus through the page using a keyboard, the callout gets focus after the Tab pickup and before the Recently closed, but I assume it'll need some extra logic to be added into the code. I'd say if the alert/callout will be included in the DOM first, it should be announced first (on page load) and then the entire page would be heard too, but the keyboard nav would be funkier with callout > tab pickup > recently closed > colorways, which I think is acceptable, because the feature callout/alert is visually on the top of the page content, so it would be still logical. I hope it helps

Thanks Anna, appreciate the context and verbose steps! I think I see the issue with my testing. I seem to be having an issue with NVDA not auto reading the content (and I can't seem to use insert + down arrow to go through the content either) and I was accidentally enabling the regular windows VO with one of the shortcut/hotkeys which wasn't reproducing the error. Wondering if it's an issue with my virtual machine as I'm using a macOS device but parallels virtual machine for windows testing. Will figure that out and see what's going on with NVDA and the ordering issue!

Comment 20

[Negin]

(In reply to Anna Yeddi [:ayeddi] from comment #18)

(In reply to Negin from comment #5)

I believe this is unrelated to the feature callout tour. I've set the tour to complete and used VO to tab through the content and it skips the content that has a .zap-card class (which is the synced tabs section that causes the VO to read through the content in a "random way" since it isn't reading over that section).

I believe this is happening because .zap-card is using pseudo element/:before which skips the synced tabs section because it's not focusable. I've verified this by trying to tab through the content and it's not possible to tab/focus in on that section with or without the feature tour being rendered.

I think this bug may be more suited for the firefox view team as I'm not sure how they'd like to proceed with that decorative element/how they'd like to make it more accessible?

Would you be able to file a bug for the callout's content and CC me in there? I noticed it with both macOS+VO and WinOS+NVDA. Using pseudo-elements for meaningful content, especially text, creates an inaccessible content that cannot be viewed by any assistive technology and it also may fail respecting users styling settings (that some users with cognitive difficulties, dyslexia, low vision may set up on their browsers)

I actually brought up this issue in the firefox-view slack channel. You can find read the thread here for additional context. But I was told this was not an issue and that the content in .zap-card isn't focusable through tabbing but using command + option + left/right arrow allows the content to be read.

edit: Sorry after further investigation the issue seems to be related to aria-owns and that's why the content in .zap-card was not being read because it was conveniently the element that had that attribute while testing. I made the wrong assumption that be not rendering the callout it was still not being read by VO but that's because it still had that attribute. It seems like aria-owns is not supported on MacOS which describes why the VO ordering was different across Windows/MacOS.

Comment 21

[Meg Viar [:mviar]]

(In reply to Negin from comment #15)

And Meg, do you mind expanding on this comment (One issue I do see is that it then reads the Feature Callout screen content a second time when it reaches it in the page after resuming reading page content.) you left earlier, I'm unable to reproduce this using NVDA so if you have any repro steps that would be helpful!

Hey Negin, I saw this with MacOS voiceover, not NVDA.

Comment 22

[Negin]

Attachment: Bug 1790382 - Update Firefox View Feature Callout so that screenreaders read expected content in the proper order

Comment 23

[Anna Yeddi [:ayeddi]]

Just to confirm, the baseline testing is with the following combinations of the OS + screen reader:

• MacOS and VoiceOver (built-in)
• Windows OS and NVDA (third party, open source)
• Windows OS and JAWS* (third party, paid)
  *JAWS is tested depending on availability (i.e. I do not have the license on my Win machine), but NVDA would catch the majority of the issues for both screen readers.

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cf4f7e5d0f9d
Update Firefox View Feature Callout so that screenreaders read expected content in the proper order r=emcminn

Comment 25

[Cristian Tuns]

Backed out for causing mochitest failures on browser_feature_callout_resize.js

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | browser/components/firefoxview/tests/browser/browser_feature_callout_resize.js | Uncaught exception in test - The callout container has role of alert - timed out after 50 tries

Comment 26

[Negin]

Sorry one more follow-up question/s :ayeddi! I'm curious your thoughts on my proposed solution for this (In reply to Cristian Tuns from comment #25)

Backed out for causing mochitest failures on browser_feature_callout_resize.js

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | browser/components/firefoxview/tests/browser/browser_feature_callout_resize.js | Uncaught exception in test - The callout container has role of alert - timed out after 50 tries

Ah my mistake, missed cleaning up the test file. Will push up the fix shortly.

Comment 27

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a1ee4628fa11
Update Firefox View Feature Callout so that screenreaders read expected content in the proper order r=emcminn

Comment 28

[Iulian Moraru]

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

Comment 29

[Anna Yeddi [:ayeddi]]

(In reply to Negin from comment #26)

Sorry one more follow-up question/s :ayeddi! I'm curious your thoughts on my proposed solution for this

Looks great to me - thank you for working on the patch, Negin!

Comment 30

[Alice Varro [avarro], Ecosystem QA]

I have verified this issue using the latest Firefox Nightly 108.0a1 (Build ID: 20221101093931) on Windows10x64 using NVDA screen reader and on macOS 12.6 using the built-in VoiceOver screen reader and I can confirm the following:

• The content of the Firefox View Feature Callout is being read in the proper order (first the callout message and then the content of the Firefox View page - starting with the "Tab Pickup" section).
• The screen readers do not read again the callout message after finishing reading the content of the Firefox View's sections.