1506382 - Make the new about:config page more easily navigable with accessibility technology

Status: RESOLVED FIXED

(Toolkit :: Preferences, enhancement, P1)

Description

[Matthias :Kammueller]

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.

Comment 1

[Matthias :Kammueller]

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 2

[:Paolo Amadini]

(In reply to :Matthias Kammüller from comment #1)
> 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

I'm not sure I understand the difference between (1) and the first solution in comment 0. It seems to me that in all the cases where we change the aria-label we'll have to use the programmatic localization API and a different way of mapping the row to the JavaScript objects, right?

Comment 3

[Matthias :Kammueller]

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.

Comment 4

[:Paolo Amadini]

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

Comment 5

[Marco Zehe (:MarcoZ)]

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.

Comment 6

[Yura Zenevich [:yzen] (please use "needinfo")]

Is there a way to see the work in progress atm?

Comment 7

[Matthias :Kammueller]

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?

Comment 8

[Yura Zenevich [:yzen] (please use "needinfo")]

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

Comment 9

[Matthias :Kammueller]

- 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?

Comment 10

[James Teh [:Jamie]]

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.

Comment 11

[James Teh [:Jamie]]

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.

Comment 12

[:Paolo Amadini]

Hm, would screen readers read the name and value when focusing the button if their cells were 'th scope="row"' instead of 'td'? Would this improve the navigation or would it be worse?

One thing to keep in mind is also that most of the time the preference names are filtered, so the number of rows to navigate would be small.

Comment 14

[:Paolo Amadini]

Jamie, is my interpretation of comment 11 correct that, while there is a difference in how the page can be explored, the basic use case of searching for a preference name, and then toggling or editing it, is still easily achievable when using screen readers?

I'm starting to think that most of the extra information we're accustomed to see in the old page may be inconsequential with regard to the real task that the user has to do with this page. And we have telemetry data that shows how the 98% use case is search and toggle, with little else being done on the page.

In fact, having a lot of extra information can be distracting. I feel the data type of existing preferences, for example, is only useful when developing new features, and Firefox developers can easily find detailed information on preferences with simple "Services.prefs" calls from any browser console, or by looking at the default preference files.

Comment 15

[James Teh [:Jamie]]

(In reply to :Paolo Amadini from comment #12)

Hm, would screen readers read the name and value when focusing the button if their cells were 'th scope="row"' instead of 'td'?

If the user was navigating by button or navigating by row through the column with the buttons, yes. I'd guess that's not a common usage pattern, though.

Would this improve the navigation or would it be worse?

While it makes sense to have the name as a row header, having the value as a row header feels inappropriate.

(In reply to :Paolo Amadini from comment #14)

Jamie, is my interpretation of comment 11 correct that, while there is a difference in how the page can be explored, the basic use case of searching for a preference name, and then toggling or editing it, is still easily achievable when using screen readers?

Yes. However, the original concern here was that the modified state is not exposed. (IMO, the presence or absence of the Reset button is not sufficient.) That is still a problem and still a regression.

Comment 16

[:Paolo Amadini]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3cefbe1f53a971f7d06ef76ee2a4df80a9c61913

Comment 17

[:Paolo Amadini]

Attachment: Bug 1506382 - Make the new "about:config" page more easily navigable with accessibility technology. r=Jamie,flod

Comment 18

[:Paolo Amadini]

(In reply to James Teh [:Jamie] from comment #15)

Yes. However, the original concern here was that the modified state is not exposed. (IMO, the presence or absence of the Reset button is not sufficient.) That is still a problem and still a regression.

The attached patch should fix this, and uses the "th" element only for the name as you suggested. Loading all the preferences is slower because we need more elements and an additional localized string, but it shouldn't be an issue since we don't display all preferences by default.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/02db4035c94c
Make the new "about:config" page more easily navigable with accessibility technology. r=Jamie,flod

Comment 20

[Oana Pop-Rus]

https://hg.mozilla.org/mozilla-central/rev/02db4035c94c

Comment 21

[Mike de Boer [:mikedeboer]]

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