One key value is the priority of constituencies, which is enshrined in the HTML Design Principles:
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.To better understand this principle, let's consider a specific example: whether the browser's password manager should be enabled for a given web site.
The password manager is a source of conflict for these competing interests. Implementors (myself included) believe that password managers improve security by reducing the costs of using a large number of more complex passwords. Many banks, however, disagree. They believe that password managers reduce security because passwords stored in password managers can be stolen by miscreants.
How do browser vendors resolve this conflict? By default, we enable the password manager. Because users have a higher priority than implementors (i.e., browser vendors), browsers let users turn the password manager off. Because authors (i.e., site operators) also have a higher priority than browser vendors, browsers let authors disable the password manager on their own web sites by setting autocomplete=off.
The careful reader will have noticed that the scheme above violates the priority of constituencies in one case. What if the user wants to use the password manager on a web site sets autocomplete=off? Because users have a higher priority than authors, the browser should resolve this conflict in favor of the user. Typically, browsers handle this case via their extension system. For example, the autocomplete=on extension lets users override authors who want to disable the password manager.
How, then, should we respond to web site operators who wish to block or override these sorts of extensions? As long as we believe that these extensions faithfully enact the user's will, we're hard-pressed to let authors block these extensions because that would violate the priority of constituencies. Instead, we ask authors to be humble and accept the user as sovereign.