2010-03-12 14 views
9

Sembra nella maggior parte dei browser, uno <input type="submit"> tratta sia [barra spaziatrice] che [invio] come un clic, ma un collegamento <a> considera solo [invio] come un clic.jQuery - Evento click trigger sui link con barra spaziatrice?

La mia app utilizza un numero di link formattati per simulare i pulsanti, quindi un utente che è abituato a premere un pulsante e premere [barra spaziatrice] sarà frustrato.

Questo bit di jQuery risolve il problema:

$("a.Button").die("keypress").live("keypress", function(e) { 
    if (e.which == 32) { 
     $(this).trigger("click"); 
     e.preventDefault(); 
    } 
}); 

La mia domanda: C'è una ragione per non farlo? Sono un po 'riluttante a ignorare il comportamento predefinito del browser su qualcosa di fondamentale come questo, ma dal momento che sto già abusando del tag link per farlo apparire come un pulsante, almeno in questo modo non sto violando le aspettative dell'utente ulteriore.

+0

FWIW questa è un'app con un pubblico limitato. Javascript è un requisito dichiarato per l'utilizzo. Fa un uso pesante di mappe, grafici, griglie modificabili e altri elementi visivi e/o interattivi, e non mi è chiaro che sarebbe possibile renderlo utilizzabile tramite uno screen reader. –

+0

Questo non sembra funzionare per i pulsanti di collegamento ASP.NET che producono elementi di ancoraggio con un href di 'javascript: WebForm_DoPostBackWithOptions (new WebForm_PostBackOptions ("ctl00 $ main $ uclFind $ uclEntry $ btnGet", "", true, "", "", falso, vero)) ' –

risposta

6

Penso che lo standard più importante da mantenere non sia il comportamento del browser, ma piuttosto la risposta attesa dell'utente.

Se hai eliminato la visualizzazione dei collegamenti trasformandoli in pulsanti, l'utente deve essere in grado di trattare quei "pulsanti" esattamente come farebbe se fosse un pulsante reale, altrimenti confonderai e irriterai gli utenti che hanno speso anni con questo comportamento "dotto".

0

Ci sono i problemi di usabilità standard.

Penso che "sembra" sia la chiave qui. Se qualcuno usa uno screen reader, vedrà un link e agirà in modo appropriato.

Se qualcuno ha disattivato javascript, la funzione jquery (ovviamente) non verrà eseguita e otterrà anche il comportamento del collegamento.

Ovviamente hai già fatto la ricerca dell'anima (!) Usando un collegamento come un pulsante, quindi è un caso di trattare con questi due casi - screen reader e non javascript.

Se non è possibile simulare il comportamento del pulsante (su un collegamento) per questi due casi, offrirai a persone diverse un'esperienza diversa, il che è un buon motivo per non utilizzare la funzione. O la barra spaziatrice dovrebbe attivare ogni utilizzo di questi link/pulsanti o nessuno di essi.

+0

Non sono d'accordo per un paio di motivi 1) Solo perché gli standard esistono non significa che debbano essere applicati in ogni situazione. In questo caso particolare, se ha seguito il tuo consiglio, avrebbe dovuto rinunciare * alla risposta prevista di ogni singolo utente *, piuttosto che ai pochi selezionati che hanno scelto JS. 2) Si suppone anche che un utente preferisca che funzioni su * no *, piuttosto che su * alcuni * sistemi. Vedo che si tratta di un problema con le app lato client, ma sul Web, per tutti gli scopi pratici, le pagine Web vengono visualizzate quasi sempre in modi leggermente diversi. L'aspettativa dell'utente è che questo sarà il caso. – dclowd9901

+0

Abbastanza corretto - che dire degli screen reader, hanno ragione di ignorare? – amelvin