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)
Tracking
()
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]:
- Open the browser using the profile from prerequisites.
- Click the "Not now" button from the bottom right part of the page.
- 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.
Updated•3 years ago
|
Assignee | ||
Comment 1•2 years ago
|
||
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.)
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Comment 2•2 years ago
|
||
(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.
Reporter | ||
Comment 3•2 years ago
|
||
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).
Comment 4•2 years ago
|
||
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?
Reporter | ||
Comment 5•2 years ago
|
||
I've tried the following two scenarios using the "Up" and "Down" arrow keys
- If the "Down" arrow key is pressed after the "NVDA" says "Blank" the screen reader automatically reads the "Not Now" button.
- 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.
Comment 6•2 years ago
|
||
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).
Updated•2 years ago
|
Assignee | ||
Comment 7•2 years ago
|
||
Updated•2 years ago
|
Assignee | ||
Comment 8•2 years ago
|
||
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 :)
Comment 9•2 years ago
|
||
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:
- Give the
<main>
element role="dialog" and tabindex="-1". - Label the
<main>
element with the heading: aria-labelledby="id-of-h1-element". - 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.
Assignee | ||
Comment 10•2 years ago
|
||
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!
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 11•2 years ago
|
||
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?
Updated•2 years ago
|
Comment 12•2 years ago
|
||
Pushed by emcminn@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/7b3b1024a24f Adjusting focus for screen readers on about:welcome r=Jamie
Comment 13•2 years ago
|
||
Backed out for causing node failures.
Backout link: https://hg.mozilla.org/integration/autoland/rev/0ab3831585fde082bb288efe132f0e038ce5c22b
Failure log: https://treeherder.mozilla.org/logviewer?job_id=360256725&repo=autoland&lineNumber=395
Assignee | ||
Comment 14•2 years ago
|
||
Looks like the bundle file got out of date somehow. I'll update it and push again
Comment 15•2 years ago
|
||
Pushed by emcminn@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/906724828a00 Adjusting focus for screen readers on about:welcome r=Jamie
Comment 16•2 years ago
|
||
Backout by malexandru@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d800f323b1f6 Backed out changeset 906724828a00 for causing node newtab failures.
Assignee | ||
Comment 17•2 years ago
|
||
Just tried one more time; there was an issue with my local bundle. Hopefully this one sticks :)
Comment 18•2 years ago
|
||
Pushed by emcminn@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/88123257353e Adjusting focus for screen readers on about:welcome r=Jamie
Comment 19•2 years ago
|
||
bugherder |
Comment 20•2 years ago
|
||
Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Comment 21•2 years ago
|
||
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).
Updated•2 years ago
|
Updated•2 years ago
|
Description
•