Accesibilidad de formularios en entornos de realidad virtual. Metaverso inclusivo.

En el metaverso también hay formularios. Quizás no es lo que uno espera, pero así es.

En general, podemos aplicar todo lo que sabemos sobre accesibilidad y usabilidad en formularios de páginas web, aplicaciones móviles o documentos, pues parece que se está trasladando literalmente lo que conocemos a un entorno que es nuevo, diferente y que ofrece muchas más posibilidades.

Después de rellenar uno de estos formularios, siempre me pregunto cómo habríamos ideado la inclusión de esta información en el metaverso si no tuviéramos el bagaje de décadas de formularios web. Pero, de momento, es lo que hay.

En este artículo, todos los ejemplos son capturas de formularios en mundo virtuales que he realizado con unas Oculus Meta Quest 2.

Índice

• Etiquetas visibles y comprensibles
• Instrucciones para evitar errores
• Mensajes de error en la validación
• No uses el color para transmitir información
• Ofrece sugerencias si es posible
• Evita poner límites de tiempo
• Información sobre el estado
• Contraste de color
• Ubicación
• Pide confirmación y permite revisar los datos
• Tamaño de los elementos
• Teclado virtual
• Los botones del formulario
• Reflexión final

Artículos relacionados

• Accesibilidad en XR, metaverso accesible e inclusivo. Guía de accesibilidad en entornos de Realidad Virtual (VR)
• Mi investigación sobre accesibilidad en entornos de realidad virtual (VR) 2023. Metaverso accesible e inclusivo.

Etiquetas visibles y comprensibles

Cada campo de formulario debe tener una etiqueta visible asociada.

En los campos de tipo texto y en los campos desplegables (select) la etiqueta debe estar colocada delante o encima del campo. Por el contrario, en los campos de tipo radio o de tipo casilla de verificación (check), la etiqueta debe estar colocada después del campo.

Es importante que la etiqueta siga visible cuando escribas un dato en el campo, de lo contrario, no sabremos qué dato se nos está solicitando.

Por otra parte, las etiquetas de los campos deben ser comprensibles, tenemos que tener claro qué dato se nos pide en el campo.

También es útil, cuando el formulario tiene muchos campos, agruparlos temática y visualmente.

Ejemplo correcto

Este es el formulario de registro de Immerse, un entorno de realidad virtual donde puedes aprender y practicar idiomas.

Las etiquetas de este formulario están bien situadas respecto a los campos. Además, son siempre visibles, aunque los campos cojan el foco o se escriba en su interior.

Ejemplo incorrecto

Este es el formulario de acceso a Engage, una plataforma de negocio para crear tus propios mundos virtuales.

En este formulario, la etiqueta de los campos de texto está dentro del campo y, aunque permanece visible cuando el campo coge el foco, desaparece cuando se escribe dentro del mismo.

Podríamos preguntarnos qué sentido tiene ocultar la contraseña en esta pantalla, puesto que es la de acceso y solo la veo yo.

En realidad, puedo tener la gafas sincronizadas con el móvil; o estar proyectando en otro dispositivo, como una televisión; o retransmitiendo, para que otras personas puedan ver lo que yo veo, lo cual es muy útil cuando haces pruebas con usuarios o le enseñas a alguien a utilizar las gafas. En estos casos es necesario poder ocultar la contraseña.

Instrucciones para evitar errores

En los formularios hay que dar las instrucciones necesarias para evitar errores en su cumplimentación. Por ejemplo, hay que indicar los campos obligatorios o los formatos y rangos de valores requeridos.

Esta información puede estar asociada a cada campo o darse de manera general en el formulario, por ejemplo, al principio del mismo si todos los campos son obligatorios.

Este tipo de información es importante y no puede estar situada dentro del campo, pues la perderíamos al escribir en él, tal y como he comentado en el caso de las etiquetas.

Ejemplo correcto

Este es el formulario para ponerte un contador en Arthur, un entorno de trabajo y colaboración en realidad virtual. La ayuda bajo el primer campo, siempre visible, nos indica que el tiempo debe estar expresado en minutos.

En el formulario de registro de Immerse, que ya hemos comentado, cuando el campo contraseña coge el foco se muestra un tooltip con las características que debe tener la contraseña para ser válida. Hay una instrucción inicial indicando que deben rellenarse los campos, aunque podría ser más explícita.

Ejemplo incorrecto

En el buscador de formularios de evaluación de Engage, hay dos campos de tipo fecha cuya etiqueta está dentro del campo. En esa etiqueta se indica además el formato de fecha que se espera. Esto es incorrecto, pues al escribir en el campo perdemos esta información.

Mensajes de error en la validación

Cuando se produce un error de validación, el mensaje de error debe explicar claramente por qué se ha producido el error. También debe quedar claro qué campo ha dado el error.

Es habitual encontrar formularios que no muestran errores de validación y en los que, por tanto, debes adivinar qué campo ha dado error y por qué ha dado error.

Ejemplo correcto

Este es el formulario del primer paso para el registro en Engage. Cuando pulsas el botón “Registrarse” se marcan los errores que has cometido. No tienes dudas sobre los campos que han dado error ni de qué error se ha producido.

Sin embargo, ten en cuenta que lo más importante es evitar los errores. Si en este formulario se informara de los campos obligatorios, se estaría previniendo que se cometieran errores.

No uses el color para transmitir información

Hay personas que no pueden, o les resulta difícil, distinguir los colores. Por esta razón, no se debe utilizar el color para transmitir información. Por ejemplo, no uses el color para indicar cuáles son los campos obligatorios, erróneos o seleccionados; o para distinguir los enlaces del texto que les rodea.

Por otra parte, recuerda que las instrucciones no pueden darse tampoco haciendo referencia solo a aspectos sensoriales como el color, la forma, la posición o el sonido. Por ejemplo, sería incorrecto incluir una instrucción como “Los campos erróneos están resaltados en rojo” o "Cuando se produzca un error oirás un pitido".

Ejemplo incorrecto

Este es el formulario para crear un examen de evaluación en Engage. Al pulsar el botón “Guardar la respuesta” se han resaltado con un color diferente los campos obligatorios no rellenos. Los errores deben indicarse con texto.

Ejemplo incorrecto

En el formulario de acceso a Arthur, se puede observar que hay enlaces que se diferencian solo por el color del texto que les precede, con el que tampoco tienen una ratio de contraste suficiente. Este error es habitual y se puede observar en otros formularios de este artículo.

Ofrece sugerencias si es posible

A veces, cuando se comete un error en un campo, es muy útil que te ofrezcan sugerencias de valores posibles y disponibles.

Ejemplo incorrecto

Este es el tercer paso del formulario de registro de Engage. Si incluyes un nombre de usuario que ya está en uso, el mensaje te informa del error, pero no te sugiere nombres de usuario disponibles similares. Esto te obliga a ir probando con distintas opciones.

Ejemplo correcto

Un tipo de información que puede ser de ayuda cuando rellenas un campo es saber su longitud máxima.

Este es el formulario para crear un mundo en Meta Horizon. En el campo “Name”, donde escribes el nombre que quieres darle al mundo, se indica la longitud del campo y cuántos caracteres se han escrito en él.

Evita poner límites de tiempo

Hay personas que necesitan más tiempo para realizar las tareas. Evita incluir límites de tiempo a menos que este sea muy extenso, de lo contrario, permite que el límite de tiempo pueda ser cancelado o ampliado.

Ejemplo correcto

En los formularios de evaluación que creas en Engage, puedes elegir que sean con o sin tiempo:

Información sobre el estado

Se tiene que saber el estado de los componentes del formulario, ¿el campo tiene el foco? ¿está seleccionado? ¿está deshabilitado?

Ejemplo correcto

En este formulario de evaluación de Engage, el radio que está seleccionado está marcado y resaltado con un color que contrasta con el fondo negro. Por desgracia, no se ha tenido en cuenta que, aunque el fondo azul del campo resaltado contrasta con el fondo negro, su texto blanco ya no contrasta sobre este azul y es poco legible, así que en ese aspecto concreto no es un buen ejemplo.

En el formulario se indica que es un formulario “sin temporizador”, algo que hemos comentado en el apartado anterior que es lo más recomendable para que todas las personas tengan tiempo suficiente para responder.

Estos formularios los tienes luego disponibles en la tablet asociada a tu mano en los diferentes mundos de Engage, desde la cual puedes acceder a una evaluación, modificarla o crear una nueva.

Contraste de color

Los textos deben tener suficiente contraste con el fondo. Es muy habitual encontrar textos que no contrastan con el fondo, y no solo en formularios, pues tengo que decir que el metaverso también está lleno de texto, pero de eso hablaré otro día.

Las WCAG 2.1 indican que el contraste mínimo en el nivel AA es de 4,5:1 para texto pequeño y 3:1 para texto grande. En el nivel AAA es de 7:1 para texto pequeño y 4,5:1 para texto pequeño.

En el caso de otros elementos no textuales, como los bordes de los campos de formulario o de los botones, deben alcanzar al menos un contraste de 3:1.

Es cierto que en el metaverso podemos acercarnos a los objetos, pero no siempre podemos acercarnos tanto como quisieramos. A veces, tampoco se muestran a tu misma altura si accedes sentado, ni siempre puedes configurar este aspecto. Tampoco tienes muchas veces la opción de poder ampliar el texto. Por otra parte, si necesitas gafas en el mundo real y por comodidad no te las pones con las gafas de realidad virtual, verás más borroso.

En resumen, es importante el tamaño del texto y el color.

Ejemplo incorrecto

En esta captura del listado de formularios de evaluación de Engage, el botón con borde verde no alcanza la ratio mínima de contraste con el fondo.

Ubicación

Es una buena práctica ubicar a las personas para que sepan en todo momento dónde se encuentran.

Ejemplo correcto

En el menú de configuración de Altspace, metaverso social por desgracia actualmente ya no disponible, la opción en la que nos encontramos, “Settings”, y la opción de menú concreta, “General”, están resaltadas. En el caso de “General” no se resalta solo por el color, sino que tiene una marca adicional. En el caso de “Settings”, aunque se marca con el color, la diferencia de contraste es muy superior a 3:1 (el contraste es de 5,9:1).

Ejemplo correcto

El formulario de registro de Engage tiene tres pasos y en cada uno se informa de cuántos pasos hay y en cuál nos encontramos.

Pide confirmación y permite revisar los datos

Cuando un proceso implica varios pasos, se debe permitir volver a los pasos anteriores, o bien tener una pantalla de resumen para poder revisar los datos antes de confirmar.

Por otra parte, antes de borrar datos, pide confirmación.

Ejemplo correcto

Ventana de solicitud de confirmación antes del borrado de datos. Sí, en el metaverso también hay ventanas modales.

Tamaño de los elementos

Los elementos de interacción deben tener un tamaño adecuado para que sean sencillos de pulsar.

Ejemplo correcto

Este es el formulario para crear notas en Arthur. El tamaño de sus botones hace que sean fáciles de pulsar.

En algunos entornos, el foco tiene un imán para ayudar a pulsar los botones, como en Immerse. En cualquier caso, siempre es preferible tener botones grandes.

Además, este formulario es un ejemplo de flexibilidad en los métodos de entrada de datos, ya que permite añadir nota por texto y nota por voz.

Teclado virtual

Para rellenar los campos de formulario siempre usas un teclado virtual, diferente según la aplicación.

Se agradece cuando el teclado tiene las teclas grandes y los caracteres o datos que necesitas para rellenar campos concretos.

Ejemplo correcto

En el formulario para acceder a Immerse hay un campo solicitando el email. El teclado virtual me ofrece de manera destacada las opciones que necesito, no solo la “@” sino opciones como “@gmail.com” o “@yahoo.com”.

Los botones del formulario

Los formularios deberían tener siempre un botón. Por otra parte, si tienen botón para borrar o cancelar, debería diferenciarse del principal para evitar errores.

Ejemplo correcto

Ejemplo de formulario de opciones de configuración con un botón "Aceptar". La captura está tomada del juego Beat Saber.

Ejemplo correcto

En el formulario para crear un contador en Arthur, el botón "Cancel" es diferente y menos relevante que el botón “Start Timer”.

Reflexión final

Si estás acostumbrado a evaluar formularios en web, aplicaciones móviles o documentos, seguramente te haya llamado la atención que no he nombrado los requisitos habituales para que los formularios sean accesibles mediante lector de pantalla.

La razón es que no existe en estos entornos una tecnología equivalente al lector de pantalla y, por tanto, hoy en día son completamente inaccesibles para las personas ciegas.

Por lo demás, este podría haber sido un artículo resumiendo los requisitos de accesibilidad y usabilidad de un formulario web.

Me queda esa sensación, como indicaba al comienzo del artículo, de que se está trasladando lo que ya conocemos a un entorno que es nuevo y en gran medida diferente, y me pregunto cómo habríamos ideado la inclusión de esta información en el metaverso si no tuviéramos el bagaje de décadas de formularios web.

---

Todas las imágenes de este artículo son capturas realizadas por Olga Carreras con unas Oculus Meta Quest 2.

---

Artículos de Olga Carreras sobre accesibilidad en VR (Realidad Virtual)

• General - Diferentes discapacidades
  • Accesibilidad en XR, metaverso accesible e inclusivo. Guía de accesibilidad en entornos de Realidad Virtual (VR), 2022
  • Ejemplos de opciones de accesibilidad en entornos de realidad virtual (VR) 2023. Metaverso accesible e inclusivo, 2023
  • Accesibilidad de formularios en entornos de realidad virtual. Metaverso inclusivo, 2023
• Discapacidad auditiva
  • Subtítulos inmersivos. Informe final del grupo de trabajo del WAI-W3C "Immersive Captions Community Group"
• Análisis de aplicaciones VR concretas
  • Probando las características de accesibilidad de Cosmonious High (Realidad Virtual), 2023
  • Opciones de accesibilidad en un laboratorio de química en Realidad Virtual (VR), accesibilidad en entornos de aprendizaje , 2023
  • Viajar en Realidad Virtual. Opciones de accesibilidad. Metaverso y turismo inclusivo, 2024
• Reseñas de libros
  • Reseña del libro "Immersive Content and Usability" de Preston So
  • Reseña del Libro blanco de accesibilidad para desarrolladores de videojuegos de AEVI y Fundación ONCE
• Cursos, ponencias, congresos
  • Resumen de todas las presentaciones sobre accesibilidad en XR del 2024 XR Access Symposium. Insights from XR Assistive Technology
  • Cursos gratuitos de accesibilidad en Pamplona (octubre de 2023). PDF accesibles. Metaverso accesible.

Aceptar/Cancelar o Cancelar/Aceptar

Ayer me preguntaban en Twitter mi opinión sobre cuál debe ser en web el orden de los botones:

1. Aceptar/Cancelar, siguiendo el orden de lectura natural como hace Windows.
2. Cancelar/Aceptar, poniendo la conclusión, la acción que te lleva hacia delant,e a la derecha como hace Apple.

Antes de continuar recomiendo el artículo “OK–Cancel or Cancel–OK?” de Jakob Nielsen

En función del tipo de usuarios con los que testeemos, podremos encontrar preferencias para todos los gustos, a veces en función de la plataforma que usan y otras veces no.

Sin embargo, la respuesta según mi opinión a cuál es el orden más recomendable no es ni la “a”, ni la “b”, ni siquiera que los pongas en función del porcentaje de usuarios Windows vs MAC que tengas según las estadísticas de tu sitio. Para mi, la respuesta adecuada es que el orden no es lo realmente importante como explico a continuación.

Supongamos que vamos a testear un formulario con los siguientes botones:

y que comprobamos que los usuarios se equivocan y esperan encontrar el botón “Aceptar” a la izquierda. ¿Lo importante es el orden? ¿es eso lo que debemos cambiar?

Veamos otras modificaciones posibles que no implican cambiar el orden de los botones pero que evitan las equivocaciones de los usuarios:

En este ejemplo, se busca un nombre más específico para el botón “Aceptar”, se muestra seleccionado por defecto, se centra con el formulario y su literal se pone en negrita y un poco más grande.

Da igual como los coloques, derecha o izquierda, la claridad de los mismos es independiente de su orden:

 

En función del formulario podemos buscar un literal también más específico para el botón “Cancelar”, que incluso se puede incluir como un enlace.

 

Y según el tipo de portal, la libertad en el diseño ayudará también a diferenciar los botones:

Por tanto, las claves para mí, no son el orden, sino:

• mantener la consistencia en el orden y la presentación de los botones en todas las páginas del sitio
• cuidar el copy de los botones para que sea lo más específico posible
• pero sobre todo, diferenciar visualmente la acción principal de la opción secundaria como he ejemplificado antes

Desde un punto de vista de accesibilidad

Todo lo dicho anteriormente está enfocado a decidir si el orden de los botones ayuda a evitar errores a los usuarios que visualizan el formulario .

Sin embargo, hay otros factores asociados al tema del orden de los botones que puede ayudarnos a decidir cuál poner primero:

• El primer botón será el que aparezca resaltado y el que responderá a la tecla Enter. Es verdad que esto se puede modificar, aunque con javascript.
• El usuario que se mueve con el tabulador por el formulario llegará en primer lugar al primer botón. También esto se puede modificar, pero entonces incumpliríamos la pauta de mantener la coherencia entre el orden visual y el del foco.

Estos dos factores favorecen a los usuarios que utilizan lectores de pantalla, aunque hay que recodar que tienen atajos de teclado para acceder al listado de elementos del formulario, o para ir a los botones de la página.

Si la pregunta es cuál es el orden que yo prefiero, me viene a la memoria la discusión que duró días con una aplicación del Santander con la que se hizo al final un documento específico sobre el tema, y se puso Aceptar a la derecha. Es la opción que yo prefiero como usuaria (y lo soy de Windows) pues asocio Cancelar con Volver y Aceptar con Siguiente. Pero esto son ya preferencias personales y batallitas.

Artículos relacionados

• Formularios usables: 60 Directrices de Usabilidad
• Formularios accesibles según las WCAG 2.0
• Formulario con varios botones. Implementación usable y accesible
• Enlaces que actúan como botones. Implementación accesible.
• Sirius. Nueva sistema para la evaluación de la usabilidad web
• Arquitectura de información. Fundamentos

Formularios usables: 60 Directrices de Usabilidad

Artículos relacionados
[19-07-07] Formulario con varios botones. Implementación usable ...
[02-06-09]Formularios accesibles según las WCAG 2.0

Fuentes del artículo

60 Directrices para realizar formularios usables

Generales

1. Pida sólo la información absolutamente necesaria.

2. Infiera información a partir de otra disponible.

Por ejemplo, la provincia se puede inferir del C.P.

3. Reutilice los campos cuando sea posible.

Por ejemplo, el email puede servirnos en ocasiones como nombre de usuario.

4. No pida la información dos veces.

Por ejemplo, si el usuario ha rellenado la dirección de facturación, no le obligue a volver a rellenar la dirección de envío si no es necesario, pregúntele si quiere que sea la misma.

Textos

5. Proporcione un título al formulario que exprese claramente su función.

6. Si necesita instrucciones, que sean breves y comprensibles.

7. Utilice una nomenclatura clara y familiar, sin tecnicismos ni extranjerismos.

8. Sea consistente en el uso de los términos.

Es decir, use siempre las mismas palabras para los mismos conceptos.

9. No utilice preguntas complejas ni haga pensar al usuario.

10. Redacte siempre las opciones de forma afirmativa.

Por ejemplo, junto a un check escriba “Deseo recibir el boletín" en vez de "No deseo recibir el boletín".

Organización

11. Organice los campos en una sola columna de datos.

Sin entrar en las razones de accesibilidad que lo justifican (ver "75 Directrices de accesibilidad de Jakob Nielsen") me cuesta muchas discusiones hacer comprender que, apelotonando los datos en la misma línea o colocándolos en varias columnas, se pierde tanto a nivel de usabilidad que no merece la pena el espacio vertical que se gana.

Como siempre, hay muchos contextos de uso y excepciones justificables, como los formularios que se rellenan de forma repetitiva y constante, pero la excepción nunca puede convertirse en norma.

Una sola columna funciona mejor. Los formularios con dos columnas tienen más probabilidades de que los usuarios pasen por alto algunos campos, dado que crean un orden ambiguo de lectura. Sus ojos se moverán hacia donde espera encontrar el próximo campo, que será habitualmente hacia abajo, en vertical. No esperan a que se les indique mediante el parpadeo del cursor dónde mirar.

[En "Formularios largos: ¿una pantalla con scroll o varias páginas?" de Usolab (resumen en español del artículo "Caroline's Corner - Long Forms: Scroll or Tab?" de Caroline Jarrett)]

12. Organice los campos en grupos lógicos, utilizando para ello la mínima cantidad de elementos visuales (evitando así ruido visual).

13. Agrupe, si es posible, los campos obligatorios al comienzo del formulario.

14. Evite fragmentar la petición de información.

Por ejemplo, no pida por separado el tipo de vía, la calle, el número, etc. si no es estrictamente necesario.

15. Proporcione un diseño ordenado, alineando verticalmente todas las etiquetas y todos los campos entre si.

Todos los campos deben estar verticalmente alineados entre sí a la izquierda.

¿Cómo alinear las etiquetas entre sí: a la derecha, a la izquierda o las colocamos encima del campo?

• Si tenemos que rellenar datos que son familiares (y no son muchos): Etiquetas en vertical encima del campo.
• Cuando necesitemos ajustar el espacio vertical: Etiquetas a la izquierda del campo, alineadas a la derecha.
• Hay que ajustar el espacio vertical, y los datos no nos son familiares o son complejos: Etiquetas al lado del campo, alineadas a la izquierda.

"Consejos para el diseño de formularios": resumen en español de las conclusiones de Luke Wroblewski

16. Sitúe las respuestas de los campos radio buttons y check box después de los mismos.

De esta manera se favorece la alineación vertical de todos los controles.

17. Utilice etiquetas estándar para agrupar campos y hacer más manejable la información(OPTGROUP, FIELDSET)

18. Si se utilizan radio buttons o checks box agrupe visualmente de forma clara y unívoca los distintos grupos de opciones.

19. Distinga visualmente los campos deshabilitados siguiendo las normas de facto (poniéndolos en gris claro)

Tipos de campos

20. El tamaño visible de los campos de texto debe corresponderse con la longitud del contenido que ha de introducir el usuario.

21. Homogeneice los anchos de los campos de texto cuando estos sean similares (evitando así ruido visual).

22. Dote a los campos de texto de flexibilidad para que admitan los datos en cualquier formato.

Por ejemplo, un campo para introducir el número teléfono debería admitir paréntesis, guiones, espacios; un campo para introducir importes debería admitir decimales con punto o con coma, etc.

23. Evite el uso de combos.

No las use por ejemplo para seleccionar el país, fecha o profesión a no ser que sea estrictamente necesario, en cuyo caso incluya una opción del tipo “Otros” que pueda englobar casos no recogidos en las opciones proporcionadas.

24. Evite que las combos recarguen la página para rellenar otros campos, pero cuando así sea, asegúrese de que el formulario conserva el mismo estado que tenía antes de recargar la página: con los mismos campos visibles o activos, y con todos los campos rellenos con los mismos datos que antes de la recarga.

25. Si se utilizan combos o radio buttons seleccione siempre una opción por defecto, asegurándose de que sea la más probable.

De lo contrario, el usuario no puede volver al estado inicial del formulario; si es necesario incluya una opción "Ninguna".


26. Si se utiliza un check box para presentar una única opción que no es obligatoria (recibir publicidad, aceptar unas cláusulas) no la marque por defecto.

27. Si se utilizan radio buttons asegúrese de que todas las opciones son claramente excluyentes.

• No los utilice cuando las respuestas sean más de tres y complejas, o más de cinco y simples.
• Siempre que se cumpla la regla anterior, utilice radio buttons en vez de combos

28. Si un radio button tiene más de dos respuestas, colóquelas en vertical, unas debajo de otras alineadas a la izquierda.

Funcionamiento

29. Valore la posibilidad de evitar, mediante JavaScript, que en determinados campos se pueda introducir determinados caracteres.

Por ejemplo, que en el campo DNI sólo se puedan introducir números y letras, haciendo que el resto de caracteres no se puedan teclear en el campo.

[A mí, personalmente, no me gusta esta práctica]

30. No implemente saltos automáticos del foco del formulario.

Por ejemplo, en los campos de cuenta, no haga que el foco se mueva sólo al siguiente campo cuando se ha rellenado el anterior.

Un error típico es introducir el salto automático entre campos de texto consecutivos y hacer innecesario el uso del tabulador.

Aunque este comportamiento puede parecer que facilita la tarea de introducción de datos, no es adecuado porque quita control a los usuarios, no es un funcionamiento estándar y es necesario mirar la pantalla para saber en que campo se está.

Todo ello puede provocar fácilmente errores, como por ejemplo, introducir datos pertenecientes a un campo en el siguiente cuando no se introduce el formato esperado por el salto automático.

[En "Controles de formularios en diseño web, radio buttons, check-boxes..." de Eduardo Manchón]

Además es un práctica prohibida en las WCAG 2.0 "3.2.2 On Input: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A)" aunque admiten que se implemente si se avisa antes al usuario de este comportamiento.

31. Asegúrese de que la tecla "Intro" realiza la acción principal.

32. Evite, mediante JavaScript, que el usuario pueda impacientarse y enviar dos veces el formulario.

33. Al implementar la validación de los formularios (o al limitar el tamaño de los campos) piense si su formulario puede ser utilizado por usuarios de otros países.

Por ejemplo, el C.P. o el teléfono no tienen la misma longitud en unos países que en otros; por ejemplo, en España hay usuarios que no tienen DNI sino tarjeta de residencia.

Ayudas

34. Identifique claramente los campos obligatorios y los opcionales mediante el literal (Obligatorio) u (Opcional), según si se van a marcar los obligatorios o los opcionales, colocando dicho literal detrás de la etiqueta del campo y por tanto antes del campo.

Para saber si marcar los obligatorios o los opcionales seguir las directrices de Luke Wroblewski:

• Indique los campos obligatorios cuando sean menos que los opcionales.
• Indique los campos opcionales cuando sean menos que los obligatorios.

Para saber por qué poner el texto (Obligatorio) u (Opcional) después del literal y no después del campo, o por qué se debe indicar mediante un texto y no mediante un asterisco, leer "75 Directrices de accesibilidad de Jakob Nielsen"

35. Incluir ayudas breves o ejemplos junto a los campos, pero sólo cuando sea realmente necesario para saber cómo ingresar un dato.

Asegúrese de que al leer en línea estas ayudas o ejemplos se lean antes que el campo, por ello, un buen lugar para colocarlas es encima del campo. Para comprender por qué colocarlas en esta posición leer: "75 Directrices de accesibilidad de Jakob Nielsen"

Botones

36. No incluya un botón "Reset" (es decir, de Limpiar o Borrar el formulario)

37. En los formularios de un sólo paso evite tener un botón "Cancelar" cuya función sea en realidad volver a la página anterior.

38. Distinga entre las acciones primarias y secundarias (volver, imprimir etc.) de su formulario.

Evite las secundarias, pero si ha de incluirlas distíngalas visualmente de forma inequívoca, destacando visualmente las primarias.

Por ejemplo, poniendo las acciones primarias como botones y las secundarias como enlaces.

39. Coloque los botones o enlaces que realizan las acciones primarias (por ejemplo el botón "Enviar") lo más cerca posible del último campo del formulario. No los separé del formulario mediante, por ejemplo, una línea.

40. Dé un nombre adecuado a los botones del formulario, relacionado con su acción y no de carácter general.

Por ejemplo, use "Buscar" en vez de un genérico "Aceptar".

Errores

41. Cuando se produzca un error al rellenar el formulario proporcione en la parte superior del mismo, y con suficiente contraste, un listado de los errores. Por cada error indique qué campo lo ha provocado, por qué motivo, cómo solucionarlo y un enlace al campo.

42. Destaqué los campos que han dado error pero no se base para ello únicamente en el color.

Acompáñelos de un icono de error que aparezca también en el resumen del comienzo de la página.

Repita el mensaje de error al lado del campo para no tener que volver a la lista inicial para saber qué error lo provocó. Ver un ejemplo de cómo mostrar los errores de un formulario.

43. Cuando se produzca un error, el formulario no debe resetearse, es decir, los campos no erróneos deben seguir manteniendo la información en ellos introducida.

44. Redactar claramente los textos de error mediante términos claros, sencillos y no técnicos.

No utilizar mensajes genéricos del tipo “No se ha podido enviar el formulario”.

45. Evite validar los campos uno a uno, cuando pierden el foco, mostrando inmediatamente un mensaje de error al usuario. A los usuarios les incomoda esta práctica.

Feedback

46. Cuando el usuario envíe el formulario, infórmele del resultado de su acción: indíquele si se ha realizado correctamente, qué datos se han enviado, cómo puede ponerse en contacto con los responsables del sitio si ha habido problemas o para hacer un seguimiento del mismo, o cómo puede modificar los datos enviados.

47. Si el proceso de envío es lento, incluya en la página un mensaje de "enviando datos".

Respuesta

48. Informe a los usuarios de por qué deben rellenar el formulario y cuándo y a través de que medio recibirán una respuesta.

49. Si es un formulario de contacto envíe un email automático confirmado que se ha recibido.

50. Si es un formulario de contacto, asegúrese de que la empresa tenga los mecanismos necesarios para responder de forma rápida y adecuada al mismo.

Legalidad

51. Incluya las cláusulas de protección de datos cuando sea pertinente.

Accesibilidad

52. Asocie explícitamente las etiquetas con sus controles mediante LABEL y su atributo "for".

53. Compruebe que el tabulador permite acceder a todos los campos en el mismo orden que el visual.

54. Mejore la experiencia del usuario mediante JavaScript y AJAX pero asegúrese que el formulario funcione correctamente sin ellos.

55. No establezca un límite de tiempo ajustado para complementar el formulario.

Formularios extensos

56. Si los formularios son muy extensos la solución no son las columnas, sino la división en páginas bien rotuladas que indiquen al usuario en que paso está del proceso (por ejemplo Paso 3 de 4).

57. Si el formulario se presenta en varias páginas hay que seguir el lema 1 tema = 1 página.

58. El usuario debe poder volver a los pasos anteriores.

59. No solicite información externa en medio del proceso mediante la abertura de una ventana nueva del navegador.

60. Evite la utilización de pestañas para crear formularios de varias páginas.

Fuentes

• "Best Practices for Form Design" de Luke Wroblewski
  
• "Formularios usables" de Javier Cabrera
  
• "Usabilidad al diseñar formularios de contacto" de Reynier Matos Padilla
  
• "Formularios" en desarrolloweb.com
  
• "Directrices de usabilidad para el diseño de formularios" de Josep Casanovas
  
• "Controles de formularios en diseño web, radio buttons, check-boxes..." de Eduardo Manchón
  
• "El principio de Visibilidad y el de Guiar en lugar de controlar: ¿son incompatibles? " de Josep M. Junoy
  
• "Formularios en la web, recomendaciones generales de diseño" de Eduardo Manchón
  
• "Usability and HTML Forms" de Andrew Starling
  
• "Reset and Cancel Buttons" de Jakob Nielsen
  
• "Checkboxes vs. Radio Buttons" de Jakob Nielsen
  
• "Should I use a drop-down? Four steps for choosing form elements on the Web" de Sarah Miller and Caroline Jarrett
  
• "Caroline's Corner - Long Forms: Scroll or Tab?" de Caroline Jarrett
  
• "Simplified Form Errors" de Adam Kalsey
  
• "Developing an Online Form" de usability.org
  
• "Usabilidad y Accesibilidad de sitios web. Lista de comprobaciones" del Laboratorio Aragonés de Usabilidad
  
• Las Elmer 2: User interface guidelines for governmental forms on the Internet (PDF), guía del Gobierno de Noruega sobre la creación de formularios usables y accesibles.

Artículos relacionados
[19-07-07] Formulario con varios botones. Implementación usable ...
[02-06-09]Formularios accesibles según las WCAG 2.0