When updating my nightly build from 8.0a1 to 9.0a1, I got the dialog saying "Disable add-ons you no longer use". There is a series of checkboxes I can tab through, and none of them have accessible names. I suspect these somehow label the different add-ons, but the link between the checkbox and the corresponding label isn't there. Thus, screen reader users have no way of knowing which ones are checked or not.
Somewhat related to this: clicking the labels also doesn't (un)check their corresponding checkboxes.
(In reply to Dão Gottwald [:dao] from comment #1) > Somewhat related to this: clicking the labels also doesn't (un)check their > corresponding checkboxes. Filed bug 680363 for this.
Also somewhat related to this, there's no keyboard focus indication outline.
Created attachment 554825 [details] Checkbox mockup I used DOM Inspector to rearrange the document resulting in this mockup. The checkboxes are now real checkboxes so that would help with both screen reader and keyboard accessibility. I'm not sure what to do about a long translation of the word "Keep" though. (Currently it would just push the "Name" header over...) The other alternative I was pondering was replacing the grid with a tree, however in this case it wouldn't be possible to eat into the icon space with the "Keep" header.
(In reply to firstname.lastname@example.org from comment #4) > Created attachment 554825 [details] > Checkbox mockup > > I used DOM Inspector to rearrange the document resulting in this mockup. > > The checkboxes are now real checkboxes so that would help with both screen > reader and keyboard accessibility. > > I'm not sure what to do about a long translation of the word "Keep" though. > (Currently it would just push the "Name" header over...) I guess we could just have a hidden label for the checkboxes and then somehow hide the actual name label from accessibility tools? > The other alternative I was pondering was replacing the grid with a tree, > however in this case it wouldn't be possible to eat into the icon space with > the "Keep" header. Last I checked the checkboxes in trees looked decidedly non-native too, otherwise I'd have loved to use a tree here, it would have saved a lot of problems.
Who can fix this?
tracking-firefox8: ? → +
Created attachment 562399 [details] [diff] [review] Patch v1 Sometimes, the simplest of solutions works. Tested using NVDA. Patch also adds focus indication on the checkboxes (and only the checkboxes, to save re-doing a lot of the code).
Assignee: nobody → bmcbride
Status: NEW → ASSIGNED
Attachment #562399 - Flags: review?(robert.bugzilla)
Comment on attachment 562399 [details] [diff] [review] Patch v1 Didn't review beyond a casual inspection and it looks fine. I'd prefer it if someone that works on theme code more than I reviewed the css and I am fine if the checkboxes now have a tooltip but if they do you should make sure UX is ok with it.
Attachment #562399 - Flags: review?(robert.bugzilla) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla9
Comment on attachment 562399 [details] [diff] [review] Patch v1 Should probably have this on beta (ie, 8), since that's the first version people will see this dialog. Simple patch - main part is just adding a tooltip. But it makes a huge difference to the accessibility of the dialog.
Hi guys. How can I verify this? It's enough to update from nightly build 9.0a1 to 10.0a1 and see that the checkboxes are functional? Thanks
(In reply to Vlad [QA] from comment #12) > Hi guys. > How can I verify this? It's enough to update from nightly build 9.0a1 to > 10.0a1 and see that the checkboxes are functional? > Thanks Before the upgrade make sure that extensions.shownSelectionUI is false and it'd be ideal to upgrade with a screenreader installed as Blair did to make sure it is reading things out correctly.
Marco, would you be so kind to verify this fix? You are the reporter and probably the best person here for this task. Thanks so much.
Meant to verify this after I upgraded to 10.0a1, but got distracted. This is definitely fixed in the 10.0a1 nightly builds. Current build identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111007 Firefox/10.0a1
Status: RESOLVED → VERIFIED
https://hg.mozilla.org/releases/mozilla-beta/rev/46691e6ce598 (This was already on Aurora, as it landed on Central before the last merge.)
You need to log in before you can comment on or make changes to this bug.