Closed Bug 886077 Opened 8 years ago Closed 8 years ago

Can't access address bar using Spiel screen reader

Categories

(Firefox for Android :: General, defect, P1)

All
Android
defect

Tracking

()

VERIFIED FIXED
Firefox 25
Tracking Status
firefox22 --- unaffected
firefox23 + verified
firefox24 + verified
firefox25 --- verified

People

(Reporter: maxli, Assigned: maxli)

References

Details

(Keywords: access, regression)

Attachments

(1 file)

Exploring by touch or flicking left/right does not seem to be able to find it.

Seems to be a regression that was introduced in Firefox 23.
Here's some more information gathered from the e-mail that was sent to me regarding this issue:

"Before I will try to describe my findings I must say I have tried Firefox beta which is currently at version 22.0 and with this version everything is working as it should and the title saying "Enter search or address" at the top of the main Firefox window is accessible while using that version.

At the right hand side on the top of the main Firefox window there is a view of type android.widget.RelativeLayout. Inside this view there is a button which is used to open a list of currently open tabs.
This android.widget.RelativeLayout has its ContentDescription set to the name of the currently loaded website or there is a text "enter search or address" when no page is currently loaded.
I am afraid this was not always like that and mostlikelly there was a text view or another control inside the android.widget.RelativeLayout I am talking about all the time.

I am afraid this was not an accessibility related change, perhaps this was a visually oriented change but according to the spiel author's response to my quest for a fix to this situation it would require a serious rewrite of spiel functionality in order to be able to change its presentation paradigm to be able to make this android.widget.RelativeLayout anounced via speech.
Additionally it is not possible to distinguish this instance of android.widget.RelativeLayout from other views of this type therefore it is also inpossible to try to come up with a script in order to try to come up with a solution via scripting."

So, some overloading of relativeLayout caused this breakage. I wasn't even aware you could assign contentDescription to this purely layout-providing element! We should try to get this fixed properly.
Keywords: regression
tracking-fennec: --- → ?
Priority: -- → P1
Assignee: nobody → maxli
Is this a problem in any other screen readers?
It is a problem in Spiel, a widely used screen reader for Android. It is not a problem in TalkBack, the screen reader that comes bundled with Android. However, Spiel is particularly favored among real power users. Its spacial representation of elements is more accurate than TalkBack's, and it is scriptable, which means it can be easily enhanced without having to actually build the whole project.

While TalkBack accounts for such things as a contentDescription on a android:relativeLayout element, and it simply puts it whereever it thinks it fits in the spacial representation, Spiel's architecture is different, and layout elements are strictly treated as such.
Attached patch PatchSplinter Review
Lucas, you added these lines which seem to be causing the problem. What problem was that trying to solve? AFAICT everything still works fine after removing these, but I don't know if I missed something.

Marco, could you check (in both TalkBack and Spiel) to make sure I haven't missed breaking anything obvious?
Attachment #767121 - Flags: review?(lucasr.at.mozilla)
Attachment #767121 - Flags: feedback?(marco.zehe)
Max, what bug does that change point to? I seem to remember we did have to do something like this a year ago to solve the duplication of a button in the awesome bar, I believe having to do with the site security or so. I am building with this patch now to see if that problem then occurs again. Anyway, looking in the original bug might provide some more context.
(In reply to Marco Zehe (:MarcoZ) from comment #5)
> Max, what bug does that change point to? I seem to remember we did have to
> do something like this a year ago to solve the duplication of a button in
> the awesome bar, I believe having to do with the site security or so. I am
> building with this patch now to see if that problem then occurs again.
> Anyway, looking in the original bug might provide some more context.

The changeset is the last of bug 858687. I don't see any mentions of anything accessibility related at all in that bug.
(In reply to Max Li [:maxli] from comment #6)
> The changeset is the last of bug 858687. I don't see any mentions of
> anything accessibility related at all in that bug.

After a little more investigation, that line was introduced in bug 771380 in which you do see that duplication. But the bug above appears to be where the regression happened.
Comment on attachment 767121 [details] [diff] [review]
Patch

I can confirm that this fixes the missing control in Spiel, and that it does not seem to reintroduce bug 771380. The conditions described in bug 771380 comment #44 no longer seem to apply due to several rewrites of that component. f=me.
Attachment #767121 - Flags: feedback?(marco.zehe) → feedback+
Firefox-22 is not affected, right?
(In reply to Aaron Train [:aaronmt] from comment #9)
> Firefox-22 is not affected, right?

Correct.
Attachment #767121 - Flags: review?(lucasr.at.mozilla) → review+
https://hg.mozilla.org/mozilla-central/rev/74357fe0651d
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 25
Verified fixed in Firefox 25.0a1 (2013-06-27) by both me and Peter, who originally reported the bug to us.
Status: RESOLVED → VERIFIED
Comment on attachment 767121 [details] [diff] [review]
Patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 858687
User impact if declined: Blind users of the alternative Android screen reader Spiel could no longer access the button to enter an address or search term in the awesome bar.
Testing completed (on m-c, etc.): Yes.
Risk to taking this patch (and alternatives if risky): None known.
String or IDL/UUID changes made by this patch: None.
Attachment #767121 - Flags: approval-mozilla-beta?
Attachment #767121 - Flags: approval-mozilla-aurora?
Attachment #767121 - Flags: approval-mozilla-beta?
Attachment #767121 - Flags: approval-mozilla-beta+
Attachment #767121 - Flags: approval-mozilla-aurora?
Attachment #767121 - Flags: approval-mozilla-aurora+
This got broken again between the 2013-06-28 and 2013-06-29 builds. The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8e3a124c9c1a&tochange=c5ce065936fa

Max, can you investigate what happened? It looks like the patch was reverted.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(In reply to Marco Zehe (:MarcoZ) from comment #15)
> This got broken again between the 2013-06-28 and 2013-06-29 builds. The
> regression range is:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=8e3a124c9c1a&tochange=c5ce065936fa
> 
> Max, can you investigate what happened? It looks like the patch was reverted.

Seems like the patch for bug 887020 (written around the same time as my patch) reverted it.
Can you re-land on inbound? Or does the patch have to be rewritten?
https://hg.mozilla.org/mozilla-central/rev/d3a746cf592d
Status: REOPENED → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → FIXED
Re-landed bug fix verified in the Firefox 25.0a1 nightly build of 2013-07-01.
Status: RESOLVED → VERIFIED
Verified fixed in Firefox Aurora 24.0a2 (2013-07-02).
Verified fixed in Firefox 23 Beta (2013-07-02)
tracking-fennec: ? → ---
You need to log in before you can comment on or make changes to this bug.