martes, 2 de junio de 2009

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:




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:

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



10 comentarios :
Anónimo dijo...

Si tenemos varias páginas con formularios que tienen una gran cantidad de campos (cajas de texto, combos...) ¿cual es la mejor manera para alinearlos? teniendo en cuenta que debemos aplicar su width desde el css. ¿Debemos escribir una clase por cada uno de los elementos?

Olga Carreras dijo...

Artículo relacionado

Accessible forms using WCAG 2.0

Anónimo dijo...

me gustas

Anónimo dijo...

Buenos días.

En primer lugar, gracias por la información de tu blog, es muy interesante.

Quería preguntarte si conoces alguna herramienta/editor WYSWYG para construir formularios web accesibles.
La cuestión es que en nuestro CMS tenemos el FCKEditor (versión antigua del CKEditor) y no se pueden crear formularios accesibles para las wcag 2.0, ya que no se pueden asociar las etiquetas de fomar explícita sin tocar el código fuente (queremos evitar esa opción).


Gracias por tu atención

Anónimo dijo...

Hola!!! En primer lugar felicitarte por el blog, está genial!! Pero tengo una duda que no he podido solventar buceando en el. A la hora de implementar dos Select dependientes (por ejemplo, Provincia y Municipios) las únicas soluciones que he encontrado dependen de Javascript como la técnica SCR19. ¿Hay alguna forma de implementarlos de forma completamente accesibles? Gracias!!!

Olga Carreras dijo...

Supongo que lo que quieres es una solución que no dependa de javascript.

En ese caso, si no se soporta javascript o está desactivado, la primera select en vez de cargar la segunda por javascript lo hace con una llamada al servidor. Sin olvidar que tienes que informar de ello al usuario y poner el foco en la segunda select cuando vuelvas a cargar la página.

Anónimo dijo...

He seguido tus indicaciones y he hecho que el segundo select se cargue después de pulsar un botón pero no consigo mover el foco sin javascript. ¿Alguna sugerencia? Estoy usando el framework de Tapestry

Olga Carreras dijo...

HTML 5: propiedad del campo autofocus

Fernando dijo...

Hola, Olga.

El uso de asterisco para campos obligatorios ya es un estandar reconocido por la W3c, y su posición después de la etiqueta parece ser que es el preferido y el que recoge dicho organismo como estandar y como atributo de HTML5.

Quería saber tu opinión acerca de colocar el asterisco antes de la etiqueta. Para darte más información, estamos hablando en un contexto de uso de aplicaciones tipo CRM, donde hay multitud de campos y etiquetas, y también en formularios web. Su colocación antes de la etiqueta no favorece la usabilidad al usuario, mejor que después? O esto también depende de la alineación de las etiquetas (a la derecha, pegado al campo alineado a la izquierda). Sin embargo, aún no hay muchos formularios con el asterisco antes de la etiqueta.

Muchas gracias y te felicito por tu blog, una referencia para todos los que nos dedicamos a esto de la usablidad.

Olga Carreras dijo...

Habría que estudiar la aplicación concreta, según el número de campos que son obligatorios, su alineación, la frecuencia de uso de ese formulario por los usuarios y por tanto su familiaridad con el mismo, etc.

Publicar un comentario