Hcfyk

To be honest, I don't really see any use for the "forgot password" button/link unless the user put in a wrong password before. In my current project, we need as much space as possible and I was thinking about showing it only when needed. My colleague talked about "Accessibility"-reasons why it is not possible, but also couldn't give me a real argument.

What is your take on it?

Let me try to paint a picture to explain why your comment below is a huge oversight.

Tbh I don't really see any use for the "forgot password" button/link, unless the user put in a wrong password before.

Imagine a scenario where the users come to your application after a while and they don't remember the password. It means, they already know that an account exists but they haven't used it in a long time so they have definitely forgotten the password.

In this scenario, the first thing they'd do is ... ?

They will look for a password recovery option which is something in the lines of a "Forgot Password" option.

In such a condition, the user hasn't put in a wrong password yet, but they need that option

Your colleague is absolutely right about accessibility. Hiding critical actions and information selectively is a very bad practice.

It's a very bad idea to not show the link. You should always give the user the option, even if they are likely to try a few passwords first.

How about an example - what if you have a password manager, and your credentials for this site is somehow lost/missing from your password manager?

You have no idea what the password is, as it will likely be some random combination of letters, numbers, characters, etc., and therefore will want to reset it straight away.

Globally Consistent Convention Versus Design "Wants"

There is always weight towards convention in user experience/interface design for numerous reasons, but crucial systems where there is a safety/security element are ones where that should be given even higher than normal priority.

In my current project we need as much space as possible

Your reason for wanting to try breaking with a globally (externally) consistent pattern is essentially "we're lacking space".

Others have explained certain aspects of why this is a pattern you shouldn't break from specifically in relation to the element you're asking about. Those are great answers and this is merely meant to be a supplemental piece in addition to them. I want to address why you feel the need to break from convention in the first place and advise that you circle back to this encompassing design issue as the real reason you tried finding something to cut at all, and what therefor instead needs to be addressed.

Needs vs Wants

My simplest advice would be this: when dealing with anything related to security or safety, I recommend you consider conventional design components and layouts to be "needs" and your contravening design level issues to simply be "wants": if you can come up with a hard need related to the core purpose of the interface (for example: people are misclicking on a UI element and it is causing authentication issues), then it can be properly weighed against the various reasons already behind the conventional design needs (such as, if we move these elements to avoid misclicks, does it cause a worse issue to emerge that was already foreseen in the current design, making this a necessary evil), but until it arrives at that point it is merely a want and can generally be considered lower precedence.

Generally speaking, a login page/screen/modal should have as little extraneous information going on as possible, both for the sake of usability but also potentially for the sake of security (for example, avoid loading external resources where possible here). If you have a space issue on your login interface, something is almost certainly "wrong" with the encompassing design (even if this is an embedded interface of some kind). It's impossible to speculate about what per se the problem is without any related information, but I'd strongly urge you to stop trying to look for ways to break from convention here and instead look at how you can refactor the design of this interface to better fit with conventional login interface paradigms, even if it means that this screen does not perfectly match the design templating of other screens (I'd absolute advise that you keep at least related elements consistent: brand logos, colors, etc, but simply find ways to cull elements and/or reduce whitespace areas/etc that are not necessary for a login screen).

Login interfaces in particular have numerous usability concerns which overlap with security concerns, and breaking with conventional design--beyond the generalized usability reasons to try to stick with common convention due to related user knowledge/expectations--can have severe security implications here that are not always immediately foreseeable: don't break from convention simply to satisfy having seemingly backed yourself into a design corner where something "doesn't look nice" or "doesn't fit": re-examine the surrounding design itself so that it can encompass the conventional interface/component layout. If you have a specific need or reason to change the design related to a functionality change, that would be worth exploring (but will most likely result in the same outcome, per the other answers).

More simply put:

If "everyone" else can fit a login dialog with a password reset link into their login screen, what have you done that makes doing so a difficulty for you? Look to that for something to change first.

"If it ain't broke, don't fix it" simply because something else is broke with it in it. Re-align your thinking as to what the issue is.

As a quick example of why it's a good idea to stick with convention particularly in circumstances where mistakes may result in worse implications than simply someone not being pleased with the flow, or the aesthetic (short of a direct functional reason to change from it, with careful exploration of related consequences): what happens if you were to reverse the order of the username and password fields? Let's say it's for a web page: ideally everything is coded correctly so every aspect of this goes across HTTPS as POST fields. What if, in trying to get clever, someone loaded a "reset password" link with the username as a get parameter (querystring)? So what happens when someone tries logging in, puts their credentials in in reverse of the input fields, and then without paying enough attention clicks the "reset password" link... and that happens to be a non https page/endpoint?

Even if it's https, that url with querystring is now in the server logs most likely. Which ideally are secure. And ideally there's no association now with a specific account. But it's one more potential place for that to leak.

What happens if someone tries entering their parameters in reverse during a presentation? This happens even with standard configurations by simple user error (accidental tab/etc), but how often would it happen if the fields were reversed? If there's a malicious actor in the audience, do they get kicked out if they manage to log in during the timeframe between the accidental password reveal and the user resetting their password, or can they keep navigating within the application? etc.

Aside: On Accessibility

(I'm writing this in relation to an assumption of this being in a web page, but similar accessibility concepts/constructs exist in other interfaces)

FYI, this might not be an accessibility issue if this is a webpage that you submit with the submit action being that it loads the same page again from the server with the related markup of a login attempt that did not authenticate alongside a link to the password reset.

Where this becomes a possible accessibility issue is that if this is dynamically AJAXed, such that it sends the results to the server via client side scripting and then updates the page without reloading it, you may require ARIA tagging (most likely as live regions, and you'll need to carefully consider how much/what you mark as live regions versus not) to allow screen readers to update properly regarding the submission error and the availability of the link.

Particularly with screen readers, it's important to keep in mind that updates to parts of the page that aren't being interacted with can be very non obvious, especially if the person accessing the page has already explored those areas and formed a mental model in relation to them where they no longer anticipate related information being present there. In turn, it requires careful consideration (and actual testing!) to not create a circumstance where dynamic updates create an overwhelming level of immediate feedback via added aria-live decoration (while keeping a flow that allows people to reach related updated information intuitively), and you also need to pay attention to what the dynamic updates do in various screen readers in terms of cursor location changes, if any.

If someone forgets there password they will first look for a forget password so this would just waste the user's time, annoying them causing them to want to leave. Also some people will use the change password to find out a username that they have forgotten so this would force then to try and remember it, annoying them. Finally some users will use the password reset to change the password, this will annoy them as most other sites will do this.
When designing a application/website it is all about making any action easy and fast. Hidding the forgot password button makes it harder and slower. This should never be done.

This needs to be answered alongside the context in your question:

we need as much space as possible

I don't know what your login page looks like or why you so desperately need the space, but assuming you do, then yes, an easy thing to cut is a Forgot Password link on the first login page. It's not ideal, and you will probably lose users that come back after a while and don't want to guess a password. You need to balance that and other UX options with your need for real estate.

A more holistic approach to the problem is sharing your current login screen and its detailed space requirements. There are ways to indicate actions to users without a giant text span, and likewise there is probably a better way to solve your problem without hiding functionality.

14L3jrwgsSohY27kVkNq3pc836PapmDxNw