以下是我的意思的一些例子：
google.com - 焦点设置在“搜索”框中
gmail.google.com - 焦点设置在“用户名”字段中（实际上，大多数网络电子邮件客户端执行此操作）。
stackoverflow，问一个问题 - 焦点设置在“标题”框中。
有时，这是一个方便的功能 - 例如，在Google上。但是，从可用性的角度来看，在登录页面上真的被认为是一个很好的功能吗？
就个人而言，我经常输入我的用户名，开始输入我的密码，然后页面完成加载并将焦点重新放回用户名字段。不幸的是，由于我有复杂的密码迫使我在键入时查看键盘，我没注意到焦点转移时。对于站在我身后的人来说，我常常会在未屏蔽的用户名字段中键入我的密码。
另一种情况，不那么危险但仍然很烦人，就是当我在我的主页仍在加载时在我的地址栏中输入网址时。然而，一旦它完成，如果我没有进入网址，焦点就会从我身上偷走并放在其他领域。
是否应对网站和/或浏览器进行编程，以便在用户已与网站或浏览器进行交互时不会改变焦点？像这样的问题会困扰普通（即非程序员）用户吗？
答案 0 :(得分：3)
当网站成为焦点时，我个人讨厌它。主要原因是在我的笔记本电脑上，如果我正在使用触控板并按下退格键，它将自动导航回上一页。如果焦点放在文本框上，它会将退格处理为我正在尝试删除字符。
我的个人偏好（这与最佳实践没什么关系）是它没有任何东西应该有初始焦点，但第一个标签会将它带到你想要初始焦点的元素。
答案 1 :(得分：3)
这些是两个单独的问题，答案不同：
问：应该关注用户最有可能使用的输入字段吗？
答：绝对是的，如果“大多数用户”确实是90％或更多。
问：网页完成加载后会发生这种情况吗？
答：没有。“onLoad”事件是一个非常愚蠢的地方。输入字段应该在出现时立即获得焦点 - 当页面完成加载时，它通常完全无关紧要。只需放置一个<script>标记，将焦点设置在输入元素本身之后。
答案 2 :(得分：2)
我在Gmail中遇到同样的问题，我发现它有点烦人，特别是因为它应该容易规避：
在OnLoad事件处理程序中，检查输入框（用户名或密码）是否已包含文本。如果是这种情况，请不要更改焦点。
与所有简单的解决方案一样，如果有一些奇怪的副作用使其不实用，我也不会感到惊讶，但无论如何我都会尝试一下。 哦，如果它有效，你为什么不向谷歌发送电子邮件？ ; - ）
话虽如此，我认为这种行为是usability glitch，这不是一个错误，但有点烦人。不要惹恼你的顾客。解决它。
答案 3 :(得分：1)
我认为只有我们的程序员在页面加载之前才有输入的习惯;-) 大多数非程序员朋友都等到他们看到来自装载区的“已完成”信号。
但是上面的两个问题比每次都要移动我们的鼠标指针/使用标签以在没有关注特定控件的网站中输入我们想要的内容（用户名，密码）而烦人。
“网站和/或浏览器是否应该进行编程，以便在用户已经与网站或浏览器进行交互时不会改变焦点？”
我认为应该启用浏览器而不是网站。因为这将是另一次回到服务器的行程，并且对于低速连接可能会感到沮丧。
总的来说，我认为这只是我们可以忍受的另一个小问题/烦恼。正如我所说，只有程序员甚至在页面加载之前才会跳转类型。我的大多数朋友都不知道他们可以在页面加载之前输入：）
答案 4 :(得分：1)
有些网站实际上有一个用户，普通用户使用键盘（普通用户 - 有些像我一样，也使用键盘进行导航）。谷歌搜索等网站实际上希望您只需输入您要查找的内容并点击enter。
具有多个输入区域和多个退出路径的站点虽然有时会将初始焦点放在某处，然后它会变得很烦人。如果他们的输入区域有一些奇怪的标签顺序会变得更糟 - 所以他们实际上强制你使用鼠标。
当网站完成加载时，我个人看不到焦点的变化，而不是普通用户。但是，正如我所提到的，如果它真的很有用，那么它就是你特定应用中的用例。这可能是将应用程序显示在某些人的beta阶段并执行可用性测试的问题。
答案 5 :(得分：1)
是的，焦点应默认为用户开始输入的最可能位置。不这样做是教科书糟糕的UI设计。
当焦点违约干扰你已经在做的事情时，这不是焦点违约的固有问题，而是实施不充分的失败。除了其他原因之外，这就是为什么我把一个generic 'smart' autofocus script组合在一起，如果你已经开始打字，那就会让你感到孤独。
（是的，我知道它很毛茸茸。大多数毛羽都在处理跨浏览器的问题 - 实际上，只有一次失败的Firefox。）