Closed Bug 649929 Opened 9 years ago Closed 9 years ago
Improve screen reader readability of the Help/About window
Screen readers that use fuzzy logic to try and determine the text associated with each deck panel of this window currently grab stuff from various sources which is not always accurate. This is to improve the semantic markup used in the XUL of this window to tell screen readers what we actually want read. As a side, it will also fix the label/menulist association of the update channel choser, this is currently missing the control attribute.
Try-server builds will appear here: http://firstname.lastname@example.org
1. Add WAI-ARIA magic to the various panels to make them read the text in proper order. Some don't need the magic, since there is only one text child, which is OK. 2. Also, properly label the combobox for the update channels, and make sure to assign the description for each channel, so it can be read by screen reader users when asking for the focused item, without them having to navigate around and look for the channel description themselves.
Assignee: nobody → marco.zehe
Status: NEW → ASSIGNED
Comment on attachment 525966 [details] [diff] [review] Patch try-server run completed with only two random oranges in reftests. The one thing I couldn't test is the association of the description to the combobox of the channel selector. Gavin, is this approach correct in principle?
Comment on attachment 525966 [details] [diff] [review] Patch I think you should be able to just have the one line from setAccChannelDescription added directly to selectChannel. setChannelMenuitem triggers a select event which in turn calls selectChannel, so you shouldn't need to call it explicitly in gChannelSelector.init(). Should the code in gChannelSelector.init() prepend "currentChannelText" to the detailsBox's aria-describedby when it unhides that description? (I'm not sure I understand why that aria-describedby or the one on the dialog are necessary - shouldn't things be "described by" their visible labels/descriptions automatically?)
(In reply to comment #4) > I think you should be able to just have the one line from > setAccChannelDescription added directly to selectChannel. setChannelMenuitem > triggers a select event which in turn calls selectChannel, so you shouldn't > need to call it explicitly in gChannelSelector.init(). Thanks for the clarification, fixed locally! > Should the code in gChannelSelector.init() prepend "currentChannelText" to the > detailsBox's aria-describedby when it unhides that description? (I'm not sure I > understand why that aria-describedby or the one on the dialog are necessary - > shouldn't things be "described by" their visible labels/descriptions > automatically?) The label/accessibleName is the initial label that appends/prepends the actual select. That's the stuff that gets spoken automatically by screen readers. The description below that, the one that talks about the cutting edge stuff or the "stable code", is additional info that gets put into the accessibleDescription of the combobox object. NVDA reads this automatically on focus, others read it when asked for the info. It's info you might want to hear, but do not necessarily need to hear each time the element gets focus. So accName is what's spoken always, accDescription is additional info that is optionally spoken *after* the name and current value. So no, the texts as they are now will be fine, they will all be spoken once, and no redundandy is necessary. The same goes for the tab panels: Screen readers have a fuzzy logic that tries to determine which of the text children *might* be the description for the panel. By setting aria-describedby explicitly, we can prevent them from applying the fuzzy logic, and explicitly control what they'll speak to the user when focus enters the tab panel.
Comment on attachment 525966 [details] [diff] [review] Patch Thanks for the explanation! Looks good to me with that change, but I'd like to see the final patch before r+ing.
Attachment #529444 - Flags: review?(gavin.sharp) → review+
Landed on nightly: http://hg.mozilla.org/mozilla-central/rev/f6ae3b6615f2
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 6
Thanks! This is much nicer. :) Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110503 Firefox/6.0a1
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.