Prácticas recomendadas para el formulario de acceso

Usa las funciones del navegador multiplataforma para crear formularios de acceso que sean seguros, accesibles y fáciles de usar.

Sam Dutton

Si los usuarios alguna vez necesitan acceder a tu sitio, es fundamental que el diseño del formulario de acceso sea bueno. Esto es especialmente cierto para las personas con conexiones deficientes, que usan dispositivos móviles, están apuradas o bajo estrés. Los formularios de acceso mal diseñados tienen porcentajes de rebote altos. Cada rebote podría significar un usuario perdido y disconforme, no solo una oportunidad de acceso perdida.

Este es un ejemplo de un formulario de acceso simple que demuestra todas las prácticas recomendadas:

Lista de tareas

• Usa elementos HTML significativos: <form>, <input>, <label> y <button>.
• Etiqueta cada entrada con un <label>.
• Usa atributos de elementos para acceder a las funciones integradas del navegador: type, name, autocomplete, required.
• Asigna a los atributos name y id de entrada valores estables que no cambien entre cargas de páginas o implementaciones de sitios web.
• Coloca el acceso en su propio elemento <form>.
• Asegúrate de que el formulario se envíe correctamente.
• Usa autocomplete="new-password" y id="new-password" para la entrada de contraseña en un formulario de registro y para la contraseña nueva en un formulario de restablecimiento de contraseña.
• Usa autocomplete="current-password" y id="current-password" para ingresar una contraseña de acceso.
• Proporciona la funcionalidad Mostrar contraseña.
• Usa aria-label y aria-describedby para las entradas de contraseñas.
• No dupliques las entradas.
• Diseña formularios de modo que el teclado del dispositivo móvil no oculte las entradas ni los botones.
• Asegúrate de que los formularios se puedan usar en dispositivos móviles: usa texto legible y asegúrate de que las entradas y los botones sean lo suficientemente grandes como para funcionar como objetivos táctiles.
• Mantén el desarrollo de la marca y el estilo en tus páginas de registro y acceso.
• Realiza pruebas en el campo y en el laboratorio: crea estadísticas de páginas, estadísticas de interacción y medición de rendimiento centrada en el usuario en tu flujo de registro y acceso.
• Realiza pruebas en varios navegadores y dispositivos: El comportamiento de los formularios varía significativamente entre las plataformas.

Usa código HTML significativo

Usa elementos compilados para la tarea: <form>, <label> y <button>. Estos habilitan la funcionalidad integrada del navegador, mejoran la accesibilidad y agregan significado a tu marcado.

Usa <form>

Es posible que te sientas tentado a unir las entradas en un <div> y controlar el envío de datos de entrada solo con JavaScript. Por lo general, es mejor usar un elemento <form> simple. Esto hace que tu sitio sea accesible para los lectores de pantalla y otros dispositivos de accesibilidad, habilita una variedad de funciones integradas del navegador, facilita la compilación de un acceso funcional básico para navegadores más antiguos y puede funcionar incluso si falla JavaScript.

Usa <label>

Para etiquetar una entrada, usa un <label>.

<label for="email">Email</label>
<input id="email" …>

Por dos motivos:

• Si presionas o haces clic en una etiqueta, el enfoque se mueve a su entrada. Asocia una etiqueta con una entrada usando el atributo for de la etiqueta con el name o id de la entrada.
• Los lectores de pantalla anuncian el texto de la etiqueta cuando esta o su entrada se enfocan.

No uses marcadores de posición como etiquetas de entrada. Es probable que las personas olviden para qué servía la entrada una vez que comienzan a ingresar texto, en especial, si se distraen ("¿Estaba ingresando una dirección de correo electrónico, un número de teléfono o un ID de cuenta?"). Existen muchos otros problemas potenciales con los marcadores de posición. Consulta No use el atributo marcador de posición y Los marcadores de posición en los campos de formulario son dañinos si no estás convencido.

Lo mejor es colocar las etiquetas sobre las entradas. Esto permite un diseño coherente en dispositivos móviles y computadoras de escritorio y, según la investigación de IA de Google, permite que los usuarios realicen un análisis más rápido. Obtienes etiquetas y entradas de ancho completo, y no necesitas ajustar el ancho de la etiqueta ni de la entrada para que se ajusten al texto de la etiqueta.

Abre el Glitch label-position en un dispositivo móvil para comprobarlo.

Usa <button>

Usa <button> para los botones. Los elementos de botón proporcionan un comportamiento accesible y una funcionalidad de envío de formularios integrada, y se pueden aplicarles diseños fácilmente. No tiene sentido usar un <div> ni algún otro elemento que pretenda ser un botón.

Asegúrate de que el botón de envío indique lo que hace. Algunos ejemplos son Crear cuenta o Acceder, no Enviar o Iniciar.

Cómo garantizar el envío correcto del formulario

Ayuda a los administradores de contraseñas a comprender que se envió un formulario. Existen dos maneras de hacerlo:

• Navega a otra página.
• Emula la navegación con History.pushState() o History.replaceState() y quita el formulario de contraseña.

Con una solicitud XMLHttpRequest o fetch, asegúrate de que el acceso correcto se informe en la respuesta y se controle quitando el formulario del DOM, además de indicarle al usuario que se realizó correctamente.

Considera inhabilitar el botón Acceder una vez que el usuario lo presione o haga clic en él. Muchos usuarios hacen clic en los botones varias veces, incluso en sitios que son rápidos y responsivos. Eso ralentiza las interacciones y aumenta la carga del servidor.

Por el contrario, no inhabilites el envío de formularios mientras esperas la entrada del usuario. Por ejemplo, no inhabilites el botón Acceder si los usuarios no ingresaron su PIN de cliente. Es posible que los usuarios omitan algo en el formulario y, luego, intenten presionar varias veces el botón Acceder (inhabilitado) y piensen que no funciona. Como mínimo, si debes inhabilitar el envío de formularios, explícale al usuario qué falta cuando hace clic en el botón inhabilitado.

No dupliques las entradas

Algunos sitios obligan a los usuarios a ingresar correos electrónicos o contraseñas dos veces. Eso podría reducir los errores para algunos usuarios, pero genera trabajo adicional para todos los usuarios y aumenta las tasas de abandono. Pedir la información dos veces tampoco tiene sentido cuando los navegadores completan automáticamente las direcciones de correo electrónico o sugieren contraseñas seguras. Es mejor permitir que los usuarios confirmen su dirección de correo electrónico (de todos modos, deberás hacerlo) y facilitarles el restablecimiento de la contraseña si es necesario.

Aprovecha al máximo los atributos de los elementos

Aquí es donde ocurre la magia. Los navegadores tienen varias funciones integradas útiles que usan atributos de elementos de entrada.

Mantén las contraseñas privadas, pero permite que los usuarios las vean si lo desean

Las entradas de contraseñas deben tener type="password" para ocultar el texto de la contraseña y ayudar al navegador a comprender que la entrada es para contraseñas. (Ten en cuenta que los navegadores usan una variedad de técnicas para comprender los roles de entrada y decidir si ofrecen o no guardar contraseñas).

Debes agregar un botón de activación Mostrar contraseña para permitir que los usuarios verifiquen el texto que ingresaron. No olvides agregar un vínculo Olvidaste la contraseña. Consulta Habilita la visualización de contraseñas.

Proporciona el teclado correcto a los usuarios de dispositivos móviles

Usa <input type="email"> para brindarles a los usuarios de dispositivos móviles un teclado adecuado y permitir que el navegador valide las direcciones de correo electrónico integradas de forma básica. ¡No se requiere JavaScript!

Si necesitas usar un número de teléfono en lugar de una dirección de correo electrónico, <input type="tel"> habilita un teclado telefónico en dispositivos móviles. También puedes usar el atributo inputmode cuando sea necesario: inputmode="numeric" es ideal para números de PIN. En Todo lo que necesitas saber sobre inputmode, encontrarás más detalles.

Evita que el teclado del dispositivo móvil obstruya el botón Acceder

Lamentablemente, si no tienes cuidado, los teclados para dispositivos móviles pueden cubrir el formulario o, lo que es peor, obstruir parcialmente el botón Acceder. Los usuarios pueden rendirse antes de darse cuenta de lo que sucedió.

Cuando sea posible, evita esto mostrando solo los campos de correo electrónico o teléfono y contraseña, y el botón Acceder en la parte superior de la página de acceso. Coloca otro contenido a continuación.

Prueba en una variedad de dispositivos

Deberás realizar pruebas en una variedad de dispositivos para tu público objetivo y hacer ajustes según corresponda. BrowserStack permite pruebas gratuitas para proyectos de código abierto en una variedad de navegadores y dispositivos reales.

Considera usar dos páginas

Algunos sitios (como Amazon y eBay) evitan el problema pidiendo el correo electrónico o el teléfono y la contraseña en dos páginas. Este enfoque también simplifica la experiencia: al usuario solo se le asigna una tarea a la vez.

Lo ideal es que esto se implemente con un solo <form>. Usa JavaScript para mostrar inicialmente solo la entrada de correo electrónico, luego ocultarla y mostrar la entrada de contraseña. Si debes forzar al usuario a navegar a una página nueva entre ingresar su correo electrónico y su contraseña, el formulario de la segunda página debe tener un elemento de entrada oculto con el valor del correo electrónico para permitir que los administradores de contraseñas almacenen el valor correcto. En Estilos de formularios de contraseña que comprende Chromium, se proporciona un ejemplo de código.

Ayuda a los usuarios a evitar volver a ingresar datos

Puedes ayudar a los navegadores a almacenar datos correctamente y autocompletar entradas para que los usuarios no tengan que recordar ingresar valores de correo electrónico y contraseña. Esto es especialmente importante en dispositivos móviles y fundamental para las entradas de correo electrónico, que tienen porcentajes de abandono altos.

Este proceso tiene dos partes:

1. Los atributos autocomplete, name, id y type ayudan a los navegadores a comprender el rol de las entradas para almacenar datos que se pueden usar más adelante para el autocompletado. Para permitir que se almacenen datos para el autocompletado, los navegadores modernos también requieren que las entradas tengan un valor name o id estable (no generado de forma aleatoria en cada carga de página o implementación del sitio) y que se encuentren en un <form> con un botón submit.

2. El atributo autocomplete ayuda a los navegadores a autocompletar correctamente las entradas con datos almacenados.

Para las entradas de correo electrónico, usa autocomplete="username", ya que los administradores de contraseñas en navegadores modernos reconocen username, aunque deberías usar type="email" y es posible que quieras usar id="email" y name="email".

Para las entradas de contraseñas, usa los valores autocomplete y id adecuados para ayudar a los navegadores a diferenciar entre contraseñas nuevas y actuales.

Usa autocomplete="new-password" y id="new-password" para una contraseña nueva

• Usa autocomplete="new-password" y id="new-password" para la entrada de contraseña en un formulario de registro o la contraseña nueva en un formulario para cambiar la contraseña.

Usa autocomplete="current-password" y id="current-password" para una contraseña existente

• Usa autocomplete="current-password" y id="current-password" para la entrada de contraseña en un formulario de acceso o la entrada de la contraseña anterior del usuario en un formulario para cambiar la contraseña. Esto le indica al navegador que quieres que use la contraseña actual que almacenó para el sitio.

Para un formulario de registro, sigue estos pasos:

<input type="password" autocomplete="new-password" id="new-password" …>

Para acceder, haz lo siguiente:

<input type="password" autocomplete="current-password" id="current-password" …>

Compatibilidad con administradores de contraseñas

Los diferentes navegadores controlan la función Autocompletar de correo electrónico y la sugerencia de contraseña de manera un poco diferente, pero los efectos son muy similares. En Safari 11 y versiones posteriores para computadoras, por ejemplo, se muestra el administrador de contraseñas y, luego, se usa la autenticación biométrica (huella dactilar o reconocimiento facial) si está disponible.

Chrome para computadoras muestra sugerencias de correo electrónico, muestra el Administrador de contraseñas y autocompleta la contraseña.

Los sistemas de contraseñas y autocompletado de los navegadores no son simples. Los algoritmos para adivinar, almacenar y mostrar valores no están estandarizados y varían de una plataforma a otra. Por ejemplo, como señala Hidde de Vries: "El administrador de contraseñas de Firefox complementa sus heurísticas con un sistema de recetas".

Autocompletar: Qué deben saber los desarrolladores web, pero no saben tiene mucha más información sobre el uso de name y autocomplete. En la especificación de HTML, se enumeran los 59 valores posibles.

Habilita el navegador para que sugiera una contraseña segura

Los navegadores modernos usan heurísticas para decidir cuándo mostrar la IU del administrador de contraseñas y sugerir una contraseña segura.

A continuación, te mostramos cómo lo hace Safari en computadoras.

(La sugerencia de contraseña única y segura está disponible en Safari desde la versión 12.0).

Los generadores de contraseñas integrados en el navegador significan que los usuarios y los desarrolladores no necesitan averiguar qué es una "contraseña segura". Dado que los navegadores pueden almacenar contraseñas de forma segura y autocompletarlas según sea necesario, los usuarios no necesitan recordar ni ingresar contraseñas. Animar a los usuarios a aprovechar los generadores de contraseñas integrados en el navegador también significa que es más probable que usen una contraseña única y segura en tu sitio, y que sea menos probable que reutilicen una contraseña que podría estar comprometida en otro lugar.

Ayuda a evitar que los usuarios omitan entradas por accidente

Agrega el atributo required a los campos de correo electrónico y contraseña. Los navegadores modernos solicitan y establecen automáticamente el enfoque de los datos faltantes. No se requiere JavaScript.

Cómo diseñar para dedos y pulgares

El tamaño predeterminado del navegador para casi todo lo relacionado con los elementos de entrada y los botones es demasiado pequeño, especialmente en dispositivos móviles. Esto puede parecer obvio, pero es un problema común con los formularios de acceso en muchos sitios.

Asegúrate de que las entradas y los botones sean lo suficientemente grandes

El tamaño y el padding predeterminados para las entradas y los botones son demasiado pequeños en computadoras de escritorio y aún peores en dispositivos móviles.

Según las guías de accesibilidad de Android, el tamaño de objetivo recomendado para los objetos de pantalla táctil es de 7 a 10 mm. Los lineamientos de interfaz de Apple sugieren 48 x 48 px, y el W3C sugiere al menos 44 x 44 píxeles CSS. En función de eso, agrega (al menos) alrededor de 15 px de padding a los elementos de entrada y los botones para dispositivos móviles, y alrededor de 10 px en computadoras de escritorio. Pruébala con un dispositivo móvil real y un dedo o pulgar reales. Debes poder presionar cómodamente cada una de las entradas y los botones.

La auditoría de Lighthouse Los objetivos táctiles no tienen el tamaño adecuado puede ayudarte a automatizar el proceso de detección de elementos de entrada que son demasiado pequeños.

Cómo diseñar para el pulgar

Busca objetivo táctil y verás muchas imágenes de dedos índices. Sin embargo, en el mundo real, muchas personas usan los pulgares para interactuar con los teléfonos. Los pulgares son más grandes que los índices, y el control es menos preciso. Esto es una razón más para que los objetivos táctiles tengan un tamaño adecuado.

Haz que el texto sea lo suficientemente grande

Al igual que con el tamaño y el padding, el tamaño de fuente predeterminado del navegador para los elementos de entrada y los botones es demasiado pequeño, en especial en dispositivos móviles.

Los navegadores en diferentes plataformas ajustan el tamaño de las fuentes de manera diferente, por lo que es difícil especificar un tamaño de fuente en particular que funcione bien en todas partes. Una rápida encuesta de sitios web populares muestra tamaños de 13 a 16 píxeles en computadoras de escritorio: coincidir con ese tamaño físico es un buen mínimo para el texto en dispositivos móviles.

Esto significa que debes usar un tamaño de píxeles más grande en dispositivos móviles: 16px en Chrome para computadoras de escritorio es bastante legible, pero incluso con buena visión es difícil leer el texto 16px en Chrome para Android. Puedes establecer diferentes tamaños de píxeles de fuente para diferentes tamaños de viewport con las consultas de medios. 20px es aproximadamente correcto en dispositivos móviles, pero debes probarlo con amigos o colegas que tengan visión baja.

La auditoría de Lighthouse El documento no usa tamaños de fuente legibles puede ayudarte a automatizar el proceso de detección de texto demasiado pequeño.

Proporciona suficiente espacio entre las entradas

Agrega suficiente margen para que las entradas funcionen bien como objetivos táctiles. En otras palabras, intenta dejar un margen de aproximadamente un dedo de ancho.

Asegúrate de que tus entradas se vean claramente

El diseño de borde predeterminado de las entradas hace que sean difíciles de ver. Son casi invisibles en algunas plataformas, como Chrome para Android.

Además del padding, agrega un borde: en un fondo blanco, una buena regla general es usar #ccc o un color más oscuro.

Usa las funciones integradas del navegador para advertir sobre valores de entrada no válidos

Los navegadores tienen funciones integradas para realizar la validación básica de formularios para entradas con un atributo type. Los navegadores advierten cuando envías un formulario con un valor no válido y centran la atención en la entrada problemática.

Puedes usar el selector CSS :invalid para destacar los datos no válidos. Usa :not(:placeholder-shown) para evitar seleccionar entradas sin contenido.

input[type=email]:not(:placeholder-shown):invalid {
  color: red;
  outline-color: red;
}

Prueba diferentes formas de destacar entradas con valores no válidos.

Usa JavaScript cuando sea necesario

Activar o desactivar la visualización de la contraseña

Debes agregar un botón de activación Mostrar contraseña para permitir que los usuarios verifiquen el texto que ingresaron. La usabilidad se ve afectada cuando los usuarios no pueden ver el texto que ingresaron. Actualmente, no hay una forma integrada de hacerlo, aunque hay planes para su implementación. En su lugar, deberás usar JavaScript.

En el siguiente código, se usa un botón de texto para agregar la funcionalidad Mostrar contraseña.

HTML:

<section>
  <label for="password">Password</label>
  <button id="toggle-password" type="button" aria-label="Show password as plain text. Warning: this will display your password on the screen.">Show password</button>
  <input id="password" name="password" type="password" autocomplete="current-password" required>
</section>

Este es el código CSS para que el botón se vea como texto sin formato:

button#toggle-password {
  background: none;
  border: none;
  cursor: pointer;
  /* Media query isn't shown here. */
  font-size: var(--mobile-font-size);
  font-weight: 300;
  padding: 0;
  /* Display at the top right of the container */
  position: absolute;
  top: 0;
  right: 0;
}

Y el código JavaScript para mostrar la contraseña:

const passwordInput = document.getElementById('password');
const togglePasswordButton = document.getElementById('toggle-password');

togglePasswordButton.addEventListener('click', togglePassword);

function togglePassword() {
  if (passwordInput.type === 'password') {
    passwordInput.type = 'text';
    togglePasswordButton.textContent = 'Hide password';
    togglePasswordButton.setAttribute('aria-label',
      'Hide password.');
  } else {
    passwordInput.type = 'password';
    togglePasswordButton.textContent = 'Show password';
    togglePasswordButton.setAttribute('aria-label',
      'Show password as plain text. ' +
      'Warning: this will display your password on the screen.');
  }
}

Este es el resultado final:

Cómo hacer que las entradas de contraseña sean accesibles

Usa aria-describedby para describir las reglas de contraseñas. Para ello, debes proporcionarle el ID del elemento que describe las restricciones. Los lectores de pantalla proporcionan el texto de la etiqueta, el tipo de entrada (contraseña) y, luego, la descripción.

<input type="password" aria-describedby="password-constraints" …>
<div id="password-constraints">Eight or more characters with a mix of letters, numbers and symbols.</div>

Cuando agregues la funcionalidad Mostrar contraseña, asegúrate de incluir un aria-label para advertir que se mostrará la contraseña. De lo contrario, los usuarios podrían revelar contraseñas por error.

<button id="toggle-password"
        aria-label="Show password as plain text.
                    Warning: this will display your password on the screen.">
  Show password
</button>

Puedes ver ambas funciones de ARIA en acción en el siguiente Glitch:

En Cómo crear formularios accesibles, encontrarás más sugerencias para que los formularios sean accesibles.

Validación en tiempo real y antes del envío

Los elementos y atributos de formularios HTML tienen funciones integradas para la validación básica, pero también debes usar JavaScript para realizar una validación más sólida mientras los usuarios ingresan datos y cuando intentan enviar el formulario.

En el Paso 5 del codelab del formulario de acceso, se usa la API de Constraint Validation (que es compatible con muchos servicios) para agregar validación personalizada con la IU del navegador integrada para establecer el enfoque y mostrar instrucciones.

Más información: Usa JavaScript para una validación más compleja en tiempo real.

Analytics y RUM

El dicho "Lo que no se puede medir, no se puede mejorar" es particularmente cierto para los formularios de registro y acceso. Debes establecer objetivos, medir el éxito, mejorar tu sitio y repetir el proceso.

Las pruebas de usabilidad de descuento pueden ser útiles para probar cambios, pero necesitarás datos del mundo real para comprender realmente cómo los usuarios experimentan tus formularios de registro y acceso:

• Análisis de páginas: vistas de páginas de registro y acceso, porcentajes de rebote y salidas
• Análisis de interacciones: embudos de objetivos (¿en qué punto los usuarios abandonan tu acceso o flujo de acceso?) y eventos (¿qué acciones realizan los usuarios cuando interactúan con tus formularios?).
• Rendimiento del sitio web: Métricas centradas en el usuario (¿tus formularios de registro y acceso son lentos por algún motivo? Si es así, ¿cuál es la causa?).

También te recomendamos que implementes pruebas A/B para probar diferentes enfoques de registro y acceso, y lanzamientos en etapas para validar los cambios en un subconjunto de usuarios antes de lanzarlos a todos los usuarios.

Lineamientos generales

Una IU y una UX bien diseñadas pueden reducir el abandono de formularios de acceso:

• No hagas que los usuarios busquen el acceso. Coloca un vínculo al formulario de acceso en la parte superior de la página con un texto claro, como Acceder, Crear cuenta o Registrarse.
• Mantén el enfoque. Los formularios de registro no son el lugar para distraer a las personas con ofertas y otras funciones del sitio.
• Minimiza la complejidad del registro. Recopila otros datos del usuario (como direcciones o detalles de tarjetas de crédito) solo cuando los usuarios vean un beneficio claro de proporcionarlos.
• Antes de que los usuarios comiencen a usar el formulario de registro, deja en claro cuál es la propuesta de valor. ¿Cómo se benefician de acceder? Ofrece a los usuarios incentivos concretos para que completen el registro.
• Si es posible, permite que los usuarios se identifiquen con un número de teléfono celular en lugar de una dirección de correo electrónico, ya que es posible que algunos usuarios no usen el correo electrónico.
• Facilita a los usuarios el restablecimiento de su contraseña y haz que el vínculo ¿Olvidaste tu contraseña? sea obvio.
• Vínculo a tus documentos de las condiciones del servicio y la política de privacidad: Deja claro a los usuarios desde el principio cómo proteges sus datos.
• Incluye el logotipo y el nombre de tu organización o empresa en las páginas de registro y acceso, y asegúrate de que el idioma, las fuentes y los estilos coincidan con el resto de tu sitio. Algunos formularios no parecen pertenecer al mismo sitio que el resto del contenido, en especial si tienen una URL muy diferente.

Sigue aprendiendo

• Crea formularios asombrosos
• Prácticas recomendadas para el diseño de formularios para dispositivos móviles
• Controles de formularios más capaces
• Cómo crear formularios accesibles
• Cómo optimizar el flujo de acceso con la API de Credential Management
• Cómo verificar números de teléfono en la Web con la API de WebOTP

Foto de Meghan Schiereck en Unsplash.