Can this be upgraded to a release blocker as it is a major loss of advertised features

To figure what to do I copied and pasted the User Accessibility form settings from user.xml to profile.xml before the closing param and I coped the A11Y ini values from com_admin.ini to com_users.ini. That works - but what about the Accessibility Settings in the user menu? Both links lead to the last open tab. So should one be removed? It all needs the ini keys changing of course. Is this the right way forward?

. Is this the right way forward?

No

. Is this the right way forward?

No

Any hints on the right way? I have a J3 site with a group of users who do not have access to com_users. They might like to set personal accessibility features via the profile form. However, they should not really have access to Basic Settings, User Actions Log Options or Joomla API Token. So I will need to create a template override. Should Accessibility go into a different view? Or layout?

the changes that broke this should be reverted. then it works as you want

I had a look at the commit that implemented the changes for #29251 and noted that both links in mod_user/tmpl/default.php (Edit Account and Accessibility Settings) changed from com_users to com_admin. I think that is right because I was among those who previously reported that it was not possible for a user without permission to access com_users to change password. So it seems to me that fixing the second link by removal is the simplest solution for now (changing back to com_users&task=user.edit needs a check that the user is allowed access to com_users).

simplest but not correct

I don't like the term (and link) for accessibility settings at all.
Why not integrate the fields monochrome, fonts and highlight links into user settings?
High contrast has no effect.

That is how it was

Here is a PR: #31884
I don't see why we shouldn't fix this issue this way. Switching it back to com_users is not a viable solution.

That's a bandaid not a fix. Not only do you end up with a lot of duplicated code but even with your proposal there are still fields missing from the com_admin version of the user data. Developers always tell me that duplicated code is bad.

Yes, duplicate code is bad, however the alternative is rewriting com_users and that is not something that I want to do (now). I also don't see which fields are missing, which a normal user needs access to.

Why not integrate the fields monochrome, fonts and highlight links into user settings?

Seems that this was a misunderstanding. With user settings I am speaking about the tabs on the screen, not about the component com_users. It is ok as it is now in com_admin.

@brianteeman Could you please take a quick look at this PR #32771 to see if it address your concern?

Closing as having a pull request. Please test #32771 . Thanks in advance.