¿Qué ha pasado con el Catálogo de productos de apoyo CEAPAT?

Erase una vez...

El Centro de Referencia Estatal de Autonomía Personal y Ayudas Técnicas (CEAPAT), dependiente del Imserso, tenía un catálogo de productos de apoyo alojado en el dominio catalogo-ceapat.org.

Sorpresa, sorpresa, si ahora se accede a ese dominio aparece la siguiente página web:

¡Una página en japonés!

Cuando hasta finales del año pasado lo que aparecía era esto (copia en Internet Archive):

¿Qué ha pasado?

En la web de CEAPAT, en la página Catálogo de productos de apoyo, podemos leer:

El «Catálogo de productos de apoyo» no se encuentra disponible en la actualidad. Estamos intentando solucionar el problema y esperamos que vuelva a estar operativo a la mayor brevedad posible.

¿Qué ha pasado?

¿Dónde está el catálogo?

En whois podemos encontrar la siguiente información:

¡Ohhhh! El dominio está registrado a nombre de muruka hatanaka, de Japón. Y la fecha de actualización es 18 de febrero de 2016.

¿Qué puede haber pasado?

Presentación sobre las herramientas automáticas de evaluación de la accesibilidad web

En el congreso CSUN16 se ha presentado Accessibility Tools Presentation, una conferencia en la que se analizan cuatro herramientas automáticas de evaluación de la accesibilidad web:

• Accessibility Developer Tools Overview
• AInspector Sidebar Overview
• aXe Overview
• WAVE Overview

Técnicas de accesibilidad para la discapacidad cognitiva

El impacto que tiene la discapacidad cognitiva en el uso de la Web es de los temas de la accesibilidad web que menos ha sido estudiado. La discapacidad cognitiva agrupa diferentes tipos de discapacidades o síndromes que dificultan la sistematización de las soluciones que se deben aplicar.

Muy importante: no se debe confundir discapacidad cognitiva con discapacidad intelectual. Una puede implicar la otra y vice versa, pero no son lo mismo. Algún día lo explicaré...

El W3C acaba de publicar el primer borrador de Techniques for the The Cognitive and Learning Disabilities Accessibility Task Force (COGA). Realmente, no se puede llamar ni borrador, es más bien un esquema de lo que se pretende redactar, muchas de sus secciones están vacías. Sin embargo, es un buen inicio.

Por ahora, las principales técnicas que se deben aplicar para garantizar la accesibilidad son:

1. Use a clear structure with easy to follow sections short paragraphs manageable chunks
2. Use an easy to follow writing style
3. Provide rapid and direct feedback
4. Help the user understand the content and orientate themselves in the content.
5. Help users complete and check their work by less likely that the user will make mistakes and easy to undo mistakes when they occur
6. Provide help
7. Help the user focus and help restore the context if attention is lost
8. Enable adaptability and personalization, so that symbols text and other features rare familiar and helpful to the user
9. Minimize the cognitive skills required to use the content and avoid barriers that stop people with cognitive disabilities from using content, such as hard to use security mechanisms.

Requisitos de accesibilidad para las personas con baja visión

Hace una semana, el W3C publicó el primer borrador de Accessibility Requirements for People with Low Vision.

En esta recomendación se intenta definir el concepto de baja visión:

“Low vision” refers to visual impairments other than blindness. Other terms, such as “partially sighted” and “sight impaired”, are used in different contexts. Some governments and organizations such as the World Health Organization (WHO) define categories of low vision based on specific levels of visual acuity and field of vision. Visual acuity is the clarity or sharpness of vision. Field of vision is the area a person can see when their eyes are fixed in one position.
In many contexts, low vision only includes impairments that are not corrected with regular glasses, contact lenses, medicine, or surgery. For example, an inability to focus on objects close to the viewer but that can be overcome with reading glasses is not considered low vision in some disability rights contexts. In these contexts, low vision is often defined as visual impairment that interferes with a person’s ability to perform everyday activities.
In some contexts, such as social program benefits, people are classified as having low vision or being “legally blind”. Many people who are legally blind have some usable vision, and can read some text when it is displayed optimally for them.
In considering user needs, this document uses a broad scope of low vision to include all visual impairments except significant blindness — including impairments from aging, “color blindness”, and impairments that are often categorized as legally blind yet people have sufficient vision to see user interfaces in some situations. This document does not include all issues that are also relevant for people who are totally blind. It does include several issues that overlap with the needs of some people with cognitive disabilities.

Y se describen cinco categorías de baja visión que influyen en el uso de la Web:

• Visual acuity (clarity)
• Light sensitivity
• Contrast sensitivity
• Field of vision
• Color vision

Modo lectura fácil en Mozilla Firefox (Reader View)

Álvaro, un lector de este blog, me ha pasado la siguiente información: Disfruta leyendo páginas web con la Vista de lectura. La descripción dice:

El Modo Lector es una función de Firefox que quita distracciones como botones, publicidades e imágenes de fondo, y cambia el tamaño del texto de la página, su contraste y su diseño para una mejor legibilidad. La configuración del Modo Lector es fácilmente personalizable para cubrir tus necesidades a la hora de leer.

Lo he probado con mi sitio web sobre accesibilidad web, y no funciona.

Lo he probado con mi blog sobre accesibilidad web, y tampoco funciona.

Lo he probado con mi página personal (Sergio Luján Mora), ¡y sí que funciona!

Esta es la vista normal:

Y esta es la vista de lectura fácil:

¿Por qué unas veces funciona y otras veces no?

En la página principal de muchos sitios web no funciona, pero sí funciona en páginas de segundo nivel, como por ejemplo:

• Los españoles en el extranjero aumentan un 56,6% desde 2009
• Thomsom Reuters incorpora siete revistas de la Universidad de Alicante en Emerging Source Citation Index (ESCI) de Web of Science
• Ankara blast: Kurdish group TAK claims bombing

He tenido que buscar un poco, pero he encontrado algunas explicaciones:

• Why don't I have a reader mode icon?
• Optimize website to show reader view in Firefox
• How Does Firefox Reader View Operate (FF version 38.0.5)

Aquí está la información oficial sobre Reader view, pero no dice mucho de su funcionamiento.

Según he leído, se emplea un algoritmo para darle un puntaje a cada elemento de la página web, y si el puntaje alcanza cierto valor, se aplica el modo de lectura fácil.

Habrá que seguir investigando...

Curso Accesibilidad web avanzada: Análisis y corrección de problemas de accesibilidad en páginas y aplicaciones web

La Universidad Alcalá organiza el curso Accesibilidad web avanzada: Análisis y corrección de problemas de accesibilidad en páginas y aplicaciones web.

El curso tiene una duración de 75 horas y es gratuito. Su temario es:

• Tema 1. Estándares y legislación sobre accesibilidad web.
• Tema 2. Pautas de accesibilidad para el contenido web (WCAG 2.0)
• Tema 3. Evaluación de la accesibilidad de sitios web (WCAG-EM 1.0)
• Tema 4. Accesibilidad web avanzada (WAI-ARIA 1.0 y ATAG 2.0).

Ejemplo de control mental del ordenador: componer música

Un lector de este blog me ha pasado la noticia Violinista minusválido hace música por primera vez en 27 años usando sus ondas cerebrales.

En este blog he hablado varias veces sobre el control del ordenador con la mente (pensamiento). Es algo que ya es posible, pero no de la forma que podríamos esperar. Por ahora, un ordenador no puede leer nuestro pensamiento, pero sí que puede detectar ciertos patrones de actividad eléctrica cerebral que se pueden asociar a acciones programadas.

Wikipedia está desarrollando una plataforma de síntesis de voz

En Wikipedia is developing a speech engine for visually impaired users se explica que se está desarrollando una plataforma de síntesis de voz para 300 idiomas mediante crowdsourcing:

Researchers will begin developing the engine for Swedish, English, and Arabic, which they aim to complete by September 2017, before expanding it to the other 280 languages in which Wikipedia is available.

Según se dice en el artículo, un 25% de los usuarios de Wikipedia tendrán interés en usar este sistema:

According to Swedish telecommunications regulator PTS, which is financing the project, an estimated 25 percent of Wikipedia users — 125 million users per month — need or prefer speech to text.

Herramienta para analizar el riesgo de epilepsia por fotosensibilidad

Hace un tiempo comenté una pauta de las Pautas de accesibilidad para el Contenido Web 2.0 (WCAG 2.0) que es un poco "extraña":

Pauta 2.3 Convulsiones: No diseñar contenido de un modo que se sepa podría provocar ataques, espasmos o convulsiones.

En mi entrada No diseñar contenido de un modo que se sepa podría provocar ataques, espasmos o convulsiones comenté el famoso caso de la serie de dibujos animados Pokemon.

Álvaro, un lector de este blog, me ha avisado de la existencia de Photosensitive Epilepsy Analysis Tool (PEAT), una herramienta gratuita que evalúa el riesgo de producir ataques de epilepsia por fotosensibilidad en el contenido web.

¿Microsoft Edge el navegador más accesible?

En Is Microsoft changing the game for accessible browsers? cuentan que Microsoft está desarrollando una nueva API para su navegador Edge.

La información se basa en el artículo publicado en un blog de Microsoft, Making Microsoft products more accessible: Our path forward:

We’re also working hard on our new browser, Microsoft Edge. By the end of 2016, the browser will have improved browsing and reading experiences not just for those using our built-in assistive technologies, such as Narrator and Magnifier, but also for people who use other commercial assistive technology.

¿Cuántas personas sordociegas hay en España?

Hace tiempo me hice la pregunta ¿Cuántas personas sordociegas hay en el mundo? La respuesta que obtuve es que debe haber 1.100.000 personas sordociegas.

Ahora me he hecho la misma pregunta respecto a España y he encontrado la respuesta en Gennet Corcuera, primera sordociega que estudiará en una universidad española. Según el artículo del año 2003:

Como ella, Gennet espera convertirse en un referente para los 6.000 sordociegos españoles y está segura de que su caso "va a animarles a hacer" lo que ella y a "abrir la sociedad a la sordoceguera, como hicieron conmigo en el instituto", apunta.

Recomendación de información breve sobre usabilidad

Un compañero me ha escrito con esta solicitud:

Hola Sergio:
Te escribo por si tú conoces alguna página que describa brevemente todos o casi todos los puntos que una web debe cumplir para tener buena usabilidad.
Gracias.

Difícil, difícil... algo breve, algo rápido, yo me suelo "demorar" en lo que es importante :-)

Mi respuesta fue:

¿Usabilidad o accesibilidad? Te lo pregunto porque la mayoría de la gente lo confunde.

Usabilidad: la usabilidad es bastante subjetiva y se suele definir en base a un perfil de usuario. Sin embargo, sí que existe esta norma ISO:

ISO 9241-151:2008 Ergonomics of human-system interaction -- Part 151: Guidance on World Wide Web user interfaces

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=37031

La norma es de pago.

Pero como me pides algo breve, te recomiendo los artículos de Nielsen, en su blog hay cientos, algunos por los que puedes empezar:

https://www.nngroup.com/articles/usability-101-introduction-to-usability/

https://www.nngroup.com/articles/ten-usability-heuristics/

https://www.nngroup.com/articles/top-10-mistakes-web-design/


Accesibilidad: está la recomendación del W3C, que se convirtió en norma ISO:

ISO/IEC 40500:2012 Information technology -- W3C Web Content Accessibility Guidelines (WCAG) 2.0

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=58625

Aquí la tienes gratis:

https://www.w3.org/TR/WCAG20/

Pero como me pides algo breve, te comiendo esto:

http://webaim.org/resources/designers/

Java Jive

No hay mucha información sobre ello, pero he descubierto que en el año 1997 se desarrolló un lector de pantalla con el lenguaje de programación Java llamado Java Jive. Algunas referencias sobre ello:

• New Java technology helps blind computer users access the Net. (new screen reader code-named 'Java Jive')
• IBM Special Needs group shows prototype Java screen reader in work

Así funciona la voz de Stephen Hawking

En Así funciona la voz de Stephen Hawking: “Me apoyo en la tecnología para comunicarme y vivir” se explica cómo funciona el producto de apoyo desarrollado por Intel que emplea Stephen Hawking para comunicarse.

En el artículo podemos leer:

La responsable de que sus palabras sigan llegando hasta nosotros en la actualidad es Lama Nachman, directora del Experience Technology Lab de Intel. Su trabajo consiste en conseguir que Stephen Hawking, a pesar de sus limitadísimas capacidades motoras, pueda manejar el ordenador que siempre le acompaña. La plataforma diseñada por el equipo de Nachman se denomina ACAT e incorpora sensores de velocidad, acelerómetros, una cámara 3D y un software de predicción de palabras muy sofisticado que reduce las pulsaciones necesarias para escribir. Además Intel ha decidido abrir su código, por lo que todos los desarrolladores del mundo pueden incorporar nuevos elementos. Un ejemplo de trabajo colaborativo para hacer mejor la vida de las personas con discapacidad y conseguir que, tal y como se escuchaba al propio Hawking afirmar en la canción de Pink Floyd, puedan “seguir hablando”.

¿Iberia la web más accesible?

Eso es lo que se puede leer en Iberia.com es la página de comercio electrónico mejor valorada de España:

El resultado es que el sector con mejor experiencia de usuario es el de Viajes y Ocio, e Iberia, la empresa más accesible.

Claro, todo depende de lo que quieran decir por "accesible". Pero, esto es lo que dice Wave (25 errores y 144 alertas):

Y esto es lo que dice eXaminator (una calificación de 6.7, 2 errores muy mal y 3 errores mal):

Así que, de accesible, nada. Pero lo tendrá que ser o se enfrentará a un grave problema con el Departamento de Transporte de Estados Unidos.

¿Transparente significa accesible?

Hace dos días se publicó la noticia Fundaciones de La Caixa y Telefónica, entre las web más transparentes. En la noticia se comenta:

Las fundaciones de La Caixa, Gas Natural Fenosa, Telefónica, Accenture y Atressmedia son las fundaciones empresariales en España con un mayor nivel de transparencia en sus respectivas páginas web, según un estudio elaborado por la Fundación Compromiso y Transparencia.

El estudio determina que la transparencia voluntaria en la web supone "el esfuerzo por difundir y publicar la información relevante de la organización, haciéndola visible y accesible y a todos los grupos de interés de manera íntegra y actualizada".

Entre las condiciones que puntúa el estudio figuran la visibilidad de los contenidos en la web, la accesibilidad, la actualidad de la información que ofrece y que ésta sea completa y exhaustiva.

¿Son accesibles los sitios web de las fundaciones empresariales con un mayor nivel de transparencia? Vamos a comprobar dos de los sitios.

La fundación de La Caixa:

Según la herramienta de evaluación automática WAVE, la página contiene 4 errores (3 encabezados vacíos) y 36 alertas:

Según eXaminator, la página obtiene una calificación de 6.0, con 3 errores muy mal y 7 errores mal:

La fundación de Gas Natural Fenosa:

Según WAVE, la página tiene 14 errores (11 enlaces vacíos) y 28 alertas:

Según eXaminator la página tiene una calificación de 6.0, con 2 errores muy mal y 6 errores mal:

Pues no parece que sean muy accesibles. Los resultados de estas herramientas automáticas de evaluación se deben contrastar por un experto pero, si encuentran algo es porque seguro que hay problemas (aunque no todo lo que detectan son problemas reales).

Accesibilidad de los sitios web de las aerolíneas

En diciembre de 2015 escribí la entrada El sitio web de una aerolínea debe ser accesible (en Estados Unidos) en la que comentaba que el Departamento de Transporte de Estados Unidos está obligando a todas las aerolíneas que vuelen a Estados Unidos (norteamericanas o extranjeras, da igual) a garantizar la accesibilidad WCAG 2.0 AA de sus sitios web.

Todo esto empezó en noviembre de 2013, y entonces ya se avisaba de que se le estaba dando demasiado tiempo a las aerolíneas para cumplir algo que ya deberían de haber cumplido hace tiempo: It’s Hard to be Optimistic About the New DOT Web and Kiosks Regulations.

Y así ha ocurrido, porque se ha cumplido el primer plazo (12/12/2015) y las aerolíneas han solicitado una prórroga al Departamento de Transporte porque no han cumplido lo exigido.

¿Cómo lo sé?

Porque hace un par de días me reuní con el equipo informático de una aerolínea y estuvimos hablando de sus problemas. Esta aerolínea, al igual que Iberia (Iberia cumple con Estados Unidos, pero no con España) está interesada en cumplir porque lo exige Estados Unidos, no porque lo exija la normativa de su país o porque crea que es lo correcto.

Según me contaron, el Departamento de Estado ha ofrecido a todas las aerolíneas una prórroga hasta junio de 2016 para cumplir el primer hito de accesibilidad, que supone que las siguientes secciones deben ser accesibles: "booking" y "checking" de los vuelos, la información personal sobre un itinerario, el estado de un vuelo, el horario de un vuelo, la información de contacto y la información sobre la cuenta de viaje frecuente.

Por último, según podemos leer en Rising to the challenge of U.S. DOT accessibility requirements for web check-in, esta iniciativa ayudará a 56 millones de pasajeros con discapacidad de Estados Unidos.

Ecuador ya cuenta con un reglamento técnico para la aplicación de su norma sobre accesibilidad web

Hace dos años, Ecuador publicó la norma NTE INEN-ISO/IEC 40500 "Tecnología de la información - Directrices de accesibilidad para el contenido web del W3C (WCAG) 2.0 (ISO/IEC 40500:2012, IDT), la norma ecuatoriana sobre accesibilidad web (Ecuador ya tiene una norma sobre accesibilidad web).

Hace unos días, el 10 de febrero de 2016, el Servicio Ecuatoriano de Normalización publicó el Reglamento Técnico Ecuatoriano RTE INEN 288 “Accesibilidad para el contenido web". Este reglamento entrará en vigor el 8 de agosto de 2016 y establece:

• Los requisitos de accesibilidad que debe cumplir el contenido web al público para que pueda ser utilizado por todas las personas con o sin discapacidad, bien de forma autónoma o mediante los productos de apoyo tecnológico adecuados.
• Aplica a los contenidos web publicados en los sitios web del sector público y privado que presten servicios públicos. ¿Qué son servicios públicos? No se indica en el reglamento.
• No es aplicable al software utilizado para acceder a los contenidos Web (aplicaciones de usuario), ni al utilizado para generar dichos contenidos (herramientas de autor).
• Se debe satisfacer por completo el nivel de conformidad AA, establecido en la Norma NTE INEN-ISO/IEC 40500, Esta norma es una traducción exacta de WCAG 2.0.
• El cumplimiento de este reglamento debe ser demostrado mediante la presentación de un certificado de conformidad de primera parte, el cual debe estar colocado en el propio sitio web de acuerdo a lo que determine la autoridad competente. Un certificado de conformidad de primera parte es un certificado o evaluación que lleva a cabo la persona o la organización que provee el objeto.
• El reglamento entra en vigencia transcurridos ciento ochenta (180) días calendario desde la fecha de su promulgación en el Registro Oficial. En concreto, entrará en vigencia el 8 de agosto de 2016.
• Por último, se incluyen dos disposiciones transitorias sobre el plazo para cumplir con el reglamento y la norma:
• TRANSITORIA PRIMERA. Los propietarios de los sitios web a los que se aplica este reglamento técnico tendrán un plazo de 2 años para adecuar sus sitios web existentes al momento de entrar en vigencia el reglamento de acuerdo al nivel de conformidad “A” de la norma NTE INEN vigente. El 8 de agosto de 2018, todos los sitios web ecuatorianos que presten un servicio público deben ser accesibles WCAG 2.0 nivel A.
• TRANSITORIA SEGUNDA. Los propietarios de los sitios web a los que se aplica este reglamento técnico tendrán un plazo de 4 años para adecuar sus sitios web existentes al momento de entrar en vigencia el reglamento de acuerdo al nivel de conformidad “AA” de la norma INEN vigente. El 8 de agosto de 2020, todos los sitios web ecuatorianos que presten un servicio público deben ser accesibles WCAG 2.0 nivel AA.

En el 2050 la mitad de la población tendrá problemas de visión

En la noticia Half the world's population will be short-sighted by 2050 nos cuentan que en el 2050 la mitad de la población tendrá problemas de visión. La noticia hace referencia al estudio Global Prevalence of Myopia and High Myopia and Temporal Trends from 2000 through 2050 publicado en la revista científica Ophthalmology.

Una posible explicación de este alarmante incremento puede ser que cada vez pasamos más tiempo en espacios cerrados y necesitamos ver menos hacia "el infinito".

Uso del término persona con diversidad funcional

El término persona con diversidad funcional no se emplea muy a menudo, así que me ha sorprendido encontrarlo en un reportaje publicado en la revista Ronda:

Rihana produce ataques epilépticos (y otros tipos de ataques)

Hace unos meses escribí la entrada No diseñar contenido de un modo que se sepa podría provocar ataques, espasmos o convulsiones en la que hablaba del episodio de la serie Pokemon que produjo ataques epilépticos a varios cientos de niños japoneses.

Una de mis doctorandas me ha pasado el siguiente vídeo de Kanye West y Rihanna que tiene el siguiente aviso:

WARNING: This video has been identified by Epilepsy Action to potentially trigger seizures for people with photosensitive epilepsy. Viewer discretion is advised.

10 pruebas de accesibilidad web para realizar en 10 minutos (parte 2)

Hace unos días se publicó el artículo 10 pruebas de accesibilidad web para realizar en 10 minutos (parte 2), mi décima contribución al Observatorio de la Accesibilidad de la Confederación Española de Personas con Discapacidad Física y Orgánica (COCEMFE).

Empresas u organizaciones que ofrecen servicios de accesibilidad web

No es un catálogo exhaustivo, simplemente las empresas u organizaciones que he recordado en cinco minutos.

En España:

• Lotura
• Olga Carreras
• Taller Digital de la Universidad de Alicante
• Tanta Comunicación
• TAW, además del famoso analizador también ofrece servicios de consultoria.

A nivel internacional:

• Access iQ (Australia)
• Digital Accessibility Centre (Reino Unido)
• WebAIM (Estados Unidos)

Ejemplo de vídeo accesible

El siguiente vídeo es accesible porque:

• Posee subtítulos para personas con problemas de audición.
• Posee audiodescripción para las personas con problemas de visión.

Dos problemas típicos

Hace unos días estuve en comunicación con una persona responsable del Foro Histórico de las Telecomunicaciones, una iniciativa muy interesante.

Le comenté dos errores típicos que afectan a la accesibilidad de una página web:

Uso de colores con poco contraste

Hay texto con un color gris claro que es difícil de leer para usuarios con problemas de contraste.

En la siguiente imagen se muestra una página tal como la ve una persona sin problemas de visión. El texto principal está en gris, tiene un tamaño pequeño y un grosor fino, eso dificulta la lectura a personas con algunos tipos de problemas de visión. Incluso una persona sin problemas de visión tendrá dificultades para ver la página si usa un teléfono móvil a plena luz del día.

En la siguiente imagen  se muestra una simulación de visión de bajo contraste. El texto principal ahora es más difícil de leer.

Para calcular si dos colores tienen un contraste suficiente se puede usar alguna de las herramientas online que calcula el contraste entre dos colores. Yo suelo utilizar Color Contrast Checker, pero hay otras igual de válidas.

Enlaces no destacados cuando reciben el foco

Algunos enlaces no se destacan cuando reciben el foco con el teclado, eso impide su uso por los usuarios que no utilicen un ratón o dispositivo táctil.

En la siguiente imagen, el enlace "Multimedia" de la barra de navegación principal está destacado, correcto, eso ayuda a los usuarios a no "sentirse perdidos". Pero no se destacan los enlaces cuando reciben el foco por el teclado. En esta captura, yo me he situado en el enlace "Museo", se puede saber porque en la parte inferior de la captura se visualiza la URL del enlace. Sin embargo, el propio enlace no aparece destacado.

La página de la universidad en la que trabajo no es un ejemplo de excelencia, el error de enlaces no destacados existe. Pero en el caso de la barra de navegación principal sí que se destacan los enlaces, aparece una línea debajo del enlace cuando el usuario se desplaza. En este ejemplo, el enlace "La universidad" aparece destacado, ya que es el enlace sobre el que me he situado.

Estudios integrales sobre la accesibilidad de la Ley General de derechos de las personas con discapacidad y de su inclusión social

Hace justo dos años se aprobó la Ley General de derechos de las personas con discapacidad y de su inclusión social. En esa ley, el artículo 24 decía:

En el plazo de dos años desde la entrada en vigor de esta ley, el Gobierno deberá realizar los estudios integrales sobre la accesibilidad a dichos bienes o servicios que se consideren más relevantes desde el punto de vista de la no discriminación y accesibilidad universal.

¿Dónde está ese informe?

Accesibilidad en Moodle

Accessibility es un "bloque", un plugin para Moodle que mejora su accesibilidad. La descripción de este plugin dice:

The block allows users to customise Moodle to their visual needs.  It supports changing of text sizes and colour schemes.  Customisations save to the user's session, allowing them to persist between pages, and can also be saved to the database allowing them to apply permanently.

The block also integrates ATBar from Southampton University ECS. This provides extra tools and customisation options, including dictionary lookup and Text-to-speech.  Visual customisations performed with ATBar don't currently persist, and can be used as well as or instead of the block's own customisations.

El scroll infinito

El scroll infinito es una técnica que se puede encontrar en muchos sitios web en los que una búsqueda produce un "resultado infinito". Por ejemplo, la búsqueda de imágenes en Google o en flickr emplean esta técnica en vez de la paginación tradicional.

En Infinite Scrolling and Accessibility (It’s Usually Bad) se explica que es una mala práctica, tanto desde el punto de vista de la usabilidad como de la accesibilidad.

Uso del atributo aria-owns

En el artículo Using the aria-owns attribute se explica el uso del atributo aria-owns. Este atributo es útil para indicar una relación de dependencia padre/hijo que puede ser clara en la presentación visual, pero que puede no existir realmente en la estructura de la página, es decir, que no existe en el DOM.

Por ejemplo, puede ser útil para definir relaciones de dependencias en listas anidadas.

Asegura un alto contraste para el texto sobre las imágenes

En el artículo Ensure High Contrast for Text Over Images se explica que hay que asegurar que el texto que se muestre sobre las imágenes presente el suficiente contraste. Esto es complicado, ya que una imagen no suele tener un color uniforme, así que lo mejor es evitarlo.

Siete cosas que un diseñador debe saber sobre accesibilidad web

El artículo 7 Things Every Designer Needs to Know about Accessibility recoge siete cosas que un diseñador debe saber sobre accesibilidad web:

1. Accessibility is not a barrier to innovation.
2. Don’t use color as the only visual means of conveying information.
3. Ensure sufficient contrast between text and its background.
4. Provide visual focus indication for keyboard focus.
5. Be careful with forms.
6. Avoid component identity crises.
7. Don’t make people hover to find things.

Ejemplo de sitio web con características para mejorar la accesibilidad

OER Commons es un sitio web que posee un conjunto de opciones que mejoran la accesibilidad web.

Signo dólar leído como peso argentino

Hace unos días recibí esta consulta:

Hola Sergio,
Hace rato que te sigo como referente y aprendo con todo lo que compartís y con lo que respecta a la accesibilidad.

Hace ya unos años que estoy enfocado en experiencia de usuario y, por supuesto eso no deja de lado la accesibilidad.

Estoy trabajando en una empresa que desarrolla un software bancario y formamos un equipo exclusivo para trabajar en accesibilidad. Al trabajar en el rubro bancarío se me presenta el siguiente problema y quería pedirte ayuda a ver si me puedes dar alguna punta para solucionarlo.

El tema sobre el cual quiero consultarte es que en Argentina se utiliza el siguiente signo $, que representa a nuestra moneda que es peso argentino. Lo que sucede es que el símbolo es leído como dólar por el lector de pantallas.

La solución que encontramos es que se exprese la frase Pesos argentinos / dolares estadounidenses, etc.

Tu conocerás alguna forma de que se pueda aclarar el significado de los símbolos independientemente de los ya definidos en los lectores?

Desde ya muchas gracias y felicitaciones por tus aportes a la accesibilidad: :)

Muy buena pregunta...

En primer lugar, el símbolo del dólar "$"no sólo representa el dólar, es un símbolo monetario utilizado por ($ en la Wikipedia):

• el peso, ya sea el argentino, mexicano, chileno, colombiano, dominicano, uruguayo, etc.;
• el dólar, ya sea el estadounidense (US$), australiano (A$), canadiense (C$), etc.;
• el córdoba nicaragüense, C$;
• el pa'anga o dólar tongano, T$.

Nunca he leído nada sobre ello, así que no conozco ninguna respuesta formal. Lo único que puedo es sugerir algunas opciones que se me ocurren.

1. En vez de utilizar el carácter del símbolo de dólar, utilizar una imagen del símbolo del dólar y en el texto alternativo indicar "peso argentino".

Esta solución funciona, pero no es práctica: dificulta la redacción de los textos y además, algunos navegadores indican que existe una imagen con el aviso "gráfico".

2. Utilizar la etiqueta abbr para indicar que el símbolo del dólar es una abreviatura, e indicar con el atributo title su significado.

Esta solución es mejor que la anterior, pero tiene dos problemas importantes. Por un lado, la mayoría de los editores online de contenido web, como TinyMCE, no suelen tener un botón para etiquetar las abreviaturas. Pero si el texto es generado por una aplicación web entonces sí que es posible etiquetarlo correctamente. Por otro lado, hay lectores de pantalla que no interpretan la etiqueta abbr.

3. Añadir un texto oculto que indique que la moneda es "peso argentino".

Creo que es la que sugieren en la pregunta que me hicieron cuando dicen "la solución que encontramos es que se exprese la frase Pesos argentinos / dolares estadounidenses". Si en la página aparece el símbolo del dólar es imposible lograr que el lector de pantalla no lo lea, pero sí que es posible utilizar CSS para añadir un texto oculto que sólo lo lea el lector de pantalla. No es una buena solución.

Por tanto, no conozco una solución óptima. ¿Alguna persona que conozca una buena solución puede dejar un comentario?

Tableta con pantalla en Braille

En microsiervos he leído el artículo Un tablet con pantalla en Braille para personas con discapacidad visual:

Un equipo de investigadores de la Universidad de Michigan trabaja en el desarrollo de un tipo nuevo de pantalla en Braille que permita a personas con discapacidad visual acceder a la información de forma mucho más asequible y cómoda de lo que la tecnología les permite actualmente.

Bueno, puede ser que sí o puede ser que no, porque más de una vez he escuchado que gracias a la digitalización y los lectores de pantalla, es posible que las próximas generaciones de personas ciegas ya no necesiten el braille. En cualquier caso, lo importante es que haya diversidad de opciones y cada persona elija lo más apropiado para sus necesidades.

Un vídeo sobre el dispositivo que se ha desarrollado:

10 pruebas de accesibilidad web para realizar en 10 minutos (parte 1)

Hace unos días se publicó el artículo 10 pruebas de accesibilidad web para realizar en 10 minutos (parte 1), mi décima contribución al Observatorio de la Accesibilidad de la Confederación Española de Personas con Discapacidad Física y Orgánica (COCEMFE).

Magnificadores de pantalla gratuitos

Un magnificador de pantalla es un software que permite visualizar la pantalla de un ordenador con un considerable aumento en su tamaño, lo que supone una ayuda para las personas con problemas de visión.

Hace unos días mantuve una conversación telefónica con una persona que busca un magnificador de pantalla para su trabajo. Tiene baja visión y en su trabajo no quieren comprarle ZoomText, el mejor magnificador que tiene un pequeño problema, cuesta $400.

En List Of Best Free Screen Magnifiers se ha recopilado una lista de magnificadores de pantalla gratuitos:

• Magnifying Glass
• DesktopZoom
• Moo0 Magnifier
• Virtual Magnifying Glass Portable
• Magnifying Glass
• Magnifixer
• OneLoupe
• Able Opus See Sharp
• 1ClickZoom
• EzMagnifier
• uToolbox Magnifier Tool
• Super Magnifier
• ZoomIt
• ClZoom
• Virtual Magnifying Glass
• Dragnifier

Compromiso de Microsoft para una web más inclusiva

En el artículo Accessibility: Towards a more inclusive web with Microsoft Edge and Windows 10, Microsoft dice que tiene el compromiso de lograr que la web sea más inclusiva y para ello están trabajando en que su nuevo navegador Edge sea más accesible que Internet Explorer:

Microsoft is committed to accessibility as a core part of software design, and today we would like to share more about how Microsoft Edge is evolving to improve support for assistive technology beyond what was possible in Internet Explorer.

Un buen ejemplo de enlaces "saltar a "

En Convention on the Rights of Persons with Disabilities se pueden ver tres enlaces "saltar a" en la parte superior de la página.

Los tres enlaces son:

• Skip link to text
• Skip link to menu
• Skip link to submenu

Complemento para simular problemas visuales

NoCoffee Vision Simulator es un excelente complemento para Google Chrome que permite simular diferentes problemas de vision.

Por ejemplo, esta es la simulación de vista borrosa:

Y esta la simulación de bajo contraste:

Curso online y gratuito "Aprende Accesibilidad Web Paso a Paso"

El curso Aprende Accesibilidad Web Paso a Paso sigue abierto en la plataforma Udemy con más de 2300 estudiantves.

Es un MOOC, y por tanto online y gratuito, para el que hemos preparado más de 9 horas de vídeo y más de 40 ejercicios tipo test para evaluar el aprendizaje.

No hay fecha de principio ni de fin, tú marcas el ritmo en un proceso de autoaprendizaje guiado. Al finalizar el curso conocerás los principales problemas de falta de accesibilidad que presentan las páginas web y serás capaz de plantear e implementar soluciones para esos problemas.

El curso se estructura de la siguiente manera:

1. Bienvenida al curso: Es una introducción y una visión general del curso donde ya veremos algunos ejemplos de problemas de accesibilidad.
2. Qué es la accesibilidad web: Repasaremos la definición de accesibilidad web; cómo esta mejora la vida de las personas con discapacidad; los mitos asociados a la accesibilidad web; sus beneficios; o de la mano de Sergio Luján Mora repasaremos cosas que deberías saber sobre la accesibilidad web y ejemplos de sitios web accesibles.
3. Las personas con discapacidad y la Web: En esta sección se repasan los principales tipos de discapacidad y cómo afectan al acceso a la web. Antonio Ferrández nos explicará a lo largo de diversos vídeos los diferentes productos de apoyo que emplean las personas con discapacidad.
   
   Un total de 21 lecciones donde por ejemplo podremos ver una entrevista con una persona sordociega.
   
   
4. Pautas y leyes: En esta sección Olga Carreras presenta una introducción a las WCAG 2.0 y Sergio Luján Mora repasa a través de diferentes lecciones y vídeos la legislación española sobre accesibilidad web y recursos para consultar la legislación existente en otros países.
   
5. Contenido accesible: En esta sección repasaremos a lo largo de 23 lecciones, la mayoría en vídeo, cómo lograr que el contenido de una página web sea accesible y comprensible.
   
   Hablaremos de la accesibilidad de las imágenes, del audio y del vídeo; Sergio Luján Mora tratará temas como los subtítulos para el contenido multimedia o los captcha; o Ester Serna nos hablará, entre otras cosas, de la accesibilidad en relación con los encabezados, el idioma o las tablas de las páginas web. Olga Carreras explicará la accesibilidad del contenido multimedia.
   
   
6. Navegación accesible:
En esta sección aprenderemos en 13 lecciones, 12 de ellas en vídeo, a lograr que la navegación dentro de una página web y entre las páginas de un sitio web sea accesible. Por ejemplo Sergio Luján Mora nos hablará del título de la página, los enlaces "saltar a" o de las barras de navegación como listas de enlace. Olga Carreras hablará de los enlaces accesibles, de la navegación por teclado y de las múltiples vías, ubicación y consistencia.

7. Diseño accesible: En esta sección aprenderemos a lograr que la presentación de una página web sea accesible. Entre otras cosas, Sergio Luján Mora nos hablará del color, del contraste o de la tipografía.
   Olga Carreras enseñaré las buenas y malas prácticas así como los errores comunes de accesibilidad en los sitios Responsive Design.
   
8. Interacción accesible: En esta sección aprenderemos a lograr que la interacción de un usuario con una página web sea accesible.
   Olga Carreras hablará de Javascript y accesibilidad y de WAI-ARIA.
   
9. Accesibilidad y posicionamiento: En esta sección Olga Carreras presenta una introducción al posicionamiento orgánico en buscadores y su relación con la accesibilidad web.
   
10. Análisis y evaluación de la accesibilidad: En esta lección Olga Carreras presentará la metodología de evaluación WCAG-EM y las principales herramientas de evaluación automática. Ester Serna enseñará a utilizar la herramienta TAW y barras de herramientas como Wave o Web Developer Toolbar.
    
11. Conclusiones

100 lecciones, más de 9 horas de vídeo subtitulados y con transcripción accesible. Todos los profesores del curso esperamos que aprendáis mucho sobre cómo mejorar la accesibilidad web de vuestras páginas.

Curso online y gratuito en la plataforma Udemy: Aprende Accesibilidad Web paso a paso

Comparación del nivel de accesibilidad en Europa

Monitoring eAccessibility es un proyecto que lideró Technosite en los años 2010 y 2011. Como resultado del proyecto se desarrollaron varios informes sobre el estado de accesibilidad en Europa.

Por ejemplo, en el informe del año 2010 encontramos este gráfico el estado de las tecnologías asociadas a la accesibilidad electrónica por países:

Según este gráfico España estaba bien situado, por encima de la media de los países europeos.

Y en la siguiente tabla se muestra el estado de accesibilidad de los sitios web gubernamentales:

Ejemplo de sitio web con características para mejorar la accesibilidad

Digital Accessibility Centre es una organización del Reino Unida dedicada a mejorar la accesibilidad digital.

Su sitio web incluye varias características interesantes que mejoran la accesibilidad web:

• Enlace "saltar a"
• Diferentes combinaciones de colores para mejorar el contraste
• Navegación por teclado
• Controles para parar el carrusel de imágenes

Un guante traduce la lengua de signos en habla

En el artículo This glove translates sign language into speech se explica que en la Universidad de Londres han desarrollado un guante que traduce en tiempo real la lengua de señas en habla:

The glove has five sensors, each placed on one finger, to track hand movements. The sensors detect the bends and curvatures made by the fingers and reports the values to a serial monitor. An accelerometer is also attached to the glove to detect the orientation of the hand.
All of the values collected are run through a program that determines which letters to display on an LED matrix display. Ayoub recently added a chip that can convert the hand gestures into spoken word.

Y un vídeo:

La accesibilidad y el SEO van de la mano

Eso es lo que dice el artículo Accessibility, usability and SEO go hand in hand:

I think there are two parts to the answer: the first one is to clarify that web accessibility is not just to create a comfortable environment for people with disabilities but for all users. It’s about ensuring that all parts of the website can be navigated easily, that interaction happens naturally and that all users understand the website without having to spend hours studying it.
The second question is how web accessibility influences website architecture. I assume that you mean both information architecture (IA) and technical architecture. Good web accessibility is about ensuring that the site is organized in a meaningful and logical manner, in order to help users with the task of navigation and comprehension. IA is a tool or technique that can help achieve that goal. In addition to that, the technical platform needs to be made accessible to both users and search engine bots.  So things like navigation, labeling, shallow vs deep website structure are often key to effective content findability and discovery, particularly when it comes to indexation of large websites. Web accessibility does clearly influence website architecture by demanding standards-compliant techniques (HTML sitemaps, HTML5 vs jQuery, not using Javascript for navigation, etc.)

Y cinco cosas que mejoran tanto la accesibilidad como el SEO:

• Semantic Markup (descriptive & hierarchical headings, page titles etc.)
• ​Descriptive Link text (anchor text)
• Image optimisation (both in caption and alt tag)
• Recommendations to make the site architecture crawlable
• Writing short, concise and memorable urls

Unas gafas que mejoran la visión de las personas con ceguera al color o daltonismo

En EnChroma’s Accidental Spectacles Find Niche Among the Colorblind podemos leer que unas gafas que se inventaron para que los cirujanos estuvieran protegidos de la luz del láser y pudieran diferenciar mejor el tejido humano ayudan también a las personas con ceguera al color o daltonismo a diferenciar los colores.

Pero cuidado, estas gafas no producen milagros, no ayudan ni a todas las personas ni en todas las situaciones:

Mr. Dykes countered that the glasses were not meant to be a cure, in the same way that reading glasses don’t cure farsightedness. He also acknowledged that the glasses don’t work for all types of colorblindness and said the company had a 30-day return policy for that reason. “It works in some cases and not others,” he said. “It’s not a magical cure or a cheat.”

Un alumno en cada clase

La iniciativa #1ineveryclassroom de Colour Blind Awareness tiene como objetivo concienciar a la gente del hecho de que la ceguera al color o daltonismo es más frecuente de lo que se cree. Según explican:

Statistically speaking one child in every classroom has a colour vision deficiency so we hope, having watched the animation, teachers will question which of the children they are currently teaching might be affected. 

We also want the animation to make parents to question whether their own children might be colour blind. 1 in 12 boys and 1 in 200 girls have a colour vision deficiency but 80% are undiagnosed when they reach secondary school. 

Y un vídeo asociado a esta iniciativa:

Accesibilidad en la Administración Electrónica en España

Ayer comentaba que existe el Observatorio de Accesibilidad Web, dependiente del Gobierno de España, pero parece que su actividad en los últimos cinco años ha sido más bien escasa. El único informe que parece que han producido es Accesibilidad en la Administración Electrónica en España: El resultado de un esfuerzo continuo de mejora, informe que en realidad es un "copia y pega" del estudio Monitoring e-Accessibility de la Comisión Europea. En este estudio se evaluó  la accesibilidad de servicios de Administración Electrónica de los Estados miembros de la Unión Europea, Estados Unidos, Australia, Canadá y Noruega.

En este informe se afirma:

El Observatorio de Accesibilidad Web en la Administración Electrónica realiza, entre otras actuaciones una evaluación periódica de la accesibilidad de portales y sitios webs de las Administraciones Públicas españolas. 

Pero sólo he podido encontrar información de los meses comprendidos entre mayo 2010 y octubre 2011:

El Observatorio de Accesibilidad Web

Supuestamente, porque todo esto más bien parece ciencia ficción, existe el Observatorio de Accesibilidad Web:

El Observatorio de Accesibilidad es una iniciativa del Ministerio de Hacienda y Administraciones Públicas que tiene como objetivo ayudar a mejorar el grado de cumplimiento en materia de accesibilidad de los portales de la Administración (AGE, CCAA y EELL).

Este observatorio proporciona el siguiente servicio:

Observatorio de Accesibilidad Web. Estudio periódico que proporciona datos de evaluación de los portales con el objetivo de disponer de información de estado y evolución de la Accesibilidad Web en los mismos.

Se supone que han realizado estos estudios:

Inicialmente, los estudios del Observatorio de Accesibilidad Web se planificaron para llevarse a cabo durante 2010 y principios del 2011. Para cada uno de los ámbitos, se realizaron varias ejecuciones del estudio que permitieron mostrar la evolución del estado de accesibilidad en este periodo.
Dado el grado de éxito y aceptación de la iniciativa, así como por los buenos resultados obtenidos, se decidió prolongar su actividad durante el año 2011 completo.
Durante 2012 y 2013 se mantuvieron las actividades del servicio de diagnóstico en línea y la comunidad accesibilidad. Así mismo se potenció la generación de materiales de ayuda ante la aprobación de la nueva Norma UNE 139803:2012.
Desde el 2014 se está trabajando para reiniciar los estudios periódicos del observatorio y además ofrecer en 2015 los correspondientes servicios actualizados al nuevo estándar UNE 139803:2012.

Pero lo único que he encontrado en las Notas Técnicas es el informe Accesibilidad en la
Administración Electrónica en España: El resultado de un esfuerzo continuo de mejora.

Iberia cumple con Estados Unidos, pero no con España

Causa sonrojo, por no decir indignación, la respuesta dada por Iberia respecto a la accesibilidad de su sitio web: están introduciendo cambios para adaptarla a la nueva legislación del Departamento de Transporte de Estados Unidos, pero... ¿qué pasa con la adaptación a la legislación española?

El sitio web de una aerolínea debe ser accesible (en Estados Unidos)

El Departamento de Transporte de Estados Unidos emitió la siguiente orden en noviembre de 2013: Nondiscrimination on the Basis of Disability in Air Travel: Accessibility of Web Sites and Automated Kiosks at U.S. Airports and Accessibility of Aircraft and Stowage of Wheelchairs; Final Rules. En ese documento aparece WCAG 137 veces.

Tiene 38 páginas, a 3 columnas, así que es un poco larga de leer. Pero en US airlines now required to be web accessibility compliant nos resumen lo más importante:

• Las páginas web "core" de las aerolíneas que operan en Estados Unidos deben cumplir WCAG 2.0 AA el 12/12/2015. El "core" incluye "booking" y "checking" de los vuelos, la información personal sobre un itinerario, el estado de un vuelo, el horario de un vuelo, la información de contacto y la información sobre la cuenta de viaje frecuente.
• El resto de páginas web debe ser accesible el 12/12/2016.

Recordemos que en España la situación es muy diferente. Por ejemplo, hace unos meses, a Iberia le impusieron la primera sanción por falta de accesibilidad de su web. Eso sí, sólo 30.000 euros.

Emisión accesible del Cara a cara

Anoche, pudimos ver los epítetos "ruin y miserable" en lengua de señas y escrito durante la emisión del Cara a cara entre Mariano Rajoy y Pedro Sánchez.

En La Academia de Televisión producirá una señal accesible del #CARAaCARA2015 entre Mariano Rajoy y Pedro Sánchez podemos leer:

La Academia de las Ciencias y las Artes de Televisión, como en los debates del 2008 y 2011, pondrá a disposición de todos los medios de comunicación una señal accesible del cara a cara entre Mariano Rajoy y Pedro Sánchez. Las personas sordas o con discapacidad auditiva podrán acceder en igualdad de condiciones a dicha retransmisión a través de un servicio de subtitulado e interpretación en lengua de signos.
Esta iniciativa que garantiza la participación sin barreras de las personas sordas  en la vida política, además de dar cumplimiento a lo estipulado en  la Ley General de la Discapacidad, en la Convención de Naciones Unidas de los Derechos Humanos de las Personas con Discapacidad y en la propia Ley por la que se reconocen las lenguas de signos españolas y se regulan los medios de apoyo a la comunicación oral.

Pero, ¿cómo se logra el subtitulado en tiempo real?

En la actualidad existen diferentes técnicas para lograr los subtítulos en tiempo real (Subtitulado en tiempo real de informativos en directo para la televisión mediante reconocimiento automático del habla):

• Estenotipia
• Sistemas semiautomáticos (locutores en la sombra)
• Sistemas automáticos (reconocimiento automático del habla)

¿Qué sistema se habrá usado? Quizás el que se anunciaba en el año 2011, Un proyecto de I+D+I facilitará el subtitulado automático en programas de TV, que parece que fue desarrollado por la Universidad Carlos III a partir del trabajo Desarrollo de un sistema de sincronización de subtítulos para subtitulación de programas de TV en directo.

Por cierto, en la siguiente fotografía se muestra una Grandjean Stenotype del año 1949.

Cuando el HTML y el CSS de un sitio web no es válido, ¿se puede decir que no es accesible?

Un amigo me pregunta:

Hola Sergio, un  gusto en saludarte... Quisiera que me ayudes con la siguiente interrogante: Cuando en un sitio web el validador del w3c para html y el validador CSS me presentan errores, entiendo que muy difícilmente cumpliría con la accesibilidad, mi afirmación es correcta?.. ó el sitio si puede presentar esos errores y decir que cumple con la accesibilidad?...

Y mi respuesta:

Depende...

Una cosa es cumplir con la accesibilidad, que se debe traducir en "cumplir con unas pautas", algo que sea verificable, y otra cosa es que sea o no sea realmente accesible.

Las pautas están para ayudar a crear un sitio web accesible, pero un sitio web puede cumplir las pautas y puede no ser accesible. Y al revés también es cierto, puedes no cumplir ciertas pautas y el sitio web puede ser accesible.

¿Y las pautas exigen que un sitio web sea válido?

El W3C discutió sobre el tema en Validity and Accessibility (es del año 2005). La conclusión fue:

In the end, it's about balancing flexibility and freedom with order and control. I don't yet know where the right balance lies with respect to validity and accessibility, but I do know I'm glad we're having this debate.

En WCAG 1.0 sí que se exigía que un sitio web fuese válido, en 3.2 Create documents that validate to published formal grammars decía:

Validating to a published formal grammar and declaring that validation at the beginning of a document lets the user know that the structure of the document is sound. It also lets the user agent know where to look for semantics if it needs to.

En WCAG 2.0 se relajó, se exige que no existan ciertos errores, pero no se exige que sea válido 100%:

4.1.1 Parsing: In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. (Level A)

Conclusión: si se utiliza WCAG 1.0, que sea válido forma parte de los requisitos para considerar que un sitio web es accesible. Si se utiliza WCAG 2.0, no es un requisito. En cualquier caso, mi consejo es que se debe lograr que las páginas sean válidas, no sólo por la accesibilidad, sino porque proporciona múltiples ventajas: mejora la compatibilidad del código con los diferentes navegadores, evita ciertos problemas que existen cuando el código no es válido, ayuda al mantenimiento futuro, etc.

Duplicación de los roles con ARIA

Todos los elementos de HTML poseen un rol nativo que es expuesto a los productos de apoyo como los lectores de pantalla.

ARIA permite modificar el rol nativo de cualquier elemento. Por ejemplo, con ARIA se puede convertir un simple

en un botón... ¡pero no se tiene que hacer, aunque se pueda!

Una duda que a veces surge es si se debe añadir el rol a aquellos elementos que ya lo tienen. Por ejemplo, ¿conviene escribir button role="button" o input role="checkbox" type="checkbox"?

No, no conviene hacerlo porque no aporta ninguna ventaja, pero sí que puede ocasionar algunos problemas.

Como identificar que un enlace o botón abren una ventana nueva

En WCAG 2.0 no existe un requisito de accesibilidad que indique que se tenga que hacer, pero es una buena práctica.

La típica forma es añadir un icono con forma de ventana y una flecha que indica que se abre una ventana nueva. Pero existe una forma mejor.

En ARIA existe la propiedad aria-haspopup="true". En la especificación oficial podemos leer sobre aria-haspopup lo siguiente:

Indicates that the element has a popup context menu or sub-level menu.
This means that activation renders conditional content. Note that ordinary tooltips are not considered popups in this context.
A popup is generally presented visually as a group of items that appears to be on top of the main page content.

Si se añade aria-haspopup="true" a un enlace o a un botón, los lectores de pantalla modernos anunciarán que el enlace o el botón se abren en una ventana nueva al activarse.

Complementos para Google Chrome

En Chrome Extensions de Stanford Online Accessibility Program encontramos estos complementos:

WAVE Extension for Chrome

A web accessibility evaluation tool developed by WebAIM.org.

Web Developer Extension for Chrome

This is a Chrome version of the Firefox extension with the same name. With this extension, you can disable CSS, display alt attributes,
show headings and other elements via the outline, and display ARIA roles and view a document outline (via "Information").

Color Contrast Analyzer

This extension allows you to analyze color contrast on web pages. Unlike other contrast analyzers, this one will assess text within images and text that is on top of background images or gradients.
The developer has a blog post about it.

Accessibility Developer Tools

This extension adds an accessibility audit and an accessibility sidebar to your Chrome Developer Tools.
When you use this extension to run an audit, the results appear as a list of issues for you to consider.
You also have options to enable or disable rules. You may find it helpful to review the rules used for the evaluation
before you run this Google developer tool so you will know what will need to be checked manually, as well. The accessibility sidebar is used to inspect individual elements. The tool now works across iframes.
Learn more about the library of code that runs the extension by visiting the Accessibility Developer Tools
Git repository. This library of accessibility testing and utility code consists of an accessibility audit, which is the same audit provided by the Chrome extension referred to above.
Also included is code to calculate contrast ratios (including color suggestions), retrieve and validate ARIA attributes and states, and assess text alternatives.

Tenon Check

Tests pages against WCAG 2.0 using Tenon.io.

ChromeVox

This is a screen reader to be used with Chrome. At this time, few people who are blind use it. However, it may be helpful to give you a basic idea of how your page will work for
screen reader users. This is not a full, generalizable screen reader; rather, it has been designed to work specifically with Google's products.

ARIA Validator

Scans page for WAI-ARIA implementation issues. Adds a button to Chrome that you can click when you want to validate the ARIA implementation of the HTML page you are viewing.

Longdesc

Highlights and provides right-click (or Ctrl-click on Mac) access to image long descriptions, where provided.

La accesibilidad de la web de Renfe

En el artículo La web de Renfe que se publicó hace unos días, José Ángel Carrey que ha denunciado los problemas de accesibilidad de la web de Renfe comenta su experiencia:

Como todo el mundo sabe, la web de Renfe incumple los criterios de accesibilidad. Ello supone que las personas ciegas totales no podemos efectuar de manera cómoda y autónoma la compra, cambio, anulación de billetes, y la consulta de horarios. Especialmente grave es la cosa cuando se trata de comprar un billete no promocionado, en que toca escoger asiento, pues el proceso de elección de asiento es totalmente gráfico, y el lector de pantalla no puede reconocerlo, con lo que no se puede comprar el billete de forma autónoma.

Y la respuesta que está preparando:

Estamos en trámites para interponer el correspondiente recurso contencioso-administrativo contra esta resolución. De momento, el procedimiento ha ido a parar a la sección IV de la Sala de lo Contencioso-Administrativo de la Audiencia Nacional, y el plazo para interponer el recurso está suspendido hasta tanto se resuelvan las solicitudes de justicia gratuita presentadas por mí y por la ACIC.

Siete cosas que cualquier diseñador debe saber sobre accesibilidad web

El artículo 7 Things Every Designer Needs to Know about Accessibility explica siete cosas que cualquier diseñador debe saber sobre accesibilidad web:

1. La accesibilidad no es una barrera para la innovación.
2. No uses el color como el único medio de transmitir información.
3. Asegura que existe suficiente contraste entre el texto y el fondo.
4. Propociona una indicación visual del foco del teclado.
5. Ten cuidado con los formularios.
6. Evita las crisis de identidad de los componentes.
7. No hagas que la gente tenga que pasar el cursor del ratón para descubrir cosas.