Closed Bug 1736550 Opened 3 years ago Closed 2 years ago

The elements from the "Import", "Themes" and "Thank you" slides of the "about:welcome" page are not recognized by a screen reader software

Categories

(Firefox :: Messaging System, defect, P1)

Desktop
Windows
defect

Tracking

()

VERIFIED FIXED
97 Branch
Iteration:
97.1 - Dec 6 - Dec 19
Tracking Status
firefox93 --- wontfix
firefox94 --- wontfix
firefox95 --- wontfix
firefox96 --- wontfix
firefox97 --- verified

People

(Reporter: mcoman, Assigned: emcminn, NeedInfo)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file)

[Affected versions]:

  • Firefox Release 93.0 - Build ID: 20210927210923
  • Firefox Beta 94.0b7 - Build ID: 20211017185800
  • Firefox Nightly 95.0a1 - Build ID: 20211018214442

[Affected Platforms]:

  • Windows 7 x64
  • Windows 8.1 x64

[Prerequisites]:

  • Have a new Firefox profile.
  • Have a screen reader software installed and enabled.

[Steps to reproduce]:

  1. Open the browser using the profile from prerequisites.
  2. Click the "Not now" button from the bottom right part of the page.
  3. Observe the behavior.

[Expected result]:

  • All the elements are from the second slide of the "about:welcome" page are successfully recognized by the screen reader software.

[Actual result]:

  • The screen reader software says "blank" and no other elements are recognized.

[Additional Notes]:

  • This issue is not reproducible on Windows 10 and macOS 11.6.
  • This issue is also reproducible on the "Themes" and "Thank you" slides.
  • The issue is not reproducible on the upgrade spotlights.
Assignee: nobody → emcminn
Iteration: --- → 95.2 - Oct 18 - Oct 31
Priority: -- → P1

I've been able to reproduce this on a virtual machine, and I was able to solve it by removing the role="presentation" from the root welcome container. However, doing that also causes a change in behaviour for NVDA on Windows 10 and for VoiceOver on Mac, where the initial welcome screen becomes less verbose: screen reader focus goes right to the "Welcome to Firefox" header and misses reading the hero text "Fire Starts Here" and the image caption. On windows, sometimes NVDA doesn't read the primary button until it is focused by the user (by tabbing/keyboard navigation).

I'm wondering what the preferred trade-off is here? The screen reader function (on Windows 10 and Mac) seems less than ideal with this fix, but at least the later screens become accessible for older versions of windows. (With the fix, all the screens will read out at least the first header.)

Flags: needinfo?(asa)
Iteration: 95.2 - Oct 18 - Oct 31 → 96.1 - Nov 1 - Nov 14
Flags: needinfo?(asa) → needinfo?(jteh)

(In reply to Marius Coman [:mcoman], Ecosystem QA from comment #0)

[Expected result]:

  • All the elements are from the second slide of the "about:welcome" page are successfully recognized by the screen reader software.

[Actual result]:

  • The screen reader software says "blank" and no other elements are recognized.

Can you elaborate on what you mean by "recognized" here? For example, do you mean that NVDA says "blank" and even using the arrow keys does not allow you to access the elements on the page? Or is this just referring to the fact that "blank" and nothing else is reported, but you didn't try using the arrow keys? Neither situation is great, but the former is a lot more severe and indicative of a bigger problem, which is why I ask.

  • This issue is not reproducible on Windows 10

If I go to about:welcome on Windows 10 and press "Not now", I often (but not always) get "blank". So I suspect there is a timing issue at play here rather than an OS issue.

(In reply to Emily McMinn :emcminn from comment #1)

I was able to solve it by removing the role="presentation" from the root welcome container.

Nice find! That said, that's pretty bizarre. I don't understand why removing that should fix the issue. I would like to investigate that further, but I'm currently dealing with other high priority work, so I won't be able to get to that for at least a few days.

However, doing that also causes a change in behaviour for NVDA on Windows 10 and for VoiceOver on Mac, where the initial welcome screen becomes less verbose: screen reader focus goes right to the "Welcome to Firefox" header and misses reading the hero text "Fire Starts Here" and the image caption.

I don't think it's going to be possible to fix this for subsequent screens, since we're essentially dealing with a single page app here (and screen readers still don't handle auto reading too well for those). However, it'd be nice if we could at least get nice reading on the first screen.

Currently, we focus the h1 when a screen appears. Would it be possible to avoid this for the initial screen, but still do it for subsequent screens? We need to do it for subsequent screens because otherwise, the user won't know that anything changed. However, on the initial screen, we don't want to do it because doing so overrides the auto reading of the page.

Flags: needinfo?(mcoman)
Flags: needinfo?(jteh)
Flags: needinfo?(emcminn)

Hi James,

I have retested this issue and I have managed to reproduce it on Windows 10 x64 with the latest Firefox Release (94.0.1 Build ID - 20211103134640) installed. However, it seems that the issue is intermittent, I have managed to reproduce it 6 times in 10 tries, and I have not found any steps to reproduce it constantly.

Also, if we are focusing the second slide's elements using key navigation the behavior differs from an element to another:

  • The slide's heading is not recognized at all.
  • If the Primary button from the second slide is focused, right after the NVDA screen reader says "Blank", nothing happens, the button is not recognized. However, if the Primary button is focused for a second time using the "Tab" key, then the button is successfully recognized.
  • The "Not now" button is successfully recognized each time.

If you need extra information please don't hesitate to ping me here or on Slack (mcoman).

Flags: needinfo?(mcoman)

Thanks. When NVDA says "blank", if you explore the page with the up and down arrow keys like you would in a word processor (this is an NVDA feature), does NVDA report the other elements on the page?

Flags: needinfo?(mcoman)

I've tried the following two scenarios using the "Up" and "Down" arrow keys

  1. If the "Down" arrow key is pressed after the "NVDA" says "Blank" the screen reader automatically reads the "Not Now" button.
  2. If the "Up" arrow key is pressed after the "NVDA" says "Blank" the screen reader automatically reads the last line of the Heading 2 (in my case the "bookmarks, and more." string from the "Import" slide).

From these two scenarios, it looks like the Primary button is automatically focused after the slide is opened but not recognized.

Flags: needinfo?(mcoman)

Thanks. That confirms my own findings. So, the page isn't blank (which would be very bad), but somehow the focus isn't being picked up correctly (which is bad, but nowhere near as bad).

Iteration: 96.1 - Nov 1 - Nov 14 → 96.2 - Nov 15 - Nov 28
Attachment #9251205 - Attachment description: WIP: Bug 1736550 - Adjusting focus for screen readers on about:welcome → Bug 1736550 - Adjusting focus for screen readers on about:welcome

I have a WIP here: https://phabricator.services.mozilla.com/D131413

I see some improvement on MacOS and Win10 just removing the check from the welcome page; I'll check it on the virtual machine once the build is up :)

Flags: needinfo?(emcminn)

Unfortunately, for me, this patch doesn't fix the issue. It might increase the frequency with which NVDA behaves correctly (not reading "blank"), but I still see it a lot. I think role="presentation" might be a red herring; this seems to be a race condition and perhaps that changes the timing slightly on some systems.

I had more luck delaying the focus slightly:

diff --git a/browser/components/newtab/content-src/aboutwelcome/components/MultiStageProtonScreen.jsx b/browser/components/newtab/content-src/aboutwelcome/components/MultiStageProtonScreen.jsx
index fb8c040d35765..e4c2d1ea907de 100644
--- a/browser/components/newtab/content-src/aboutwelcome/components/MultiStageProtonScreen.jsx
+++ b/browser/components/newtab/content-src/aboutwelcome/components/MultiStageProtonScreen.jsx
@@ -10,7 +10,9 @@ import { SecondaryCTA, StepsIndicator } from "./MultiStageAboutWelcome";
 
 export class MultiStageProtonScreen extends React.PureComponent {
   componentDidMount() {
-    this.mainContentHeader.focus();
+    if (this.props.order !== 0) {
+      setTimeout(() => this.mainContentHeader.focus(), 0);
+    }
   }
 
   render() {

Even then, it occasionally failed (but very rarely). Increasing the timeout to 50 or something might make it more reliable, but the fact that we're relying on an arbitrary delay here feels brittle.

I still don't understand why this is happening. I'm going to try to do some debugging with NVDA to figure it out, but I didn't get to that today. The setTimeout could be an interim fix, though.

One downside I've realised with not focusing the heading on the initial screen is that a screen reader user gets nothing if they use the browser's back command (alt+leftArrow). Is that a use case we care about?

A better (but more complicated) overall fix for all of this could be as follows:

  1. Give the <main> element role="dialog" and tabindex="-1".
  2. Label the <main> element with the heading: aria-labelledby="id-of-h1-element".
  3. Focus the <main> element instead of the heading for all screens.

That will cause NVDA to treat each screen as a separate document, so the entire page will get read as if this weren't an SPA.

Hi Jamie,
I'll give that solution a try, it sounds reasonable to me, and I agree we want to go for the most robust solution. I'll let you know how it goes!

Iteration: 96.2 - Nov 15 - Nov 28 → 96.3 - Nov 29 - Dec 6
Attachment #9251205 - Attachment description: Bug 1736550 - Adjusting focus for screen readers on about:welcome → WIP: Bug 1736550 - Adjusting focus for screen readers on about:welcome

Hi Jamie - I put together a patch with the above solution and I still saw issues on Windows with NVDA. Frequently the Welcome page doesn't get read beyond "Welcome to Firefox. Dialog." I've added a check to only apply the role=dialog if we're not on the Welcome page, and I think the behaviour is much better. The welcome page gets read completely, and then for other pages we get "${header}, dialog, and N more items." Can you take a look and let me know if the behaviour is consistent for you and if it makes for an ok solution?

Flags: needinfo?(jteh)
Attachment #9251205 - Attachment description: WIP: Bug 1736550 - Adjusting focus for screen readers on about:welcome → Bug 1736550 - Adjusting focus for screen readers on about:welcome
Pushed by emcminn@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7b3b1024a24f
Adjusting focus for screen readers on about:welcome r=Jamie

Looks like the bundle file got out of date somehow. I'll update it and push again

Flags: needinfo?(emcminn)
Pushed by emcminn@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/906724828a00
Adjusting focus for screen readers on about:welcome r=Jamie
Backout by malexandru@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d800f323b1f6
Backed out changeset 906724828a00 for causing node newtab failures.

Just tried one more time; there was an issue with my local bundle. Hopefully this one sticks :)

Pushed by emcminn@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/88123257353e
Adjusting focus for screen readers on about:welcome r=Jamie
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 97 Branch

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.

I have verified that this issue is no longer reproducible with the latest Firefox Nightly (97.0a1 Build ID - 20211215215113) installed on Windows 10 x64. Now I can confirm that the "Make default", "Import", "Themes", "Thank you" slides from the "about:welcome" page are now recognized by a screen reader software (NVDA).

Status: RESOLVED → VERIFIED
Iteration: 96.3 - Nov 29 - Dec 6 → 97.1 - Dec 6 - Dec 20
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: