The button to open the menu in Fennec Native on ICS needs an accessibility string so it can be found via Explore By Touch by blind users. It currently has no label and is skipped over when exploring the screen.
Created attachment 636743 [details] [diff] [review] Something like this Untested, but basically copied from setting the tabs contentDescription.
Attachment #636743 - Flags: review?(margaret.leibovic)
Comment on attachment 636743 [details] [diff] [review] Something like this It's easy to miss this, but you'll also need to add the string to strings.xml.in: http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/strings.xml.in We just use that file as an intermediary to get the strings from the dtd into Java resources, so it's a mechanical change to just use the same entity names in there.
Attachment #636743 - Flags: review?(margaret.leibovic) → review-
Created attachment 636777 [details] [diff] [review] Patch 2 Thanks, added.
Comment on attachment 636777 [details] [diff] [review] Patch 2 This looks good to me, but I'd also like Sriram to take a look to make sure I didn't miss any gotchas in this BrowserToolbar code.
Comment on attachment 636777 [details] [diff] [review] Patch 2 Review of attachment 636777 [details] [diff] [review]: ----------------------------------------------------------------- I would suggest doing this in the layout files. layout/browser_toolbar.xml layout-land-v14/browser_toolbar.xml layout-xlarge/browser_toolbar.xml layout-sw600dp/browser_toolbar.xml Anything in XML is precompiled and hence faster to load, than doing in java. And while this is done, I would suggest adding content descriptions for "back" and "forward" buttons too.
Attachment #636777 - Flags: feedback?(sriram) → feedback-
I agree with Sriram about optimizing for performance. Marco, if you need an example of how to do it in the XML, we already do it for the find in page bar: http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/resources/layout/find_in_page_content.xml#5
Thanks to you both! Any other buttons that can be interacted with that I can fix here besides menu, back and forward? I mean, while I'm here...
Created attachment 636823 [details] [diff] [review] Patch v3 Used XML as suggested. If these are all that are needed for handhelds, I could add others in the related tablet bug 758431.
(In reply to Marco Zehe (:MarcoZ) from comment #7) > Thanks to you both! Any other buttons that can be interacted with that I can > fix here besides menu, back and forward? I mean, while I'm here... The "reader", "site_security", and "stop" ImageButtons can all be interacted with, and those are available on all devices.
Comment on attachment 636823 [details] [diff] [review] Patch v3 Review of attachment 636823 [details] [diff] [review]: ----------------------------------------------------------------- This looks good to me.
Attachment #636823 - Flags: review?(sriram) → review+
Created attachment 636834 [details] [diff] [review] Patch4 I also added the other ones Margaret suggested. I also reused the "forward" entity that was already defined instead of creating a duplicate one, and I also used the reader_mode entity for the reader button. Re-requesting review to make sure this is all OK.
Attachment #636834 - Flags: review?(sriram)
Comment on attachment 636834 [details] [diff] [review] Patch4 Review of attachment 636834 [details] [diff] [review]: ----------------------------------------------------------------- Aah right! Forward is already there with menu items. So, could you move the entities to be with Forward, so everything stays together? Also, since we do "@string/forward", could you rename everything to be consistent with it? Like "@string/menu", "@string/back" and so on. r+ with these changes.
Attachment #636834 - Flags: review?(sriram) → review+
Pushed with requested changes to inbound: http://hg.mozilla.org/integration/mozilla-inbound/rev/ad3bf1e13093 Thanks!
Target Milestone: --- → Firefox 16
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Axel - does a11y have localization? Is this a concern for uplift to aurora?
Yes, the patch has l10n impact, and that's raising a concern for uplift.
I believe this could become even more of a concern once I verify the fix in today's Nightly build, and request approval for Aurora for the patch. If the patch is not taken, the initial accessible Firefox for Android release would be left with a lot of controls inaccessible to blind users on touch-screen-only devices. However, having said that, if they were in English for some languages in the initial release, that would still be OK. These strings don't show up anywhere visually, they just get spoken by the text-to-speech engine on the Android device.
Verified the fix in Nightly/Android 16.0a1 (2012-06-28). The Menu button and others, if visible, are now accessible with TalkBack's Explore By Touch feature in ICS.
Status: RESOLVED → VERIFIED
Created attachment 637444 [details] [diff] [review] Patch re-based for Aurora [Approval Request Comment] Bug caused by (feature/regressing bug #): None, neglegance in initial implementation of Native Android UI. User impact if declined: Blind users on Ice Cream Sandwich will not be able to find the unlabeled buttons via Explore By Touch. In essence, they won't be able to open the menu, for example. Firefox 15 will be the first accessible release, and while web content won't support the Explore By Touch feature yet, the native UI will. Without this, users will have a hard time setting up Sync and do any other adjustments or access basic functionality like bookmarking pages etc. Testing completed (on m-c, etc.): Yes. Risk to taking this patch (and alternatives if risky): None. Just addition of invisible strings and properties in XML files that are only effective when TalkBack, the Android screen reader for the blind, is running. The strings are being spoken as the labels for the buttons. String or UUID changes made by this patch: Addition of 4 localizable strings that get spoken by a text-to-speech engine, but never displayed on the screen.
Assignee: nobody → marco.zehe
Attachment #637444 - Flags: approval-mozilla-aurora?
[triage comment] definitely a usability issue for people relying on explore by touch and we do want everyone to be able to set up sync. I'm for approving for Aurora and I trust that this localization can be managed in time before this gets to release.
tracking-firefox15: ? → +
tracking-firefox16: ? → +
Attachment #637444 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
FYI, l10n just won't bother with this change. Marco, mind posting a note to .l10n on why you're landing this? Note, having string freeze breaks at this point is a clear sign of problems earlier in the cycle.
Pushed to Aurora: http://hg.mozilla.org/releases/mozilla-aurora/rev/5b386b3d56d8
status-firefox15: affected → fixed
(In reply to Axel Hecht [:Pike] from comment #21) > Note, having string freeze breaks at this point is a clear sign of problems > earlier in the cycle. Yes, the problem was only discovered when I got my Galaxy Nexus (an ICS device without a hardware menu button) that actually showed me the problem. But as I stated earlier, if in a first accessible release the spoken strings are in English, it's better than not being able to discover them at all. Note that these strings are already in Nightly/central for 16, so translators should be able to pick them up easily if they haven't already.
You need to log in before you can comment on or make changes to this bug.