Simposio online sobre medidas de la accesibilidad web

El W3C, a través del WAI, organiza Website Accessibility Metrics Online Symposium el próximo 5 de diciembre de 2011. En la petición de artículos (call for papers) podemos ver que el plazo para enviar propuestas finaliza el próximo día 1 de noviembre.

El objetivo principal de este simposio es reunir, analizar y discutir experiencias prácticas relacionadas con la medición de la accesibilidad web.

Mitos y malentendidos sobre la ceguera al color

En mi clase del sábado sobre accesibilidad web de la asignatura Experiencia de usuario perteneciente al Curso de especialista en Diseño Web de la Universidad de Alicante surgió el daltonismo o ceguera al color, un problema de la visión que impide la correcta diferenciación de algunos colores. Sobre este tema ya he hablado en otras ocasiones, como por ejemplo:

• ¿Los daltónicos tienen problemas para navegar por la Web? (26/07/2008)
  
• Mejora de la accesibilidad para personas con daltonismo (28/10/2008)

¿Qué dice WCAG 1.0 sobre este tema? Si consultamos las Pautas de Accesibilidad al Contenido en la Web 1.0 del WAI podemos encontrar la siguiente pauta que hace referencia al color:

Pauta 2: No se base sólo en el color.
Asegúrese de que los textos y gráficos son comprensibles cuando se vean sin color.

Si el color por sí mismo se usa para transmitir información, las personas que no puedan diferenciar ciertos colores, y los usuarios que no tengan pantallas en color o utilicen dispositivos de salida no visuales, no recibirán la información. Cuando los colores de primer plano y de fondo tienen un tono similar, pueden no proporcionar suficiente contraste en las pantallas monocromáticas, así como a las personas con diferentes tipos de deficiencias de percepción de los colores.

Puntos de verificación:
2.1 Asegúrese de que toda la información transmitida a través de los colores también esté disponible sin color, por ejemplo mediante el contexto o por marcadores [Prioridad 1]
2.2 Asegúrese de que las combinaciones de los colores de fondo y primer plano tengan suficiente contraste para que sean percibidas por personas con deficiencias de percepción de color o en pantallas en blanco y negro [Prioridad 2 para las imágenes. Prioridad  3 para texto].

Esta claro que una persona ciega no puede percibir los colores y un lector de pantallas tampoco le va a leer los colores, así que no se puede depender de los colores para transmitir información esencial. ¿Y qué problemas tienen los daltónicos?
Existe bastante desinformación al respecto: por ejemplo, la mayoría de la gente asocia daltonismo con los colores rojo y verde, pero también existen otros tipos de daltonismo. El artículo Color Blindness Myths and Misunderstandings explica algunos mitos y malentendidos que existen sobre la ceguera al color. Los principales mitos son:

• Normalmente, la ceguera al color no significa la incapacidad de ver los colores, sino la incapacidad de distinguir algunos colores entre sí.
• La ceguera al color no significa que no se pueda ver el color rojo: no se puede distinguir de otros colores y, además, existe problemas de visión similares con otros colores distintos al rojo.
• Existe una visión normal del color: no exactamente, existe todo un espectro de posibilidades.
• Los problemas de visión con los colores suponen una molestia, pero no un problema grave: no es así, hoy en día los colores se emplean profusamente y su incorrecta interpretación puede ocasionar graves problemas.

Para terminar esta entrada, un par de herramientas que nos pueden ayudar a entender el daltonismo.

Color Blind Web Page Filter simula cómo ve una página web una persona con daltonismo: permite introducir la URL de una página y seleccionar el tipo de daltonismo, tal como podemos observar en la siguiente imagen.

Por otro lado, Colour Contrast Analyser es una herramienta que permite determinar si una combinación de dos colores (color de primer plano y de fondo) poseen el suficiente contraste de brillo y color.

¿Las pautas de WCAG garantizan realmente la accesibilidad?

En septiembre de 2009 escribí la entrada ¿Las pautas de WCAG garantizan realmente la accesibilidad?

Ahora acabo de encontrar una conferencia/seminario con el título Do Web Accessibility Guidelines guarantee Universal Design? que se celebró el 7 de mayo de 2009 en Oslo. No he encontrado los materiales de la conferencia, pero algunas de las charlas fueron:

• WCAG 2.0 - addressing the needs of people with disabilities and older people. A discussion of the opportunities and challenges created by this new standard in relation to Universal Design of the Web.
• WCAG 2.0 in practice: examples of what selected guidelines mean for the visually impaired.
• Universal Design in practice: examples of what it means for people with severe mobility impairments to make a Web site universally designed.

Traducción al castellano de WCAG 2.0

Acabo de descubrir que SIDAR publicó el pasado 15 de diciembre de 2009 una traducción autorizada al castellano por el W3C de las Pautas de Accesibilidad para el Contenido Web (WCAG) 2.0.

Por lo que he podido comprobar, el resto de documentos que componen WCAG 2.0, como puede ser Comprender las WCAG 2.0 o Técnicas para las WCAG 2.0 no han sido traducidas, pero esperemos que lo hagan en breve. ¡¡Ánimo!!

[Actualización 11/02/2010] Carlos Egea, que fue parte del equipo traductor de las Pautas de Accesibilidad al Contenido en la Web 1.0, me indica que por ahora esta traducción es una versión candidata, no es una versión oficial aún.

¿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.

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.

Hoja de trucos para pasar de WCAG 1.0 a 2.0

Web Content Accessibility Guidelines 1.0 — 2.0 Transition Cheat Sheet es una "hoja de trucos" donde podemos encontrar una correspondencia entre las pautas de WCAG 1.0 y WCAG 2.0 y agrupadas por nivel de conformidad (A, AA y AAA).

Por ejemplo, ¿cuál es la correspondencia entre las pautas que indican la necesidad de definir el idioma empleado en una página web (el uso del atributo lang)?

En esta hoja de trucos podemos ver que el punto de verificación 4.3 (Identify the primary natural language of a document) de WCAG 1.0 se corresponde con el criterio de cumplimiento 3.1.1 (Language of Page: The default human language of each Web page can be programmatically determined) de WCAG 2.0.

Además, el punto de verificación 4.1 (Clearly identify changes in the natural language of a document's text and any text equivalents, e.g., captions) de WCAG 1.0 se corresponde con el criterio de cumplimiento 3.1.2 (Language of Parts: The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text) de WCAG 2.0.

Cómo citar los documentos del WAI

Acabo de leer la página Referencing and Linking to WAI Guidelines and Technical Documents. En esta página nos explican como tenemos que citar (y enlazar) los documentos del WAI. Los principales consejos son:

1. Es mejor citar la página de descripción general (overview) que una especificación técnica concreta: la página de descripción general contiene una introducción, enlaces a documentos relacionados y el estado de revisión de los documentos.
2. Cuando se cite un documento concreto, es mejor citar la última versión que una versión concreta. Para ello hay que fijarse en la URL y utilizar aquella que no indique una versión. Por ejemplo, la dirección http://www.w3.org/TR/WCAG/ enlaza con la última versión de las pautas de accesibilidad al contenido web. El documento que se aloje en esta dirección irá cambiando según aparezcan nuevas versiones. Si se quiere indicar una versión concreta, por ejemplo la versión 2.0, entonces la dirección es http://www.w3.org/TR/WCAG20/.
3. Cuando se cite una guía de referencia o un documento técnico, es recomendable también citar a continuación la página con la descripción general sobre dicho documento. Por ejemplo,Web Content Accessibility Guidelines (WCAG) 2.0, WCAG Overview.

Entender la accesibilidad web correctamente

O evitar "construir la casa por el tejado". O evitar "poner el carro delante del caballo". Porque cuando uno se aproxima a la accesibilidad web a través de las pautas de accesibilidad al contenido, lo que está haciendo es "construir la casa por el tejado": está estudiando la solución a un problema, pero no conoce el problema en profundidad. Cuando uno conoce un problema se encuentra en disposición de proporcionar soluciones (buenas o malas), pero tiene la capacidad de hacerlo.

¿Cómo conocer el problema? El WAI del W3C ofrece el documento How People with Disabilities Use the Web. En este documento se muestran los siguientes escenarios de personas con discapacidad que utilizan productos de apoyo para navegar en la Web:

• Online shopper with color blindness - user customized style sheets
• Reporter with repetitive stress injury - keyboard equivalents for mouse commands, access keys
• Online student who is deaf - captioned audio from multimedia
• Accountant who is blind - appropriate table markup and alternative text
• Student with dyslexia - use of supplemental graphics, freezing animated graphics, multiple search options
• Retiree with aging-related conditions managing personal finances - screen magnification, stopping scrolling text, avoiding pop-up windows
• Supermarket assistant with cognitive disability - clear and simple language, consistent design, consistent navigation options, multiple search options
• Teenager who is deaf and blind seeking entertainment - accessible multimedia, device-independent access, appropriate table markup

Si se conocen los problemas que tienen los distintos tipos de personas con discapacidad y se conocen los productos de apoyo (hardware y software) que emplean para resolver o reducir sus problemas, se podrán crear sitios web mucho más accesibles.

La versión actual de este documento, que hace referencia a WCAG 1.0, está actualmente en fase de revisión. Se espera que para 2010 se publique una versión actualizada.

Un consejo al día

El sitio web One guideline a day tiene el objetivo de ayudar a aprender las nuevas pautas WCAG 2.0. Para ello, ofrece cada día una nueva guía con sus criterios de éxito (success criteria).

Mapa conceptual de WCAG 2.0

Acabo de encontrar un Mapa conceptual de WCAG 2.0 en formato PDF. Este mapa conceptual de las pautas WCAG 2.0 representa gráficamente los 4 principios, las 12 directrices y los 60 criterios de cumplimiento. Además, para cada criterio de cumplimiento indica su nivel de adecuación.

Traducción no oficial de WCAG 2.0

El W3C mantiene una página web con traducciones de WCAG 2.0. La traducción autorizada al castellano de WCAG 2.0 comenzó en abril de 2009. Sin embargo, ya existe una traducción no autorizada: Pautas de Accesibilidad de Contenido Web 2.0.

Otro documento que ha traducido del inglés el mismo autor es Comparativa entre los puntos de comprobación de las Pautas de Accesibilidad de Contenido Web 1.0 y las Pautas 2.0, agrupados por prioridades, traducción de Comparison of WCAG 1.0 Checkpoints to WCAG 2.0, Grouped by Priorities.

Hacia las pautas WCAG 2.0

El Centro de Referencia en Accesibilidad y Estándares Web, dependiente de INTECO, ha publicado recientemente el documento Hacia las Pautas WCAG 2.0: Guía de transición para evaluadores y desarrolladores.

Aunque por el título puede parecer que este documento va a explicar cómo pasar de WCAG 1.0 a WCAG 2.0, en realidad ofrece una introducción a las nuevas pautas, explicando los documentos que componen las nuevas pautas y la forma de leerlos e interpretarlos.

Al inicio de este documento podemos encontrar la siguiente explicación:

Esta Guía ofrece una visión general de las nuevas Pautas, tanto de su filosofía y organización como de otros aspectos más prácticos que permitan entender su significado en el día a día.

En primer lugar, se ofrece un resumen de los antecedentes históricos de las Pautas 2.0, así como el proceso de aprobación seguido por el W3C.

A continuación se analiza la nueva estructura y organización de las WCAG 2.0 y su documentación asociada, destacando las principales diferencias con respecto de sus predecesoras.

Por último, se ofrecen explicaciones detalladas sobre la aplicación y significado de las WCAG 2.0 en relación a los distintos elementos encontrados en las páginas web, tratando de establecer las similitudes y diferencias con respecto de la versión 1.0 de las Pautas.

Accesibilidad de las herramientas de autor

Hace unos días escribí sobre la accesibilidad de los gestores de contenidos. Como comente, los gestores de contenidos son herramientas de autor. Según el WAI, "las herramientas de autor permiten, facilitan y promueven la aportación de texto alternativo en una página Web".

Para las herramientas de autor existen una serie de pautas, Authoring Tool Accessibility Guidelines (ATAG). ¿Qué nos dicen estas pautas? La ATAG 1.0 (febrero 2000) se compone 7 pautas y 28 puntos de verificación:

• PAUTA 1: Facilitar la accesibilidad de la autoría.

Si las marcas se generan de forma automática, muchos autores no se darán cuenta de la accesibilidad del producto final, a menos que le dediquen un esfuerzo añadido para realizar las correcciones oportunas a mano.

Puesto que a un número importante de autores la accesibilidad no les resulta familiar, las herramientas de autor son responsables de generar marcado accesible de forma automática y, donde sea adecuado, de guiar al autor para producir contenido accesible.

• PAUTA 2: Generar marcado estándar.

La conformidad con estándares promueve la interoperabilidad y la accesibilidad al facilitar que existan navegadores especializados para usuarios concretos.

• PAUTA 3: Dar soporte a la creación de contenido accesible.

Una información bien estructurada y la incorporación de contenidos accesibles equivalentes son fundamentales para un diseño accesible.

Sin embargo, por ejemplo, la producción de información equivalente útil para las herramientas de accesibilidad, puede ser uno de los aspectos más complejos del diseño web y las herramientas de autor deben facilitar y automatizar este proceso.

• PAUTA 4: Proporcionar medios par verificar y corregir contenido inaccesible.

Muchas herramientas permiten al autor crear documentos con poco o ningún conocimiento de las marcas subyacentes. Para asegurar la accesibilidad, las herramientas de autor deben ser diseñadas de forma que puedan identificarse automáticamente contenidos inaccesibles, y permitir su corrección incluso en los casos en los que las marcas están ocultas al autor.

• PAUTA 5: Integrar las soluciones de accesibilidad en la interfaz de usuario.

Cuando se añade una nueva característica a una herramienta existente sin una integración apropiada, el resultado es una discontinuidad obvia. Por lo tanto, es importante que la creación de contenido accesible sea un proceso natural dentro de la herramienta.

• PAUTA 6: Promover la accesibilidad en la ayuda y documentación.

Los autores pueden no estar familiarizados con los problemas de accesibilidad que surgen al crear contenido web. La ayuda y la documentación deberían explicar los problemas habituales de accesibilidad y sus soluciones con ejemplos ilustrativos.

• PAUTA 7: Asegurar que la herramienta de autor sea accesible para autores con discapacidad.

Las herramientas de autor son aplicaciones con elementos de interfaz de usuario estándar y como tal tienen que seguir una pauta de accesibilidad.

Color y contraste

Las combinaciones de color con poco contraste pueden causar problemas a algunos grupos de usuarios con problemas de visión. Las Pautas de Accesibilidad al Contenido en la Web 1.0, en su pauta 2.2 dice:

2.2 Asegúrese de que las combinaciones de los colores de fondo y primer plano tengan suficiente contraste para que sean percibidas por personas con deficiencias de percepción de color o en pantallas en blanco y negro [Prioridad 2 para las imágenes. Prioridad 3 para texto].

Existen algunas herramientas que permiten calcular la diferencia de brillo y de color entre dos colores. Por ejemplo:

• Colours and contrast
• Luminosity Colour Contrast Ratio Analyser
  

¿WCAG 2.0 es la solución a los problemas de accesibilidad?

Acabo de encontrar el artículo WCAG 2.0 is official - but is that all you need to make a site accessible? ¿WCAG 2.0 es la solución a los problemas de accesibilidad actuales? En este breve artículo se plantea que adherirse a una pautas no es la única forma de resolver los problemas de accesibilidad. Además, hay que:

• Utilizar los estándares de la Web.
• Evitar las tecnologías propietarias.
• Asegurar que los sitios web validan siempre que sea posible.

Otro artículo sobre WAI-ARIA

A través de un comentario que me han hecho a la entrada Introducción WAI ARIA que escribí ayer me han pasado el enlace de otro artículo parecido: WAI-ARIA, una aproximación. El artículo explica qué es WAI-ARIA, sus orígenes, las soluciones que aporta y contiene algunos ejemplos de utilización: la definición de una zona de navegación (la típica barra de navegación o de menú de un sitio web) y cómo hacer que un widget de tipo slider (barra deslizante) sea accesible.

Las pautas de accesibilidad con ejemplos

Acabo de encontrar el sitio Web Accessibility. Los más interesante es el apartado Web Content, que contiene numeros ejemplos que explican las pautas de accesibilidad del W3C.

Las pautas están agrupadas por temas (Color, Formularios, Marcos, Imágenes, etc.). Así, por ejemplo, para el tema del color se comentan los siguientes puntos de verificación:

• 2.1 Asegúrese de que toda la información transmitida a través de los colores también esté disponible sin color, por ejemplo mediante el contexto o por marcadores [Prioridad 1]
  
• 2.2 Asegúrese de que las combinaciones de los colores de fondo y primer plano tengan suficiente contraste para que sean percibidas por personas con deficiencias de percepción de color o en pantallas en blanco y negro [Prioridad 2 para las imágenes. Prioridad 3 para texto].

Y se propone el empleo de la herramienta Colour Contrast Analyser para calcula el contraste entre el color del primer plano y el color del fondo.

WCAG 2.0: ¡por fin!

Acabo de leer en El País la noticia W3C marca nuevas directrices para hacer más accesible Internet a todos los públicos. ¿Es verdad? Sí, ya tenemos la versión de las pautas de accesibilidad del contenido web: Web Content Accessibility Guidelines (WCAG) 2.0 (W3C Recommendation 11 December 2008). ¡Enhorabuena!

La noticia dice:

World Wide Web Consortium (W3C), organización internacional dedicada al desarrollo de Internet, acaba de lanzar nuevas directrices para ayudar a diseñadores y desarrolladores de páginas web a crear sitios más accesibles para personas mayores y con discapacidad, según informan a través de un comunicado de prensa.

Se trata de las Pautas para la accesibilidad del contenido en la web WCAG2.0, que tienen por objetivo eliminar las barreras para acceder a Internet que encuentran las personas con discapacidad visual, física, cognitiva y neurológica, así como los mayores.

Según W3C, estas directrices mejoran sus medidas actuales y estándares de accesibilidad para todo tipo de contenido online, ya sea texto, imágenes, audio y vídeo y aplicaciones web. También explican cómo hacer dicho contenido más fácil de navegar y leer, utilizando alternativas de texto para las imágenes, subtítulos para el audio, contrastes de color, comandos de teclado, así como compatibilizarlo con el uso de ayudas técnicas.

"WCAG 2.0 representa el resultado de un importante esfuerzo de colaboración, y su resultado final cuenta con un amplio apoyo del sector de la nuevas tecnologías, las organizaciones para la discapacidad y el ámbito de la investigación", ha asegurado Gregg Vanderheiden, vicepresidente del grupo de trabajo que desarrolla estas directrices.

Por su parte George Kerscher, secretario del Consorcio Daisy, que ha creado el estándar para facilitar la lectura y consulta de los libros hablados digitales a las personas ciegas, considera que WCAG 2.0 ayudará a las organizaciones que suministran información a través de Internet a adaptarse a los nuevos requisitos que establece la Convención de Naciones Unidas sobre los Derechos de las Personas con Discapacidad.

"Dicha convención reconoce por primera vez el acceso a la información y las comunicaciones como un derecho humano, y WCAG 2.0 pretende contribuir a hacer ese derecho una realidad en todo el mundo", ha subrayado Kerscher.

El W3C también tiene su noticia: Estándar Web del W3C define la accesibilidad para la Web de nueva generación.

Vídeos sobre accesibilidad del Congreso de WebMasters 2007

Cinco vídeos con la presentación que María Jesús Fernández Ruiz realizó sobre la accesibilidad web en el Congreso de WebMasters 2007.

Lástima que en los vídeos sólo se vea a la conferenciante y no se vean las transparencias que utilizó. Todo lo que cuenta es muy interesante, pero los vídeos son un poco aburridos.