TalkBack stopped working in web content

RESOLVED FIXED in Firefox 53

Status

()

Firefox for Android
General
RESOLVED FIXED
4 months ago
a month ago

People

(Reporter: Roy Nickelson, Assigned: jchen)

Tracking

(Blocks: 1 bug, {access, regression})

50 Branch
Firefox 54
access, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox53+ verified, firefox54 verified, firefox-esr52 unaffected, fennec+)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

4 months ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161208153507

Steps to reproduce:

start TalkBack
Navigate to 
https://labs.ssbbartgroup.com/index.php/ARIA_Checkbox_role
Navigate to one of the check boxes



Actual results:

Talkback announces Button


Expected results:

TalkBack should announce check box
tracking-fennec: --- → ?
Hi Sorina,
If this bug can be reproduced, could you provide a regression window?
Flags: needinfo?(sorina.florean)
Regression window:
Last known good build: 2016-12-10
First known bad build: 2016-12-11

Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8404d26166a35406f46ff237ed132735c98882b2&tochange=c51e7406d7b2e2246a1ece0d8989282ca752039f

Device: Huawei MediaPad M2 (Android 5.1.1).
Flags: needinfo?(sorina.florean)
Changes from Jim & Eugen during that day.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(nchen)
Flags: needinfo?(esawin)
(Assignee)

Updated

4 months ago
Assignee: nobody → nchen
Blocks: 1321418
Status: NEW → ASSIGNED
Flags: needinfo?(nchen)
Flags: needinfo?(esawin)
See Also: → bug 1331946
(Assignee)

Comment 4

4 months ago
Created attachment 8833593 [details] [diff] [review]
Follow-up to fix accessibility breakage (v1)

Follow-up to fix breakage in accessibility caused by the bundle
conversion. In particular, optString(foo) should have been converted to
getString(foo, "") because optString returns "" by default.

Also fix a small bug in Presentation.jsm where an array or null should
be used instead of a string.
Attachment #8833593 - Flags: review?(s.kaspari)
(Assignee)

Comment 5

4 months ago
Created attachment 8834066 [details] [diff] [review]
Follow-up to fix accessibility breakage (v2)

Updated patch
Attachment #8834066 - Flags: review?(s.kaspari)
(Assignee)

Updated

4 months ago
Attachment #8833593 - Attachment is obsolete: true
Attachment #8833593 - Flags: review?(s.kaspari)
Attachment #8834066 - Flags: review?(s.kaspari) → review+
(Assignee)

Updated

4 months ago
Duplicate of this bug: 1331946
tracking-fennec: ? → +

Comment 7

4 months ago
Pushed by nchen@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/ffddbc50a846
Follow-up to fix accessibility breakage; r=sebastian

Comment 8

4 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/ffddbc50a846
Status: ASSIGNED → RESOLVED
Last Resolved: 4 months ago
status-firefox54: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 54
Verified as fixed in build 54.0a1 (2017-02-16);
Device: Asus ZenPad 8 (Android 6.0.1).
status-firefox54: fixed → verified
(Assignee)

Updated

a month ago
status-firefox53: --- → affected
(Assignee)

Comment 10

a month ago
Comment on attachment 8834066 [details] [diff] [review]
Follow-up to fix accessibility breakage (v2)

Approval Request Comment
[Feature/Bug causing the regression]: Bug 1321418
[User impact if declined]: TalkBack accessibility feature does not work on web content
[Is this code covered by automated tests?]: No
[Has the fix been verified in Nightly?]: Yes, and Aurora/Beta.
[Needs manual test from QE? If yes, steps to reproduce]: No
[List of other uplifts needed for the feature/fix]: None
[Is the change risky?]: No
[Why is the change risky/not risky?]: Patch has been on 54+ for a while, but was never uplifted to 53.
[String changes made/needed]: None
Attachment #8834066 - Flags: approval-mozilla-release?
Hi Liz, we should consider including this fix in 53.0.1. This fix has been on 54 for almost 2 months and verified by SoftVision.
tracking-firefox53: --- → +
Flags: needinfo?(lhenry)

Updated

a month ago
Keywords: regression
I've seen several recent examples of a regression marked only as tracking-fennec:+ but not marked as affected for a particular version. I think we have a good chance here to improve how our triage systems work together. 

I'd like to suggest: when you see new issues, please add the "regression" keyword and possibly "regressionwindow-wanted".  We should be all be proactive about it. When did the issue start? How bad is this regression for users? What versions does it affect? Should we uplift the fix?   

We need to ask those questions so that we can avoid shipping regressions, or fix those regressions as soon as possible. So, we have to just go a little bit beyond landing the patch and verifying the bug was fixed in Nightly. 

This will really help, because then you will get all the "machinery" of QE, release management, and platform triage (engineering managers) noticing fennec issues, and getting the fixes where they should be.  

n-i to some folks in this bug, to make sure you see my comment, not because this needs any reply. 
I will also send my suggestion to the release-drivers mailing list.
Flags: needinfo?(whuang)
Flags: needinfo?(sorina.florean)
Flags: needinfo?(s.kaspari)
Flags: needinfo?(nchen)
Flags: needinfo?(lhenry)
Flags: needinfo?(kbrosnan)
Flags: needinfo?(kbrosnan)
Comment on attachment 8834066 [details] [diff] [review]
Follow-up to fix accessibility breakage (v2)

Broke accessibility on release, let's uplift this and test.
Attachment #8834066 - Flags: approval-mozilla-release? → approval-mozilla-release+
(Assignee)

Comment 14

a month ago
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #12)
> I'd like to suggest: when you see new issues, please add the "regression"
> keyword and possibly "regressionwindow-wanted".  We should be all be
> proactive about it. When did the issue start? How bad is this regression for
> users? What versions does it affect? Should we uplift the fix?

Got it and I agree. I should have done better here, and I will remember these points in the future. Thanks!
Flags: needinfo?(nchen)
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #12)
> I've seen several recent examples of a regression marked only as
> tracking-fennec:+ but not marked as affected for a particular version. I
> think we have a good chance here to improve how our triage systems work
> together. 
> 
> I'd like to suggest: when you see new issues, please add the "regression"
> keyword and possibly "regressionwindow-wanted".  We should be all be
> proactive about it. When did the issue start? How bad is this regression for
> users? What versions does it affect? Should we uplift the fix?   
> 
> We need to ask those questions so that we can avoid shipping regressions, or
> fix those regressions as soon as possible. So, we have to just go a little
> bit beyond landing the patch and verifying the bug was fixed in Nightly. 
> 
> This will really help, because then you will get all the "machinery" of QE,
> release management, and platform triage (engineering managers) noticing
> fennec issues, and getting the fixes where they should be.  
> 
> n-i to some folks in this bug, to make sure you see my comment, not because
> this needs any reply. 
> I will also send my suggestion to the release-drivers mailing list.

Will do that in the feature. Thanks!
Flags: needinfo?(sorina.florean)
Flags: needinfo?(s.kaspari) → needinfo?(max)

Comment 16

a month ago
Agree. We will also do that in future Fennec triage meeting. Thanks, Sebastian. :)
Flags: needinfo?(max)
Flags: needinfo?(whuang)
Hello, 

I've verified this issue in 54.0b2 Beta build and the latest Nightly, the issue seems to be reproducible, as described in Comment 0. Could this be a new regression maybe or was the fix never applied to these builds?
status-firefox54: verified → affected
status-firefox55: --- → affected
Flags: needinfo?(lhenry)
Hi Bogdan, It looks like the fix hasn't landed on release yet, but I'm a bit worried that it also may not be on 54.  Wes can you take a look and make sure this has really landed on 54?
Flags: needinfo?(lhenry) → needinfo?(wkocher)
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #18)
> Hi Bogdan, It looks like the fix hasn't landed on release yet, but I'm a bit
> worried that it also may not be on 54.  Wes can you take a look and make
> sure this has really landed on 54?

Patch landed on m-c when m-c was 54. I'd assume a new regression. Can qa track down a new regression range to see when it popped back up on 54? Perhaps :bogdan can run a Nightly build from right after this originally landed to see if the fix could be verified?
Flags: needinfo?(wkocher)
Bogdan, can you follow up?  
Jim, can your team in Taipei help? 
This is our main blocker right now for the fennec 53 dot release.  
The patch here hasn't landed on mozilla-release yet. But, we think it may not have worked in 54. 
It sounds like there is potentially an issue on 53, 54, and 55. Maybe a different cause than the original issue?
Flags: needinfo?(nchen)
Flags: needinfo?(bogdan.surd)
(Assignee)

Comment 21

a month ago
The STR in comment 0 works for me. The checkboxes are announced as "check button", which is the expected behavior AFAICT.
Flags: needinfo?(nchen)
(In reply to Roy Nickelson from comment #0)
> User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101
>
> Expected results:
> 
> TalkBack should announce check box

 The expected result is that they should be announced as check boxes, not buttons. If it's ok that they are announced as buttons, the issue can be considered as fixed and verified.
Flags: needinfo?(nchen)
(Reporter)

Comment 23

a month ago
If an element has a Roll of Checkbox then it should be announced as a checkbox. A checkbox is not the same as a button. The roll indicates to the user how to interact with the control.  
The expected behavior is Talkback will announce something like option 1 check box not checked when activating the check box by Double tapping on it Talkback should announce checked.
I still can't tell, on which branches does this now work, and on which is it still broken? 
Does TalkBack work in general for content now? And on which branches? 

I would think that check boxes are different than buttons, since they have different behavior for users. 

David, I wonder if you can help here since this is a pretty big accessibility issue affecting our release population.
Flags: needinfo?(dbolter)
Keywords: access
It looks like this is fixed everywhere except 53, but it looks like it will be in 53.0.1.
Wes could you land this on m-r? Thanks!
Flags: needinfo?(wkocher)
(Assignee)

Comment 27

a month ago
(In reply to Roy Nickelson from comment #23)
> If an element has a Roll of Checkbox then it should be announced as a
> checkbox. A checkbox is not the same as a button. The roll indicates to the
> user how to interact with the control.  
> The expected behavior is Talkback will announce something like option 1
> check box not checked when activating the check box by Double tapping on it
> Talkback should announce checked.

We should probably open another bug about changing "check button" to "check box". Unfortunately there was a different bug that broken TalkBack completely, and that issue ended up being worked on in this bug.
Flags: needinfo?(nchen)
(Assignee)

Updated

a month ago
Blocks: 1359888
(Assignee)

Updated

a month ago
Summary: TalkBack announces Check Boxes as buttons → TalkBack stopped working in web content

Comment 28

a month ago
uplift
https://hg.mozilla.org/releases/mozilla-release/rev/5cbf464688a4
status-firefox53: affected → fixed
status-firefox54: affected → fixed
status-firefox55: affected → ---
status-firefox-esr52: --- → unaffected
Flags: needinfo?(wkocher)
Flags: needinfo?(dbolter)
Flags: needinfo?(bogdan.surd)
See Also: → bug 1360113
Duplicate of this bug: 1358131
Device: Honor 8 (Android 6.0)
Builds:
 - 53.0.1 (Build 2)
 - 54.0b2
status-firefox53: fixed → verified
status-firefox54: fixed → verified
You need to log in before you can comment on or make changes to this bug.