1843227 - Accessible::ScrollTo SCROLL_TYPE_ANYWHERE doesn't trigger infinite scroll on YouTube video lists

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

Spun off bug 1818126.

STR (with the NVDA screen reader):

1. Open this page: https://www.youtube.com/@LGR/videos
2. Wait a few seconds for the page to load.
3. Press control+end to move to the bottom of the document.
4. Wait a few seconds for the page to scroll.
5. Press h to move to the next video.
   • Expected: NVDA reports the next video heading.
   • Actual: NVDA says "no next heading"

Impact: This makes it impossible for keyboard and screen reader users to scroll to earlier videos that aren't initially rendered.

Chrome does not have this problem with YouTube on Windows.

This was addressed for the tab key in bug 1818126 and it will likely be addressed for other methods of focus in bug 1842679. However, screen reader review cursors (e.g. NVDA browse mode) don't necessarily focus as the user moves, so fixing focus doesn't deal with this. The tab key fix at least serves as a workaround.

The fix for the tab key was to use WhereToScroll::Center instead of WhereToScroll::Nearest. To do this for a11y, we'd need to make a similar change for SCROLL_TYPE_ANYWHERE.

One concern is that we define SCROLL_TYPE_ANYWHERE as:

Scroll an object the minimum amount necessary in order for the entire frame to be visible (if possible).

Center would not be "the minimum amount necessary". However, ATK_SCROLL_ANYWHERE is defined as:

Scroll the object vertically and horizontally so that as much as possible of the object becomes visible. The exact placement is determined by the application.

And IA2_SCROLL_TYPE_ANYWHERE is defined as:

Scroll the object or substring such that as much as possible of the object or substring is within the top level window. The placement of the object is dependent on the application.

Android and Mac also use SCROLL_TYPE_ANYWHERE, but I'm not sure what the expectations are there.

If I'm reading the code right, Chrome already scrolls to centre for Windows IA2_SCROLL_TYPE_ANYWHERE and when scrolling on Mac. I'm a little less certain about Chrome on Android, as it even though it defaults to centre alignment, it also passes a rect and I'm not sure what impact that has.

This NVDA issue comment points out the inconsistency between Firefox and Chrome regarding where they scroll.

My feeling is that we should change SCROLL_TYPE_ANYWHERE to scroll to centre, which solves both the YouTube problem and the browser inconsistency.

Comment 1

[James Teh [:Jamie]]

Eitan, can you comment on the scrolling behaviour for Mac and Android? Would changing them to scroll to centre when not visible be problematic for users? Am I correct that this is what Chrome does on both platforms?

Comment 2

[Eitan Isaacson [:eeejay]]

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

Eitan, can you comment on the scrolling behaviour for Mac and Android? Would changing them to scroll to centre when not visible be problematic for users? Am I correct that this is what Chrome does on both platforms?

You are right that Safari and Chrome in MacOS and Chrome in Android indeed to scroll the item to the center of the screen. This is honestly surprising to me but seems like a good behavior to emulate. It does eliminate some weirdness we have when we scroll in Android with the bottom toolbar being where it is.

Comment 3

[James Teh [:Jamie]]

Not sure if inconsistent cross-browser support for accessibility APIs on popular websites classifies as a web compat issue, but flagging just in case.

Comment 4

[Dennis Schubert [:denschub]]

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

support for accessibility APIs on popular websites classifies as a web compat issue

Good question, we haven't really had to have a formal opinion on that, yet.

If we understand this correctly, this bug makes YouTube significantly harder to use for people who rely on the accessibility APIs. We would this consider "breaking a site in a critical way", and we consider YouTube "a very important site", so this is a P1. One could argue that only a subset of our users are affected by this, but since this bug is already filed in the Accessibility component, let's treat this as a WebCompat P1 for now.

Comment 5

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

The severity field for this bug is set to S3. However, this bug has a P1 WebCompat priority.
:Jamie, could you consider increasing the severity of this web compatibility bug?

For more information, please visit BugBot documentation.

Comment 6

[James Teh [:Jamie]]

Attachment: Bug 1843227: When scrolling with nsIAccessibleScrollType::SCROLL_TYPE_ANYWHERE, scroll to center instead of nearest.

This is consistent with other browsers and thus more web compatible.
In particular, it makes infinite scroll work correctly on YouTube (e.g. when scrolling with screen readers), which didn't work previously.

Comment 7

[James Teh [:Jamie]]

Release Note Request (optional, but appreciated)
[Why is this notable]: This fixes infinite scrolling on YouTube with a screen reader.
[Affects Firefox for Android]: yes
[Suggested wording]: YouTube video lists now scroll correctly when navigating with a screen reader.
[Links (documentation, blog post, etc)]: None

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/78dee4ec9d82
When scrolling with nsIAccessibleScrollType::SCROLL_TYPE_ANYWHERE, scroll to center instead of nearest. r=eeejay

Comment 9

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/78dee4ec9d82

Comment 10

[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-firefox117 to wontfix.

For more information, please visit BugBot documentation.

Comment 11

[Donal Meehan [:dmeehan]]

:jamie do you plan on adding a beta uplift request on this or let it ride the trains with 118?
(This will dictate where we put the release note)

Comment 12

[James Teh [:Jamie]]

I plan on an uplift. I'll do that today.

Comment 13

[James Teh [:Jamie]]

Comment on attachment 9347588 [details]
Bug 1843227: When scrolling with nsIAccessibleScrollType::SCROLL_TYPE_ANYWHERE, scroll to center instead of nearest.

Beta/Release Uplift Approval Request

• User impact if declined: Screen reader users can't scroll to access further videos in YouTube video lists.
• 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): Isolated change which does notably change our behaviour but makes it more consistent with other browsers. Covered by automated test.
• String changes made/needed:
• Is Android affected?: Yes

Comment 14

[Dianna Smith [:diannaS] - on Leave, back on August 9th]

Comment on attachment 9347588 [details]
Bug 1843227: When scrolling with nsIAccessibleScrollType::SCROLL_TYPE_ANYWHERE, scroll to center instead of nearest.

Approved for 117.0b6

Comment 15

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/fa00393d9b3f