If local admin is incapable of configuring user accounts, how are websites supposed to figure out who is who, and which browser is on shared computer?
After all, if managing user accounts is too hard for said admin (or we are talking about a shared PC in a library, which doesn't have user accounts as a matter of principle) - just make browser always start in private/incognito mode on shared computer. It is as easy as adding command-line argument "--private-window" for firefox or "--temp-profile" for chrome. That's it. Window closed - autocomplete gone. Problem solved.
Multiple quality folks on a shop floor accessing a QMS from the same machine. If an IT admin forgets to disable password saving, compliance rules could be broken if one quality member has the ability to electronically sign a document using someone else's saved password.
Your actual problem is that your users can't change even the most basic settings, and you're not in a position to change it for them. I'm sure autocomplete isn't the first nor the last symptom you'll have due to this problem. Good defaults are important, but good defaults are about more than what works for shared desktops in schools with clueless IT people.
It speaks negatively of the web over a native app for this to be disabled by default.
So how would allowing a small percentage of web apps to disable autocomplete resolve this? It only makes it slightly less painful for the websites where autocomplete is disabled - everywhere else you have the same problem. You're asking the wrong people to solve this for you here.
This change is for all input fields.
> We don't just ignore the autocomplete attribute, however. In the WHATWG standard, we defined a series of new autocomplete values that developers can use to better inform the browser about what a particular field is, and we encourage developers to use those types. [2]
> In cases where you really want to disable autofill, our suggestion at this point is to utilize the autocomplete attribute to give valid, semantic meaning to your fields. If we encounter an autocomplete attribute that we don't recognize, we won't try and fill it.
> As an example, if you have an address input field in your CRM tool that you don't want Chrome to Autofill, you can give it semantic meaning that makes sense relative to what you're asking for: e.g. autocomplete="new-user-street-address". If Chrome encounters that, it won't try and autofill the field.
If you would read what they actually wrote you would notice that - as usual - the headline does not even remotely catch the complexity of the problem.
Our user base is almost entirely shared desktops / Chromebooks in schools. Not all school admins are smart enough to disable password saving / autocomplete (not to mention not all schools have someone for this) so we see cases of a kids account getting misused because it was saved on some library desktop all the time.
Give users the option to opt out, but taking the power out of the app developers hands by default is short-sighted.