1477959 - Order of acessibles not according to screen layout

Status: RESOLVED DUPLICATE of bug 1616146

(Core :: Disability Access APIs, defect, P2)

Description

[Marco Zehe (:MarcoZ)]

STR:
1. On an Android device, run Firefox Nightly and TalkBack, and bring up any web page.
2. Perform the up, then down, swipe gesture to go to the top of the screen.

Expected: TalkBack would move to the first accessible, which is in the browser chrome.
Actual: TalkBack focuses the first web page element.

3. Now, perform the down, then up, swiping gesture to go to the bottom of the screen.

Expected: TalkBack should focus the last visible page element.
Actual: TalkBack focuses the menu button, which is at the top right corner of the screen, but the last element of our browser chrome.

4. Swipe right once.

Expected: TalkBack should transition from the browser chrome to the first web page element.
Actual: The edge bonk sound is heard, indicating that this is the last accessible on the screen that is available.

It appears that the order of elements is first all web page elements currently visible, then the browser chrome native widgets.

Comment 1

[James Teh [:Jamie]]

Marco, is this still valid in Fenix with the address bar at top (or at bottom for that matter)?

Comment 2

[Marco Zehe (:MarcoZ)]

The situation is two way:

1. If the toolbar is at the bottom, which it is by default, you can swipe inside web content, or inside the bar. But you cannot go from one to the other. They are totally closed containers each.
2. If the toolbar is at the top, you can navigate from the tool bar into web content, but not backwards.

Comment 3

[James Teh [:Jamie]]

Is this fixed by bug 1616146 and/or bug 1616337?

Comment 4

[Eitan Isaacson [:eeejay]]

Oops. Yeah, I would consider this a dup.