1146838 - Tabs tray is inaccessible to VoiceOver

Status: RESOLVED FIXED

(Firefox for iOS :: General, defect)

Description

[Marco Zehe (:MarcoZ)]

In build 5, the tabs tray is completely inaccessible to VoiceOver. VoiceOver only identifies the whole screen as "Tabs Tray", but there are no individual controls to swipe to or find by exploring the screen.

Steps:
1. Run build 5.
2. Go to a page.
3. Turn on VoiceOver by going to Settings/General/Accessibility/VoiceOver and turn it on. Note that this changes your gestures. Single tap highlights, double-tap activates, swiping left and right goes back and forth between controls.
4. It might be a good idea to set the triple-click home to toggle VoiceOver in Settings/General/Accessibility/Triple click home, at the bottom of the Accessibility screen. That way, VoiceOver can easily be toggled on and off.
5. Return to Fennec and find the "Show Tabs (1)" button at the top right. Once it's highlighted, double-tap anywhere on the screen to activate.
6. Touch anywhere on the screen.

VoiceOver will read, and possibly put a box around, the whole screen without being able to identify different controls within this screen.

The controls need to be exposed via the UIAccessibility protocol and friends, the container will be an UIAccessibilityContainer with the individual controls added, they all need the correct AccessibilityActivation set etc. They seem to not be inheriting from the standard UIKit things any more. There is no information exposed at all.

This is a regression from the first build I tried, build 1, where this tray worked for the most part.

Comment 1

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Marco, we need some guidance here I think. It is pretty easy to add accessibility labels to the individual tabs, but what should their contents be? The page URL? Or the page title? Or both? Or a custom formatted text?

Comment 2

[Marco Zehe (:MarcoZ)]

I'd say the Page Title, as is usual for the tabs in Safari, or in Firefox for Android, fo that matter. And then give each of the AccessibilityElements all the actions there are. e. g. if you can tap on it to activate and swipe it to close the tab, if VoiceOver doesn't pick up on these automatically, add the AccessibilityCustomActions to it so the VoiceOver rotor can be used to perform all actions in a controlled fashion.

Comment 3

[Boris Dušek]

https://github.com/mozilla/firefox-ios/pull/306

Comment 4

[Boris Dušek]

The only remaining issue, AFAIK, is that the "Sign In" button (i.e. the title view) is completely inaccessible (i.e. can't be reached with VoiceOver neither using swipe gestures, nor using touch exploration). My guess is it could be a UIKit accessibility bug (when UINavigationItem contains `titleView` instead of `title`, accessibility might get confused), but will probably look at it sometime again and see if that is the case and if there is any workaround possible.

Comment 5

[Boris Dušek]

Added a commit to the pull request to fix the "Sign In" button. Turned out to really be a very bizarre AppKit accessibility issue with a (hopefully acceptable) workaround.

Comment 6

[Brian Nicholson (:bnicholson)]

Attachment: Pull request

Flagging myself just so this doesn't get overlooked, but if anyone else wants to take this review that'd be super.

Comment 7

[Wesley Johnston (:wesj)]

Comment on attachment 8588940 [details] [review]
Pull request

A couple comments in the PR. Can you update it, and I'll land it.

Comment 8

[Boris Dušek]

(In reply to Wesley Johnston (:wesj) from comment #7)
> A couple comments in the PR. Can you update it, and I'll land it.

I will do it today (and then say so here).

Comment 9

[Boris Dušek]

(In reply to Boris Dušek from comment #8)
> (In reply to Wesley Johnston (:wesj) from comment #7)
> > A couple comments in the PR. Can you update it, and I'll land it.
> 
> I will do it today (and then say so here).

OK, now it's done. Please take a look.

Comment 10

[Boris Dušek]

I was wondering if the PR could get reviewed? (I just rebased btw.)

Comment 11

[Marco Zehe (:MarcoZ)]

wesj, does this need re-review? Or missing anything else to move forward with it? This bug is keeping me from testing some essential parts of the app. :)

Comment 12

[Boris Dušek]

I again rebased the PR, fixing conflicts. I would appreciate a review.

Comment 13

[Wesley Johnston (:wesj)]

Looks good. merged. Sorry for the delay.

Comment 14

[Boris Dušek]

Thanks.

Comment 15

[Marco Zehe (:MarcoZ)]

Did this make the cut for build 8? If so, the fix doesn't work. if not, I'll have to be patient for the next build. Build 8 didn't have any change to the behavior, e. g. still only the tabs tray being one big blob without any discernable controls.

Comment 16

[Boris Dušek]

If git tag AuroraV8 is to be trusted, then it unfortunately did not make the cut by approx. 15 commits (or 1 day). So you will have to wait for the next build (i.e. AuroraV9 I guess).

Comment 17

[Marco Zehe (:MarcoZ)]

OK, then that answers it. Thanks!