Manipulação de eventos usando Javascript é um assunto delicado e merece atenção especial quando se trata de desenvolvimento Web client-side. Ao automatizar uma provável ação do usuário devemos considerar diversos contextos de uso. Lembremo-nos que contexto de uso é a combinação envolvendo usuários, tarefas, equipamentos (hardware, software e materiais), ambiente físico e social em que algo é usado. Vide: http://warau.nied.unicamp.br/?id=t601
É muito comum encontrarmos páginas que tentam prever o clique do usuário em determinado campo atribuindo foco automático ao primeiro campo vazio. Um exemplo corriqueiro é o de telas de autenticação em que o primeiro campo vazio ganha foco automaticamente, seja o campo de nome de usuário ou de senha, caso o nome de usuário possa ser recuperado de alguma forma (e.g., cookie).
Isto é legal e realmente deixa a interação mais eficiente. Pode aumentar a satisfação do usuário, pode evitar a mudança de um dispositivo para outro (e.g., do teclado para o mouse), pode envolver questões de acessibilidade na movimentação do ponteiro até o campo ou barreiras que um usuário cego poderia enfrentar até que o foco chegasse ao campo vazio, só para citar alguns.
No entanto, a antecipação às ações de usuário sem considerar se o usuário já está interagindo com a interface pode ser um "tiro no pé".
Imagine que o usuário está preenchendo o nome de usuário em uma página de autenticação. Então, o evento load é disparado e em seguida o foco é alterado automaticamente para o campo da senha, uma vez que o conteúdo do nome de usuário era diferente de vazio, mas antes do usuário terminar de escrever o nome. O que isto pode causar? Algo que deveria economizar um clique custará um clique e eventuais backspaces. Este cenário pode ocorrer, por exemplo, se a máquina estiver sobrecarregada ou se houver uma lentidão momentânea na rede.
Identifiquei um problema deste tipo e resolvi verificar em dois webmails famosos.
Gmail – No Gmail o foco é atribuído automaticamente para o primeiro campo vazio. Se, antes do navegador disparar o evento load, você clicar no campo nome de usuário e começar a digitar, assim que o evento load for disparado, o campo senha ganha foco automaticamente enquanto está preenchendo o usuário. Isto acontece porque a verificação é baseada no campo nome de usuário estar ou não vazio. Assim, se você não tiver terminado de escrever o nome, terá que retornar ao campo nome de usuário para terminar de preenchê-lo. Em suma, o que deveria economizar ações, poode custar uma quantidade igual ou maior de ações caso o foco automático não fosse usado.
Yahoo – No e-mail do Yahoo o foco é atribuído automaticamente para o campo ID Yahoo, mas se o usuário começar a digitá-lo antes do evento load da página ser disparado, a mudança não é feita automaticamente. Assim, a utilização feita no Yahoo é mais conservadora e não chega a custar mais ações para o usuário.
Note que a armadilha é atribuir foco automático em um campo após o usuário começar a disparar eventos. O evento load das páginas é disparado pelo navegador. Uma possível solução é "desligar" o foco automático caso o usuário atribua foco a qualquer elemento.
Por fim, alguém pode pensar se isso é, de fato, tão crítico. Faltariam dedos para contar problemas mais comuns e muito mais críticos, mas acho que comentar e discutir detalhes de desenvolvimento Web client-side como este são produtivos para quem deseja melhorar acessibilidade e usabilidade de websites via smart defaults.