Blog para dispositivos móviles | [S] Ir al contenido |
Su navegador no admite frames. <a href='http://www.blogger.com/home'>Acceder a la página pricipal de Blogger</a>

viernes 19 de junio de 2009

Metodología para la evaluación de la accesibilidad Web: "Evaluating Web Sites for Accessibility" de la WAI

Artículos relacionados




"Evaluating Web Sites for Accessibility" es una suite de documentos de la WAI que constituye la metodología a seguir para evaluar la accesibilidad de un sitio Web y asegurar la calidad de los procedimientos.

El objetivo de este artículo es dar a conocer y resumir estos documentos en español.


Índice


  1. Examen preliminar de la accesibilidad de un sitio Web
  2. Evaluación de la conformidad de accesibilidad de un sitio Web
  3. Metodología para la evaluación de contextos específicos
  4. Inclusión de los usuarios en la evaluación de la accesibilidad Web
  5. Selección de herramientas de evaluación de la accesibilidad Web
  6. Listado y búsqueda de herramientas de evaluación de la accesibilidad Web
  7. Uso combinado de expertos para evaluar la accesibilidad Web
  8. Plantilla para informes de evaluación de accesibilidad



Examen preliminar de la accesibilidad de un sitio Web


Describe una metodología para identificar rápidamente posibles problemas de accesibilidad en un sitio Web. Consta de cinco pasos:

  • Seleccionar una muestra representativa de páginas.
  • Examinar las páginas usando navegadores gráficos haciendo las siguientes pruebas:
    • Desactivar las imágenes y comprobar que existe para ellas una alternativa adecuada.
    • Desactivar el sonido y comprobar que el contenido del audio está disponible a través de texto equivalente.
    • Comprobar que se puede aumentar el tamaño de fuente y que la página es usable con un tamaño de fuente grande.
    • Probar con diferentes resoluciones de pantalla y/o con diferentes tamaños de ventana para verificar que el desplazamiento horizontal no es necesario.
    • Visualizar o imprimir la pantalla en escala de grises y observar si el contraste es suficiente.
    • Utilizar el teclado para navegar a través de los enlaces y controles de formulario, asegurándose de que se puede acceder a todos los vínculos y controles y que los vínculos indican claramente a dónde conducen.

  • Examinar las páginas con un lector de pantalla y un navegador sólo texto para comprobar que toda la información está disponible y en un orden significativo.
  • Utilizar al menos dos herramientas de evaluación automática para analizar las páginas de la muestra.
  • Resumir los resultados obtenidos indicando:
    • Los diferentes tipos de problemas detectados, pero también los aspectos positivos que se han encontrado.
    • El método por el cual se detectaron los diferentes problemas, indicando claramente que no se trata de una evaluación completa de la conformidad de accesibilidad.
    • Incluir recomendaciones sobre medidas de seguimiento, la realización de un análisis completo y las maneras de abordar los problemas identificados.




Evaluación de la conformidad de accesibilidad de un sitio Web


Describe la metodología a seguir para determinar si un sitio Web cumple con las normas de accesibilidad (Web Content Accessibility Guidelines (WCAG)).

Los pasos son los siguientes:

  • Determinar el alcance de la evaluación: el nivel de conformidad (A,AA,AAA) a evaluar, la muestra representativa de las páginas que se van a analizar y la URL base que incluye todas las páginas a analizar en las revisiones automáticas (si no es posible por el tamaño del sitio o su naturaleza dinámica, seleccionar una muestra ampliada de páginas representativas).
  • Utilizar herramientas de evaluación de la accesibilidad Web:


  • Evaluación manual de la muestra de páginas:
    • Aplicar la checklist de accesibilidad a las páginas de la muestra.
    • Examinar las páginas usando navegadores gráficos (descripción en el apartado anterior)
    • Examinar las páginas con un lector de pantallas y un navegador sólo texto para comprobar que toda la información está disponible y en un orden significativo.
    • Leer y evaluar el contenido de las páginas, ¿el texto es claro, sencillo y adecuado al propósito del sitio?
  • Resumir los problemas y las mejores prácticas identificadas para cada tipo de página, con una URL de ejemplo y el método por el que fueron identificados. Recomendar la reparación de los problemas de accesibilidad detectados, la ampliación de los aspectos positivos y el mantenimiento y seguimiento del sitio.



Metodología para la evaluación de contextos específicos



  • La evaluación durante el proceso de desarrollo es esencial pues los problemas de accesibilidad detectados de manera temprana son más fáciles de corregir. Para una evaluación eficaz durante el proceso de desarrollo es necesario:
    • Establecer claramente los requisitos de accesibilidad para el nivel de conformidad deseado.
    • Participación en las reuniones iniciales de planificación del sitio.
    • Acordar un calendario de revisión durante el proceso de desarrollo.
    • Proporcionar información sobre métodos de evaluación para que los desarrolladores pueden hacer por lo menos una evaluación preliminar por su cuenta.

  • Seguimiento. Para facilitar que un sitio mantenga el nivel de conformidad en el futuro se recomienda:
    • Una declaración clara del nivel de conformidad esperado y el alcance del sitio Web al que esto se aplica.
    • Identificar claramente las personas responsables del seguimiento del sitio y los procedimiento a seguir para convertir rápidamente en conformes las páginas no conformes.
    • Definir unas expectativas claras con respecto a la frecuencia, el método y el alcance de las evaluaciones.
    • Establecer un proceso de validación y evaluación de todas las páginas modificadas y los nuevos tipos de páginas antes de que se añadan al sitio.
    • Software para facilitar la evaluación.
    • Incorporar en el sitio una dirección para la información sobre accesibilidad.
    • Establecer pruebas automáticas o semi-automáticas para identificar los problemas hallados en la evaluación global.

  • Evaluación de los sitios Web "heredados", no activos, que pasa por identificar al propietario, su obligación o interés por hacerlo accesible, etc.
  • Evaluación de páginas Web generadas dinámicamente:
    • Plantillas

      Evaluar la accesibilidad de las plantillas estáticas según las WCAG. Añadir un mínimo de contenido textual a las plantillas y volver a evaluar.
    • Contenido

      Evaluar la capacidad del sistema de gestión de contenidos para almacenar y generar información de accesibilidad. ¿Permite incorporar contenido alternativo a imágenes, sonidos y vídeos? ¿Las tablas pueden generarse con los recursos de accesibilidad? ¿Genera (X)HTML válido?
    • Plantillas y contenido combinado.

      Las páginas que se generan como resultado de una consulta a una base de datos deben ser capturadas y evaluadas por medio de las WCAG ¿Las páginas generadas conservan las características de accesibilidad?



Inclusión de los usuarios en la evaluación de la accesibilidad Web



La inclusión de personas con discapacidad en la evaluación de la accesibilidad durante el desarrollo contribuye a entender mejor los problemas de accesibilidad y aplicar las soluciones más eficaces.

  • Inclusión efectiva de los usuarios.

    Partiendo de la base de que las evaluaciones previas de accesibilidad detectan los principales problemas de accesibilidad, se puede involucrar a los usuarios de muy diversas maneras, desde evaluaciones informales (preguntando por ejemplo a un usuario que use un lector de pantalla sobre un tema concreto) hasta un test de usuarios formal optimizado para problemas de accesibilidad.

    En cualquier caso es más efectivo realizar evaluaciones informales a lo largo de todo el proceso que realizar un test formal al final del mismo.

    Se debería buscar unas cuantas personas con discapacidad e incluirlas en todo el proceso de desarrollo para completar tareas en prototipos y discutir con ellos los problemas de accesibilidad.

    Examinar cuidadosamente todos los votos y evitar el supuesto de que los comentarios de una persona con una discapacidad se aplican a todas las personas con discapacidad. Una persona con una discapacidad no sabe necesariamente cómo otras personas con la misma discapacidad interactúan con la Web, ni saben lo suficiente sobre otras discapacidades para proporcionar orientación sobre otras cuestiones de accesibilidad.
  • Incluyendo diversos usuarios

    Hay que tener en cuenta que hay muchos tipos de discapacidad y los usuarios utilizan diferentes tecnologías asistivas. Es también muy importante tener en cuenta no sólo su experiencia en Internet sino también con determinada tecnología asistiva. Del mismo modo, es imprescindible tener claro cuál es el público objetivo del sitio.


    Para seleccionar de forma correcta a los usuarios se recomienda leer "Planning Usability Testing"


  • Analizar los problemas de accesibilidad.

    La accesibilidad Web depende de varios factores, incluyendo los navegadores Web, las tecnologías de asistencia (AT) y el contenido Web. Para cualquier problema de accesibilidad es necesario determinar qué componentes son los responsables. Por ejemplo, si un usuario tiene problemas con una tabla de datos, puede ser porque el código (X)HTML no está marcado correctamente, o porque a los usuarios que usan una AT no se les facilita la lectura de los datos efectivamente o porque el usuario no sabe utilizar correctamente la AT.

    Además de encontrar los problemas de accesibilidad, la evaluación con usuarios con discapacidad revela los problemas generales de usabilidad que afectan a todos los usuarios, incluidos aquellos sin discapacidades.
  • Conclusiones y presentación de informes.

    La combinación de la participación de los usuarios con la evaluación de la conformidad según las WCAG asegura que la amplia gama de cuestiones de accesibilidad están cubiertas.


    Los informes deben incluir el ámbito del estudio y los parámetros de evaluación, tales como los métodos de prueba y las características del usuario. Por ejemplo, si el estudio incluyó sólo las pruebas de usabilidad con los participantes que son ciegos, su informe debe aclarar que no se evalúa la conformidad con las WCAG y que no se aplica a todas las personas con discapacidad. Así, el informe puede ayudar a los lectores a sacar las conclusiones apropiadas.

  • Optimización de los test de usuario para los problemas de accesibilidad.

    A la hora de definir específicamente pruebas de usabilidad para encontrar los problemas de accesibilidad, el protocolo será diferente del de un típico test de usuarios, por ejemplo:

    • La técnica "think-aloud" facilitará mucho la interacción.
    • La recogida de datos se centrará en la comprensión de los errores relacionados con los problemas de accesibilidad, en lugar de centrarse en el tiempo o la satisfacción de los usuarios.
    • Las tareas se centrarán en áreas específicas de preocupación para los posibles problemas de accesibilidad, en lugar de en los problemas generales de uso del sitio.




Selección de herramientas de evaluación de la accesibilidad Web


En algunos casos, las herramientas de evaluación son propensas a producir resultados falsos o engañosos. Los resultados de las herramientas de evaluación no deben ser utilizados para determinar los niveles de conformidad, salvo que se lleven a cabo por evaluadores experimentados que entienden las capacidades y limitaciones de las herramientas con el fin de alcanzar resultados exactos.

Las herramientas de evaluación de la accesibilidad Web no puede determinar la accesibilidad de sitios web, sólo pueden ayudar a hacerlo.



Listado y búsqueda de herramientas de evaluación de la accesibilidad Web





Uso combinado de expertos para evaluar la accesibilidad Web


  • Los evaluadores de accesibilidad deben tener conocimientos sobre:
    • Tecnologías Web y especificaciones y estándares del W3C.
    • Herramientas de la validación de las tecnologías Web.
    • WCAG y técnicas asociadas.
    • Metodología de la evaluación de la accesibilidad Web.
    • Uso de una amplia variedad de herramientas de evaluación de la accesibilidad Web.
    • Conocimientos sobre las tecnologías de asistencia y estrategias de adaptación ("How People with Disabilities Use the Web ")
    • Inclusión de las personas con discapacidad en la evaluación de accesibilidad.



Plantilla para informes de evaluación de accesibilidad



Presenta un formato recomendado para la comunicación de los resultados de una evaluación de accesibilidad Web de acuerdo con las WCAG 1.0.



Artículos relacionados

TAW WCAG 2.0

!Qué gran noticia!

Se presenta la nueva versión del analizador de accesibilidad TAW que permite validar de acuerdo a las WCAG 2.0 .

De momento está en versión BETA.

viernes 12 de junio de 2009

Documentos que recomiendo conocer (5)

Serie "Documentos que recomiendo conocer"

"Hacia las Pautas WCAG 2.0" de Inteco


Esta guía me ha encantado, es de lo mejorcito que he leído sobre las WCAG 2.0. Clara, concisa y muy completa. Es un honor que me hayan referenciado dentro de los enlaces relacionados.

Si te interesa este tema te recomiendo el estudio que estoy haciendo sobre las técnicas de las WCAG 2.0 y que puedes seguir en la etiqueta "Técnicas WCAG 2.0".




"Guía de Accesibilidad y Seguridad en Trámites online" de Inteco



El objetivo de esta guía es la de ayudar a los desarrolladores a la hora de incluir mecanismos de tramitación seguros en los sitios Web que desarrollan, de tal forma que ésta sea accesible según los requisitos que dicta la norma UNE 139803:2004, permitiendo así el acceso a ellos a todos los usuarios independientemente de sus propias limitaciones o las derivadas de su entorno.

Habla de la accesibilidad de los formularios y de la accesibilidad en los mecanismos de acceso (captcha, DNIe, etc.) pero desde mi punto de vista es demasiado básica e incompleta.

Si te interesa el tema de los formularios accesibles te recomiendo que amplíes la información con "Formularios accesibles según las WCAG 2.0"

Si quieres ampliar información sobre la accesibilidad de los captchas y estar al día sobre las últimas novedades en este campo te recomiendo "Captchas y la W3C"

Sobre accesibilidad y DNIe te recomiendo mi primer artículo "Accesibilidad, firma electrónica y DNIe en el ámbito de las Administraciones Públicas"

También está relacionado con este documento el artículo "Tarjeta de coordenas y accesibilidad"




"Opera Web Standards Curriculum" de Opera



This tutorial course takes students from complete beginner to having a solid grounding in standards-based Web design, including HTML, CSS, and JavaScript development. The course is supported by top companies and organizations such as the Web Standards Project (WaSP) and Yahoo!.

Split into more than 50 focused articles, students can follow the curriculum from start to finish or simply read articles that interest them the most. Each article contains essential theory, practical examples, and exercise questions. The first 41 articles are now published, and roughly ten ones covering JavaScript basics will follow ASAP, to complete the course.

Why should you incorporate the Opera WSC into your curriculum? Web standards in a Web site promote efficiency, ease of maintenance, accessibility, device compatibility, and search optimization. The Opera WSC features the most up-to-date practices in Web standards. Best of all, the course is free, requiring no expensive textbooks.


De momento sólo disponible en inglés.



Improving Access to Government through Better Use of the Web. W3C Interest Group Note 12 May 2009


Mejora del acceso a la Administración a través de un mejor uso de la Web. Primer Borrador de Trabajo público.


La Administración electrónica se refiere al uso de la Web o de otras tecnologías de la información por parte de los órganos de gobierno (locales, estatales, federales o internacionales) en su interacción con la ciudadanía, entre departamentos y secciones, así como entre las propias administraciones.

Admitiendo que las administraciones a lo largo de todo el mundo necesitan asistencia y una guía para alcanzar el potencial de la administración electrónica a través de la tecnología y la Web, este documento busca encontrar y definir, pero no resolver aún, los distintos problemas y retos con los que se encuentran las administraciones.

Los casos de uso, documentación y explicación se centran en los estándares técnicos existentes o requeridos, pero además ofrece contexto para apuntar y describir los problemas adicionales y tareas que existen antes de que se consiga el éxito.


[En Noticias W3C]




"Discapacidad y eAccesibilidad" de Rocío Miranda de Larra. Fundación Orange



[...] el número de personas que se podrían beneficiar de la tecnología accesible superaba los 15 millones de personas o, lo que es lo mismo, el 39% de la población de nuestro país. [...] Así pues, un 62% de adultos en edad laboral es usuario potencial de las tecnologías accesibles. Nos encontramos, pues, ante un mercado creciente, aunque para ello es necesario aceptar el hecho de que el concepto de “discapacidad” no debe limitarse a las personas con discapacidad severa, sino que existe un porcentaje mayor de población que puede benefi ciarse de este tipo de productos.

Se estima que el mercado norteamericano de la tecnología accesible pasará de los 57 millones de usuarios del año 2003 a los 70 millones en 2010. Más de dos tercios (el 69%) de los usuarios de PC con discapacidades leves o moderadas utiliza hoy en día alguna modalidad de tecnología accesible. Hay, por lo tanto, un enorme potencial para las empresas del sector, ya que tanto las tasas de uso del ordenador, como el número de personas mayores y potenciales usuarios de TIC accesibles, crece año a año.


Razones de uso de la tecnología accesible. Véase la descripción larga

Descripción detallada de la imagen "Razones de uso de la tecnología accesible". El enlace se abre en ventana nueva.

Es muy interesante la cantidad de datos estadísticos que proporciona.


"E-Accesibilidad. Eliminación de barreras para el acceso a la Sociedad Digital del Conocimiento" (PDF, 7.32MB)



Del Observatorio Regional de la Sociedad de la Información (ORSI). Junta de Castilla y León. 2008. Me han parecido muy interesantes los capítulos "Casos de uso" y "Tendencias de futuro".



"Recomendaciones a los usuarios de Internet", (PDF, 404KB)


Nueva guía de la Agencia Española de Protección de Datos.

En la guía se describen las principales amenazas para el derecho a la protección de datos que pueden existir para el ciudadano y se emiten una serie de recomendaciones para mitigar los efectos de dichas amenazas. [En Derecho de las TICs]




"Google's Search Engine Optimization Starter Guide", 2008 (PDF, 559KB)



Although this guide won't tell you any secrets that'll automatically rank your site first for queries in Google (sorry!), following the best practices outlined below will make it easier for search engines to both crawl and index your content.


Índice de buenas prácticas:

  • Create unique, accurate page titles. Good practices for page title tags
  • Make use of the "description" meta tag. Good practices for description meta tags.
  • Improve the structure of your URLs. Good practices for URL structure.
  • Make your site easier to navigate. Good practices for site navigation.
  • Offer quality content and services. Good practices for content.
  • Write better anchor text. Good practices for anchor text.
  • Use heading tags appropriately. Good practices for heading tags.
  • Optimize your use of images. Good practices for images.
  • Make effective use of robots.txt. Good practices for robots.txt
  • Be aware of rel="nofollow" for links.
  • Promote your website in the right ways. Good practices for promoting your website.
  • Make use of free webmaster tools.
  • Take advantage of web analytics services.



"Sistemas de lectura y libros digitales" de Manuel Costa Romero de Tejada.


Aunque se escribió en el año 2001, me ha parecido que sigue siendo bastante actual.

jueves 11 de junio de 2009

Noticias... (19)

Estas son las noticias que han llamado últimamente mi atención:


  • [01-06-09] "JCCM.ES, un nuevo portal en Internet a la altura de la Ley de Acceso Electrónico" en computing.es


    La Junta de Comunidades de Castilla-La Mancha ha lanzado su nuevo portal con la plataforma FatWire Content Server 7.5. La noticia dice que "cuenta con la certificación de accesibilidad AA". En realidad no tiene una certificación sino simplemente el sello "AA" del W3C. Si bien es cierto que ha mejorado mucho su accesibilidad y que muchas páginas pasan el TAW, la realidad es que no cumple con las WCAG 1.0 en su nivel de adecuación AA. Deberían seguir trabajando en ello...


  • [08-06-09] "La primera experiencia española de Open Government" en seraccesible


    Aragón Participa es la primera web española nacida con la mentalidad Open Government, construida íntegramente con Software Libre, pretende ser un canal de participación de los ciudadanos en las políticas públicas del Gobierno de Aragón.

    El portal incorpora, como novedad tecnológica, un asistente virtual al que los cuidadanos se puede dirigir para hacer llegar sus preguntas o reflexiones.



  • [04-06-09] "Estándar del PDF accesible - Standard for accessible PDF" en La hoguera de las brujas

    Por fin se ha aprovado PDF/UA (Universal Accesibility) como ISO/AWI (approved work item) 14289. Es el primer paso hacia un estándar abierto de PDF accesible. Aunque todavía no es público, el desarrollo se puede consultar en PDF edtime


  • [22-05-09] "Google Chrome 2.0, 30% más rápido" en anieto2k

    Hoy se ha publicado una nueva versión de Google Chrome, la 2.0 estable, que se está presentando a la red como una versión 30% más rápida que su versión anterior. Hay que decir que ese incremento de velocidad es en el motor javascript llamado V8. Lo que hace que este incremento en páginas muy cargadas de Javascript sea muy significativo.

    Artículo relacionado: Chrome (IV): accesibilidad



  • [09-06-09] "Safari 4 ya está aquí" de Programar a ciegas


  • En cuanto a su accesibilidad indicar que en MacOS X resulta más accesible incluso que la versión 3 aunque siguen apareciendo algunos problemas al encontrar webs que no cumplen las pautas de accesibilidad para la Web.

    VoiceOver accede mejor a la barra de pestañas y a la zona de favoritos. Ahora resulta más cómodo navegar entre la lista de favoritos y elegir entre las distintas pestañas abiertas.

    Sigue sin poder acceder a la capa de accesibilidad de los objetos Flash aunque ahora si notifica que hay un objeto incrustado dentro.

    Lo más importante es que Safari implementa HTML5 y WAI ARIA y voiceOver es compatible con las páginas que incorporen estas tecnologías.

    Con Safari 4 el acceso a la nueva Web resultará posible para aquellos que utilicen ordenadores con el sistema operativo de Apple. La versión para Ms Windows de Safari resulta incompatible con los lectores de pantallas más conocidos, como NVDA, JAWS y Window eyes.


  • [08-06-09] "Safari 4 [NO] más rápido que Google Chrome en el V8 Benchmark Suite" de anieto2k

    ... podemos decir con el 100% del convencimiento que Google Chrome es hoy por hoy, el navegador más rápido (ejecutando javascript) del lejano oeste.



martes 2 de junio de 2009

Formularios accesibles según las WCAG 2.0

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
[28-02-08] Formularios usables: 60 Directrices de Usabilidad




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.