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)
Firefox OS Graveyard
Gaia::System::Status bar, Utility tray, Notification
ARM
Gonk (Firefox OS)
Tracking
(blocking-b2g:2.5+, b2g-v2.2 unaffected, b2g-master verified)
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.
Reporter | ||
Comment 1•9 years ago
|
||
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).
Updated•9 years ago
|
Comment 2•9 years ago
|
||
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)
Keywords: regressionwindow-wanted
Comment 3•9 years ago
|
||
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 | ||
Updated•9 years ago
|
Assignee: nobody → apastor
Flags: needinfo?(apastor)
Assignee | ||
Comment 4•9 years ago
|
||
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
Assignee | ||
Comment 5•9 years ago
|
||
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)
Reporter | ||
Comment 6•9 years ago
|
||
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.
Assignee | ||
Comment 7•9 years ago
|
||
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)
Reporter | ||
Comment 8•9 years ago
|
||
(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)
Assignee | ||
Comment 9•9 years ago
|
||
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!
Assignee | ||
Comment 10•9 years ago
|
||
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)
Comment 11•9 years ago
|
||
Assignee | ||
Comment 12•9 years ago
|
||
- 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 13•9 years ago
|
||
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)
Updated•9 years ago
|
blocking-b2g: --- → 2.5+
Whiteboard: [systemsfe]
Updated•9 years ago
|
Target Milestone: --- → FxOS-S2 (10Jul)
Assignee | ||
Updated•9 years ago
|
Attachment #8629568 -
Flags: review?(etienne)
Assignee | ||
Updated•9 years ago
|
Attachment #8629538 -
Attachment is obsolete: true
Comment 14•9 years ago
|
||
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)
Assignee | ||
Comment 15•9 years ago
|
||
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 16•9 years ago
|
||
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+
Assignee | ||
Comment 17•9 years ago
|
||
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)
Reporter | ||
Comment 18•9 years ago
|
||
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+
Assignee | ||
Comment 19•9 years ago
|
||
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Updated•9 years ago
|
Comment 20•9 years ago
|
||
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)
Updated•9 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in
before you can comment on or make changes to this bug.
Description
•