Prácticas recomendadas para el formulario de acceso

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

Si alguna vez los usuarios necesitan acceder a tu sitio, es fundamental que tengas un buen diseño del formulario de acceso. Esto es especialmente cierto para las personas que tienen malas conexiones, usan dispositivos móviles, tienen prisa o están bajo estrés. Los formularios de acceso mal diseñados obtienen porcentajes de rebote elevados. Cada rebote podría significar la pérdida de un usuario y su descontento, no solo una oportunidad de acceso perdida.

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

Verificado

• Usa elementos HTML significativos: <form>, <input>, <label> y <button>.
• Etiqueta cada entrada con un <label>.
• Usa los atributos de un elemento para acceder a las funciones integradas del navegador: type, name, autocomplete, required.
• Proporciona valores estables de los atributos de entrada name y id que no cambien entre las cargas de página o las implementaciones del sitio 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 la contraseña de acceso.
• Proporciona la funcionalidad Mostrar contraseña.
• Usa aria-label y aria-describedby para las entradas de contraseña.
• No dupliques las entradas.
• Diseña formularios de modo que el teclado del dispositivo móvil no oculte entradas ni botones.
• Asegúrate de que los formularios se puedan usar en dispositivos móviles: usa texto legible y comprueba que las entradas y los botones sean lo suficientemente grandes 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 lab: Compila las estadísticas de la página, las estadísticas de interacción y la medición del rendimiento centrada en el usuario en tu flujo de registro y acceso.
• Realiza pruebas en distintos navegadores y dispositivos: El comportamiento de los formularios varía considerablemente según las plataformas.

Usa HTML significativo

Usa elementos compilados para el trabajo: <form>, <label> y <button>. Estas habilitan la funcionalidad integrada del navegador, mejoran la accesibilidad y agregan significado a tu lenguaje de 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. En general, es mejor usar un elemento <form> antiguo y normal. Esto permite que los lectores de pantalla y otros dispositivos de asistencia puedan acceder a tu sitio, habilita una variedad de funciones integradas del navegador, simplifica la compilación de un acceso funcional básico para navegadores más antiguos y puede seguir funcionando incluso si falla JavaScript.

Usa <label>

Para etiquetar una entrada, usa un <label>.

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

Dos motivos:

• Cuando el usuario presiona o hace clic en una etiqueta, el foco se mueve a su entrada. Asocia una etiqueta a una entrada mediante 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 cuál fue el significado de la entrada una vez que comenzaron 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 uses el atributo de marcador de posición y Los marcadores de posición en los campos del formulario son perjudiciales si no te convencen.

Es probable que sea mejor colocar las etiquetas por encima de las entradas. Esto permite un diseño coherente en dispositivos móviles y computadoras de escritorio y, según la investigación de Google AI, permite que los usuarios realicen un análisis más rápido. Obtienes etiquetas de ancho completo y entradas, y no necesitas ajustar el ancho de la etiqueta y la entrada para que se ajuste 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 botones proporcionan un comportamiento accesible y una funcionalidad integrada para el envío de formularios. Además, se les puede dar estilo fácilmente. No tiene sentido usar un <div> u otro elemento que pretenda hacerse pasar por un botón.

Asegúrate de que el botón Enviar diga lo que hace. Algunos ejemplos son Crear cuenta o Acceder, no Enviar ni Comenzar.

Asegúrate de que el formulario se haya enviado correctamente

Ayudar 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. Para ello, debes quitar el formulario del DOM y también indicarle al usuario que el acceso 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 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 a la espera de 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 se pierdan algo del formulario y, luego, intenten presionar varias veces el botón Acceder (inhabilitado) y creen que no funciona. Como mínimo, si debes inhabilitar el envío de formularios, explícale al usuario lo que 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. Esto puede reducir los errores de algunos usuarios, pero genera trabajo adicional para todos los usuarios y aumenta los porcentajes de abandono. Preguntar dos veces tampoco tiene sentido cuando los navegadores autocompletan 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 su contraseña si es necesario.

Aprovecha al máximo los atributos de los elementos

Aquí es donde realmente 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 se trata de contraseñas. (ten en cuenta que los navegadores usan una variedad de técnicas para comprender las funciones de entrada y decidir si ofrecer o no guardar contraseñas).

Debes agregar un botón de activación de Mostrar contraseña para permitir que los usuarios verifiquen el texto que ingresaron y no olvides agregar el vínculo Olvidé la contraseña. Consulta Cómo habilitar la visualización de contraseñas.

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

Usa <input type="email"> para brindarles a los usuarios de dispositivos móviles un teclado adecuado y habilitar la validación básica de direcciones de correo electrónico integradas por parte del navegador. 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 el dispositivo móvil. También puedes usar el atributo inputmode cuando sea necesario: inputmode="numeric" es ideal para los números PIN. En Todo lo que quisiste saber sobre el modo de entrada, encontrarás más detalles.

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

Lamentablemente, si no tienes cuidado, es posible que los teclados de dispositivos móviles cubran el formulario o, lo que sea peor, obstruyan parcialmente el botón Acceder. Los usuarios pueden darse por vencidos antes de darse cuenta de lo que sucedió.

Siempre que sea posible, evita este problema mostrando solo las entradas de correo electrónico/teléfono y contraseña, y el botón Acceder en la parte superior de la página de acceso. Incluye otro tipo de contenido debajo.

Realiza pruebas en una gran variedad de dispositivos

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

Considera usar dos páginas

Para evitar el problema, algunos sitios (como eBay y Amazon) solicitan un correo electrónico, un teléfono y una 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 sería que esto se implemente con un solo <form>. Usa JavaScript para mostrar inicialmente solo la entrada de correo electrónico y, luego, ocultarla y mostrar la entrada de la contraseña. Si debes obligar al usuario a que navegue a una página nueva después de ingresar su correo electrónico y contraseña, el formulario de la segunda página debe tener un elemento de entrada oculto con el valor de correo electrónico, para permitir que los administradores de contraseñas almacenen el valor correcto. En Estilos de formulario de contraseña que Chromium comprende, se proporciona un ejemplo de código.

Ayuda a los usuarios a evitar tener que 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 particularmente importante en los dispositivos móviles y es crucial para las entradas de correo electrónico, que obtienen porcentajes de abandono altos.

Esto tiene dos partes:

1. Los atributos autocomplete, name, id y type ayudan a los navegadores a comprender la función de las entradas con el fin de almacenar datos que luego se pueden usar para el autocompletado. Para permitir que los datos se almacenen para el autocompletado, los navegadores modernos también requieren entradas que tengan un valor name o id estable (que no se genere de forma aleatoria en cada carga de página o implementación de sitio) y que estén en una <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 de los navegadores modernos reconocen username, aunque deberías usar type="email" y quizás quieras usar id="email" y name="email".

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

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

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

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

• Usa autocomplete="current-password" y id="current-password" para ingresar la contraseña en un formulario de acceso, o bien la entrada anterior del usuario en un formulario de cambio de 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:

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

Para acceder:

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

Cómo brindar asistencia a los administradores de contraseñas

Los distintos navegadores manejan las sugerencias de autocompletado de correos electrónicos y contraseñas de una manera diferente, pero los efectos son casi iguales. Por ejemplo, en Safari 11 y versiones posteriores para computadoras de escritorio, se muestra el administrador de contraseñas y, si está disponible, se usa la autenticación biométrica (huellas digitales o reconocimiento facial).

La versión de Chrome para computadoras de escritorio muestra sugerencias de correo electrónico, muestra el administrador de contraseñas y autocompleta la contraseña.

Los sistemas de Autocompletar y contraseñas del navegador 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 lo indica Hidde de Vries: "El administrador de contraseñas de Firefox complementa su heurística con un sistema de recetas".

Autocompletar: Lo que los desarrolladores web deben saber, pero no lo saben, tiene mucha más información sobre el uso de name y autocomplete. La especificación de HTML enumera los 59 valores posibles.

Habilitar el navegador para que sugiera una contraseña segura

Los navegadores modernos usan heurística 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 de escritorio.

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

Gracias a los generadores de contraseñas de navegador integrados, los usuarios y desarrolladores no necesitan descubrir qué es una “contraseña segura”. Dado que los navegadores pueden almacenar contraseñas de forma segura y autocompletarlas según sea necesario, no es necesario que los usuarios las recuerden ni ingresen. Si invitas a los usuarios a aprovechar los generadores de contraseñas integrados en el navegador, también es más probable que usen una contraseña única y segura en tu sitio, y que vuelvan a usar una que podría estar comprometida en otro lugar.

Ayuda a evitar que los usuarios falten entradas accidentalmente

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

Diseño 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 relleno predeterminados para las entradas y los botones son demasiado pequeños en computadoras de escritorio y, aún peor, en dispositivos móviles.

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

La auditoría de Lighthouse no tiene el tamaño adecuado puede ayudarte a automatizar el proceso de detección de elementos de entrada que son demasiado pequeños.

Diseñar para el pulgar

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

Haz que el texto sea lo suficientemente grande

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

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

Eso significa que debes usar un tamaño de píxeles mayor en dispositivos móviles: 16px en Chrome para computadoras es bastante legible, pero incluso con buena visión es difícil leer el texto 16px en Chrome para Android. Puedes configurar diferentes tamaños de píxeles de fuente para diferentes tamaños de viewport con las consultas de contenido multimedia. 20px se puede usar directamente en dispositivos móviles, pero deberías probarlo con amigos o colegas con problemas de visión.

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, apunta a alrededor de un dedo de margen.

Asegúrate de que las entradas se vean claramente

El estilo de borde predeterminado de las entradas dificulta la visualización. Son casi invisibles en algunas plataformas como Chrome para Android.

Además del padding, agrega un borde: sobre 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 validaciones básicas de formularios de entradas que tengan un atributo type. Los navegadores te advierten cuando envías un formulario con un valor no válido y establecen el foco en la entrada problemática.

Puedes usar el selector de 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 maneras de destacar las 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 de Show password para que los usuarios puedan verificar el texto que ingresaron. La usabilidad se ve afectada cuando los usuarios no pueden ver el texto que ingresaron. Por el momento, no hay una forma integrada de hacerlo, aunque hay planes de implementación. En su lugar, deberás usar JavaScript.

El siguiente código 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 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 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 definir las reglas de contraseña. Para ello, asígnale 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 función 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 las contraseñas sin darse cuenta.

<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 se incluyen más sugerencias para que los formularios sean accesibles.

Validar en tiempo real y antes del envío

Los elementos y atributos del formulario 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 validación de restricciones (gran compatibilidad) para agregar validación personalizada con la IU integrada del navegador a fin de establecer el enfoque y mostrar mensajes.

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

Analytics y RUM

"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.

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

• Estadísticas de páginas: Vistas de páginas de registro y acceso, porcentajes de rebote y salidas.
• Estadísticas de interacción: Embudos de objetivos (¿dónde abandonan los usuarios tu flujo de acceso o acceso?) y eventos (¿qué acciones realizan los usuarios cuando interactúan con tus formularios?)
• Rendimiento del sitio web: Se trata de métricas centradas en el usuario (¿por algún motivo tus formularios de registro y acceso son lentos y, de ser así, cuál es la causa?).

También puedes considerar la posibilidad de implementar pruebas A/B si quieres probar diferentes enfoques de registro y acceso, y lanzamientos en etapas para validar los cambios en un subconjunto de usuarios antes de publicarlos para todos los usuarios.

Lineamientos generales

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

• No hagas que los usuarios busquen acceder. Coloca un vínculo al formulario de acceso en la parte superior de la página con palabras bien comprendidas, como Acceder, Crear cuenta o Registrarse.
• Mantén la concentración Los formularios de registro no son un recurso para distraer a las personas con ofertas y otras funciones del sitio.
• Minimiza la complejidad del registro. Recopilar otros datos del usuario (como direcciones o detalles de la tarjeta de crédito) solo cuando los usuarios vean un beneficio claro de proporcionar esos datos
• Antes de que los usuarios comiencen en el formulario de registro, deja en claro cuál es la propuesta de valor. ¿Cómo se benefician del acceso? Brinda a los usuarios incentivos concretos para completar 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 no usen el correo electrónico.
• Haz que sea fácil para los usuarios restablecer su contraseña y haz que el vínculo ¿Olvidaste tu contraseña? sea obvio.
• Vínculo a los documentos de las Condiciones del Servicio y la Política de Privacidad: deja en 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 tus páginas de registro y de 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 otro contenido, en especial si tienen una URL significativamente diferente.

Seguir aprendiendo

• Crea formularios asombrosos
• Prácticas recomendadas para el diseño de formularios para dispositivos móviles
• Controles de formularios con mayor capacidad
• Cómo crear formularios accesibles
• Optimización del 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.