It's a valid accessibility to add a % increase
I can't imagine any accessibility case for decreasing the font size

That's not saying there isnt a case for setting the font size just that accessibility options is not the correct place to set a decrease

I agree to the decrease like @brianteeman said - Can we have a value slider or a num field to set the increase, then you would not need to add severall percentages? Or is the dropdown more accessible?

any of those can be accessible

I can't imagine any accessibility case for decreasing the font size

There is a use case. Unfortunately I cannot describe it in English and dn't have the ophthalmologist vocabulary. There are people who can see only a small area like at the end of a tunnel. They try to make fonts small so that they see more in the small area they can see.

I can't imagine any accessibility case for decreasing the font size

I understand but why not use this parameter? Why to add another one (in case, there is a demand for such feature) . You can add new feature (decreasing) with only adding new values to current parameter.

Having smaller font size means for somebody displaying more content on screen (without scrolling, moving, etc).

There is a use case. Unfortunately I cannot describe it in English and dn't have the ophthalmologist vocabulary. There are people who can see only a small area like at the end of a tunnel. They try to make fonts small so that they see more in the small area they can see.

Yes, and I don't think, extending plus values by minus values is something complicated and may bother someone.

So what about a num field for percentage input? It's probably most flexible?

So what about a num field for percentage input? It's probably most flexible?

There is a range form field in Joomla! (HTML) but it does not display values:

@chmst valid point

So what about a num field for percentage input? It's probably most flexible?

You can even add own values (text form field), but then you need to completely overwrite this feature, because there is no option to add own values to static CSS file.

I'm a little confused as to why this is a com_users option but the styling is part of the template. Either this option should be moved to the template or the styling should go in a core SCSS file and be imported via the template

I'm a little confused as to why this is a com_users option but the styling is part of the template. Either this option should be moved to the template or the styling should go in a core SCSS file and be imported via the template

It's because it's user specific style change for accessibility.

That's fair enough. But then if I install a 3rd party backend template, this setting will most likely not work unless the developer uses the same CSS.

I'm a little confused as to why this is a com_users option but the styling is part of the template. Either this option should be moved to the template or the styling should go in a core SCSS file and be imported via the template

Hmmm, I think, a strategic decision must be made here. Will all accessibility parameters be bound to the template? If yes, parameters should be moved to template. If no, even if it's technically bad (affecting the template by the component), it should stay where it is for now.

What about a Template style select in User settings and the possibility to add a new template style easily from there? For this every backend user would need to have the rights to create a new style. It would not be a11y settings but style settings in general but solve the need for customisation? The settings that are there now would have to move to template styles in a seperate tab named accessibility?

Any comments on how these settings compare to Accessibility plugin? Do we need both?

Any comments on how these settings compare to Accessibility plugin? Do we need both?

I by myself don't know, the purpose of this PR was just extend current existing parameter "increase font size" by more options (instead of YES/NO)

Why there are two accessibility settings (one core in user profile, second plugin), hard to say.

In fact, if there will be not the core option, this PR does not make any sense more.

We have discussed this at JAT and we think the option to reduce the font size is not needed. The font size is small enough so that the case of people with tunnel vision does not apply here. Also there is a browser mechanism that allows you to freely adjust the font size. Also after checking, this is not required by any success criterion as there is no such requirement in Functional Performance Criteria.

We have discussed this at JAT and we think the option to reduce the font size is not needed. The font size is small enough so that the case of people with tunnel vision does not apply here. Also there is a browser mechanism that allows you to freely adjust the font size. Also after checking, this is not required by any success criterion as there is no such requirement in Functional Performance Criteria.

Does this mean, decreasing text size will even be removed from Accessibility plugin?

We have discussed this at JAT and we think the option to reduce the font size is not needed. The font size is small enough so that the case of people with tunnel vision does not apply here. Also there is a browser mechanism that allows you to freely adjust the font size. Also after checking, this is not required by any success criterion as there is no such requirement in Functional Performance Criteria.

The accessibility rule is that a user should be able to resize the text. Although it doesnt specifically state decrease in size in the techniques for satisfying the criteria it states a button to increase and decrease. In the additional document Accessibility Requirements for People with Low Vision it does explicitly state the need to reduce the text size.

The font size is small enough so that the case of people with tunnel vision does not apply here

Wow - I didn't know we had medical experts on the JAT - thats an awesome improvement. Seriously I am sure in the cold light of day reading what you wrote again you will realise that was a silly statement.

there is a browser mechanism that allows you to freely adjust the font size

A browser mechanism is not an accepted method for passing any criteria.

The technical issue mentioned by @C-Lodder also applies to the one font size which can be set right now without this PR, that it's a user setting which is wort nothing if a 3rd party template doesn't support it. This PR here doesn't change that, and it doesn't make anything worse in this aspect.

Regarding accessibility: I am not an accessibility expert, but I don't think that there are rules telling we have to use only a normal and a large size like now, but are not allowed to have more choices like this PR adds with a small and easy code change. And for me it is perfect for accessibility if that can be adjusted on user level. So to me this PR seems to be an improvement.

If there is anything wrong with accessibility settings on user level in J4, then it is wrong with and without this PR.

So I see no reason to block this PR with a discussion which leads far away from what this PR does.

Decreasing font size is not required by WCAG, this is true. And I surely will not decrease font sizes with my old eyes :).

But - why don't we name these settings "Personal settings". We could do here so many things, it must not be for disabled. So everyone could set font size as he/she likes and it does not matter if it is set due to disabilities or personal preferences.

BTW the purpose of this PR/idea is to somehow improve the potential of one parameter. The parameter itself just sets the font size to 18px which is really absurd. If we already have such a parameter, why not use more values. Because parameters are here to allow different settings. Limiting them to only one value does not make sense.

But - why don't we name these settings "Personal settings".

Removing the words accessibility is fine by me. But if we do that as we already have a tab called basic settings how about either calling it advanced settings or merging the fields into that tab

Limiting them to only one value does not make sense.

I have no idea why I originally wrote this feature with that font setting - there must have been some document I was following but I don't remember and now it doesn't seem logical

I have no idea why I originally wrote this feature with that font setting - there must have been some document I was following but I don't remember and now it doesn't seem logical

So, if you are the author of the original parameter, you are the only one here who can say:
a) Yes, it can be extended because it does not break the original function
b) or No, it cannot be extended because it breaks the original function

:-)

I like the idea of integrating the accessible settings into the basic settings. And removing the accessibility .. . Some people like monochrome - but not due to a disability. So this seems better "inclusive".

So how about having a Template style setting in the User Settings?

So how about having a Template style setting in the User Settings?

There's already an option for that (only for backend though).

If these options are kept, they'll have to be moved to Atum's accompanying plugin.

What plugin?

If these options are kept, they'll have to be moved to Atum's accompanying plugin.

Yes you are right, so it would be good to make it more userfriendly to create a personal style and save it directly in the profile. Actually some less clicks than clicking on: system, template styles, copy style, set up, user profile, select style

Hi @PhocaCz thank you for your idea.

As the branch is deleted and the approach should be a more comprehensive enhancement, I'll close it here.

But probably you could open a discussion here to get something going?