Closed
Bug 1113505
Opened 10 years ago
Closed 7 years ago
Add a switch to enable/disable quick toggle for screen reader
Categories
(Firefox OS Graveyard :: Gaia::System, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: tjao, Assigned: tjao)
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20141126041045
Steps to reproduce:
Press volume up, then down, three times.
Actual results:
Screen reader enabled.
Expected results:
Screen reader enabled only if they already enabled quick toggle in accessibility menu.
Assignee | ||
Comment 1•10 years ago
|
||
Similar to Bug 957674, I accidentally enabled the screen reader by pressing those magic keys even without knowing what screen reader is. No kidding, I already encounter this problem twice this half year.
Since I have no idea what's happening and could not disable this function, I have no choice but to reset my phone.
I suggest adding a switch for quick toggle function in the accessibility menu so that user will not accidentally enable screen reader.
Assignee | ||
Comment 2•10 years ago
|
||
Forgot to mention, the version is 2.0.0.0-prerelease for Flame.
Component: General → Gaia::System
OS: All → Gonk (Firefox OS)
Hardware: All → ARM
Assignee | ||
Comment 3•10 years ago
|
||
Hello Evelyn, do you know is this an easy bug or not? I would like to do it but I'm not familiar with System.
Flags: needinfo?(ehung)
Comment 4•10 years ago
|
||
I think the implementation is not tough, so feel free to take it. You can discuss with accessibility team, and I think :eeejay is a good contact on Gaia side.
:eeejay, would you like to mentor this contributor? Thanks!
Flags: needinfo?(ehung) → needinfo?(eitan)
Comment 5•10 years ago
|
||
I am not sure I entirely agree with this feature suggestion. The quick toggle allows blind users to turn on the screen reader without any sighted assistance. Having it be a pref, would make it impossible for blind users to enable the screen reader by themselves.
I see the current volume button activation useful for two cases:
1. Blind bootstrapping. Allowing a blind user to start the screen reader by themselves when first purchasing a device.
2. Quick toggle. Turning the screen on an off quickly (for developers, for blind users who hand the device to a sighted user, for visually impaired users who don't always need the screen reader, etc..)
For case 2, I think that perhaps an option like is suggested here would be good.
For case 1, I think we may need to make the key combination more obscure and hard to stumble upon. Maybe make the amount of key press successions bigger, or make it a more complex patters something like:
up-down, up-up-down-down, up-up-up-down-down-down, up-up-up-up-down-down-down-down.
Tom, is this something you would like to implement?
Flags: needinfo?(eitan)
Assignee | ||
Comment 6•10 years ago
|
||
Thank for your explanation, it's a shame that I was not aware of case 1.
I think the current key pattern is complex enough, but it still didn't prevent me from accidental activation.
Maybe we can add a confirm step after we hit the key pattern, for example, displaying a YES/NO dialog or asking user for some swipe gesture. Doing so will make the quick toggle not so quick, so a "don't ask me again" option may be needed.
:eeejay, do you think this is OK?
Flags: needinfo?(eitan)
Comment 7•10 years ago
|
||
(In reply to Tom Jao[:tjao] from comment #6)
> Thank for your explanation, it's a shame that I was not aware of case 1.
>
> I think the current key pattern is complex enough, but it still didn't
> prevent me from accidental activation.
> Maybe we can add a confirm step after we hit the key pattern, for example,
> displaying a YES/NO dialog or asking user for some swipe gesture. Doing so
> will make the quick toggle not so quick, so a "don't ask me again" option
> may be needed.
>
> :eeejay, do you think this is OK?
I think that may work too, but will be harder to implement. The screen reader would need to be on for the user to read the dialog. For a swipe, we would need to capture it.
I still think a more complex pattern would be good.
Flags: needinfo?(eitan)
Comment 8•10 years ago
|
||
Assign to Tom, feel free to deassign yourself if the final decision is too complicated to manage.
Assignee: nobody → mabolosilugia
Assignee | ||
Comment 9•10 years ago
|
||
After some thinking in this topic, I found that key issue is that users don't know screen reader is enabled and have no control of their phone. The first problem they will have is not able to unlock their phone, like bug 1116075.
Maybe we can leave the key pattern of quick toggle as it was, just think about how to notify users that screen reader is enabled and tell them how to use it or disable it. I know there will a caption if you use quick toggle, but I don't think users know how to use/disable it if they enabled it by accident.
My first idea is adding a help description on lockscreen such "Screen reader enabled, use swipe to navigate and double tap for clicking." I believe users will try every physical buttons (including power button) if they got stuck, and there are many space for displaying such description on lockscreen.
Would you give me some advices? Thanks.
Flags: needinfo?(eitan)
Comment 10•10 years ago
|
||
I think those are all good ideas. We need a "first time use" dialog and tutorial. Once that is in place I think the mysterious change of behavior would be more clear. Of course, that is ambitious and not a quick fix.
I like the idea of having some info on the lockscreen as you suggest. Lets see what Marco has to say from a usability perspective. The text might get annoying for regular screen reader users, but I think it would be very useful for everybody else.
Flags: needinfo?(eitan)
Comment 11•7 years ago
|
||
Firefox OS is not being worked on
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•