Closed Bug 1211115 Opened 9 years ago Closed 6 years ago

When the screen reader is enabled, sometimes the focus is not correctly set after some operations.

Categories

(Firefox OS Graveyard :: Gaia::System::Accessibility, defect, P2)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:2.5+)

RESOLVED WONTFIX
blocking-b2g 2.5+

People

(Reporter: julienw, Unassigned)

References

Details

(Keywords: access, regression)

It looks like that when we enter the System app for some things from an app (for example: with a select input), when we exit the dialog, the focus is not given back to the app.

Here is a STR:
1. Enable the screen reader.
2. Enter the Settings app > Languages, and enables the language choice input.
3. Dismiss the input by enabling the "OK" button (you can longpress it and double tap to activate).

=> The focus is still in the system app and we can't enter the Settings app back unless we longpress a link, but a real Screen Reader user will have a hard time doing this.

This makes it very difficult to navigate for a screen reader user.


A similar bug, maybe related, is that we don't have the focus on the lockscreen when waking up the phone from idle mode, here is the STR:
0. Take care that the lockscreen is enabled.
1. Enable the screen reader.
2. Press the "Power" button.
3. Press the "Power" button to wake up the phone.
4. Try to unlock the phone without using the "longpress" shortcut.
=> It's not possible because the focus seems to stay in the System app.

Asking a blocking status because this is very confusing for a screen reader user.
Blocks: gaiaa11y
Eitan, Can you please help triage this and set a priority?

Thanks
Flags: needinfo?(eitan)
Is this a regression?
Keywords: qawanted
Component: Gaia::System → Gaia::System::Accessibility
REPRO in builds: 

Environmental Variables:
Device: Aries 2.5
BuildID: 20151005111147
Gaia: b994cedaa7ef9bfadcbe841601d9dc8d2e5379f9
Gecko: 45f01961ecd0ad9a45067f3e08bfb92539042eeb
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 44.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0


RESULTS: 
When lockscreen is on, cannot unlock when Reader is enabled, when tapping different areas of the UI-lockscreen, 
the Screen Reader describes whatever UI is under the locked screen. Had to restart to get back to normal device operation. 

Environmental Variables:
Device: Flame 2.5
BuildID: 20151004150211
Gaia: f3d9981dccfa4dfdfcb865d95fdcfb85e4077e1e
Gecko: 3d7532ce81ac571962abc3b99582fe7f5d685192
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 44.0a1 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

RESULTS: 
When lockscreen is on, cannot unlock when Reader is enabled, when tapping different areas of the UI-lockscreen, 
the Screen Reader describes whatever UI is under the locked screen. Had to restart to get back to normal device operation.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
Keywords: qawanted
QA Contact: sleedavid
NO REPRO on BUILD: 

Environmental Variables:
Device: Flame 2.2
BuildID: 20150114002502
Gaia: 7c5b27cad370db377b18a742d3f3fdb0070e899f
Gecko: 748b20315f75
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 37.0a2 (2.2) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

RESULTS: 
The screen reader works as expected when lockscreen is activated the focus stays on the appropriate graphic element.
No Repro per build: 

Environmental Variables:
Device: Flame 2.2
BuildID: 20151006032504
Gaia: 5dd95cfb9f1d6501ce0e34414596ef3dd9c2f583
Gecko: fc588eb28eab
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 37.0 (2.2) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0


RESULTS: 
When activate screen Reader then enable Lockscreen, the Screen Reader behaves as expected unlocking screen.
Keywords: accessregression
Flags: needinfo?(jmercado)
Keywords: access
(In reply to Julien Wajsberg [:julienw] from comment #0)
> It looks like that when we enter the System app for some things from an app
> (for example: with a select input), when we exit the dialog, the focus is
> not given back to the app.
> 
> Here is a STR:
> 1. Enable the screen reader.
> 2. Enter the Settings app > Languages, and enables the language choice input.
> 3. Dismiss the input by enabling the "OK" button (you can longpress it and
> double tap to activate).
> 
> => The focus is still in the system app and we can't enter the Settings app
> back unless we longpress a link, but a real Screen Reader user will have a
> hard time doing this.
> 

I just tested this, the focus returns to the settings app, specifically to the language select widget.

> This makes it very difficult to navigate for a screen reader user.
> 
> 
> A similar bug, maybe related, is that we don't have the focus on the
> lockscreen when waking up the phone from idle mode, here is the STR:
> 0. Take care that the lockscreen is enabled.
> 1. Enable the screen reader.
> 2. Press the "Power" button.
> 3. Press the "Power" button to wake up the phone.
> 4. Try to unlock the phone without using the "longpress" shortcut.
> => It's not possible because the focus seems to stay in the System app.
> 
> Asking a blocking status because this is very confusing for a screen reader
> user.

When the screen is turned on, the screen reader cursor is placed in the lock screen.

I tested this on master with both a flame and z3c.

Julien, unless you reliably reproduce this. I would mark this as worksforme.
Flags: needinfo?(eitan)
Julien, can you still reliably reproduce? If yes, it might be worth a video/video call.
Flags: needinfo?(felash)
With latest dogfood build, I have another issue in the lockscreen: the focus is on the (new) utility tray. But I don't seem to have the issue in the language list anymore (yet I can hear all options without entering the input, and cannot act on them at all).

So maybe the focus issue is fixed, but there are other issues now.
Flags: needinfo?(felash)
The utility tray issue is known (bug 1209718).

You can hear all the options without bringing up the selection dialog? That is a problem. Can't reproduce here. Or do you mean when the dialog appears? Double tapping after hearing a specific option selects it.
Yep, it was without bringing up the selection dialog.

I'll try again with the newest build today.
Flags: needinfo?(felash)
ok, I don't reproduce either the initial bug or the bug I'm talking about in comment 8.

Closing !
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(felash)
Resolution: --- → WORKSFORME
I think I got a similar issue when starting an activity.

For example:
1. Open the Messages app
2. Activate the "new message" button.
3. Activate the "+" button.

=> Then I couldn't select a contact.

Yura, can you try to reproduce and see if we should reopen ? The screen reader is crashing too much for me and it makes me crazy (bug 1214149).
Flags: needinfo?(yzenevich)
(In reply to Julien Wajsberg [:julienw] from comment #12)
> I think I got a similar issue when starting an activity.
> 
> For example:
> 1. Open the Messages app
> 2. Activate the "new message" button.
> 3. Activate the "+" button.
> 
> => Then I couldn't select a contact.
> 
> Yura, can you try to reproduce and see if we should reopen ? The screen
> reader is crashing too much for me and it makes me crazy (bug 1214149).

For me the screen reader lands on the status bar icon, which is up the tree from the messages app in the system app. There are 2 issues here IMO:

* Document loaded event focus might be happening before hide event for the previous frame. this means that the new frame auto focus is cancelled. Need to investigate.

* A bigger issue though is that the screen is not well explorable by touch which i'd need to take a look at as well.
Flags: needinfo?(yzenevich)
OK I'm reopening this then.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Blocking 2.5 with a P2 Priority.
blocking-b2g: 2.5? → 2.5+
Priority: -- → P2
Hi Julien,

So the bug 1218897 has landed. The issue with contact selection should be working now. Is that right?
Flags: needinfo?(felash)
Hey Yura, it works but not completely.

I can select a contact, but once it's selected, it takes a _really_ long time (I'd say between 5 and 10 seconds) to return control to Messages.

Moreover, it's quite awkward to select a contact in Messages. I filed bug 1225213 about that.
Flags: needinfo?(felash)
Julien,

As you filed a bug for the new issue, is the core issue resolved? Do we have more work on this bug or can we close? Also, should the new bug block 2.5?

Thanks
Flags: needinfo?(felash)
No, you can reread my comment :) There are _2_ issues. I filed a separate one for the bug in Contacts, because it's obviously unrelated to this one.

Yet I still think this behavior here:

> I can select a contact, but once it's selected, it takes a _really_ long time (I'd say 
> between 5 and 10 seconds) to return control to Messages.

is incorrect and belongs to this bug.

About the new bug, this should IMO block but this is not my call though.
Flags: needinfo?(felash)
(In reply to Julien Wajsberg [:julienw] from comment #19)
> No, you can reread my comment :) There are _2_ issues. I filed a separate
> one for the bug in Contacts, because it's obviously unrelated to this one.
> 
> Yet I still think this behavior here:
> 
> > I can select a contact, but once it's selected, it takes a _really_ long time (I'd say 
> > between 5 and 10 seconds) to return control to Messages.
> 
> is incorrect and belongs to this bug.
> 
> About the new bug, this should IMO block but this is not my call though.

Hmm this is weird, I an on nightly Aries and selection is super fast with the screen reader.. What's your device/gaia combo, Julien?
Flags: needinfo?(felash)
I was testing on Flame but I'll try on Aries (I just need to take time to flash to latest build).
I still have this on both Flame and Aries :(

Selection is fast, but _after_ the selection, we can't do anything during several seconds.
Flags: needinfo?(felash)
Firefox OS is not being worked on
Status: REOPENED → RESOLVED
Closed: 9 years ago6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.