Formularios accesibles según las WCAG 2.0

El objetivo de este artículo es la presentación de una serie de documentos que facilitan la evaluación de la accesibilidad de los formularios de acuerdo con los criterios definidos en las WCAG 2.0:

• Técnicas WCAG 2.0 asociadas a la implementación de formularios accesibles
• Guía rápida de normas de accesibilidad WCAG 2.0 para formularios
• Checklist para validar formularios de acuerdo con las WCAG 2.0
• Documentación de interés

Una de las cosas que más llamó mi atención cuando leí las WCAG 2.0 y sus técnicas asociadas (Techniques for WCAG 2.0) es el gran número de ellas que están referidas a los formularios.

Muchas de las prácticas que hasta ahora eran recomendables para hacer un formulario lo más usable posible y que recopilé en "Formularios usables: 60 Directrices de Usabilidad", están ahora recogidas en las WCAG 2.0 y se convierten por tanto en requisitos imprescindibles para que los formularios sean accesibles.

A continuación presento una serie de documentos que he elaborado para evaluar la accesibilidad de los formularios de acuerdo con los criterios definidos en las WCAG 2.0.

Técnicas WCAG 2.0 asociadas a la implementación de formularios accesibles

Las técnicas de las WCAG 2.0 están organizadas temáticamente, pero por desgracia, la documentación de las WCAG 2.0 no incluye un índice de las técnicas referentes a formularios, a enlaces, etc.

Por ello, el primer documento que necesité elaborar fue una recopilación de las técnicas relacionadas con los formularios. Dicha recopilación es extensa puesto que incluye el título de las 47 técnicas asociadas a formularios, su enlace, descripción y procedimiento de validación.

Documento: Técnicas WCAG 2.0 asociadas a la implementación de formularios accesibles (word, 320KB). Descarga directa. Documento en inglés salvo la introducción.

Guía rápida de normas de accesibilidad WCAG 2.0 para formularios

Una vez recopiladas y estudiadas las técnicas WCAG 2.0 relacionadas con los formularios, me resultó imprescindible la creación de un listado de normas de accesibilidad, fácil de consultar y memorizar.

A continuación incluyo la lista de normas de accesibilidad y las técnicas que las avalan. Asociada a cada técnica indico si es una técnica "sufficient" o "advisory" (obligatoria o recomendada), así como los criterios de éxito asociados a cada una y su nivel (A,AA,AAA)

Es importante tener en cuenta que a veces las técnicas se aplican o no en función de unas reglas, o que el desarrollador puede elegir entre varias técnicas para cumplir con un criterio de éxito, recopilo esta información en el documento Checklist para validar formularios de acuerdo con las WCAG 2.0.

• Utiliza controles de formulario de forma estándar indicando correctamente su nombre, valor y estado (H91 - Sufficient [2.1.1 - A, 4.1.2 - A])
• No limites el tiempo que el usuario dispone para completar un formulario, o dispón de un mecanismo para anular o ampliar el límite de tiempo (G5 - Sufficient [2.2.3 - AAA], G133 - Sufficient [2.2.1 - A], G198 - Sufficient [2.2.1 - A])
• Proporciona un botón de tipo "submit" para iniciar un cambio de contexto. Si un control de formulario provoca un cambio de contexto debes informar de ello previamente (G13 - Sufficient para la 3.2.2 - A - Advisory para la 3.3.2 - A, G80 - Sufficient [3.2.2 - A], H32 - Sufficient [3.2.2 - A] - , H84 - Sufficient [3.2.2 - A], F9, F36)
  
  La técnica SCR19 - Sufficient [3.2.5 - AAA] explica cómo asociar un evento ONCHANGE a una SELECT sin causar un cambio de contexto.
• Indica si un campo es obligatorio en el LABEL asociado al campo, por ejemplo mediante un texto "(obligatorio)" o mediante un asterisco explicando su significado al comienzo del formulario (H90 ? [3.3.2 - A])
• Proporciona descripciones textuales (no un mero asterisco o cambio de color) para identificar los campos obligatorios que no fueron completados (G83 - Sufficient [3.3.1 - A, 3.3.3- AA, 3.3.2 - A], F81)
• Cuando se produzca un error de validación proporciona una descripción textual que:
  
  • Describa la naturaleza del problema
  • Informe de los valores admitidos
  • Proporcione ejemplos de valores correctos o incluso propuesta de valores similares a los introducidos pero correctos (mediante corrección ortográfica por ejemplo)
  • Permita localizar los campos que han provocado el error (si la descripción se sitúa al comienzo del formulario) mediante un enlace a dichos campos, y un enlace al listado de errores.
  
  (G84 - Sufficient [3.3.1 - A, 3.3.3- AA], G85 - Sufficient [3.3.1 - A, 3.3.3 - AA], G139 - Advisory [3.3.1 - A, 3.3.3 - AA], G177 - Sufficient [3.3.3- AA], G194 - Sufficient [3.3.5 - AAA])
  
  La técnica SCR32 - Sufficient [3.3.1 - A,3.3.3 - AA] describe cómo realizar validaciones en cliente y añadir el texto de los errores vía DOM.
  
• Valida los campos en cliente advirtiendo del error y devolviendo el foco al campo que produjo el error (SCR18 - Sufficient [3.3.1- A,3.3.3 - AA] salvo para 3.3.4 - AA que es Advisory)
• Los campos que requieran un formato de datos concreto (fechas, nº de cuenta, etc.) deben tener asociada información sobre el formato esperado o un ejemplo (G89- Sufficient [3.3.2 - A, 3.3.5 - AAA])
• Cuando el formulario es corto o tiene muchos campos del mismo tipo, incluir un texto de instrucciones al comienzo del formulario en vez de repetir la información en cada campo (G184 - Sufficient [3.3.2 - A,3.3.5 - AAA])
• Se debe proporcionar una página de verificación de datos que permita modificarlos cuando el formulario supone una operación irreversible, por ejemplo de tipo financiero o jurídico (G98 - Sufficient [3.3.4 -A, 3.3.6 -AAA])
• Cuando una aplicación Web ofrece la posibilidad de suprimir información, el servidor debe proporcionar un medio para recuperar la información que el usuario ha eliminado por error (G99 - Sufficient [3.3.4 - AA, 3.3.6 - AAA])
• Cuando el formulario realiza una operación irreversible (eliminar datos, transacción económica) proporcionar un check no seleccionado por defecto del tipo "Confirmo que he revisado los campos y deseo enviar/eliminar" (G155 - Sufficient [3.3.4 - AA, 3.3.6 - AAA])
• En las situaciones en las cuales una acción no se puede deshacer, pida confirmación antes de enviar un formulario indicando la opción seleccionada y sus consecuencias (G168 - Sufficient [3.3.4 - AA, 3.3.6 - AAA])
• Establecer un periodo de tiempo durante el cual los usuarios pueden cancelar o modificar la orden enviada con el formulario. Debe indicarse el periodo de cancelación y el procedimiento para el mismo. (G164 - Sufficient [3.3.4 -AA, 3.3.6 - AAA])
• Debe ser evidente el campo que tiene el foco, por ejemplo el agente de usuario debe mostrar la barra vertical parpadeante en el punto de inserción de contenido de un campo de texto o puntear el contorno de los radios y checks (G149 - Sufficient [2.4.7 - AA])
• Cada control de formulario debe tener una etiqueta visible inmediatamente después en el caso de los radios y checks e inmediantemente delante (sobre el campo o a la izquierda del mismo) en el resto de controles (G162 - Sufficient [3.3.2 - A], F86)
• Utiliza elementos LABEL para asociar etiquetas a los controles del formulario. Asócialos de forma explícita (H44 - Sufficient [1.1.1 - A, 1.3.1 - A, 3.3.2 - A, 4.1.2 - A], F86)
• Utiliza el atributo TITLE para identificar los controles del formulario cuando el elemento LABEL no puede ser usado. Por ejemplo, en el caso de un LABEL, un INPUT de búsqueda y una SELECT para restringir la búsqueda, esta SELECT sin LABEL asociado llevaría el TITLE "Busca en" (H65 - Sufficient [1.1.1 - A, 1.3.1 - A, 3.3.2 - A, 4.1.2 - A)
• Utiliza el atributo TITLE para proporcionar ayuda contextual en los controles del formulario (H89 - Advisory [3.3.5 - AAA], F86)
• Cuando un botón está asociado a un control de formulario (por ejemplo un campo de texto más un botón "buscar") el botón debe situarse inmediatamente después del campo. El campo no tiene porque tener etiqueta (de este modo se evita contenido repetido en la página) pero el texto del botón debe ser muy claro puesto que sirve tambień de etiqueta para el control (G167 - Sufficient [3.3.2 - A])
• Los nombres, etiquetas, etc. deben ser consistentes para el contenido con una misma funcionalidad (G197 - Sufficient [3.2.4 - AA])
• Informa convenientemente de que el formulario se ha enviado con éxito (G199 - Advisory [3.3.1 - A, 3.3.2 -A, 3.3.4- AA, 3.3.6 -AAA])
• Proporciona un orden de tabulación lógico mediante tabindex cuando el de por defecto no es suficiente (H4 - Sufficient [2.4.3 - A])
• Agrupa semánticamente los controles relacionados, especialmente los radio y checks mediante FIELDSET y LEGEND (H71 - Sufficient [1.3.1 - A, 3.3.2 - A])
• Agrupa los OPTIONS de una SELECT mediante OPTGROUP (H85 - Sufficient [1.3.1 - A])
• Usa eventos independientes del dispositivo, ofreciendo de forma redundante eventos de teclado y ratón (SCR2 - Sufficient [2.1.1 - A, 2.1.3 - AAA], SCR20- Sufficient [2.1.1 -A, 2.1.3-AAA])
  
  La técnica SCR35 - Sufficient [2.1.1-A, 2.1.3-AAA] explica como el evento ONCLICK es accesible desde teclado y ratón.
• El tamaño del texto introducido en los campos de un formulario debe también aumentar cuando se incrementa el tamaño de fuente del contenido (C17 - Advisory [1.4.4 - AA], ? [1.4.8- AAA])
• Identifica los campos obligatorios mediante la propiedad REQUIRED (ARIA2 - Advisory [3.3.3 - AA])
  
  La técnica ARIA4 - Advisory [1.3.1 - A, 3.3.2 - A] explica como añadir la propiedad de forma dinámica.
• Identifica el rango de valores válido mediante las propiedades VALUEMIN y VALUEMAX (ARIA3 - Advisory [3.3.3 - AA])

Checklist para validar formularios de acuerdo con las WCAG 2.0

Una vez interiorizadas las normas de accesibilidad que deben cumplir los formularios, el siguiente documento que me resultó necesario crear fue una herramienta de trabajo que facilitara las labores de revisión.

Este documento es una excel que tiene las siguientes columnas ordenadas por el nivel de cumplimiento (A,AA,AA) y el tipo de técnica (sufficient, advisory o failure):

• Número y enlace de la técnica
• Criterios de éxito asociados y su nivel de cumplimiento
• Enlace a las normas de aplicación asociadas a la técnica
• Procedimiento de validación (en versión original en inglés)
• Celda para indicar si se cumple o no la técnica
• Celda para apuntar observaciones

Documento: Checklist para validar formularios de acuerdo con las WCAG 2.0 (Excel, 85KB). Descarga gratuita previa aceptación del contrato coloriuris.

Documentación de interés

Documentando este artículo me encontré con uno muy bueno, que recomiendo leer de forma complementaria: "Accessible Forms using WCAG 2.0" de Roger Hudson.

También recomiendo leer:

• Formularios usables: 60 Directrices 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
[30-01-11] Respuesta a 25 dudas habituales sobre accesibilidad web
[27-03-09] AJAX accesible IV: Técnicas ARIA de las WCAG 2.0
[12-02-08] WCAG 2.0