Closed Bug 1506382 Opened 2 years ago Closed 2 years ago
Make the new about:config page more easily navigable with accessibility technology
Bug 1506382 - Make the new "about:config" page more easily navigable with accessibility technology. r=Jamie,flod
47 bytes, text/x-phabricator-request
|Details | Review|
One thing to think about is that we need to convey the "hasUserValue" status to screen readers also, without relying just on font weight. This may be a special aria-label on the value cell that includes "value (modified)" or "value (default)", or a hidden element after the value. In Fluent the former solution needs a string with parameters, and maybe we'll have to make the function asynchronous, so you may consider filing a separate bug for it.
I think there are three options: 1) add the "Modified" status to the aria-label of the row (that would result in the need for a map row <-> pref) 2 & 3) the options above What would you prefer, Paolo?
Comment 0 suggested to add an aria-only label behind the value. (We would not have to change the row-label in this case -> everything else would still work) Option (1) would be to edit the aria-label of the row. This would have the advantage that we can copy this concept for the locked state.
Thanks Matthias, I see the difference now. I don't actually know what would be the best way to make the state accessible. Marco, now that we have an MVP of the "about:config" page implemented in HTML, it may be a good time to think about how to make the table easy to use with screen readers. You can test it in Nightly at "chrome://browser/content/aboutconfig/aboutconfig.html". After you filter preferences using the textbox, the most important thing for us is to make it easy to navigate preferences and read or change their value. Secondarily, we're trying to convey whether a preference has a non-default value. Currently, we're using a bold font weight, and we have a reset button only for those preferences. Visually, we'd like to keep the layout simple and not add a column that spells out the state redundantly. Any suggestions on how to implement this? We had some thoughts in comment 0 and comment 1, but maybe the button presence is enough, or maybe there is another way we should structure the table, and I'd like to use this bug to fix other issues we may have at present. We currently set an aria-label on the entire row, I don't know if that is still the right thing to do: https://searchfox.org/mozilla-central/rev/3fdc51e66c9487b39220ad58dcee275fca070ccd/browser/components/aboutconfig/content/aboutconfig.js#129 I think the reason was that we split the preference name with <wbr> elements, and it resulted in multiple text leaves in the accessibility inspector: https://searchfox.org/mozilla-central/rev/3fdc51e66c9487b39220ad58dcee275fca070ccd/browser/components/aboutconfig/content/aboutconfig.js#174
Flags: needinfo?(paolo.mozmail) → needinfo?(mzehe)
I am on PTO this week and won't get to it until next. Redirecting the NI to Jamie as he's at Mozlando and immediately available to chat about this. I don't know if conveying something by font-weight alone is enough to satisfy WCAG criteria, similar to what is stated for colors. Yzen might be the best person to answer this one.
Is there a way to see the work in progress atm?
You can test it in Nightly at "chrome://browser/content/aboutconfig/aboutconfig.html" We do not have an a11y version of the modified and locked state yet since we're unsure how to do this the ebst way. Would you prefer a (modified) aria-label for the row or should it be behind the name or value of the pef?
Hi I looked at the panel briefly, having bold font for modified prefs is fine for sighted users, since it's a bit different than color information. However, the fact that its modified indicated via font weight is not accessible to screen readers. There's definitely something else that needs to happen. You can use aria-describedby to indicate that it is modified. I would suggest though consulting with someone in UX to see if they have better ideas to convey modified state rather than just bold font, perhaps an icon (that would have a text alternative and would solve the issue of indicating modified state to screen readers) of some sort (or a * prefix before the label). Also I noticed there are other things that could be improved in terms of accessibility such as, but not limited to: * labels for columns (for both screen reader and sighted users) * adding a new property row has no labelling and is an accessibility concern for sighted and screen reader users * some buttons (like a choice of a pref type) are really a radio button and not a list of buttons (at least semantically) * buttons need better labelling as they lack context (e.g. you could use aria-labelledby pointing to the row since you define an aria-label on it). * Marco should still probably see what it feels like with the actual SR
- Headers for the column will be added with Bug 1502894. - The "add a preference" functionality will probably be redesigned as a module. Thanks for the other hints! So you would add the "this preference is modified / locked" at the row, did I understand that correctly?
From the screen reader perspective, whether to put the info on the row or the colunn is complicated because the rows aren't focusable like they used to be. That itself is arguably a regression. I need to give this some thought, but haven't had a chance to do that this week. I'll try to provide some thoughts once I'm back home. Apologies for the delay.
Sorry for the delay. While this is somewhat beyond the scope of this bug, it's worth noting that this new page imposes a significant difference (regression?) from a keyboard usability perspective. (This is relevant here for reasons described below.) It's still possible to do everything from the keyboard, but it's not as intuitive. Previously, each row was focusable (using up/down arrows) and you could edit/toggle the value by pressing enter or reset/perform other actions using the context menu. Now, the individual buttons are all focusable; as a keyboard user, you must tab to navigate through all buttons (regardless of what row they're on). I'm not sure whether this is behaviour worth implementing. It's certainly possible, but it would involve a bit of work and it depends how many users are likely to care. (Also, the context menu part would probably be quite tricky.) For a screen reader user, this is usable as is (except for the indication of states), since the page gets treated as a document and the user can use table navigation commands to explore the table. The reason this is relevant here is that previously, the label on the row was the primary source of information for screen reader users, since the row got focus. Now that the row doesn't get focus, its label is irrelevant. The value cell isn't focusable either (it isn't an interactive control), so its description (aria-describedby) will not be reported by several screen readers, nor will its label. It's hard to know what to suggest here. I despise off-screen text, but it's probably the only way to do this if you don't want to impact the visual design in any way. I do wonder whether font weight (without even an icon) is intuitive/discoverable, but that's a question for UX.
Summary: Make "modified" state accessible in new about:config → Make the new about:config page more easily navigable with accessibility technology
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/02db4035c94c Make the new "about:config" page more easily navigable with accessibility technology. r=Jamie,flod
Assignee: nobody → paolo.mozmail
Status: NEW → ASSIGNED
Priority: P3 → P1
https://hg.mozilla.org/projects/cedar/rev/02db4035c94cfac1a13c0f7786ca2a258d36a453 Bug 1506382 - Make the new "about:config" page more easily navigable with accessibility technology. r=Jamie,flod
You need to log in before you can comment on or make changes to this bug.