Drop the font size increase preference

Development
#1

Context

Hello!
When working on the implementation of the new accessibility preferences, it became apparent that the font-size increase that we supported previously in the Extra accessibility user preference was not possible to update without a lot of changes to the codebase.

Vote object

Drop the font size increase preference from xwiki standard flavor.

Clarifications

Here are a few pros and cons I identified related to this vote object:

(+) The former implementation did not consider the color theme font-size into account. If the wiki admin already set a large font-size-base, the users with accessibility extra turned ON could have smaller text than the regular user.
(+) The former implementation is nearly impossible to extend. It relied on loading a new CSS depending on the user preference. This could end up quite a large cost if multiple preferences with multiple options take this architecture. This and over details in our font-size system brought a lot of technical debt. See the discussions on the PR for XWIKI-21492, especially this one, as a proof of this technical debt.
(+) Most users nowadays are already used to playing with the zoom level of the page (Ctrl + +) to fit their preferences. This feature can be useful (understand “better than nothing”) for some users but I don’t see many cases where it would be critical for the user experience.
(+) The extra accessibility feature was outdated and we did not receive many user reports regarding it (if any at all?). In my opinion this is a hint that the feature was not used a lot. Removing a part of this feature would not impact many users (and as said above, not in a critical way, there’s easy ways around this feature regression).
(+) The object of this vote influences only the display, I don’t see it breaking any extension or custom code.
(-) It’s a regression on feature.
(-) It can impact the user experience of any regular user of XWiki (not only admins or devs).

Opinion

I think the pros far outweight the cons, and for the sake of updating the extra accessibility feature without introducing even more tech debt I think this feature should be dropped.
Note that adding this feature back could be an improvement we consider later down the line, but :

  • it’s not a critical one
  • it could overlap with modern browser features (need to check if it’s actually relevant or an alternative solution would fit better)
  • we need to define and apply new best practices in order to avoid it being a large technical debt.

For what it’s worth, here’s my +1 :slight_smile:

Conclusion

Did you find out additional pros and cons related to this proposal?
Do you agree with the object of this vote?

Thanks in advance for your inputs!
Lucas C.

#2

I’ll close the vote at 6PM on next Friday, March the 29th :slight_smile:

#3

Hi,

AFAIU the feature is not working most of the time but is it working with the standard theme?
Also in 14.10.x the UI setting is
image

so my understanding is that only underline links would remain as accessibility setting? is that correct?

#4

It works with the standard theme but there’s a major bug on it that wasn’t even reported (I’ll create a ticket for it if we decide to keep the feature in). Some of the text is not getting bigger even with the setting turned ON.
pretty much only page content and panel content are updated in size. The size of the last modified by... info is still smaller than the regular size :confused:
Here is the same page, with the extra accessibility setting turned OFF (left) and ON (right). Same display conditions.
image

Yup :+1:
I’d like to update our underline link options, but currently it’s been stuck in a PR for a while mostly because of the difficulties that come along with trying to update the font-size change cleanly.

#5

Ok so if there’s a major bug it’s not really working even there :slight_smile:

So I’d be +0 to remove it: it does sound like an interesting feature if it’s properly implemented, but indeed better remove it if right now it’s not working at all and we don’t plan to fix it soon.

#6

Some history (FWIW):

  • Feature added by Sergiu in XWiki 2.5M2 → XWIKI-5543
  • Admin UI added in XAADMINISTRATION-172

There doesn’t seem to be any open jira issue about “extra accessibilty”. Either it’s not used (as Lucas mentioned) or it’s used but working satisfactorily enough for the users.

Indeed, I don’t see what this feature is bringing over the browsers zoom features. It seems it’s even possible for users to ask the browser to remember the zoom level for a domain (works on Chrome at least but probably on FF and other browsers too).

So +0 from me too to remove it. Will need to be documented in the release notes.

It could have been nice to ask in the user category if anyone is using this feature and what they’d say about removing the feature in favor of the browser zoom feature. If it’s not used, we should not get any answer…

Technically, would you remove the “Extra Accessibility” xproperty in favor of an explicit “Enable Link Underline” one?

Thanks

#7

I can confirm it works on FF too :slight_smile: It even updates the zoom level of other windows of the same domain live.

I’ll open a new topic for the few days left before the vote ends :+1:

Yup, this is the solution our discussions on XWIKI-21492: Underline inline links by Sereza7 · Pull Request #2694 · xwiki/xwiki-platform · GitHub converged to :slight_smile:
We made sure backwards compatibility is kept so that it doesn’t break anything or force users to set their preferences again.

Thanks for your feedback!
Lucas

#8

Thank you for your feedback!

There are two +0.
The vote is not passed but there’s no veto.
I’ll go along with the implementation and we’ll continue with the lazy consensus procedure that would happen if no vote was made. That means reverting the changes if someone is against them.