[Spike] Different scroll behavior for top/bottom toolbar when Talkback is enabled

[Mugurell]

Seen while working on #10686

Currently with talkback enabled:

• top toolbar does not animate
• bottom toolbar does animate

Not sure if this is a bug or a workaround / something that should be kept or not.

---

Agreed specs are found in #1718 (comment)

• If a user has accessibility services enabled and launches the app, we will set the default toolbar to be top (and FIXED not dynamic)
• If a user enables accessibility services, fixed top toolbar will be enabled on the next app launch (unfortunately due to how we inflate the browser we only check if they're enabled when it's first created--do you think this is a major problem? It seems like this is a small edge case)
• If a user with accessibility services goes into settings to change their toolbar it will respect what they select

Why blocking the dynamic behavior was discussed only for the top toolbar is probably because at that time the bottom toolbar was not scrollable. It was always in a fixed place. So if users had a11y services enabled but selected the toolbar to be placed at the bottom, the toolbar would be fixed in place by default.
Then when the dynamic behavior was implemented for the bottom toolbar I think this special a11y case was just overlooked.

┆Issue is synchronized with this Jira Task

[Mugurell]

Saw a ticket about having this behavior for the top toolbar but with no reasons as to why - #10026
Have yet to check if the behavior was consistent at that time or not.

[mcarare]

@Mugurell The fixed top toolbar for enabled a11y was introduced from the first implementation of top toolbar in #6608.

fenix/app/src/main/java/org/mozilla/fenix/utils/Settings.kt

Lines 202 to 207 in 769c1e4

	val shouldUseFixedTopToolbar: Boolean
	get() {
	val accessibilityManager =
	appContext.getSystemService(Context.ACCESSIBILITY_SERVICE) as? AccessibilityManager
	return accessibilityManager?.isTouchExplorationEnabled ?: false
	}

But I do not see any discussion as to why either.

[Mugurell]

Proposed behavior:

• If a user has accessibility services enabled and has not yet set the toolbar position to be at the bottom (although that is the default) or has set the toolbar position to be at the top:
  • the toolbar should be placed at top in a fixed position (this is the current behavior)
• If a user has accessibility services enabled and has set the toolbar position to be at the bottom
  • the toolbar should be placed at the bottom in a fixed position (this is a difference to the current behavior)
• In both cases the toolbar would be fixed in place ignoring the dynamic behavior set in app settings. (currently the a11y fixed top toolbar ignores the dynamic behavior set in app settings)

 
The first point - if user hasn't yet set a toolbar position

• with a11y services enabled the toolbar would be placed at top
• without a11y service enabled the toolbar would be placed at the bottom
  seems a bit strange - the toolbar changing positions, but from Accessibility updates for Bottom Toolbar #1718 (comment) and Accessibility updates for Bottom Toolbar #1718 (comment) I understand this being an important functionality that we want.

Asking @eeejay and UX to confirm the if the proposed behavior (ensuring the bottom toolbar would be fixed when using a11y)

[eeejay]

I think this behavior makes sense. The one issue I can think of is that two not great things can happen when the toolbar is at the bottom with TalkBack enabled:

1. Either the UI layout will visually show the toolbar at the bottom, but talkback swipe order will first go through the toolbar before web content. This would be inconsistent with visual layout. Or..
2. The swipe order will correctly put content before the toolbar. The issue then would be that users who don't use explore-by-touch will need to swipe a variable and potentially large amount of times to reach the toolbar depending on what content is displayed.

Honestly, I am fine with either outcome since that would be something the user explicitly opted in for in the settings.

[Mugurell]

Closing after this was implemented in #18027