This is a regression, don't know how recent. STR: 1. Turn on screen reader. 2. Bring up an edit field, for example the search bar on the home screen. 3. Touch the shift key. Expected: Should be spoken as "shift toggle button". Actual: Is spoken as "shift pressed toggle button". 4. Double-tap twice to toggle on and off. Result: Screen reader will always insist that the button is pressed even when it actually isn't. At some point, the aria-pressed refresh on the shift key got broken. [Blocking Requested - why for this release]: The screen reader needs to know whether the shift key is pressed or not, in essence, if they are entering a capitalized letter or not. Since we don't indicate it when speaking the letters themselves, the status of the shift key is the only way to find out.

Triage: regression, blocking. qawanted branch check for 2.0, thanks.

This issue does occur on 2.2 KK Flame, 2.2 Flame on the v123 JB base, 2.1 KK Flame, and 2.2 OpenC. Environmental Variables: Device: Flame 2.2 BuildID: 20140916133056 Gaia: e2d70bee03b5380ac327a145e5d694fb2443f018 Gecko: 55b46de164d8 Version: 35.0a1 (2.2) Firmware Version: v165 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 Environmental Variables: Device: Flame 2.2 BuildID: 20140916133056 Gaia: e2d70bee03b5380ac327a145e5d694fb2443f018 Gecko: 55b46de164d8 Version: 35.0a1 (2.2) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 Environmental Variables: Device: Flame 2.1 BuildID: 20140916125456 Gaia: 47939f4c41d0c941e5047e5d1af74a79b7d8e0d5 Gecko: fe591acbe83b Version: 34.0a2 (2.1) Firmware Version: v165 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Environmental Variables: Device: Open_C 2.2 BuildID: 20140915201445 Gaia: e2d70bee03b5380ac327a145e5d694fb2443f018 Gecko: 0e581e529fd6 Version: 35.0a1 (2.2) Firmware Version: P821A10V1.0.0B06_LOG_DL User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 Issue does not occur on 2.0 KK Flame. Environmental Variables: Device: Flame 2.0 BuildID: 20140916091857 Gaia: 95314e27da38b8c4edf965a77eded16cc5729ea8 Gecko: 5ecb32d79d03 Version: 32.0 (2.0) Firmware Version: v165 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 On the 1.4 KK Flame Base v165 the button does not prompt any screen reader output.

Broken by bug 1035062, specifically, the commit labelled Part V. https://github.com/mozilla-b2g/gaia/commit/f07f52c29d3720e06bf2847fe556965c097b1c4f#diff-3

:eeejay, question for you: Please read the link above. I can fix this bug, but it looks like "aria-pressed" attribute does not differentiate between upper case and upper case locked. Is there another property for that we could stick into the patch in this bug? If not I would just restore what's done before. Fortunately this bug does not break 2.1 string freeze!

Please read the comment above regarding aria-pressed.

Comment on attachment 8490511 [details] mozilla-b2g:master PR#24121 Unfortunately there is no way to test this except further lengthen the time it takes to run Gij -- so here is the tiny fix.

Comment on attachment 8490511 [details] mozilla-b2g:master PR#24121 r=me, thanks.

(In reply to Tim Guan-tin Chien [:timdream] (OOO ~Sep 19) (MoCo-TPE) (please ni?) from comment #4) > :eeejay, question for you: > > Please read the link above. I can fix this bug, but it looks like > "aria-pressed" attribute does not differentiate between upper case and upper > case locked. Is there another property for that we could stick into the > patch in this bug? If not I would just restore what's done before. > > Fortunately this bug does not break 2.1 string freeze! I think for now, and for 2.1, we should just fix this regression and use aria-pressed for both upper case and caps lock. But generally, this is a good question. We should have a way to indicate that it is locked as well.

master: https://github.com/mozilla-b2g/gaia/commit/01fba5d91db2517a43ce1607ba7ea3ec5597bcf0

Comment on attachment 8490511 [details] mozilla-b2g:master PR#24121 [Approval Request Comment] [Bug caused by] (feature/regressing bug #): Regression of bug 1035062 [User impact] if declined: Screen reader will failed to indicate press state of the shift key [Testing completed]: Test done locally with inspector [Risk to taking this patch] (and alternatives if risky): Small. Simply update one line of code that wasn't updated in bug 1035062. [String changes made]: None.

v2.1: https://github.com/mozilla-b2g/gaia/commit/d71b794daec51059db93c7485e6bf65046eed2dd

This bug has been verified to fail on Flame 2.1. Issue steps: 1. Turn on screen reader. 2. Bring up an edit field, for example the search bar on the home screen. 3. Touch the shift key. **Spoken as "shift toggle button". 4. Double-tap twice to toggle on and off. Expected: Upper case can be locked. Actual: Cannot lock upper case. See attachment: Verify_Video_Flame v2.1.MP4 and logcat.txt Reproducing rate: 5/5. Flame v2.1 version: Gaia-Rev afdfa629be209dd53a1b7b6d6c95eab7077ffcd9 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/dc3018cbdbe6 Build-ID 20141123001201 Version 34.0

Hi Mike, Per talk, please help handle v2.1 bug verified by Marigold. Thank you.

Verified again with v2.1, from comment 0, original problem is spoken in incorrect string Now it can distinguish "shift toggle button" and "shift pressed toggle button" normally Gaia-Rev 5372b675e018b6aac97d95ff5db8d4bd16addb9b Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/f34377ae402b Build-ID 20141126161202 Version 34.0 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141126.193631 FW-Date Wed Nov 26 19:36:42 EST 2014 Bootloader L1TC10011880