Obtener informaciĆ³n acerca de indicadores de estado visuales
Objetivos de aprendizaje
DespuƩs de completar esta unidad, podrƔ:
- Explicar la importancia del enfoque visual
- Definir un mensaje de error Ćŗtil
- Describir la forma de diseƱar un formulario accesible
Los estados de enfoque visual
Piense en un usuario que tiene buena vista, pero no puede usar el mouse. Las personas asĆ se conocen comĆŗnmente como usuarios de teclado con visiĆ³n, ya que pueden ver, pero sufren limitaciones de control del movimiento y solo usan un teclado o un conmutador para navegar en computadoras y aplicaciones web.
Mientras un usuario de mouse con visiĆ³n puede mover el cursor hasta un botĆ³n en el que desea hacer clic, un usuario de teclado con visiĆ³n puede usar una combinaciĆ³n de las teclas Tab y de flecha para desplazarse hasta el mismo botĆ³n. Por este motivo, es esencial mostrar visualmente siempre el estado actual del enfoque de teclado para que el usuario conozca su ubicaciĆ³n en todo momento. De hecho, es un requisito de la pauta Enfoque visible WCAG 2.4.7.
El siguiente ejemplo contiene una lista de hipervĆnculos. El vĆnculo Marca se encuentra enfocado. Visualmente, Marca se muestra subrayado dentro de un recuadro azul. Con estos dos estados de enfoque visual juntos, el usuario comprende claramente su ubicaciĆ³n al navegar con teclado por la pĆ”gina. Cuando el usuario presiona la tecla Tab, esta combinaciĆ³n de subrayado y recuadro desciende dentro de la lista.
Cuando el usuario ve este enfoque visual sobre el elemento deseado, sabe que puede presionar Intro para activar el vĆnculo.
Los navegadores tienen enfoque visual integrado de forma predeterminada. Chrome y Safari usan un halo azul, mientras que Internet Explorer y Firefox usan un recuadro punteado fino. Si no le agrada el aspecto del enfoque visual predeterminado o desea estandarizar el enfoque visual en todos los navegadores, lo invitamos a diseƱar uno propio.
Al diseƱar sus propios estados de enfoque visual, tenga en cuenta los requisitos WCAG 2.1 actualizados para el contraste no textual. Si sobrescribe el enfoque visual predeterminado de un navegador, el que cree deberĆ” cumplir o superar la relaciĆ³n de contraste de color de 3:1. En este documento, se explica este requisito con gran detalle. BĆ”sicamente, si tiene un fondo gris, no puede colocar un halo gris claro alrededor de un botĆ³n gris y considerar eso enfoque visual. Muchas personas no pueden ver eso, incluso las que tienen buena vista.
Diversos estados de componentes
En algunos casos, es necesario indicar visualmente el estado de un componente. Examinemos una casilla de verificaciĆ³n y sus diversos estados.
- Sin seleccionar: cuadrado redondeado, gris y elevado
- Seleccionada: cuadrado redondeado, gris, elevado y con una marca de verificaciĆ³n negra en su interior
- Sin seleccionar y desactivada: cuadrado redondeado, gris claro y hundido
- Seleccionada y desactivada: cuadrado redondeado, gris claro, hundido y con una marca de verificaciĆ³n gris en su interior
- Sin seleccionar y enfocada: cuadrado redondeado, gris, elevado y rodeado por un halo azul
- Seleccionada y enfocada: cuadrado redondeado, gris, elevado, con una marca de verificaciĆ³n negra en su interior y rodeado por un halo azul
Esto es importante si decide cambiar por completo la manera en que un usuario ve un componente. Consideremos la variante de casilla de verificaciĆ³n del componente SLDS Visual Picker.
En el siguiente ejemplo, Visual Picker contiene tres opciones alineadas horizontalmente.
Cada opciĆ³n contiene un icono envuelto en un cuadro con un borde gris y una etiqueta debajo. SemĆ”nticamente, cada una de estas opciones es una casilla de verificaciĆ³n HTML disfrazada, por lo que los usuarios pueden usar la tecla Tab para pasar de una a otra y presionar la barra espaciadora para alternar la selecciĆ³n de una u otra.
ĀæQuĆ© estados visuales diferentes se deben considerar para este elemento?
- Predeterminado (No activado por puntero, No enfocado, No seleccionado)
- Enfocado, No seleccionado
- Enfocado, Seleccionado
- No enfocado, Seleccionado
Predeterminado: icono envuelto en un cuadro con un borde gris y una etiqueta debajo.
Enfocado, No seleccionado: borde azul y etiqueta subrayada.
Enfocado, Seleccionado: cuadro completamente azul con una marca de verificaciĆ³n en el medio y la etiqueta subrayada.
No enfocado, Seleccionado: cuadro completamente azul con una marca de verificaciĆ³n en el medio y la etiqueta sin subrayar.
En la siguiente captura de pantalla, la primera opciĆ³n estĆ” seleccionada, pero no enfocada; la segunda opciĆ³n estĆ” enfocada, pero no seleccionada; y la tercera opciĆ³n no estĆ” ni seleccionada ni enfocada.
Observe que cada estado es visualmente diferente. ĀæCĆ³mo se aplican los estilos de activaciĆ³n por puntero aquĆ? La activaciĆ³n por puntero agrega un borde azul, pero no subraya el texto. Por lo tanto, este componente sigue la convenciĆ³n:
- Enfoque: borde azul y etiqueta sin subrayar
- ActivaciĆ³n por puntero: borde azul
- SelecciĆ³n: cuadro azul con marca de verificaciĆ³n
Estos tres estados contienen elementos visuales diferentes que se pueden mezclar y combinar para comunicar visualmente una superposiciĆ³n de estados.
Un aspecto que no se mostrĆ³ aquĆ son los estados desactivados para los selectores visuales seleccionados y sin seleccionar. Siguiendo los patrones existentes, ĀæcĆ³mo se pueden diferenciar estos dos estados adicionales? Vuelva a consultar las directrices de SLDS para ver la forma de hacerlo.
Formularios
Los formularios pueden parecer simples, pero es necesario considerar muchos aspectos al diseƱar formularios que todos puedan usar con Ʃxito.
Incluir siempre etiquetas visibles
En ocasiones, los diseƱadores desean usar texto de marcador de posiciĆ³n en lugar de etiquetas reales. Sin embargo, esto genera dos problemas.
- El texto de marcador de posiciĆ³n debe cumplir con la relaciĆ³n de contraste de color de 4.5:1, la cual hace que el campo de formulario parezca ya completado.
- Luego de que el usuario completa el formulario, el propĆ³sito de cada campo puede ser poco claro sin las etiquetas visibles. Los usuarios realizan mĆŗltiples tareas a la vez y no siempre completan todo el formulario en un flujo.
Supongamos que completĆ³ este formulario, se alejĆ³ para responder un correo y regresĆ³ para ver esto:
El formulario original lucĆa asĆ:
Es mejor colocar etiquetas visibles para que los usuarios vean el propĆ³sito de cada campo de formulario en todo momento:
DiseƱar mensajes de error Ćŗtiles
Cuando un campo de formulario contiene un error, un recuadro rojo alrededor no es indicio suficiente. Es posible que los usuarios daltĆ³nicos no puedan verlo, y un recuadro rojo solo no es demasiado Ćŗtil. AsegĆŗrese de incluir un texto de error debajo del campo para explicar la forma de corregirlo.
En la siguiente captura de pantalla, se muestra otro ejemplo de mensaje de error. En lugar de indicar āEsta fecha no es vĆ”lidaā, es mĆ”s Ćŗtil explicar el formato requerido para ingresar una fecha.
Guiar al usuario para completar correctamente el formulario
Si los formularios presentan un diseƱo deficiente, el usuario puede experimentar desde disgusto hasta ansiedad y confusiĆ³n. Los formularios mal diseƱados incluso pueden impedir que los usuarios completen su trabajo.
En los formularios extensos, defina expectativas claras desde el inicio sobre la cantidad de pasos necesarios o la cantidad de tiempo aproximada que se requiere para completar el formulario. Si un usuario estƔ en la mitad del proceso, indique el paso en el que se encuentra (por ejemplo, pƔgina 3 de 5).
Evite establecer lĆmites de tiempo para completar los formularios. Si debe usar un lĆmite de tiempo, notifique al usuario la cantidad de tiempo disponible antes de que inicie el proceso y permita las extensiones.
Brindar protecciones
A menudo, los usuarios realizan mĆŗltiples tareas o experimentan otras distracciones. Proporcione opciones para que los usuarios puedan regresar a editar sus entradas en el formulario, guardar durante el proceso o reiniciar el formulario por completo. AdemĆ”s, en la creaciĆ³n de formularios para transacciones financieras o legales, proporcione una manera en la que los usuarios puedan revisar, confirmar o deshacer los cambios. Esto es esencial para todo, incluido lo siguiente:
- Compras en lĆnea
- Transferencias de dinero (incluidas las operaciones de banca en lĆnea, PayPal, Venmo, etc.)
- Contratos electrĆ³nicos (como DocuSign y Adobe Document Cloud)
Recapitulemos
Los controles interactivos y las entradas de formulario son esenciales para el diseƱo de productos interactivos. Es importante diseƱar diferencias visuales para todos los estados de estos controles. AsĆ, los usuarios pueden saber cuĆ”ndo las opciones se encuentran enfocadas, seleccionadas, desactivadas, etc. El diseƱo de formularios con protecciones y directrices claras no solo elimina los obstĆ”culos para las personas con discapacidades cognitivas, sino que brinda una experiencia mĆ”s placentera a todos.