Unless we expect every other template to follow the same settings, this is totally wrong.

Yes I would like the two or three other possible admin templates to follow the same settings. My 2c

Unless we expect every other template to follow the same settings, this is totally wrong.

Yes I would like the two or three other possible admin templates to follow the same settings. My 2c

Then they need to be advertised as system settings. If they are template related settings for a specific template, then core should be following the same practices that the ecosystem must follow, and the ecosystem doesn't get to stuff their settings directly into a core component.

Then they need to be advertised as system settings

That! Also rename it to Accessibility options and name them carefully

PS. @C-Lodder already mentioned it elsewhere that these settings ARE OS wide and thus there is no need to pamper the users with such plugins (the js thingy that renders the setting this plugin is moving around). Also it's a very good idea to ask some people with disabilities if such things are helpful to them (the answer is no because they use the browsers css override or other higher level solutions. In sort Joomla is solving a non existing problem, not the first instance...)

Remove Accessibility Settings from User Menu dropdown when plugin is disabled.

I see no reason to move a11y settings for the template out of the user options into a plugin, basically every template should use them (at least in Europe).

@HLeithner actually they could use the plugin instead

In my previous comment I've mentioned that disabled people are using higher level solutions (eg Browser plugins). Here is the proof, dyslexic people override the fonts: https://speakerdeck.com/ninjanails/death-to-icon-fonts

Don't try to solve non existing problems because someone assumes. COVID19 teach us something: read and the data and act upon them, Joomla didn't even collected any data to make such wild assumptions...

PS if you want to make Joomla truly ACCESSIBLE then DROP the Font Awesome ICON and use their svgs. You're already inaccessible for dyslexic people that will override the fonts.
In sort solve real problems not unicorn ones...

Sorry but that is not 100% correct - I was under the same misapprehension myself until relatively recently. People with permanent disabilities will of course try to implement higher level solutions but not all disabilities are permanent.

@brianteeman all I'm saying is Joomla has bigger fish to fry to be accessible (eg the icon font!!). The widget is questionable. AFAIK gov.uk is totally accessible without any fancy widget

The below refers to the colour settings only:

Permanent or not, if you have a disability, you don't go to the settings for each individual site you use and change to greyscale, high contrast, etc.
You use software or change at OS level (normally the latter)
Even some modern monitors have these types of settings.

Windows 10, MacOS, Android and iOS all have colour filters:

• Dark mode
• Greyscale
• High contrast
• Protanopia
• Deuteranopia
• Tritanopia

By all means, keep whem if you want, but if you're going to do it, do it properly and support the 4 other critical ones.

I am not commenting further on this as you have misunderstood the objective of these settings.

Enlighten me on the objective of them then...

Please add to the list of core extensions

Should these settings be displayed/editable on the frontend in edit profile since they are only applicable on the backend?

Maybe. Users can select backend template and language in frontend.

Please fix conflicts.

Please fix display value of 1.

Just an idea:
Alternatively to use the plugin, we could extend templateDetails.xml markup to have something like <userParams> tag with fieldsets of User specific settings, and then User model will load it to an user Params form. This will work across all templates without extra plugin.

I have tested this item ✅ successfully on 965a652

I have tested this item ✅ successfully on 965a652

RTC

Want to go on record saying that for me the renaming of this plugin (removing any connection to accessibility) is wrong.
Removing the resulting accessibility option link from the user profile is wrong (that was in the very first design of j4)

As it is right now it makes no sense. The description is that this is for per user settings of the atum template so I would therefore expect to see the same options in the atum template itself for default settings and vice versa.

This is just wrong.

Want to go on record saying that for me the renaming of this plugin (removing any connection to accessibility) is wrong.

Language strings can be changed.

Removing the resulting accessibility option link from the user profile is wrong (that was in the very first design of j4)

This can be added in a layout override for Atum.

The description is that this is for per user settings of the atum template so I would therefore expect to see the same options in the atum template itself

These can be added. Monochrome option is already present in template params.

@Fedik make a PR if you want.

If you have to say "these can be added" then this can not be RTC. Don't just remove functionality and expect someone else to put it back.

I think we need to have a common decision on this topic before doing changes here, instead of when everyone doing something own.

I found that my idea also not much good, because then we need to store the params for every template style,
eg $userParams[template][blablaTemplate][styleId] = [.. user params for the template style...]

For now, I think, I would keep it as it is now (in User params), there no big reason to rush it while the beta state. We can back to the topic in a future, in one of 4.x

PR updated.

#29226 (comment)

since we #31884 is merged we don't need this pr any longer thanks for your time creating this anyway!

#31884 is not related to this.