Hacker News Reader

Comment by anymouse123456 | Hacker News Reader

re: the autocomplete attribute.

It would have been nice to include a brief explanation of all the ways this feature is likely to break what you expect.

For example, recent versions of Chrome will autocomplete against a table of values across all domains for the given field "name" attribute, regardless of what you put into the autocomplete attribute [0].

I suppose this would be a fine decision if all form fields in all forms represented a global, singular datum (i.e., My Account), but it is not fine at all when dealing with collections of things (i.e., Cars, Parts or whatever).

I managed to recently work around this by generating unique-ish ids for name fields and autocomplete attributes, then fixing them before submission.

I'm obviously still salty.

[0] https://stackoverflow.com/questions/12374442/chrome-ignores-...

View on HN

I too am incredibly salty from my past accessibility work. Knowing the HTML attributes is one thing, but applying them to your product in a predictable way is another. Folks talk about the importance of cross-browser testing, but willfully neglect cross-screenreader testing. The incentive for industry to meet the needs of these users just isn't where it should be. Too many stakeholders agree that meeting the needs of able users is good enough. Accessibility is just a checkbox for most organizations. A token gesture that "we care" when really it just means "we care enough until we are forced to care more".

The issue is that 1-2% of users of a random service might use screen readers. As an industry we’ve agreed that it often makes sense to drop support for browsers with more market share. Every screen reader is going to have an order of magnitude smaller user base than the browsers we’ve decided to stop supporting.

“No one” is going to do meaningful cross-reader testing. The only reason “anyone” does any accessibility work at all is the law (and thank god for it).

YES. I wrote something [0] that combined a whole bunch of annoyances I’ve had at past jobs. Web developers tend to use a private definition of the word “accessible” that’s so hyper technical in specification that any conversation about the actual experience of using assistive technology ends with the something like “why are you using VoiceOver?”. It’s not about the resulting interface, but the specific and lintable stats.

[0] https://graypegg.com/2023/11/25/the-private-definition-of-ac...

I really wish this attribute was never added. The idea that a site owner should have that much control over my browser’s behavior is completely contrary to the concept of what a User Agent is intended to be.

I’ve never seen a legitimate use case for disabling autocomplete, but have been prevented from using my password manager on many occasions, resulting in me having to either modify the source code via developer tools, type a very long password, or copy and paste it. Both of the last two cases increase the attack surface for passwords via key logging or clipboard snooping.

The one case that has come close to being legitimate is shared computers, but that should be handled by security controls on the endpoint.

Autofill assumes all fields are associated with the person who is sitting at the computer. That assumption is wrong for an administrator editing user configuration. You don't want the admin's name or address by default if the admin is configuring a new user. Or if the admin role is editing blank user data. Admins are often managers so you can't just disable autocomplete at the browser level.

It's even worse for password fields. Browsers will aggressively attempt to fill the user's password into any password input, regardless of whether it's part of the site's login form or not. This works for most web sites, most of the time -- but it fails horribly for sites where the user really does need to enter a password for something else, like if you're setting a password on a wireless network or setting credentials on a new user you're creating.

This. But also for any data for any enumerated type.

It's so effing stupid and short sighted.

>I’ve never seen a legitimate use case for disabling autocomplete

The main one is going to be any kind of web system where the user is typing in other people's details.

Search fields can also be a bit annoying - I've seen Firefox autocomplete entries in search fields that make no sense.

For example, Firefox suggests my postal code as a search term here on HN.

The way autocomplete works in browsers is absolutely infuriating. Because a bunch of misguided orgs went around disabling autocomplete on login fields, now browsers aggressively ignore attempts to disable it and there's no elegant way to turn it off when browsers are wrong i.e., when they're autofilling user login data into database credentials.

IMHO, it's far less bad to have some "misguided orgs" disable a feature on software they wrote than to have misguided browser engineers force all web software to suggest obviously inappropriate nonsense to billions of users, forever.

Reply on news.ycombinator.com