Comencemos con un formulario de registro. La mayoría de las empresas quieren relaciones a largo plazo con sus usuarios. Para hacer eso, necesitan que los usuarios se registren. Y para hacer eso , necesitan dar valor a los usuarios a cambio. Nadie quiere suscribirse a su servicio; solo quieren acceder a lo que sea que ofrezca, o la promesa de una experiencia más rápida la próxima vez que lo visiten.

A pesar de la apariencia básica del formulario de registro, hay muchas cosas a considerar: los elementos primitivos que componen un formulario (etiquetas, botones y entradas), formas de reducir el esfuerzo (incluso en formularios pequeños como este), hasta el formulario validación.

Al elegir un formulario tan simple, podemos ampliar las cualidades fundamentales que se encuentran en los formularios bien diseñados.

## Cómo podría verse

El formulario se compone de cuatro campos y un botón de envío. Cada campo se compone de un control (la entrada) y su etiqueta asociada.

Aquí está el HTML:

 <form> <label for="firstName">First name</label> <input type="text" name="firstName"> <label for="lastName">Last name</label> <input type="text" name="lastName"> <label for="email">Email address</label> <input type="email" name="email"> <label for="password">Create password</label> <input type="password" name="password" placeholder="Must be at least 8 characters"> <input type="submit" value="Register"> </form>

Las etiquetas son donde comienza nuestra discusión.

## Etiquetas

En Accesibilidad para todos , Laura Kalbag establece cuatro parámetros generales que mejoran la experiencia del usuario para todos:

• Visual : que sea fácil de ver.
• Auditivo : que sea fácil de escuchar.
• Motor : facilita la interacción.
• Cognitivo : que sea fácil de entender.

Al observar las etiquetas desde cada uno de estos puntos de vista, podemos ver cuán importantes son las etiquetas. Los usuarios videntes pueden leerlos, los usuarios con problemas de visión pueden escucharlos usando un lector de pantalla y los usuarios con problemas de motricidad pueden enfocar más fácilmente el campo gracias al área de impacto más grande. Esto se debe a que hacer clic en una etiqueta establece el foco en el elemento de formulario asociado.

Por estas razones, cada control que acepta entrada debe tener una <label> auxiliar. Los botones Enviar no aceptan entradas, por lo que no necesitan una etiqueta auxiliar: el atributo de value , que representa el texto dentro del botón, actúa como la etiqueta accesible.

Para conectar una entrada a una etiqueta, la id de la entrada y el atributo for de la etiqueta deben coincidir y ser únicos para la página. En el caso del campo de correo electrónico, el valor es “correo electrónico”:

 html < label for = "email" > Email address </ label > < input id = "email" >

No incluir una etiqueta significa ignorar las necesidades de muchos usuarios, incluidos aquellos con discapacidades físicas y cognitivas. Al centrarnos en las barreras reconocidas para las personas con discapacidad, podemos hacer que nuestros formularios sean más fáciles y sólidos para todos.

Por ejemplo, un área de golpe más grande es crucial para los usuarios con problemas de motricidad, pero también es más fácil de golpear para aquellos sin problemas.

## Marcadores de posición

El atributo de placeholder de posición está destinado a almacenar una pista. Brinda a los usuarios una guía adicional al completar un campo, particularmente útil para campos que tienen reglas complejas, como un campo de contraseña.

Como el texto del marcador de posición no es un valor real, está atenuado para que pueda diferenciarse de los valores ingresados ​​por el usuario.

A diferencia de las etiquetas, las sugerencias son opcionales y no deben usarse como algo habitual. El hecho de que exista el atributo de placeholder de posición no significa que tengamos que usarlo. No necesita un marcador de posición de "Ingrese su nombre" cuando la etiqueta es "Nombre", eso es una duplicación innecesaria.

Los marcadores de posición son atractivos debido a su estética minimalista que ahorra espacio. Esto se debe a que el texto del marcador de posición se coloca dentro del campo. Pero esta es una forma problemática de dar una pista a los usuarios.

Primero, desaparecen cuando el usuario escribe. El texto que desaparece es difícil de recordar, lo que puede causar errores si, por ejemplo, el usuario olvida cumplir con una de las reglas de contraseña. Los usuarios a menudo confunden el texto del marcador de posición con un valor, lo que hace que se omita el campo, lo que nuevamente causaría errores más adelante. El texto gris sobre blanco carece de suficiente contraste, por lo que generalmente es difícil de leer. Y para colmo, algunos navegadores no admiten marcadores de posición, algunos lectores de pantalla no los anuncian y es posible que se corten los textos de sugerencias largos.

Eso es un montón de problemas para lo que es esencialmente solo texto. Todo el contenido, especialmente una sugerencia de forma, no debe considerarse agradable de tener. Entonces, en lugar de usar marcadores de posición, es mejor colocar el texto de sugerencia sobre el control de esta manera:

 <div class="field"> <label for="password"> <span class="field-label">Password</span> <span class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</span> </label> <input type="password" name="password"> </div>

La sugerencia se coloca dentro de la etiqueta y dentro de un <span> para que pueda tener un estilo diferente. Al colocarlo dentro de la etiqueta, los lectores de pantalla lo leerán y ampliará aún más el área de impacto.

Como con la mayoría de las cosas en el diseño, esta no es la única forma de lograr esta funcionalidad. Podríamos usar atributos ARIA para asociar la sugerencia con la entrada:

 <div class="field"> <label for="password">Password</label> <p class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</p> <input type="password" name="password"> </div>

El atributo aria-describedby se usa para conectar la sugerencia por su id , al igual que el atributo for para las etiquetas, pero a la inversa. Se adjunta a la etiqueta del control y se lee después de una breve pausa. En este ejemplo, "la contraseña [pausa] debe contener más de ocho caracteres con al menos un número y una letra mayúscula".

Hay otras diferencias, también. En primer lugar, hacer clic en la sugerencia (un <p> en este caso) no enfocará el control, lo que reduce el área de impacto. En segundo lugar, a pesar del creciente apoyo de ARIA, nunca será tan compatible como los elementos nativos. En este caso particular, Internet Explorer 11 no es compatible aria-describedby . Es por eso que la primera regla de ARIA es no usar ARIA:

"Si puede usar un elemento o atributo HTML nativo con la semántica y el comportamiento que necesita ya incorporado, en lugar de reutilizar un elemento y agregar una función, estado o propiedad ARIA para que sea accesible, entonces hágalo ".

Etiquetas flotantes

El patrón de etiqueta flotante de Matt Smith es una técnica que utiliza la etiqueta como marcador de posición. La etiqueta comienza dentro del control, pero flota sobre el control a medida que el usuario escribe, de ahí el nombre. Esta técnica a menudo es elogiada por sus cualidades extravagantes, minimalistas y de ahorro de espacio.

Desafortunadamente, hay varios problemas con este enfoque. Primero, no hay espacio para una pista porque la etiqueta y la pista son lo mismo. En segundo lugar, son difíciles de leer debido a su bajo contraste y texto pequeño, ya que normalmente están diseñados. (Es necesario un contraste menor para que los usuarios tengan la oportunidad de diferenciar entre un valor real y un marcador de posición). En tercer lugar, al igual que los marcadores de posición, pueden confundirse con un valor y podrían recortarse.

Y las etiquetas flotantes en realidad no ahorran espacio. La etiqueta necesita espacio para mudarse en primer lugar. Incluso si ahorraran espacio, no es una buena razón para disminuir la facilidad de uso de los formularios.

"Parece mucho esfuerzo cuando simplemente puede poner etiquetas sobre las entradas y obtener todos los beneficios/ninguno de los problemas".
— Luke Wroblewski sobre etiquetas flotantes

Las interfaces extravagantes y minimalistas no hacen que los usuarios se sientan increíbles; las interfaces obvias, inclusivas y sólidas sí lo hacen. Reducir artificialmente la altura de formularios como este es poco convincente y problemático.

En su lugar, debe priorizar la creación de espacio para una etiqueta siempre presente y fácilmente disponible (y una pista si es necesario) al comienzo del proceso de diseño. De esta manera, no tendrá que exprimir el contenido en un espacio pequeño.

Discutiremos varias técnicas menos artificiales para reducir el tamaño de los formularios en breve.

## El protocolo de preguntas

Una forma poderosa y natural de reducir el tamaño de un formulario es usar un protocolo de preguntas. Ayuda a asegurarse de que sabe por qué está haciendo cada pregunta o incluye un campo de formulario.

¿El formulario de registro necesita recopilar nombre, apellido, dirección de correo electrónico y contraseña? ¿Existen formas mejores o alternativas de solicitar esta información que simplifiquen la experiencia?

Con toda probabilidad, no es necesario que solicite el nombre y apellido del usuario para que se registre. Si necesita esa información más adelante, por cualquier motivo, solicítela en ese momento. Al eliminar estos campos, podemos reducir a la mitad el tamaño del formulario. Todo sin recurrir a patrones novedosos y problemáticos.

### Inicio de sesión sin contraseña

Una forma de evitar pedir una contraseña a los usuarios es utilizar el patrón de inicio de sesión sin contraseña . Funciona haciendo uso de la seguridad del correo electrónico (que ya necesita una contraseña). Los usuarios ingresan solo su dirección de correo electrónico y el servicio envía un enlace especial a su bandeja de entrada. Al seguirlo, el usuario inicia sesión en el servicio de inmediato.

Esto no solo reduce el tamaño del formulario a un solo campo, sino que también evita que los usuarios tengan que recordar otra contraseña. Si bien esto simplifica el formulario de forma aislada, en otros aspectos agrega cierta complejidad adicional para el usuario.

Primero, los usuarios pueden estar menos familiarizados con este enfoque y muchas personas están preocupadas por la seguridad en línea. En segundo lugar, tener que pasar de la aplicación a su cuenta de correo electrónico es complicado, especialmente para los usuarios que conocen su contraseña o usan un administrador de contraseñas.

No es que una técnica sea siempre mejor que la otra. Es que un protocolo de preguntas nos insta a pensar en esto como parte del proceso de diseño. De lo contrario, agregaría sin pensar un campo de contraseña en el formulario y terminaría.

### Frases de contraseña

Las contraseñas son generalmente cortas, difíciles de recordar y fáciles de descifrar. Los usuarios a menudo tienen que crear una contraseña de más de ocho caracteres, compuesta por al menos una letra mayúscula, una minúscula y un número. Esta micro-interacción no es ideal.

"Lo siento, pero su contraseña debe contener una letra mayúscula, un número, un haiku, un signo de pandilla, un jeroglífico y la sangre de una virgen".
— Meme anónimo de Internet

En lugar de una contraseña, podríamos pedirles a los usuarios una frase de contraseña. Una frase de contraseña es una serie de palabras como "monkeysinmygarden" (lo siento, eso es lo primero que me viene a la mente). Por lo general, son más fáciles de recordar que las contraseñas y son más seguras debido a su longitud: las frases de contraseña deben tener al menos 16 caracteres.

La desventaja es que las frases de contraseña se usan con menos frecuencia y, por lo tanto, no son familiares. Esto puede causar ansiedad a los usuarios que ya están preocupados por la seguridad en línea.

Ya sea que se trate del patrón de inicio de sesión sin contraseña o de las frases de contraseña, solo debemos alejarnos de las convenciones una vez que hayamos realizado una investigación exhaustiva y diversa de los usuarios. No desea intercambiar un conjunto de problemas por otro sin saberlo.

## Estilo de campo

La forma en que diseña los componentes de su formulario estará determinada, al menos en parte, por la marca de su producto o empresa. Aún así, la posición de la etiqueta y los estilos de enfoque son consideraciones importantes.

### Posición de la etiqueta

Las pruebas de seguimiento ocular de Matteo Penzo demostraron que colocar la etiqueta encima (y no al lado) del control de formulario funciona mejor.

"Colocar una etiqueta justo sobre su campo de entrada permitió a los usuarios capturar ambos elementos con un solo movimiento ocular".

Pero hay otras razones para colocar la etiqueta encima del campo. En las ventanas pequeñas no hay espacio al lado del control. Y en ventanas de visualización grandes, acercar aumenta la posibilidad de que el texto desaparezca de la pantalla.

Además, algunas etiquetas contienen mucho texto, lo que hace que se envuelva en varias líneas, lo que interrumpiría el ritmo visual si se colocara junto al control.

Si bien debe tratar de mantener las etiquetas concisas, no siempre es posible. El uso de un patrón que se adapte a contenido variable (colocando etiquetas sobre el control) es una buena estrategia.

### Aspecto, tamaño y espacio

Los campos de formulario deben verse como campos de formulario. Pero, ¿qué significa eso exactamente?

Significa que un cuadro de texto debe verse como un cuadro de texto. Las cajas vacías significan "lléname" en virtud de estar vacías, como un libro para colorear. Esto pasa a ser parte de la razón por la que los marcadores de posición no son útiles. Eliminan la posibilidad percibida que proporcionaría un cuadro de texto vacío.

Esto también significa que el espacio vacío debe estar encuadrado (bordeado). Eliminar el borde, o tener solo un borde inferior, por ejemplo, elimina las prestaciones percibidas. Al principio, un borde inferior puede parecer un separador. Incluso si sabe que tiene que completar algo, ¿el valor va por encima o por debajo de la línea?

Espacialmente, la etiqueta debe estar más cerca de su control de formulario, no del control del campo anterior. Las cosas que aparecen juntas sugieren que pertenecen juntas. Tener el mismo espacio podría mejorar la estética, pero sería a costa de la usabilidad.

Finalmente, la etiqueta y el cuadro de texto en sí deben ser lo suficientemente grandes para leer y tocar. Esto probablemente signifique un tamaño de fuente de al menos 16 píxeles e, idealmente, un objetivo de toque general de al menos 44 píxeles.

### Estilos de enfoque

Los estilos de enfoque son una perspectiva más simple. De forma predeterminada, los navegadores ponen un contorno alrededor del elemento en foco para que los usuarios, especialmente aquellos que usan un teclado, sepan dónde están. El problema con el estilo predeterminado es que a menudo es tenue y difícil de ver, y algo feo.

Si bien este es el caso, no se sienta tentado a eliminarlo, ya que hacerlo disminuirá en gran medida la experiencia del usuario para aquellos que atraviesan la pantalla con el teclado. Podemos anular el estilo predeterminado para hacerlo más claro y estéticamente más agradable.

 input:focus { outline: 4px solid #ffbf47; }

## El campo de correo electrónico

A pesar de su apariencia simple, hay algunos detalles importantes que se han incluido en la construcción del campo que afectan la experiencia.

Como se señaló anteriormente, algunos campos tienen una pista además de la etiqueta, por lo que la etiqueta está dentro de un segmento secundario. La clase field-label nos permite darle estilo a través de CSS.

 <div class="field"> <label for="email"> <span class="field-label">Email address</span> </label> <input type="email" name="email"> </div>

La etiqueta en sí es "Dirección de correo electrónico" y usa mayúsculas y minúsculas. En "Argumentando el uso de mayúsculas y minúsculas", John Saito explica que las mayúsculas y minúsculas (a diferencia de las mayúsculas y minúsculas) generalmente son más fáciles de leer, más amigables y facilitan la detección de sustantivos. Depende de usted si presta atención a este consejo, pero sea cual sea el estilo que elija, asegúrese de usarlo de manera constante.

El atributo de type de entrada se establece en email , lo que activa un teclado en pantalla específico para el correo electrónico en los dispositivos móviles. Esto brinda a los usuarios un fácil acceso a @ y . (punto) símbolos que toda dirección de correo electrónico debe contener.

Las personas que utilicen un navegador no compatible verán una entrada de texto estándar ( <input type="text"> ). Esta es una forma de mejora progresiva, que es una piedra angular en el diseño de experiencias inclusivas.

### Mejora progresiva

La mejora progresiva tiene que ver con los usuarios. Simplemente hace que nuestras vidas como diseñadores y desarrolladores también sean más fáciles. En lugar de mantenernos al día con un conjunto de navegadores y dispositivos (¡lo cual es imposible!), podemos centrarnos en las funciones.

En primer lugar, la mejora progresiva se trata de brindar siempre a los usuarios una experiencia razonable, sin importar su navegador, dispositivo o calidad de conexión. Cuando las cosas van mal, y lo harán, los usuarios no sufrirán porque todavía pueden hacer las cosas.

Hay muchas maneras en que una experiencia puede salir mal. Quizás la hoja de estilo o el script no se cargan. Tal vez todo se cargue, pero el navegador del usuario no reconoce algunos HTML, CSS o JavaScript. Pase lo que pase, usar la mejora progresiva al diseñar experiencias evita que los usuarios lo pasen especialmente mal.

Comienza con HTML para la estructura y el contenido. Si CSS o JavaScript no se cargan, está bien porque el contenido está ahí.

Si todo se carga bien, quizás no se reconozcan varios elementos HTML. Por ejemplo, algunos navegadores no entienden <input type="email"> . Eso está bien, sin embargo, porque los usuarios obtendrán un cuadro de texto ( <input type="text"> ) en su lugar. Los usuarios aún pueden ingresar una dirección de correo electrónico; simplemente no tienen un teclado específico para correo electrónico en el móvil.

Tal vez el navegador no entienda algún CSS sofisticado y simplemente lo ignore. En la mayoría de los casos, esto no es un problema. Digamos que tiene un botón con border-radius: 10px . Los navegadores que no reconozcan esta regla mostrarán un botón con esquinas en ángulo. Podría decirse que la capacidad percibida del botón se reduce, pero los usuarios salen ilesos. En otros casos, podría ser útil utilizar consultas de características.

Luego está JavaScript, que es más complicado. Cuando el navegador intenta analizar métodos que no reconoce, se producirá un ataque de silbido. Esto puede hacer que sus otros scripts (válidos y admitidos) fallen. Si su secuencia de comandos no verifica primero que los métodos existen (detección de funciones) y funcionan (pruebas de funciones) antes de usarlos, es posible que los usuarios obtengan una interfaz rota. Por ejemplo, si el controlador de clics de un botón llama a un método que no se reconoce, el botón no funcionará. Eso es malo.

Así es como realzas. Pero lo que es mejor es no necesitar una mejora en absoluto. HTML con un poco de CSS puede brindar a los usuarios una excelente experiencia. Es el contenido lo que cuenta y no necesitas JavaScript para eso. Cuanto más pueda confiar en el contenido (HTML) y el estilo (CSS), mejor. No puedo enfatizar esto lo suficiente: muy a menudo, la experiencia básica es la mejor y la más eficaz. No tiene sentido mejorar algo si no agrega valor (consulte el principio de diseño inclusivo 7).

Por supuesto, hay ocasiones en las que la experiencia básica no es tan buena como podría ser; ahí es cuando es hora de mejorar. Pero si seguimos el enfoque anterior, cuando una parte de CSS o JavaScript no se reconoce o no se ejecuta, las cosas seguirán funcionando.

La mejora progresiva nos hace pensar en lo que sucede cuando las cosas fallan. Nos permite construir experiencias con resiliencia integrada. Pero igualmente, nos hace pensar si se necesita una mejora; y si es así, cuál es la mejor manera de hacerlo.

## El campo de contraseña

Estamos usando el mismo marcado que el campo de correo electrónico discutido anteriormente. Si está utilizando un lenguaje de plantilla, podrá crear un componente que se adapte a ambos tipos de campo. Esto ayuda a hacer cumplir el principio de diseño inclusivo 3, sea consistente .

 <div class="field"> <label for="password"> <span class="field-label">Choose password</span> <span class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</span> </label> <input type="password" name="password"> </div>

El campo de contraseña contiene una pista. Sin uno, los usuarios no entenderán los requisitos, lo que probablemente cause un error una vez que intenten continuar.

El atributo type="password" enmascara el valor de la entrada reemplazando lo que el usuario escribe con pequeños puntos negros. Esta es una medida de seguridad que evita que las personas vean lo que escribiste si están cerca.

### Una contraseña revelada

Ocultar el valor a medida que el usuario escribe hace que sea difícil corregir los errores tipográficos. Entonces, cuando se hace uno, a menudo es más fácil eliminar toda la entrada y comenzar de nuevo. Esto es frustrante ya que la mayoría de los usuarios no usan una computadora con una persona mirando por encima del hombro.

Debido al mayor riesgo de errores tipográficos, algunos formularios de registro incluyen un campo adicional "Confirmar contraseña". Esta es una medida de precaución que requiere que el usuario ingrese la misma contraseña dos veces, duplicando el esfuerzo y degradando la experiencia del usuario. En cambio, es mejor dejar que los usuarios revelen su contraseña, lo que habla de los principios 4 y 5, dar control y ofrecer opciones respectivamente. De esta manera, los usuarios pueden optar por revelar su contraseña cuando saben que nadie está mirando, lo que reduce el riesgo de errores tipográficos.

Las versiones recientes de Internet Explorer y Microsoft Edge proporcionan este comportamiento de forma nativa. Como crearemos nuestra propia solución, deberíamos suprimir esta característica usando CSS como este:

 input[type=password]::-ms-reveal { display: none; }

Primero, necesitamos inyectar un botón al lado de la entrada. El elemento <button> debe ser su elemento de acceso para cambiar cualquier cosa con JavaScript, excepto, es decir, para cambiar la ubicación, que es para lo que son los enlaces. Cuando se hace clic, debe alternar el atributo de tipo entre password y text ; y la etiqueta del botón entre "Mostrar" y "Ocultar".

 function PasswordReveal(input) { // store input as a property of the instance // so that it can be referenced in methods // on the prototype this.input = input; this.createButton(); }; PasswordReveal.prototype.createButton = function() { // create a button this.button = $('<button type="button">Show password</button>'); // inject button $(this.input).parent().append(this.button); // listen to the button's click event this.button.on('click', $.proxy(this, 'onButtonClick')); }; PasswordReveal.prototype.onButtonClick = function(e) { // Toggle input type and button text if(this.input.type === 'password') { this.input.type = 'text'; this.button.text('Hide password'); } else { this.input.type = 'password'; this.button.text('Show password'); } };

#### Sintaxis de JavaScript y notas arquitectónicas

Como hay muchas variantes de JavaScript y diferentes formas de diseñar componentes, vamos a analizar las opciones que se utilizan para construir el componente de revelación de contraseña y todos los próximos componentes del libro.

Primero, estamos usando un constructor. Un constructor es una función escrita convencionalmente en mayúsculas y minúsculas: PasswordReveal , no passwordReveal . Se inicializa con la new palabra clave, que nos permite usar el mismo código para crear varias instancias del componente:

 var passwordReveal1 = new PasswordReveal(document.getElementById('input1')); var passwordReveal2 = new PasswordReveal(document.getElementById('input2'));

En segundo lugar, los métodos del componente se definen en el prototipo, por ejemplo, PasswordReveal.prototype.onButtonClick . El prototipo es la forma más eficaz de compartir métodos entre varias instancias del mismo componente.

En tercer lugar, jQuery se utiliza para crear y recuperar elementos y escuchar eventos. Si bien jQuery puede no ser necesario o preferible, usarlo significa que este libro puede enfocarse en formularios y no en las complejidades de los componentes de varios navegadores.

Si usted es un diseñador que codifica un poco, entonces la ubicuidad y la baja barrera de entrada de jQuery deberían ser útiles. Del mismo modo, si prefiere no usar jQuery, no tendrá problemas para refactorizar los componentes según sus preferencias.

Es posible que también haya notado el uso de la función $.proxy . Esta es la implementación de jQuery de Function.prototype.bind . Si no usáramos esta función para escuchar eventos, entonces se llamaría al controlador de eventos en el contexto del elemento ( this ). En el ejemplo anterior, this.button no estaría definido. Pero queremos que this sea el objeto de revelación de contraseña, para que podamos acceder a sus propiedades y métodos.

#### Opciones de interfaz alternativas

La interfaz de revelación de contraseña que construimos anteriormente alterna la etiqueta del botón entre "Mostrar contraseña" y "Ocultar contraseña". Algunos usuarios de lectores de pantalla pueden confundirse cuando se cambia la etiqueta del botón; una vez que un usuario encuentra un botón, espera que ese botón persista. Aunque el botón es persistente, cambiar la etiqueta hace que parezca que no lo es.

Si su investigación muestra que esto es un problema, puede probar dos enfoques alternativos.

Primero, use una casilla de verificación con una etiqueta persistente de "Mostrar contraseña". El estado será señalado por el atributo checked . Los usuarios de lectores de pantalla escucharán "Mostrar contraseña, casilla de verificación, marcada" (o similar). Los usuarios videntes verán la marca de verificación de la casilla de verificación. El problema con este enfoque es que las casillas de verificación son para ingresar datos, no para controlar la interfaz. Algunos usuarios pueden pensar que su contraseña será revelada al sistema.

O, en segundo lugar, cambie el state del botón, no la etiqueta. Para transmitir el estado a los usuarios de lectores de pantalla, puede cambiar el atributo aria-pressed entre true (presionado) y false (no presionado).

 <button type="button" aria-pressed="true"> Show password </button>

Al enfocar el botón, los lectores de pantalla anunciarán: "Mostrar contraseña, botón de alternar, presionado" (o similar). Para los usuarios videntes, puede diseñar el botón para que se vea presionado o no presionado según corresponda usando el selector de atributos de esta manera:

 [aria-pressed="true"] { box-shadow: inset 0 0 0 0.15rem #000, inset 0.25em 0.25em 0 #fff; }

Solo asegúrese de que los estilos no presionados y presionados sean obvios y diferenciados, de lo contrario, los usuarios videntes pueden tener dificultades para notar la diferencia entre ellos.

### Microcopia

La etiqueta está configurada en "Elegir contraseña" en lugar de "Contraseña". Este último es algo confuso y podría pedirle al usuario que escriba una contraseña que ya posee, lo que podría ser un problema de seguridad. Más sutilmente, podría sugerir que el usuario ya está registrado, lo que hace que los usuarios con deficiencias cognitivas piensen que están iniciando sesión en su lugar.

Donde "Contraseña" es ambiguo, "Elegir contraseña" proporciona claridad.

## Estilos de botones

¿Qué es un botón? Nos referimos a muchos tipos diferentes de componentes en una página web como un botón. De hecho, ya he cubierto dos tipos diferentes de botones sin mencionarlos. Hagamos eso ahora.

Los botones que envían formularios son "botones de envío" y normalmente se codifican como <input type="submit"> o <button type="submit"> . El elemento <button> es más maleable en el sentido de que puedes anidar otros elementos dentro de él. Pero rara vez hay una necesidad de eso. La mayoría de los botones de envío contienen solo texto.

Nota: en versiones anteriores de Internet Explorer, si tiene varios <button type="submit"> s, el formulario enviará el valor de todos los botones al servidor, independientemente de cuál se haya hecho clic. Necesitará saber en qué botón se hizo clic para poder determinar el curso de acción correcto a tomar, razón por la cual se debe evitar este elemento.

Se inyectan otros botones en la interfaz para mejorar la experiencia con JavaScript, al igual que hicimos con el componente de revelación de contraseña discutido anteriormente. Ese también era un <button> pero su type se estableció en button (no submit ).

En ambos casos, lo primero que hay que saber sobre los botones es que no son enlaces. Los enlaces suelen estar subrayados (por estilos de agente de usuario) o posicionados especialmente (en una barra de navegación) para que se distingan entre el texto normal. Al pasar el cursor sobre un enlace, el cursor cambiará a un puntero. Esto se debe a que, a diferencia de los botones, los enlaces tienen una percepción de rendimiento débil.

En Resilient Web Design , Jeremy Keith analiza la idea de la honestidad material. Él dice: “Un material no debe usarse como sustituto de otro. De lo contrario, el resultado final es engañoso”. Hacer que un enlace parezca un botón es materialmente deshonesto. Les dice a los usuarios que los enlaces y botones son los mismos cuando no lo son.

Los enlaces pueden hacer cosas que los botones no pueden hacer. Los enlaces se pueden abrir en una nueva pestaña o marcar para más adelante, por ejemplo. Por lo tanto, los botones no deben verse como enlaces, ni deben tener un cursor de puntero. En cambio, deberíamos hacer que los botones se vean como botones, que tienen un rendimiento percibido naturalmente fuerte. Depende de usted si tienen esquinas redondeadas, sombras paralelas y bordes, pero deben verse como botones independientemente.

Los botones aún pueden dar retroalimentación sobre el desplazamiento (y el enfoque) cambiando el color de fondo, por ejemplo.

### Colocación

Los botones de envío generalmente se colocan en la parte inferior del formulario: con la mayoría de los formularios, los usuarios completan los campos de arriba a abajo y luego envían. Pero, ¿debería alinearse el botón a la izquierda, a la derecha o al centro? Para responder a esta pregunta, debemos pensar en dónde lo buscarán los usuarios de forma natural.

Las etiquetas de campo y los controles de formulario se alinean a la izquierda (en idiomas de lectura de izquierda a derecha) y se ejecutan de arriba a abajo. Los usuarios buscarán el siguiente campo debajo del último. Naturalmente, entonces, el botón de envío también debe colocarse en esa ubicación: a la izquierda y directamente debajo del último campo. Esto también ayuda a los usuarios que hacen zoom, ya que un botón alineado a la derecha podría desaparecer más fácilmente fuera de la pantalla.

### Texto

El texto del botón es tan importante como su estilo. El texto debe describir explícitamente la acción que se está tomando. Y como es una acción, debería ser un verbo. Deberíamos tratar de usar la menor cantidad de palabras posible porque es más rápido de leer. Pero no debemos quitar palabras a costa de la claridad.

Las palabras exactas pueden coincidir con el tono de voz de su marca, pero no intercambien claridad por extravagancia.

El lenguaje simple y sencillo es fácil de entender para todos. Las palabras exactas dependerán del tipo de servicio. Para nuestro formulario de registro, "Registrarse" está bien, pero dependiendo de su servicio, "Únase" o "Registrarse" podría ser más apropiado.

## Validación

A pesar de nuestros esfuerzos por crear una experiencia de registro inclusiva, simple y sin fricciones, no podemos eliminar el error humano. La gente comete errores y, cuando lo hacen, debemos solucionarlos de la forma más fácil posible.

Cuando se trata de la validación de formularios, hay una serie de detalles importantes a considerar. Desde elegir cuándo dar retroalimentación, hasta cómo mostrar esa retroalimentación, hasta la formulación de un buen mensaje de error, todas estas cosas deben tenerse en cuenta.

### Validación de HTML5

La validación de HTML5 existe desde hace un tiempo. Al agregar solo algunos atributos HTML, los navegadores compatibles marcarán los campos erróneos cuando se envíe el formulario. Los navegadores no compatibles recurren a la validación del lado del servidor.

Normalmente, recomendaría usar la funcionalidad que proporciona el navegador de forma gratuita porque suele ser más eficaz, robusta y accesible. Sin mencionar que se vuelve más familiar para los usuarios a medida que más sitios comienzan a usar la funcionalidad estándar.

Si bien el soporte de validación de HTML5 es bastante bueno, no se implementa de manera uniforme. Por ejemplo, el atributo requerido puede marcar campos como no válidos desde el principio, lo que no es deseable. Algunos navegadores, como Firefox 45.7, mostrarán un error de "Ingrese una dirección de correo electrónico" incluso si el usuario ingresó algo en el cuadro, mientras que Chrome, por ejemplo, dice "Incluya una '@' en la dirección de correo electrónico". que es más útil.

También queremos brindar a los usuarios la misma interfaz ya sea que los errores se detecten en el servidor o en el cliente. Por estas razones diseñaremos nuestra propia solución. Lo primero que debe hacer es desactivar la validación de HTML5: <form novalidate>

### Gestión de la presentación

Cuando el usuario envía el formulario, debemos verificar si hay errores. Si los hay, debemos evitar que el formulario envíe los detalles al servidor.

 function FormValidator(form) { form.on('submit', $.proxy(this, 'onSubmit')); } FormValidator.prototype.onSubmit = function(e) { if(!this.validate()) { e.preventDefault(); // show errors } };

Tenga en cuenta que estamos escuchando el evento de envío del formulario, no el evento de clic del botón. Este último impedirá que los usuarios puedan enviar el formulario presionando Intro cuando el foco esté dentro de uno de los campos. Esto también se conoce como envío de formulario implícito .

### Mostrar comentarios

Está muy bien detectar la presencia de errores, pero en este punto los usuarios no son más sabios. Hay tres partes dispares de la interfaz que deben actualizarse. Hablaremos de cada uno de ellos ahora.

#### Titulo del documento

El <title> del documento es la primera parte de una página web que los lectores de pantalla leerán. Como tal, podemos usarlo para informar rápidamente a los usuarios que algo salió mal con su envío. Esto es especialmente útil cuando la página se vuelve a cargar después de una solicitud del servidor.

Si bien estamos mejorando la experiencia del usuario al detectar errores en el cliente con JavaScript, no todos los errores se pueden detectar de esta manera. Por ejemplo, verificar que una dirección de correo electrónico aún no se haya tomado solo se puede verificar en el servidor. Y, en cualquier caso, JavaScript es propenso a fallar, por lo que no podemos confiar únicamente en su disponibilidad.

Donde el título de la página original podría decir "Registrarse para [servicio]", en caso de error debería decir "(2 errores) Registrarse para [servicio]" (o similar). La redacción exacta depende un poco de la opinión.

El siguiente JavaScript actualiza el título:

 document.title = "(" + this.errors.length + ")" + document.title;

Como se señaló anteriormente, esto es principalmente para usuarios de lectores de pantalla, pero como suele ser el caso con el diseño inclusivo, lo que ayuda a un grupo de usuarios también ayuda a todos los demás. Esta vez, el título actualizado actúa como una notificación en la pestaña.

Resumen de errores

En comparación con el elemento del título, el resumen del error es más prominente, lo que les dice a los usuarios videntes que algo salió mal. Pero también es responsable de permitir que los usuarios entiendan qué salió mal y cómo solucionarlo.

Está ubicado en la parte superior de la página para que los usuarios no tengan que desplazarse hacia abajo para verlo después de actualizar la página (en caso de que se detecte un error en el servidor). Convencionalmente, los errores se colorean en rojo. Sin embargo, confiar solo en el color podría excluir a los usuarios daltónicos. Para llamar la atención sobre el resumen, considere también usar la posición, el tamaño, el texto y la iconografía.

El panel incluye un encabezado, "Hay un problema", para indicar el problema. Tenga en cuenta que no dice la palabra "Error", que no es muy amigable. Imagina que estabas completando tus datos para comprar un automóvil en una sala de exhibición y cometiste un error. El vendedor no diría "Error"; de hecho, sería extraño que dijera eso.

 <div class="errorSummary" role="group" tabindex="-1" aria-labelledby="errorSummary-heading"> <h2>There's a problem</h2> <ul> <li><a href="#emailaddress">Enter an email address</a></li> <li><a href="#password">The password must contain an uppercase letter</a></li> </ul> </div>

El contenedor tiene un role de group , que se utiliza para agrupar un conjunto de elementos de la interfaz: en este caso, el encabezado y los enlaces de error. El atributo tabindex se establece en -1 , por lo que se puede enfocar mediante programación con JavaScript (cuando el formulario se envía con errores). Esto garantiza que el panel de resumen de errores se desplace a la vista. De lo contrario, la interfaz parecería no responder y rota cuando se envíe.

Nota: El uso tabindex="0" significa que se podrá enfocar de forma permanente mediante la tecla Tabulador , que es un error de WCAG de orden de enfoque 2.4.3. Si los usuarios pueden tabular a algo, esperan que realmente haga algo.

 FormValidator.prototype.showSummary = function () { // ... this.summary.focus(); };

Debajo, hay una lista de enlaces de error. Al hacer clic en un enlace, se enfocará en el campo erróneo, lo que permite a los usuarios saltar rápidamente al formulario. El atributo href del enlace se establece en la identificación del control, que en algunos navegadores es suficiente para establecer el foco en él. Sin embargo, en otros navegadores, hacer clic en el enlace simplemente desplazará la entrada a la vista, sin enfocarla. Para arreglar esto, podemos enfocar la entrada explícitamente.

 FormValidator.prototype.onErrorClick = function(e) { e.preventDefault(); var href = e.target.href; var id = href.substring(href.indexOf("#"), href.length); $(id).focus(); };

Cuando no hay ningún error, el panel de resumen debe estar oculto. Esto garantiza que solo haya un panel de resumen en la página y que aparezca constantemente en la misma ubicación, ya sea que el cliente o el servidor presenten los errores. Para ocultar el panel, debemos agregar una clase de hidden .

 <div class="errorSummary hidden" ...></div>

 .hidden { display: none; }

Nota: podría usar el atributo/propiedad hidden para alternar la visibilidad de un elemento, pero hay menos soporte para ello. El diseño inclusivo se trata de tomar decisiones que sabes que es poco probable que excluyan a las personas. Usar una clase se alinea con esta filosofía.

#### Errores en línea

Necesitamos poner el mensaje de error relevante justo encima del campo. Esto evita que los usuarios se desplacen hacia arriba y hacia abajo en la página para verificar el mensaje de error y los mantiene moviéndose hacia abajo en el formulario. Si el mensaje se colocara debajo del campo, aumentaríamos la posibilidad de que el panel de autocompletar del navegador o el teclado en pantalla lo ocultaran.

 <div class="field"> <label for="blah"> <span class="field-error"> <svg width="1.5em" height="1.5em"><use xmlns:xlink="https://www.w3.org/1999/xlink" xlink:href="#warning-icon"></use></svg> Enter your email address. </span> <span class="field-error">Enter an email address</span> </label> </div>

Al igual que el patrón de sugerencias mencionado anteriormente, el mensaje de error se inyecta dentro de la etiqueta. Cuando el campo está enfocado, los usuarios de lectores de pantalla escucharán el mensaje en contexto, por lo que pueden moverse libremente por el formulario sin tener que consultar el resumen.

El mensaje de error es rojo y utiliza un icono de advertencia SVG para llamar la atención de los usuarios. Si hubiéramos usado solo un cambio de color para indicar un error, esto excluiría a los usuarios daltónicos. Así que esto funciona muy bien para los usuarios videntes, pero ¿qué pasa con los usuarios de lectores de pantalla?

Para brindarles a los usuarios videntes y no videntes una experiencia equivalente, podemos usar el atributo aria-invalid bien soportado. Cuando el usuario enfoca la entrada, ahora anunciará "No válido" (o similar) en los lectores de pantalla.

 <input aria-inval>

Nota: El formulario de registro solo consta de entradas de texto. En el capítulo 3, "Un formulario de reserva de vuelo", veremos cómo inyectar errores de forma accesible para grupos de campos como botones de opción.

### Enviar el formulario de nuevo

Al enviar el formulario por segunda vez, debemos borrar los errores existentes de la vista. De lo contrario, los usuarios pueden ver errores duplicados.

 FormValidator.prototype.onSubmit = function(e) { this.resetPageTitle(); this.resetSummaryPanel(); this.removeInlineErrors(); if(!this.validate()) { e.preventDefault(); this.updatePageTitle(); this.showSummaryPanel(); this.showInlineErrors(); } };

### Inicialización

Habiendo terminado de definir el componente FormValidator , ahora estamos listos para inicializarlo. Para crear una instancia de FormValidator , debe pasar el elemento de formulario como primer parámetro.

 var validator = new FormValidator(document.getElementById('registration'));

Para validar el campo de correo electrónico, por ejemplo, llama al método addValidator() :

 validator.addValidator('email', [{ method: function(field) { return field.value.trim().length > 0; }, message: 'Enter your email address.' },{ method: function(field) { return (field.value.indexOf('@') > -1); }, message: 'Enter the 'at' symbol in the email address.' }]);

El primer parámetro es el name del control y el segundo es una matriz de objetos de regla. Cada regla contiene dos propiedades: method y message . El method es una función que prueba varias condiciones para devolver true o false . False pone el campo en un estado de error, que se usa para llenar la interfaz con errores como se discutió anteriormente.

#### Perdonar errores triviales

En The Design of Everyday Things , Don Norman habla sobre diseñar para el error. Habla sobre la forma en que la gente conversa:

“Si una persona dice algo que creemos que es falso, cuestionamos y debatimos. No emitimos una señal de advertencia. No pitamos. No damos mensajes de error. […] En conversaciones normales entre dos amigos, las declaraciones erróneas se toman como normales, como aproximaciones a lo que realmente se quiso decir”.

A diferencia de los humanos, las máquinas no son lo suficientemente inteligentes como para determinar el significado de la mayoría de las acciones, pero a menudo son mucho menos indulgentes con los errores de lo que deberían ser. Jared Spool hace una broma sobre esto en "¿El diseño es métricamente opuesto?" (alrededor de 42 minutos en):

“Se necesita una línea de código para tomar un número de teléfono y eliminar todos los guiones, paréntesis y espacios, y se necesitan diez líneas de código para escribir un mensaje de error en el que los dejaste”.

El método addValidator (que se muestra arriba) demuestra cómo diseñar reglas de validación para que perdonen errores triviales. La primera regla, por ejemplo, recorta el valor antes de verificar su longitud, lo que reduce la carga para el usuario.

### Validación en línea en vivo

La validación en línea en vivo brinda retroalimentación a los usuarios a medida que escriben o cuando abandonan el campo ( onblur ). Hay alguna evidencia que muestra que la validación en línea en vivo mejora la precisión y reduce los tiempos de finalización en formularios largos. Esto tiene que ver en parte con dar retroalimentación a los usuarios cuando los requisitos del campo están frescos en la mente de los usuarios. Pero la validación en línea en vivo (o validación en vivo para abreviar) plantea varios problemas.

Para las entradas que requieren un cierto número de caracteres, la primera pulsación de tecla siempre constituirá una entrada no válida. Esto significa que los usuarios serán interrumpidos antes de tiempo, lo que puede hacer que cambien de contexto mental, desde ingresar información hasta corregirla.

Alternativamente, podríamos esperar hasta que el usuario ingrese suficientes caracteres antes de mostrar un error. Pero esto significa que los usuarios solo reciben comentarios después de haber ingresado un valor correcto, lo cual no tiene sentido.

Podríamos esperar hasta que el usuario abandone el campo ( onblur ), pero es demasiado tarde ya que el usuario se ha preparado mentalmente (ya menudo ha comenzado a escribir) el siguiente campo. Además, algunos usuarios cambian de ventana o usan un administrador de contraseñas cuando usan un formulario. Si lo hace, se activará el evento de desenfoque, lo que provocará que se muestre un error antes de que el usuario termine. Todo muy frustrante.

Recuerde, no hay ningún problema en dar retroalimentación a los usuarios sin actualizar la página. Tampoco hay problema con poner los mensajes de error en línea (junto a los campos); ya lo hemos hecho. El problema con los comentarios en vivo es que interrumpe a los usuarios demasiado pronto o demasiado tarde, lo que a menudo resulta en una experiencia discordante.

Si los usuarios ven errores con frecuencia, es probable que haya algún problema en otro lugar. Concéntrese en acortar su formulario y brindar una mejor orientación (buen etiquetado y texto de sugerencias). De esta forma, los usuarios no deberían ver más que algún que otro error. Veremos formas más largas en el próximo capítulo.

### Patrón de afirmación de lista de verificación

Una variación de la validación en vivo consiste en marcar las reglas (marcarlas como completas) a medida que el usuario escribe. Esto es menos invasivo que la validación en vivo, pero no se adapta a todos los tipos de campo. Aquí hay un ejemplo del formulario de registro de MailChimp, que emplea esta técnica para el campo de contraseña.

Debes poner las reglas encima del campo. De lo contrario, el teclado en pantalla podría ocultar los comentarios. Como resultado, los usuarios pueden dejar de escribir y ocultar el teclado para luego revisar los comentarios.

### Una nota sobre la desactivación de los botones Enviar

Algunos formularios están diseñados para deshabilitar el botón de envío hasta que todos los campos sean válidos. Hay varios problemas con esto.

En primer lugar, los usuarios se preguntan qué está realmente mal con sus entradas. En segundo lugar, los botones deshabilitados no se pueden enfocar, lo que dificulta que los usuarios ciegos naveguen con la tecla Tabulador para descubrir el botón. Tercero, los botones deshabilitados son difíciles de leer ya que están atenuados.

Como estamos brindando a los usuarios comentarios claros, cuando el usuario lo espera, no hay una buena razón para quitarle el control al deshabilitar el botón de todos modos.

### Elaboración de un buen mensaje de error

No hay nada más importante que el contenido. Los usuarios no vienen a su sitio web para disfrutar del diseño. Vienen a disfrutar el contenido o el resultado de usar un servicio.

Incluso la experiencia más pensada, inclusiva y bellamente diseñada no sirve de nada si ignoramos las palabras utilizadas para crear mensajes de error. Un estudio mostró que mostrar mensajes de error personalizados aumentaba las conversiones en un 0,5 %, lo que equivalía a más de 250 000 libras esterlinas en ingresos anuales.

“El contenido es la experiencia del usuario”.
—Ginny rojizo

Al igual que las etiquetas, las sugerencias y cualquier otro contenido, un buen mensaje de error brinda claridad en la menor cantidad de palabras posible. Normalmente, debemos impulsar el diseño de una interfaz en función del contenido, no al revés. Pero en este caso, entender cómo y por qué muestras mensajes de error influye en el diseño de las palabras. Es por eso que Jared Spool dice que “el contenido y el diseño son compañeros de trabajo inseparables”.

Estamos mostrando mensajes en el resumen en la parte superior de la pantalla y al lado de los campos. Mantener dos versiones del mismo mensaje es difícil de vender por una ganancia poco convincente. En su lugar, diseñe un mensaje de error que funcione en ambos lugares. “Ingrese un símbolo 'arroba'” necesita el contexto de la etiqueta del campo para que tenga sentido. "Su dirección de correo electrónico necesita un símbolo 'arroba'" funciona bien en ambos lugares.

Evite las bromas, como comenzar cada mensaje de error con "Por favor". Por un lado, esto parece cortés; por el otro, estorba e implica una elección.

Sea cual sea el enfoque que adopte, habrá alguna repetición debido a la naturaleza del contenido. Y la prueba generalmente implica enviar el formulario sin ingresar ninguna información. Esto hace que la repetición sea notoriamente obvia, lo que puede hacer que nos volvamos locos. Pero, ¿con qué frecuencia es este el caso? La mayoría de los usuarios no intentan romper la interfaz.

Diferentes errores requieren un formato diferente. Instrucciones como “Ingrese su nombre” son naturales. Pero "Ingrese un nombre que tenga 35 caracteres o menos" es más largo, más verboso y menos natural que una descripción como "El nombre debe tener 35 caracteres o menos".

Aquí hay una lista de verificación:

• Sé conciso. No utilice más palabras de las necesarias, pero no omita palabras a costa de la claridad.
• Se consistente. Use el mismo tono, las mismas palabras y la misma puntuación en todo momento.
• Se específico. Si sabe por qué algo salió mal, dígalo. "El correo electrónico no es válido". es ambiguo y pone la carga sobre el usuario. “El correo electrónico necesita un símbolo 'arroba'” es claro.
• Sea humano, evite la jerga. No utilice palabras como inválido, prohibido y obligatorio.
• Utilice un lenguaje sencillo. Los mensajes de error no son una oportunidad para promover el tono de voz humorístico de su marca.
• Usa la voz activa. Cuando un error es una instrucción y le dices al usuario qué hacer. Por ejemplo, "Ingrese su nombre", no "Se debe ingresar el nombre".
• No culpes al usuario. Hágales saber lo que salió mal y cómo solucionarlo.

## Resumen

En este capítulo, resolvimos varios desafíos fundamentales de diseño de formularios que se aplican mucho más allá de un simple formulario de registro. En muchos aspectos, este capítulo ha tratado tanto de lo que no se debe hacer como de lo que se debe hacer. Al evitar patrones de ahorro de espacio novedosos y artificiales para centrarnos en reducir la cantidad de campos que incluimos, evitamos varias fallas de usabilidad y, al mismo tiempo, hacemos que los formularios sean más agradables.

### Cosas a evitar

• Uso del atributo de placeholder de posición como mecanismo para almacenar etiquetas y texto de sugerencias.
• Uso de tipos de entrada incorrectos.
• Botones de estilo y enlaces de la misma.
• Validación de campos a medida que los usuarios escriben.
• Deshabilitar los botones de envío.
• Uso de jerga compleja y microcopia influenciada por la marca.

Y eso es. Si te ha gustado este primer capítulo de los Patrones de diseño de formularios , puedes hacerte con el libro ya mismo. ¡Feliz lectura!