Closed Bug 1177477 Opened 9 years ago Closed 9 years ago

Accessibility Regression in Status bar.

Categories

(Firefox OS Graveyard :: Gaia::System::Status bar, Utility tray, Notification, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.5+, b2g-v2.2 unaffected, b2g-master verified)

VERIFIED FIXED
FxOS-S2 (10Jul)
blocking-b2g 2.5+
Tracking Status
b2g-v2.2 --- unaffected
b2g-master --- verified

People

(Reporter: yzen, Assigned: apastor)

References

Details

(Keywords: access, regression, Whiteboard: [systemsfe])

Attachments

(1 file, 3 obsolete files)

Status bar is again no longer accessible to the screen reader user. I suspect it happened after the last update to the status bar that happened a couple of weeks before. We again have the status bar shadow instead of the real thing displayed on screen so it can only be accessed via the swipe to navigate and not explore by touch.
Steps to reproduce:

* Load the home screen with enabled the screen reader
* Tap and hold one of the status bar icons, for example - battery.

Result: Nothing happens, screen reader focus does not change, nothing is spoken by the screen reader
Expected: Screen reader focus should switch to the battery icon and the change should be spoken by the screen reader (e.g. information about the battery).
b2g-inbound regression window:

Last Working
Device: Flame
BuildID: 20150617030149
Gaia: 6be1d1fdd54c999b5f733de5f80e61cb81fbe9a0
Gecko: 2c1851ceb7b0
Version: 41.0a1 (3.0 Master) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

First Broken
Device: Flame
BuildID: 20150617033251
Gaia: 1d852d0acb3ae92fd8495e997fb7e070a7ee9295
Gecko: 322d0b795172
Version: 41.0a1 (3.0 Master) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

Last Working Gaia First Broken Gecko - no repro
Gaia: 6be1d1fdd54c999b5f733de5f80e61cb81fbe9a0
Gecko: 322d0b795172

Last Working Gecko First Broken Gaia - repro
Gaia: 1d852d0acb3ae92fd8495e997fb7e070a7ee9295
Gecko: 2c1851ceb7b0

Gaia pushlog:
https://github.com/mozilla-b2g/gaia/compare/6be1d1fdd54c999b5f733de5f80e61cb81fbe9a0...1d852d0acb3ae92fd8495e997fb7e070a7ee9295

Caused by Bug 1172867.
Blocks: 1172867
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Alberto, can you take a look at this please? This might have been caused by the landing for bug 1172867.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(apastor)
Assignee: nobody → apastor
Flags: needinfo?(apastor)
This should fix it. We'll still use moz-elements, but we'll hide the real statusbar by z-index instead of top. That way, and letting the touch events go through in the statusbar, it should be accessible by the screen reader
I'm not very convinced about this solution, but can't think on any other option... Etienne, any idea?
Attachment #8627164 - Attachment is obsolete: true
Attachment #8628739 - Flags: feedback?(etienne)
I tried the patch and it does not seem to fix the issue. The issue is similar to what we previously regressed on several times: we display a statusbar shadow with a background containg moz-element instead of the real status bar that is off-screen. Previously, we were fixing it by replacing the shadow with the real thing when we were done transitioning or opening the app/homescreen/lockscreen. Not sure if the old approach would still work though.
What does exactly mean that it doesn't fix the issue? Is that the clicks are not working? Swiping is not working?

We are displaying a moz-element, but the real one is underneath, taking the click events. I've tried with the device, and the screen reader does take those items when clicking on them.

The moz-element give us some performance improvements and reduces the code complexity. If there is not other option of making a moz-element accessible, I guess we'll need to go back... let's try to find a way of keeping it first. Thanks!
Flags: needinfo?(yzenevich)
(In reply to Alberto Pastor [:albertopq] from comment #7)
> What does exactly mean that it doesn't fix the issue? Is that the clicks are
> not working? Swiping is not working?
> 
> We are displaying a moz-element, but the real one is underneath, taking the
> click events. I've tried with the device, and the screen reader does take
> those items when clicking on them.
> 
> The moz-element give us some performance improvements and reduces the code
> complexity. If there is not other option of making a moz-element accessible,
> I guess we'll need to go back... let's try to find a way of keeping it
> first. Thanks!

Sorry I have applied the PR incorrectly, it actually works quite well. I did find one regression though and and hopefully there aren't any more: when utility tray is open, the status bar is inaccessible with screen reader (at least when i tried several times).
Flags: needinfo?(yzenevich)
That's a good point. We might have issues right now with any dialog in top of the statusbar taking the click events. I'll take a look to that.

Thanks!
Comment on attachment 8628739 [details] [review]
Link to Pull Request: https://github.com/mozilla-b2g/gaia/pull/30795

I think I managed to fix this without this trick. Will send the PR soon
Attachment #8628739 - Flags: feedback?(etienne)
- Show real statusbar while not animating
- Show the moz-element while opening/closing apps, utility tray animating, edge gestures
- Fixed the issue we had with the real statusbar and reflows on the utility tray
Attachment #8628739 - Attachment is obsolete: true
Attachment #8629568 - Flags: review?(etienne)
Comment on attachment 8629568 [details] [review]
Link to PR:  https://github.com/mozilla-b2g/gaia/pull/30816

(In reply to Alberto Pastor [:albertopq] from comment #12)
> Created attachment 8629568 [details] [review]
> Link to PR:  https://github.com/mozilla-b2g/gaia/pull/30816
> 
> - Show real statusbar while not animating
> - Show the moz-element while opening/closing apps, utility tray animating,
> edge gestures
> - Fixed the issue we had with the real statusbar and reflows on the utility
> tray

This sounds like a good approach!

Not sure I fully grasped the patch yet.
But I have 2 early comments that will probably also help me finish the review.

- can you add unit-test coverage to the statusbar.js changes?
- can you add some comments to the CSS (eg. hiding the shadow statusbar in the following cases...)


Also, not sure why, but it looks like the statusbar is not moz-element-able during the transitions. So the icons "pop" in place at the end of the opening transition for example.
You can set the |slowTransition| flag to true in AppWindowManager to inspect this more easily.

(Sorry about the delay, I'll make sure to prioritize the next review round!)
Attachment #8629568 - Flags: review?(etienne)
blocking-b2g: --- → 2.5+
Whiteboard: [systemsfe]
Target Milestone: --- → FxOS-S2 (10Jul)
Attachment #8629568 - Flags: review?(etienne)
Attachment #8629538 - Attachment is obsolete: true
Comment on attachment 8629568 [details] [review]
Link to PR:  https://github.com/mozilla-b2g/gaia/pull/30816

Thanks it's helping a lot!
Can't r+ yet because of the pause/resume issue but we're close :)
Attachment #8629568 - Flags: review?(etienne)
Comment on attachment 8629568 [details] [review]
Link to PR:  https://github.com/mozilla-b2g/gaia/pull/30816

The failing test fails with master as well. I'll track that in bug 1118637
Attachment #8629568 - Flags: review?(etienne)
Comment on attachment 8629568 [details] [review]
Link to PR:  https://github.com/mozilla-b2g/gaia/pull/30816

r=me with one tiny but important css comment :)
Might be worth it to check one last time that we're actually fixing the accessibility issue :)

Cheers, thanks for sticking with it!
Attachment #8629568 - Flags: review?(etienne) → review+
Comment on attachment 8629568 [details] [review]
Link to PR:  https://github.com/mozilla-b2g/gaia/pull/30816

Yura, could you please confirm that this patch fixes the issue? Thanks!
Attachment #8629568 - Flags: feedback?(yzenevich)
Comment on attachment 8629568 [details] [review]
Link to PR:  https://github.com/mozilla-b2g/gaia/pull/30816

Hi Alberto, this works really great. In fact it works even better than before in one place: when opening/closing the utility tray, if the screen reader focus is on one of the statusbar icons, it remains there and does not jump (which is sweet). Thanks!
Attachment #8629568 - Flags: feedback?(yzenevich) → feedback+
master: https://github.com/mozilla-b2g/gaia/commit/31eed4c0ab1a32f1a5bf8acac723595b61902027
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
This issue is verified fixed on Flame and Aries. Tap and hold on an item on status bar puts accessibility focus there.

Device: Flame 2.5
BuildID: 20150721010202
Gaia: 4fe0507781f3ed56c8ae5e66dd9489165d1ff68e
Gecko: 3a4bfa5d2d02
Gonk: 41d3e221039d1c4486fc13ff26793a7a39226423
Version: 42.0a1 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Device: Aries 2.5
BuildID: 20150721153949
Gaia: 805cf546729ba742bf23febda52970fcb35c0e8f
Gecko: 512c7e8f0030
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 42.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Depends on: 1184672
Depends on: 1225333
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: