lunes 9 de noviembre de 2009

Validador HTML de múltiples páginas

El apéndice A de WCAG 1.0 presenta un método de validación y mantenimiento de la accesibilidad basado en 10 puntos. Los puntos 2 y 3 indican que hay que validar la sintaxis de los lenguajes empleados en las páginas web (HTML, XML, CSS, ...).

Validar el CSS no es muy costoso, ya que normalmente tendremos un par de hojas de estilo en un sitio web y las podemos validar rápida y fácilmente con W3C CSS Validation Service.

Sin embargo, validar el HTML es más problemático, ya que el W3C Validation Service sólo valida una página y no es capaz de seguir los enlaces, por lo que con este validador es imposible validar de forma automática todo un sitio web.

Existe el WDG HTML Validator, que tiene una opción (Validate entire site) para supuestamente validar todo un sitio web, pero está limitado a sólo 100 páginas.

Existe otra herramienta, Multipage Validator,  que no parece que imponga un límite al número de páginas que se pueden validar. Es muy fácil de emplear y además utiliza como validador el W3C Validation Service, por lo que supone que los resultados tienen que ser totalmente correctos.

Lo he probado con mi sitio web Accesibilidad Web y en pocos segundos me ha validado 120 páginas. Durante todo el proceso se muestra una tabla con: el número de páginas indexadas, el número de páginas válidas, el número de páginas no válidas y el número de páginas que no se han podido validar, tal como podemos ver en la siguiente imagen.


miércoles 4 de noviembre de 2009

Internet Explorer Developer Tools

Acabo de encontrar el artículo Discovering Internet Explorer Developer Tools. La antigua barra de herramientas Internet Explorer Developer Toolbar no es compatible con Internet Explorer 8. Sin embargo, en su lugar disponemos, sin tener que instalarlo por separado, de las Herramientas de desarrollo (F-12). En este artículo nos explican qué herramientas existen y cómo utilizarlas.

lunes 26 de octubre de 2009

Opera Web Standards Curriculum

El Opera Web Standards Curriculum es un proyecto que comenzó hace un par de años y parece que ya ha sido completado. Se trata de un curso completo que permite a un principiante obtener una sólida base de conocimientos sobre programación web. Para ello, cubre todas las tecnologías que se emplean en la programación del cliente web, que es donde existen problemas de cumplimiento de los estándares y de compatibilidad entre los navegadores: HTML, CSS, JavaScript y DOM.

¿Qué ventajas ofrece el cumplimiento de los estándares?

Web standards in a Web site promote efficiency, ease of maintenance, accessibility, device compatibility, and search optimization.


Los estándares web en un sitio web estimulan la eficiencia, la facilidad de mantenimiento, la accesibilidad, la compatibilidad con los dispositivos y la optimización de las búsquedas (el posicionamiento).
¿Y cómo puede ayudar el empleo de los estándares a la accesibilidad web? En Opera Web Standards Curriculum nos dicen:
Web standards make the Web available to anyone, on any device, anywhere in the world.


Los estándares web hacen la Web disponible para cualquiera, en cualquier dispositivos, en cualquier sitio en el mundo.
¿No es esto el objetivo de la accesibilidad web?

En el Opera Web Standards Curriculum hay en la actualidad 51 artículos y unos cuantos que están muy relacionados con la accesibilidad web:

miércoles 7 de octubre de 2009

Evaluación manual de la accesibilidad con Web Developer

Acabo de publicar la página web Evaluación de la accesibilidad de sitios web con la barra de herramientas de Firefox Web Developer Toolbar en mi sitio web dedicado a la accesibilidad web. Es una traducción autorizada al español del artículo Evaluating Web Sites for Accessibility with the Firefox Web Developer Toolbar de Patrick H. Lauke.

La introducción del artículo dice:

Aunque el conocimiento de la accesibilidad web se ha incrementado en los últimos años, muchos desarrolladores web todavía desconocen cómo evaluar sus sitios. La relativa complejidad de los documentos del W3C, como las Pautas de Accesibilidad al Contenido en la Web 1.0 (Web Content Accessibility Guidelines 1.0, WCAG 1.0) del WAI y la riqueza de los a veces contradictorios consejos encontrados en los sitios dedicados a este tema pueden dejar a los desarrolladores con dudas sobre los aspectos prácticos de la evaluación.

A menudo, los desarrolladores carecen de tiempo o de capacitación y se basan simplemente en una de las muchas herramientas de pruebas automatizadas, como WebXACT, Cynthia o Wave. Pero incluso las revisiones automatizadas deben complementarse (y, para evitar falsos positivos, comprobadas por segunda vez) por medio de revisiones manuales.

Sobre la base de algunos de los puntos de verificación de WCAG 1.0, este artículo pretende ofrecer una descripción rápida de cómo Mozilla Firefox y la barra de herramientas Web Developer Toolbar pueden ayudar con estas revisiones manuales.

martes 6 de octubre de 2009

Las páginas que validan no posicionan mejor

Acabo de leer en un blog el artículo Las páginas que validan no posicionan mejor. En este artículo hacen referencia a "un video de Matt Cutts (responsable del buscador Web de Google), donde nos viene a decir que el que una página valide su HTML o no, no afecta a su posicionamiento en Google". El vídeo lo podemos ver en esta otra página: Las páginas que validan no posicionan mejor.

No me he podido resistir y he tenido que escribir un comentario en estas páginas, porque de algunos comentarios se puede entender que "como para Google no es importante que una página valide, para qué preocuparnos":

El problema de la validación (HTML, CSS) de las páginas web parte de los inicios de la Web, cuando cualquiera hacía una página web sin tener puñetera idea (y así siguen muchos). Cualquier persona que haya programado alguna vez sabe que, o el código está bien escrito o no se podrá compilar y por tanto no sirve para nada. Si lo mismo hubiese pasado con las páginas web, todo nos hubiese ido mejor.

Personalmente, tengo comprobado que en un alto porcentaje, el que una página no se vea bien en un navegador se debe a que el código no es válido: ante un error en el código, cada navegador “se recupera” de distinta forma e interpreta ese error y lo que viene a continuación con diferentes criterios.

A estas alturas, plantearse si es “beneficioso” que una página web sea o no sea válida lo veo “sin fundamento”. Cuando una página web valida, nos aseguramos de que en el futuro esa página se visualizará correctamente con los navegadores futuros. Y eso ya es una razón suficiente para preocuparnos de que una página sea válida. El que posicione mejor o facilite la accesibilidad son razones importantes, pero que vienen después como un beneficio añadido.

miércoles 30 de septiembre de 2009

¿Las pautas de WCAG garantizan realmente la accesibilidad?

Acabo de leer el artículo Evaluating web site accessibility: validating the WAI guidelines through usability testing with disabled users publicado en el año 2008 en el 5th Nordic conference on Human-computer interaction: building bridges.

El objetivo de este trabajo era validar empíricamente la utilidad de las pautas de accesibilidad del contenido web WCAG 1.0: comprobar si realmente las pautas son una heurística correcta para desarrollar un sitio web accesible o, si ya está desarrollado, para detectar los posibles problemas de accesibilidad.

Los resultados son bastante negativos y además parece que concluyentes, porque coinciden con estudios previos realizados por otros autores: sólo el 27% de los problemas de accesibilidad identificados por un grupo de usuarios podrían haber sido identificados mediante el uso de WCAG 1.0. La conclusión es clara según los autores:

We conclude from our findings that in its current version, the application of WCAG alone is not sufficient to guarantee website accessibility.

(Concluimos a partir de nuestras averiguaciones que en su versión actual, la aplicación exclusiva de WCAG no es suficiente para garantizar la accesibilidad de un sitio web)

Es algo que ya se intuía, pero la verdad es que un porcentaje de sólo el 27% "de éxito" es bastante bajo.

Además, en este estudio también han comprobado que hay poca o ninguna relación entre las prioridades (1, 2 y 3) de los puntos de verificación de WCAG y la importancia real de los problemas encontrados.

Por último, en este trabajo también presentan los problemas más frecuentes que tuvieron los tres grupos de usuarios con discapacidad que participaron en el estudio:

Problemas específicos de los usuarios con discapacidad visual
  • Enlaces que comienzan con la misma letra y que casi se leen igual. Estos enlaces son difíciles de distinguir.
  • Enlaces con el mismo texto que apuntan a sitios diferentes (por ejemplo, "Pulsa aquí para ir a A y pulsa aquí para ir a B").
  • Un número grande de enlaces y enlaces redundantes. Un ejemplo de enlace redundante es "leer más" que apunta al mismo sitio que el hipertexto mismo. Esto añade un trabajo extra a los usuarios que emplean lectores de pantalla.
Problemas específicos de los usuarios con discapacidad motora
  • La superficie en pantalla de un elemento/menú/botón es más grande que la superficie que en realidad se puede pulsar. En muchas ocasiones, sólo el texto se puede pulsar.
  • Los menús basados en mouse-over. Los menús que son dinámicos y no se pueden fijar en un sitio desaparecen cuando el usuario no está situado sobre ellos. Cuando ocurre esto, los usuarios tienen que empezar de nuevo desde cero.
  • Un tamaño del texto pequeño y un número grande de enlaces situados muy cerca aumente el riesgo de pulsaciones erróneas.
Problemas específicos de los usuarios con dislexia
  • El posicionamiento de los enlaces y los mecanismos de navegación. Los enlaces que se sitúan lejos en cualquiera de los lados de la página web son pasados por alto en muchas ocasiones.
  • Las páginas web abarrotadas de texto y enlaces son confusas y difíciles de leer y navegar.

martes 29 de septiembre de 2009

Los niveles A+ y A++

No es frecuente verlo, pero más de una vez he visto que alguna página web declaraba que tenía el nivel "A+" o "AA+". ¿Qué niveles son estos?

Si consultamos las pautas de accesibilidad al contenido en la web, tanto la versión WCAG 1.0 como la versión WCAG 2.0, no veremos ninguna referencia a estos dos niveles.

Por ejemplo, en WCAG 1.0, en el apartado 5. Conformance podemos leer:

This section defines three levels of conformance to this document:

  • Conformance Level "A": all Priority 1 checkpoints are satisfied;
  • Conformance Level "Double-A": all Priority 1 and 2 checkpoints are satisfied;
  • Conformance Level "Triple-A": all Priority 1, 2, and 3 checkpoints are satisfied;
Y en WCAG 2.0, en el apartado Conformance podemos leer:

In order for a Web page to conform to WCAG 2.0, all of the following conformance requirements must be satisfied:

1. Conformance Level: One of the following levels of conformance is met in full.

  • Level A: For Level A conformance (the minimum level of conformance), the Web page satisfies all the Level A Success Criteria, or a conforming alternate version is provided.

  • Level AA: For Level AA conformance, the Web page satisfies all the Level A and Level AA Success Criteria, or a Level AA conforming alternate version is provided.

  • Level AAA: For Level AAA conformance, the Web page satisfies all the Level A, Level AA and Level AAA Success Criteria, or a Level AAA conforming alternate version is provided.

Note 1: Although conformance can only be achieved at the stated levels, authors are encouraged to report (in their claim) any progress toward meeting success criteria from all levels beyond the achieved level of conformance.

Note 2: It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content.

Entonces, ¿de dónde han salido los niveles A+ y AA+? La clave está en la nota 1 del texto anterior, que anima a los autores de páginas web a indicar que han intentado cumplir pautas de niveles superiores al nivel que realmente han alcanzado. En el apartado Conformidad del documento Directrices de Accesibilidad del Contenido Web 2.0 del 30 de julio de 2004 (un borrador de la recomendación WCAG 2.0), aparece la siguiente definición de los niveles de conformidad:

  1. Para realizar una declaración de conformidad de un recurso Web con las directrices, dicho recurso debe satisfacer todos los criterios de cumplimiento de nivel 1 para todas las directrices.

  2. Puede realizarse una declaración de conformidad "WCAG 2.0 Nivel A" si se cumplen satisfactoriamente todos los criterios de cumplimiento de nivel 1 para todas las directrices.

  3. Puede realizarse una declaración de conformidad "WCAG 2.0 A+" si se cumplen satisfactoriamente todos los criterios de cumplimiento de nivel 1 para todas las directrices y algunos criterios de cumplimiento de nivel 2.

  4. Puede realizarse una declaración de conformidad "WCAG 2.0 AA" si se cumplen satisfactoriamente todos los criterios de cumplimiento de nivel 1 y todos los criterios de cumplimiento de nivel 2 para todas las directrices.

  5. Puede realizarse una declaración de conformidad "WCAG 2.0 AAA" si se cumplen satisfactoriamente todos los criterios de cumplimiento de nivel 1 y nivel 2 y todos los de nivel 3 para todas las directrices.

¿Y por qué no aparece en la recomendación definitiva? ¿Por qué no se emplea? Según podemos leer un poco después en este mismo documento, existían algunas discrepancias entre los miembros del WCAG y se ve que al final se desestimó la idea:
Las sugerencias y reacciones recibidas a raíz de WCAG 1.0 indican que los desarrolladores a menudo no tratan de cumplir ningún Punto de Verificación de Prioridad 2, porque no hay modo de indicar en la declaración de conformidad que han "hecho algo más que cumplir con el Nivel A pero no lo suficiente para reclamar el nivel AA". "A+" es una propuesta que permite a los desarrolladores declarar que "han hecho más que A pero menos que AA". Sin embargo, algunos miembros del WCAG ponen pegas a la idea de tener cualquier tipo de declaraciones de conformidad "+" como A+ o AA+.
Por cierto, ¿por qué se emplea la letra A para indicar el nivel de accesibilidad? Según el artículo sobre AAA en la Wikipedia en inglés, "AAA o Triple A se emplea para indicar que algo es de alta calidad o excelente". Por ejemplo, esta misma denominación se emplea para las valoraciones de credit rating.

Un curso sobre WCAG 2.0

Acabo de encontrar el curso Understanding Web Accessibility. El curso está en inglés y su objetivo es explicar las pautas de accesibilidad del contenido web WCAG 2.0. Desgraciadamente, el curso no es gratuito.

El curso está dividido en cuatro unidades, una unidad por cada uno de los principios de WCAG 2.0:

  1. Perceivable
  2. Operable
  3. Understandable
  4. Robust
Además, cada unidad está estructurada como sigue:
  1. The Principle (A brief description of the WCAG principle.)
  2. Reasons for Accessibility (A discussion of why the principle is important.)
  3. The Guidelines (A list of guidelines associated with the principle, along with "translations" in plain language.)
  4. Experiencing Barriers (A simulation of barriers as they might be experienced by people with disabilities.)
  5. Ways to Avoid Creating Barriers (An introduction to accessible content authoring strategies.)
    1. Success Criteria (Ways to conform with WCAG guidelines.)
    2. Sufficient Techniques (Strategies for creating accessible Web content.)
  6. Other Considerations (A discussion of accessibility issues not directly addressed by the guidelines.)
  7. Unit Quiz (Test your knowledge of the materials in the unit.)

Quinta edición del curso "Experto en accesibilidad y usabilidad de contenidos web"

La Fundación Instituto de Ciencias del Hombre junto con la Universidad de Alcalá de Henares organizan la quinta edición del curso Experto en accesibilidad y usabilidad de contenidos web. Los contenidos del curso son:

Acceso a la información

* Tema 1. Distintos tipos de discapacidades: visual, auditiva, cognoscitiva y motora.
* Tema 2. Barreras que presenta la Web a las distintas discapacidades. Simulaciones de discapacidad.
* Tema 3. Herramientas y técnicas especiales de acceso.

Accesibilidad de contenidos Web

* Tema 4. Herramientas de desarrollo.
* Tema 5. Introducción a la Accesibilidad.
* Tema 6. Directrices de Accesibilidad de la Iniciativa para una Web Accesible (WAI)
* Tema 7. Aplicando las Directrices de Accesibilidad.
* Tema 8. Análisis del grado de Accesibilidad.

Usabilidad y experiencia de usuario

* Tema 9. Introducción a la Usabilidad.
* Tema 10. Técnicas y métodos de evaluación de usabilidad y experiencia de usuario.
* Tema 11. Metodologías de Diseño Centrado en el Usuario.

Legislación y Normativa Aplicable

* Tema 12. Legislación y Normativa.
* Tema 13. Beneficios adicionales de implantar soluciones accesibles.