Change language to Cambiar idioma a inglés

Validación de Formularios y Recuperación de Errores Usable y Accesible

Publicado el 26/01/2015 @ 8:00am

[Traducción del artículo en inglés "Usable and Accessible Form Validation and Error Recovery" Copyright © www.webaim.org]

Contenidos del Artículo

Introducción

La validación de formularios es el proceso que comprueba y asegura que los usuarios han introducido toda la información necesaria y en el formato correcto en un formulario. Recuperación de errores es el proceso mediante el cual se guía al usuario para que corrija la información que falta o que es incorrecta y que se detectó durante la validación del formulario. Hay muchos métodos para realizar validación de formularios y recuperación de errores. Estos métodos se pueden clasificar en, 1) del lado del servidor - la información del formulario se manda y analiza en el servidor web a través de un lenguaje de script (como PHP, JSP, Perl, etc.) con los mensajes y recomendaciones escritos en una página que se genera de nuevo; o 2) en el lado del cliente - la validación del formulario y recuperación de errores se realiza en el cliente web o navegador usando JavaScript. Hay ventajas para cada uno de estos métodos.

Ventajas de validación y recuperación de errores en el servidor:

  • El formulario se puede completar y enviar sin interrupciones por alertas de validación, errores o avisos.
  • No requiere que el navegador del cliente soporte o tenga activados los scripts.
  • Es más seguro - los mecanismos de validación no se pueden saltar ni modificar.

Ventajas de validación y recuperación de errores en el cliente:

  • La validación puede hacerse antes de que el formulario se complete y se mande al servidor.
  • No requiere lenguajes de script en el servidor.

Algunos usuarios pueden desactivar los scripts. Por esto, los desarrolladores no deberían requerir ningún código en el lado del cliente para que el formulario funcione correctamente. Además, cualquier validación en el lado del cliente puede ser modificada o desactivada. Los programadores web pueden aprovechar los beneficios de la validación y recuperación de errores tanto en el lado del cliente como en el del servidor para asegurarse que sus formularios se completan de una manera usable y accesible.

Construyendo formularios usables

Como desarrollador, el primer paso para asegurar que los formularios se completan correctamente es hacer que el formulario sea sencillo y accesible. Esto se puede conseguir:

  • Suministrando todas las instrucciones e indicaciones necesarias.
  • Asociando todos los controles del formulario con un texto usando la etiqueta label.
  • Asociando grupos de casillas de verificación y radiobotones usando fieldset y legend.
  • Asignando un orden lógico de lectura y navegación.
  • Asegurándose de que el formulario se puede completar y enviar utilizando el teclado.
  • Comprobando que los controles, etiquetas y funcionalidad del formulario son fáciles de comprender y usar.

Si tu formulario necesita que cierto control sea seleccionado o completado, deberías indicárselo al usuario de una manera usable, accesible y clara. Las instrucciones deberían aparecer normalmente junto a o dentro del control requerido. Porque los usuarios de lectores de pantalla pueden navegar de control en control en lugar de dejar que el lector de pantalla lea el formulario de forma continua, colocar la información importante dentro de la etiqueta, permite que el lector de pantalla lo lea cuando se enfoca el control. La etiqueta debería ser descriptiva y visualmente clara.

Ejemplo

<label for="nombre">Nombre
<span style="color:red">(requerido)</span></label><br />
<input type="text" name="nombre" id="nombre" />

Se muestra:


El atributo aria-required también puede usarse para identificar campos requeridos a los usuarios de lectores de pantalla, especialmente si la etiqueta de texto que acompaña al campo no lo indica o si los campos obligatorios están se marcan con colores diferentes o un arterisco.

Si la información debe tener un formato concreto, las instrucciones adecuadas deben suministrarse dentro del label del control o a través de otro contenido asociado (como con aria-describedby). En muchos casos, los programadores pueden simplificar los formularios si no especifican un formato en particular. Si un formato concreto (ej: para los teléfonos) es necesario, por ejemplo, para que el campo se guarde en una base de datos, se pueden usar lenguajes de script para dar el formato adecuado, facilitando la tarea del usuario.

Escondiendo campos del formulario

Hay algunos casos en los que los programadores prefieren esconder visualmente algunas de las etiquetas de un formulario. Esto es normal cuando se usan formularios complejos con tablas y la cabecera identifica la función o propósito de muchos controles dentro de esa fila o columna. Mirando las cabeceras es aparente qué información debe ir en qué control. Puede ser tedioso mostrar las mismas etiquetas una y otra vez en un formulario complejo. Se complica más aún porque un elemento de tipo label puede asociarse sólo con un control del formulario. Desafortunadamente, si el <label> no está presente, los lectores de pantalla pueden ser incapaces de identificar el propósito del control.

Hay métodos para esconder etiquetas (y otros elementos) en una página web para que no aparezcan visualmente pero sigan siendo accesibles para los lectores de pantalla. Sin embargo, siempre que se escondan elementos visualmente debemos ir con mucho cuidado. Deberías preguntarte por qué la información no es útil o necesaria visualmente, pero es importante para un usuario de lector de pantalla. También deberías tener en cuenta que esconder etiquetas quita funcionalidad a la página - los usuarios pueden pulsar sobre una etiqueta label para activar o acceder al control asociado a dicha etiqueta. Esto puede ser realmente útil para usuarios con algún tipo de discapacidad motora. Lee más sobre esconder visualmente las etiquetas en un formulario.

Validación de formularios

La validación de formularios no presenta normalmente ningún problema de accesibilidad porque se realiza en segundo plano. No obstante, el modo en que se invocan los mecanismos de validación de formulario debe ser accesible. Esto significa que si estás usando validación en el lado del cliente, el proceso de validación y envío del formulario debe estar disponible para teclado y ratón.

Cómo normalmente no se puede saber que el navegador del usuario va a tener activados los scripts, el formulario debe enviarse a una URL real en caso de que los scripts estén desactivados. Deberías evitar formularios que se basan exclusivamente en funciones de script o en eventos, tal como <form action="#" onsubmit="validaformulario()"> para procesar un formulario. En lugar de eso, usa una URL de verdad para el valor de la acción. Aún podrías invocar validación en el lado del cliente, y se procesaría antes del envío si los scripts están activados - <form action="enviar.php" onsubmit="return validaformulario()">.

Recuperación de errores

Si la validación (ya sea en el lado del cliente o del servidor) detecta errores en el formulario, entonces hay un proceso de 3 pasos para asegurar que la recuperación de errores es usable y accesible:

  1. Alertar al usuario de la presencia del error de una manera evidente y accesible.
  2. Permitir al usuario un acceso fácil a los controles que necesitan ser modificados.
  3. Permitir le reenvió y revalidación del formulario.

Hay tres modos principales con los que se pueden cumplir estos requisitos. Se pueden describir como:

  • Alerta de error y enfoque
  • Errores al principio
  • Errores en línea

Ninguno de ellos es mejor respecto a la accesibilidad, pero puede haber un enfoque óptimo dependiendo del contenido, disposición y complejidad del formulario al que se aplique.

Alerta de error y enfoque

El primer paso es informar al usuario de que hay un error. El mensaje de error debe ser visible, informativo, y directamente accesible. Un método consistiría en usar el alert de JavaScript o una ventana de diálogo para informar al usuario del error.

alert de JavaScript con mensaje descriptivo

Otro método permitiría al usuario introducir respuestas de texto directamente usando el prompt de JavaScript.

prompt de JavaScript con un mensaje descriptivo

La ventaja de utilizar "Alerta de error y enfoque" es que se informa a los usuarios del error al momento y pueden resolver el problema directamente. La mayor desventaja es que los errores sólo se pueden indicar y corregir de uno en uno.

Errores al principio

El mensaje de error también puede escribirse directamente en la página web. Cuando los scripts están habilitados en el lado del cliente, puedes escribir un mensaje de error en la página antes de que el formulario se envíe. Con scripts en el lado del servidor, normalmente recargarías la página para incluir el formulario original y los mensajes correspondientes. Las páginas que muestran sólo los mensajes de error y piden al usuario que pulse "Atrás" en el navegador para volver y solucionar los problemas pueden ser complicadas. Requieren que el usuario recuerde todos los errores y entonces volver a la página anterior y encontrar dónde se produjeron los errores. Generalmente es mejor regenerar la página para que el formulario parezca y funcione de manera similar al original que fue enviado para que los campos que estuvieran correctos no se modifiquen.

Como podríamos imaginar, el método de "errores al principio" hace que los mensajes de error se muestren al principio, antes del formulario. Cuando se muestren, el foco debería ponerse directamente en el mensaje de error. Esto permite que los lectores de pantalla y los usuarios de teclado puedan acceder directamente a mensaje de error sin tener que buscarlo en la página. El mensaje debe ser visualmente aparente y llamativo. El foco se puede poner en el mensaje usando scripts en el lado del cliente como la función focus() de JavaScript, o la página generada en el servidor puede incluir un nombre de enlace (o "ancla") en la URI (por ejemplo, http://miservidor.com/formulario.php#mensajedeerror) que automáticamente pondría el foco en el enlace con ese nombre o en el id del elemento localizado al principio del mensaje de error.

El mensaje de error debe describir los errores claramente e, idealmente, incluir pistas o instrucciones sobre cómo resolverlos. Por ejemplo, "El número del curso no tiene el formato correcto" no es tan útil como "El número del curso debe tener tres dígitos". También es útil informar al usuario sobre el número de errores que se encontraron en el formulario.

Una vez que el mensaje de error se muestra al usuario, debes darle un mecanismo para que pueda acceder rápidamente al control que necesita modificarse. Puedes hacerlo con un enlace dentro del mensaje de error que enfocara el control apropiado. Aunque esto podría hacerse mediante script en el lado del cliente, es más fácil (y seguro) simplemente crear un enlace que pondrá el foco en el control del formulario (identificado por su id único y/o por su nombre).

Los errores se enlazan con los campos del formulario

La ventaja del método de "errores al principio" es que todos los errores se muestran juntos. La desventaja es que, si hay múltiples errores, puede ser difícil para el usuario recordar, encontrar y arreglarlos todos.

Errores en línea

Otra manera es mostrar los mensajes de error dentro del formulario en el contexto del control que necesita atención. Este enfoque requiere mensajes de error que resalten visualmente de forma distintiva para que llamen la atención del usuario. El mensaje de error debe estar asociado a su control correspondiente (mediante el uso de label o quizás con aria-describedby). Puede ser útil poner el foco en el primer control que deba atenderse.

La ventaja de los "errores en línea" es que los errores aparecen dentro del contexto de los controles. La desventaja es que el usuario debe buscar/navegar por el formulario hasta encontrar qué controles dieron fallo y cuál es el mensaje. Esto puede llevar un buen rato en formularios complejos.

aria-invalid

Independientemente del mecanismo utilizado para identificar y recuperarse de errores en los formularios, aria-invalid="true" debería asignares a cada control inválido. Este atributo hace que los lectores de pantalla identifiquen los campos como "incorrectos" o necesitados de atención.

Resumen

En todos los casos, los test de usuario pueden ayudarte con dificultades y problemas en los mecanismos de usabilidad, validación y recuperación de errores en tus formularios. Este artículo sólo se centra en algunas de las variantes que se pueden utilizar para asegurar usabilidad y validación en los formularios y una recuperación de errores amigable y accesible, la siguiente lista describe una serie de principios que deberían aplicarse siempre:

  • Crear formularios fáciles de usar e intuitivos. Suministra toda la información y requerimientos.
  • Asegúrate de que los formularios son accesibles usando el teclado.
  • Asocia etiquetas <label> a los controles de formulario.
  • Usa fieldset y legend para asociar grupos de casillas de verificación y radiobotones.
  • Incluye las instrucciones necesarias dentro de los elementos <label> (por ejemplo, controles requeridos o que necesitan un formato específico).
  • No bases el envío, validación y recuperación de errores exclusivamente en JavaScript.
  • Alerta al usuario de la validación de errores de una manera evidente y accesible. Suministra información en mensajes informativos.
  • Permite que el usuario tenga acceso fácil a los controles de formulario que necesitan ser modificados.
  • Permite reenvío y revalidación de la información del formulario.