1539000 - Improve fluent/accessibility interactions (to do with placeables too long for fluent to accept) in clipboard of about config

Status: RESOLVED FIXED

(Toolkit :: Preferences, enhancement, P3)

Description

[Zibi Braniecki [:zbraniecki][:gandalf]]

Spin off from bug 1483036: we struggle with a very long clibpboard message (7k characters) being sent to Fluent which has a 2.5k chars limit for placeables.

We want to figure out the right way to resolve it, so in that bug I'm going to enable the expected rejection, and point to this bug to fix it.

Comment 1

[James Teh [:Jamie]]

(In reply to :Gijs (he/him) from bug 1483036 comment 30)

(In reply to Zibi Braniecki [:gandalf][:zibi] from bug 1483036 comment 29)

I agree with Dave. Having a screenreader attempt to read out a 7k string, either JSON or not, doesn't make sense.

I didn't realize when I wrote my previous comment that this string is only used for aria-label.

It's not correct to assume that aria-label will only be used by screen readers to be read out per se, though indeed for use with screen readers that would be unhelpful.

This was indeed intended for screen readers. See below.

TBH, I don't really understand why the aria-label mirrors the span's textcontent, which is then aria-hidden. Jamie can probably help with that.

The value needs to be exposed to AT, regardless of how long it is. A screen reader user will most likely read a long value using browse mode or equivalent, which allows them to cursor through the text. Alternatively, they might read it with a braille display.

The reason for the slightly odd implementation is that there was no other way to append the " (custom)" text (essential for a screen reader user to know whether this is a custom value) in a way which did not affect visual layout. Screen readers will ignore aria-label on a span if there is text inside it, so the text inside needed to be hidden. I guess we could use an off-screen span for the " (custom)" suffix, but off-screen text is an even worse hack IMO.

Does this really need to be a localisable string? Because we're essentially using this to indicate semantics, I don't think this is a matter of linguistics. That is, whether " (custom)" appears before or after the text is not a locale specific decision. Can we just append the localised suffix to the string without using a template?

Comment 2

[Francesco Lodolo [:flod]]

Moving over my own comment from the previous bug

b) Would it be possible to expose the custom vs default information in a different way (e.g. an accessible hidden field), and leave the actual value accessible to screen readers, without passing it through Fluent?

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

Does this really need to be a localisable string? Because we're essentially using this to indicate semantics, I don't think this is a matter of linguistics. That is, whether " (custom)" appears before or after the text is not a locale specific decision. Can we just append the localised suffix to the string without using a template?

On a related note: how confusing is that this information is appended to the actual value? There's no indication, while the information is read by AT, that "(custom)" is not part of the value itself.

Comment 3

[James Teh [:Jamie]]

(In reply to Francesco Lodolo [:flod] from comment #2)

b) Would it be possible to expose the custom vs default information in a different way (e.g. an accessible hidden field), and leave the actual value accessible to screen readers, without passing it through Fluent?

That's where I was going with the idea of an off-screen span, but I really dislike off-screen content; it just feels like a horrible hack. Still, this is pretty horrible regardless.

On a related note: how confusing is that this information is appended to the actual value? There's no indication, while the information is read by AT, that "(custom)" is not part of the value itself.

True, but I don't think there's a better solution in this case. There's no standard "semantic" for indicating that something is "custom".

Comment 4

[:Gijs (he/him)]

I mean, for a sighted user, the only reason that the bold thing works to indicate "modified value" is convention / history. It's not actually very descriptive.

It would make things a lot easier if we just added an actual column for this information.

Markus, would that be OK? Why was the column removed in the redesign?

Comment 5

[Markus Jaritz [:designakt] (UX)]

(In reply to :Gijs (he/him) from comment #4)

It would make things a lot easier if we just added an actual column for this information.
Markus, would that be OK?
Why was the column removed in the redesign?

I don't see how such a column would add information. When we reviewed the new about:config I noticed its absence, but also saw that it's information is present in the text being displayed in bold - as mentioned above, and also in the presence of a a button to "reset" or "delete". This second indicator even adds some more information - is it part of the default set of preferences, or added later. (if one can delete, it's added later)

What is the best way for screen readers to represent each entry?
I pictured it something like:
Preferences
some.preference.one true toggle button
some.preference.two false toggle button reset button
some.preference.tree 1234 edit button delete button

Am I missing any information that is not accessible that way?
Or does it need to be more explicit? If so, why?
(we are assuming users that roughly know what they are getting into)

Comment 6

[:Gijs (he/him)]

(In reply to Markus Jaritz [:designakt] (UX) from comment #5)

also in the presence of a a button to "reset" or "delete". This second indicator even adds some more information - is it part of the default set of preferences, or added later. (if one can delete, it's added later)

I mean, inferring the information this way seems less obvious to me than just having a column for it... But then, I would also like to filter by modified state and we can't do that either (bug 1502867).

I don't really understand why we don't want the additional column anymore. The current state is quite confusing, it's also not possible to see what the type of a preference is, we have to infer it from the contents (which is error prone, as for sure we store numerical values as strings in places because of data type restrictions on numeric prefs).

Or does it need to be more explicit? If so, why?

I get that inferring all these things from context makes for a less cluttered display, but it's not clear to me that the end result is better. Presumably, the goal is to make it easier for the user to interpret the rendered data, but at least for me, it still ends up taking more time to interpret the now less cluttered UI, because the information is no longer explicitly represented, only implicitly.

What is the best way for screen readers to represent each entry?
I pictured it something like:
Preferences
some.preference.one true toggle button
some.preference.two false toggle button reset button
some.preference.tree 1234 edit button delete button

I defer to Jamie for this. It's still the case that, without any additional labeling, there is more information here for sighted users than for AT users, due to the bold text representing state.

I'm going to mark as P3. Really P5 for something that's not shipping, but P3 because if we feel that the additional a11y strings are necessary, we should solve this issue before letting the new thing ride the trains.

Comment 7

[James Teh [:Jamie]]

(In reply to :Gijs (he/him) from comment #6)

also in the presence of a a button to "reset" or "delete". This second indicator even adds some more information - is it part of the default set of preferences, or added later. (if one can delete, it's added later)

I mean, inferring the information this way seems less obvious to me than just having a column for it...

I agree. You can infer the information, but that's just it: you have to infer it. It's not explicit. There is cognitive load involved in realising "oh hey, there's a reset button, I guess that means I can reset this to some earlier (presumably default) state."

What is the best way for screen readers to represent each entry?
I pictured it something like:
Preferences
some.preference.one true toggle button
some.preference.two false toggle button reset button
some.preference.tree 1234 edit button delete button

I defer to Jamie for this. It's still the case that, without any additional labeling, there is more information here for sighted users than for AT users, due to the bold text representing state.

Precisely. Let me put it this way: if screen reader users need to infer it from the button, why do sighted users need the bold state? (That assumes the bold state is explicit enough, which is controversial as above.)

Comment 8

[Markus Jaritz [:designakt] (UX)]

(In reply to :Gijs (he/him) from comment #6)

I get that inferring all these things from context makes for a less cluttered display, but it's not clear to me that the end result is better. Presumably, the goal is to make it easier for the user to interpret the rendered data, but at least for me, it still ends up taking more time to interpret the now less cluttered UI, because the information is no longer explicitly represented, only implicitly.

I have no objections in adding relevant information, clarity and speed are more important here than less cluttered display.
UX started on the assumption that the developers creating this new page knew what developers need, and what not. If people using this regularly are slowed down through anything, we need to fix that! That is true for state as well as the other things you mentioned:

I would also like to filter by modified state and we can't do that either (bug 1502867).
it's also not possible to see what the type of a preference is, we have to infer it from the contents (which is error prone, as for sure we store numerical values as strings in places because of data type restrictions on numeric prefs)

It's still the case that, without any additional labeling, there is more information here for sighted users than for AT users, due to the bold text representing state.

If it is needed or helpful for screen readers to start the line with announcing the state, we should do that!
Please say what you think is needed for screen reader and what is needed for sighted people to be efficient, and we should make it work that way.

(To me the presence of buttons also represents state. I don't see how that is less information than bold. Both are expressions of the state of the preference. But if that is not obvious enough to be efficient in the long-run, this needs to change.)

Comment 9

[:Paolo Amadini]

As a developer, I didn't find myself slowed down by the absence of the state and type columns, on the contrary for me it makes the name and value of each preference easier to see and parse at a glance. In fact, when you look for a specific preference, whether it has the default value or not (which may be different in different release channels) is much less important than what the actual value is.

Adding any purely text column to represent additional state would also make bug 1524855 unfeasible, thus complicating things a lot more. If really needed, a compromise may be to use icon columns for the additional information, but I suspect at least the state icon would look visually in conflict or redundant with the icon buttons specified in bug 1533856.

<< Side note: The only edge case for which we may miss information is the type of user added preferences that need to be numbers, since people might create them with the string type by mistake. We could have a "#" or "$" icon before the value to help indicate the type. This is an edge case because if you need to add a new preference name, you're already in the land of "we wouldn't like anyone to do this and you're on your own". >>

That said, the original problem statement of this bug was "we struggle with a very long message (7k characters) being sent to Fluent". If we're not removing the limit in Fluent, then we can have easier workarounds as suggested before. For example, we can concatenate the string without Fluent: value + space + "(custom)"/"(default)". In this case, we'd need to fetch these two strings asynchronously beforehand.

Or, without changing anything in the Fluent file, send the string "$1" to Fluent programmatically to format it, instead of the actual value, then .replace("$1", value) in the returned string and assign to the attribute asynchronously when the API call returns. We can do this only when the actual value is longer than, say, 500 characters or something like that, to prevent having lots of pending async functions with live element references.

I don't think that changing the design, with all the difficulties that it poses, is a good way of moving forward to solve the original problem statement, especially since other workarounds exists. You may argue that the design needs to be changed for other reasons, but when a clear workaround exists here, I'd encourage to file a separate bug for discussing the design, or use bug 1533856.

Comment 10

[:Paolo Amadini]

I took a look at this bug now because Zibi found out that, in automation only, this exception interrupts localization, preventing the test for bug 1529319 from landing.

Prompted by the original issue, there have been discussions on this bug on whether (1) the design of Fluent is right, (2) the visual design is right, and (3) the accessibility design is right. While there is always room for improvement, the three of them have all been extensively discussed before elsewhere and approved by the UX, accessibility, and localization teams, and I don't think the issue described in comment 0 justifies any redesign at this stage. Thus, while I considered filing a separate bug, it seems better to focus this one back to the issue in comment 0.

There are exactly two preferences that cause the exception:

• network.proxy.autoconfig_url, which is set to a "data:" URL in automation only
• media.wmf.disable-d3d11-for-dlls, which is a long list like "igd11dxva64.dll: 20.19.15.4463, 20.19.15.4454; ...; nvumdshim.dll: 10.18.13.6822"

Preferences like browser.uiCustomization.state come to mind as being long, but from what I've seen they have about 1000 characters and they don't exhibit the issue, since the Fluent limit is 2500 characters. There's always talk about keeping such long strings out of the preferences system, and even if we're not always disciplined about doing that, I don't see many new preferences coming up that would exhibit the problem.

After seeing the scope of the issue, to me the pragmatic way forward seems a two-line fix that simply doesn't place the "(custom) / (default)" indication in the "aria-label", only for the affected preferences, while still including the full value for search and inspection.

I have a patch with code comments about the general issue and a simple test case, while in the commit message I've described the exact situation we have now.

Comment 11

[:Paolo Amadini]

Attachment: Bug 1539000 - Prevent Fluent exceptions when the localized value is too long. r=zbraniecki

This is achieved by not including the offending preference state in the text provided to screen readers, while still providing the full value. It currently happens only for the "media.wmf.disable-d3d11-for-dlls" preference in new profiles, and for "network.proxy.autoconfig_url" because it is set to a "data:" URL in automation. While preferences like "browser.uiCustomization.state" might theorectically grow over the limit of 2500 characters, this may be rare as they seem to be typically around 1000 characters.

Comment 12

[:Gijs (he/him)]

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

After seeing the scope of the issue, to me the pragmatic way forward seems a two-line fix that simply doesn't place the "(custom) / (default)" indication in the "aria-label", only for the affected preferences, while still including the full value for search and inspection.

I'm still confused. The text is already present in the DOM without also adding it to the aria-label attribute. Why not have only the custom/default information in the aria-label, ie why are we repeating the label. Is that even helpful - Jamie?

As it is, your patch removes information from AT users, which feels pretty wrong, "even" if it's "only some" preferences.

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

Adding any purely text column to represent additional state would also make bug 1524855 unfeasible, thus complicating things a lot more. If really needed, a compromise may be to use icon columns for the additional information, but I suspect at least the state icon would look visually in conflict or redundant with the icon buttons specified in bug 1533856.

Or we could use a fixed-width column...

Comment 13

[:Paolo Amadini]

(In reply to :Gijs (he/him) from comment #12)

The text is already present in the DOM without also adding it to the aria-label attribute. Why not have only the custom/default information in the aria-label, ie why are we repeating the label. Is that even helpful - Jamie?

If I remember correctly, that was necessary to ensure we can copy the preference text to the clipboard, including all the whitespace but not the text indicating the state, but I'm open to suggestions if there is a better way of achieving the same effect while having the clipboard tests pass and the accessibility design approved. The number of DOM elements required should also be considered for performance.

As it is, your patch removes information from AT users, which feels pretty wrong, "even" if it's "only some" preferences.

In practice the information is removed for one preference, "media.wmf.disable-d3d11-for-dlls", and the list of these preferences is not going to increase significantly. Even if this information (carried also with the "bold" style) was removed for this rare kind of preferences for the totality of our users, the impact would be negligible. While I obviously think that this pragmatic approach doesn't put any person at a disadvantage, I'm always happy to hear from our accessibility team to know if the approach is acceptable.

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

Adding any purely text column to represent additional state would also make bug 1524855 unfeasible, thus complicating things a lot more. If really needed, a compromise may be to use icon columns for the additional information, but I suspect at least the state icon would look visually in conflict or redundant with the icon buttons specified in bug 1533856.

Or we could use a fixed-width column...

Which is what I mean by "icon column", as a localized word isn't a good fit for a fixed-width column. I also pointed out the design issues it could have, but as I mentioned I think it's more productive to focus on solutions that keep the current design.

Comment 14

[:Paolo Amadini]

I also want to clarify that the current situation in Nightly is that these two preferences don't get an "aria-label" at all, so screen readers won't read the value and the state indication.

The patch that I attached to the bug strictly improves the situation, so at least the value now appears. To me, this means we can land the patch, but we can always file a bug if we think we need a different final solution.

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fc52b9f9872f
Prevent Fluent exceptions when the localized value is too long. r=zbraniecki

Comment 16

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/fc52b9f9872f

Comment 17

[James Teh [:Jamie]]

(In reply to :Gijs (he/him) from comment #12)

I'm still confused. The text is already present in the DOM without also adding it to the aria-label attribute. Why not have only the custom/default information in the aria-label, ie why are we repeating the label. Is that even helpful - Jamie?

In this case, aria-label replaces the text content in the node from an a11y client perspective; they don't get concatenated. So, if we only had aria-label="custom", users would only see "custom"; they'd lose the value. We could do this if we had an additional node specifically for the custom/default indicator, but we don't.

Comment 18

[:Gijs (he/him)]

Adjusting summary so next time I need to find this bug it'll take me less than half an hour.