Not a fan of this

my 2c is that I don't see the need for this pr - others may disagree

@brianteeman If possible, I would like to better understand your concerns about the pull request, and in particular, whether your concern is about the entire issue or just a specific commit. This would help me to address any concerns you may have and ensure that my work aligns with the goals and objectives of the issue. I value your input and would appreciate any feedback you can provide.
Thank you for your time and consideration. I look forward to the opportunity to continue contributing to the success of Joomla!

A toggle switch like this really only works when you have two opposites because you can assume the hidden value that will be revealed from the displayed value. eg Yes/No, Show/Hide

#39787 (comment)

For the component login the option is only available if you create a menu item for login but it is not required for you to create a login menu item for the login to be displayed.

What this means in real terms is that without a menu item the component will use the default values in the view.

Before this PR that meant the login and password field were displayed with a label and without a placeholder.

With this PR the login and password fields are not displayed at all unless you create a menu item (or if you already have a menu item then you must open and save it again). This is because there is no default value in the view for login_label so the if fails to match either of the conditions.

In the module before this proposal if you chose Text then you have visible text labels and placeholders

If you chose icons then you have visible icons and placeholders

With this proposal if you chose Text then you only have visible text labels

If you chose placeholder then you have one visible icon and placeholders

So now it is no longer possible to have visible labels and placeholders and a user will not expect their site to be changed in this way on update.

Thank you for bringing this issue to my attention. I understand that the change in the display of the labels and placeholders in the login component may not be what some users expect after updating the software.

The change was made to improve the user experience by streamlining the login process. However, I can see how this change could cause unexpected behavior for some users. As a solution, I propose adding an option to switch between displaying only labels, only placeholders, or both. This way, users can choose the display that works best for their needs.

Would this solution address your concern, I hope I am getting you right and do you have any further suggestions?

How do any of these changes streamline the process? I don't understand

By removing the label and placeholder text, we can reduce visual clutter and make the login process more efficient. If the labels and placeholders displayed the exact same text, then having both visible might not provide much additional value to the user. In such a case, having one or the other (either the label or placeholder) might suffice. Also a potential solution to the issue you've described is to add a default value in the view for the login_label. This way, if there is no menu item created, the toggle switch component would have a default value to fall back on, ensuring that the login and password fields are displayed even if a menu item is not created.

You are talking about user experience, but forgot about accessibility... Reducing visual clutter is thinking only about "visual" users. If you only use placeholders you introduce an issue for user with cognitive impairments and they are not always available for assistive technologies.
https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Placeholder_Research

In addition the code is wrong, if you select placeholders the label is still being rendered, but it is empty.

Thank you for bringing up the issue with accessibility @drmenzelit . I agree with you now that reducing visual clutter is not a one-size-fits-all solution and accessibility should always be a priority. In regards to the code, I apologize for the mistake. Can you suggest an ideal solution that would address both the visual clarity and accessibility concerns? I would greatly appreciate your insights and expertise on this matter.

If you use placeholders, the label should be still present but visually hidden. You can check the login module, there it is correct.

I'm pinging @crystalenka an @angieradtke from UX team, please give your opinion on that.

Thanks for tagging me, @drmenzelit !

@charvimehradu, I appreciate your attention to these things and your ideas to improve the user experience! I know that we are reviewing your PR pretty thoroughly; please know your work here is appreciated and I hope to see more contributions from you in the future. :)

Regarding placeholders and labels:
It's important not to confuse visual clutter with important context. In additional to the points raised by Viviana about people using assistive technology on the web, accessibility also relates to cognitive function as well as sighted but low vision users. While removing visible labels in favor of only placeholders is "cleaner", you lose the context of the field purpose as soon as that placeholder disappears. Additionally, placeholders do not have sufficient contrast to act as labels on their own.

Here's a good read from Duque about placeholders in forms that goes in a little more detail.

Regarding the login button:
In the context of a login page (vs the login module), I think that a start-aligned button is preferred to a full-width button. It makes sense in the module to have the button full width because it's usually shown in a different context, but on a login page that could be quite wide, a full-width button does not make as much sense and impacts the visual hierarchy. I'd be in favor of leaving the button as is, or maybe with a minimum width set so it's not quite so narrow (but not full width either).

Regarding the styling of the "forgot" links:
This is subjective but have to be cautious of when this would be merged since it could affect people's templates and/or overrides.

Hope this helps! Thank you. :)

Dear @charvimehradu,

we always should see things in the overall context. Reducing the information presented to the most necessary seems to make sense at first glance. Because everything that appears in addition must be processed cognitively. But here you start unfortunately from wrong conditions.

Joomla has written itself on the flag to be acccessible and I consider a possible configuration of inaccessible display to be wrong. @crystalenka has summarized the problem quite well.

We must always look at things from the perspective of all users. It doesn't help people with cognitive disabilities if only the placeholder is visible and disappears when clicked. They might have forgotten what they wanted to type in ...., I might do the same when I'm distracted.

The width of the button is a thing of the template. Everybody can handle it the way he thinks, because this is also always a question in which context the module appears.

All the best Angie

Dear @angieradtke @crystalenka ,

Thank you for reaching out and for your continued support in my PR. I understand the importance of accessibility and making sure that the user experience is not compromised. I apologize for the delay in my reply, as I've been focused on preparing for my internal exams.

However, I am here to help and want to make sure that we can come to a solution that benefits everyone. I will take into consideration the points raised about the placeholders and labels, and make sure to provide proper context for all users and thank you for referring me the article on accessible forms from Deque. It was a valuable read and provided a good insight into the problem with using placeholders in forms.

Regarding the login button, I appreciate the explanation about its alignment in different contexts. I will consider adjusting the width to maintain the visual hierarchy, but not make it full-width.

I understand the potential impact that the styling of the "forgot" links could have on templates and overrides. Again, I will be cautious and consider the subjectivity of this aspect while making any changes.

Thank you again for your input. I look forward to continuing to work on improving the user experience while also ensuring accessibility. :)

Hi @brianteeman @drmenzelit @crystalenka @angieradtke ,

I just wanted to let you all know that I've made some changes to the pull request. I've reverted back to using icons instead of placeholders because I realized their importance. Additionally, I wanted to clarify that I haven't removed the eye icon for the password field because it's an important feature. I would appreciate your views on whether we should keep the eye icon or not, so please let me know your thoughts. As always, I welcome any feedback or suggestions you may have.

Thanks for your help and support.

I have taken back the login button width to normal, as suggested in the feedback. I've updated the pull request with this change, and I'd be grateful if you could take another look and let me know if any further changes or updates are needed for this PR.

This pull request has been automatically rebased to 5.0-dev.

This pull request has been automatically rebased to 5.1-dev.

I have tested this item ✅ successfully on 7124211

This pull request has been automatically rebased to 5.2-dev.

This pull request has been automatically rebased to 5.3-dev.