Skip to main content
ƚnase a nosotros en TDX, San Francisco o en Salesforce+ del 5 al 6 de marzo en la conferencia de desarrolladores para la era del agente de la IA. Regƭstrese ahora.

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. Una lista de hipervĆ­nculos. El vĆ­nculo Marca se encuentra enfocado y subrayado dentro de un recuadro azul.

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

Imagen de los seis estados de la casilla de verificaciĆ³n descritos anteriormente.

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.

Visual Picker con la etiqueta ā€œAgregar los siguientes objetosā€ y las tres opciones disponibles debajo: Cuenta, Prospecto, Pedidos.

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.

Tres iconos envueltos en un cuadro con bordes grises y etiquetas debajo: icono de Cuenta, icono de Prospecto e icono de Pedidos.

Enfocado, No seleccionado: borde azul y etiqueta subrayada.

Tres iconos envueltos en un cuadro con bordes y etiquetas escritas debajo: icono de Cuenta, icono de Prospecto e icono de Pedidos. El icono de Cuenta tiene un borde azul y estĆ” subrayado para indicar que estĆ” enfocado y seleccionado.

Enfocado, Seleccionado: cuadro completamente azul con una marca de verificaciĆ³n en el medio y la etiqueta subrayada.

Tres iconos envueltos en un cuadro con bordes y etiquetas escritas debajo: icono de Cuenta, icono de Prospecto e icono de Pedidos. El icono de Cuenta pasa a tener una marca de verificaciĆ³n en el medio, el color del cuadro es azul, y la etiqueta Cuenta estĆ” subrayada para indicar que estĆ” enfocada y seleccionada.

No enfocado, Seleccionado: cuadro completamente azul con una marca de verificaciĆ³n en el medio y la etiqueta sin subrayar.

Tres iconos envueltos en un cuadro con bordes y etiquetas escritas debajo: icono de Cuenta, icono de Prospecto e icono de Pedidos. El icono de Cuenta pasa a tener una marca de verificaciĆ³n en el medio, el color del cuadro es azul, y la etiqueta Cuenta no estĆ” subrayada.

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. 

Tres iconos envueltos en un cuadro con bordes y etiquetas escritas debajo: icono de Cuenta, icono de Prospecto e icono de Pedidos. El icono de Cuenta pasa a tener una marca de verificaciĆ³n en el medio, el color del cuadro es azul, y la etiqueta Cuenta no estĆ” subrayada; pero la etiqueta Prospecto contigua estĆ” subrayada.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:

Formulario de ubicaciĆ³n con listas desplegables para InglĆ©s, InglĆ©s (SudĆ”frica) y (GMT-09:30) Hora de Marquesas (PacĆ­fico/Marquesas).

El formulario original lucĆ­a asĆ­:

Formulario de ubicaciĆ³n con listas desplegables para Seleccionar idioma, Seleccionar configuraciĆ³n regional y Seleccionar zona horaria.

Es mejor colocar etiquetas visibles para que los usuarios vean el propĆ³sito de cada campo de formulario en todo momento:

Formulario de ubicaciĆ³n con listas desplegables para Idioma, ConfiguraciĆ³n regional y Zona horaria.

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. 

Un buen ejemplo de un mensaje de error donde se indica ā€œCompletar este campoā€. Un mal ejemplo donde se encuadra en rojo el campo que se debe completar.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.

Un mal ejemplo de un mensaje de error donde se indica ā€œUtilice el formato de fecha correctoā€. Un buen ejemplo donde se brinda al usuario un ejemplo del formato de fecha correcto: ā€œSu entrada no coincide con el formato permitido MMM d, aaaaā€.

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.

Recursos

Comparta sus comentarios de Trailhead en la Ayuda de Salesforce.

Nos encantarƭa saber mƔs sobre su experiencia con Trailhead. Ahora puede acceder al nuevo formulario de comentarios en cualquier momento en el sitio de Ayuda de Salesforce.

MĆ”s informaciĆ³n Continuar a Compartir comentarios