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.

Muchos vídeos sobre discapacidad y accesibilidad

En el sitio web Disabilities, Opportunities, Internetworking, and Technology hay una gran cantidad de vídeos sobre discapacidad y accesibilidad.

Los vídeos son accesibles. Por ejemplo, el vídeo IT Accessibility: What Web Developers Have to Say tiene subtítulos, transcripción y hasta audiodescripciones. Además, el reproductor multimedia posee numerosas opciones de configuración.

Webinar: Inclusión y Autonomía de las personas con Discapacidad apoyados en la tecnología

Un repaso a los webinars que he realizado este año:

Inclusión y Autonomía de las personas con Discapacidad apoyados en la tecnología (6/8/2015)

Mapas accesibles para las personas con problemas de visión

Crear un mapa accesible es un problema complejo que por ahora no tiene una solución clara. La alternativa de crear una versión textual accesible es factible para ciertos tipos de mapas, pero cuando el mapa es complejo y muestra mucha información, es difícil que la alternativa textual se pueda utilizar con facilidad.

En 7 Tube Maps Only The Colour Blind Will Truly Appreciate no explican como crear una alternativa textual, sólo abordan el problema de crear un mapa accesible para las personas con ceguera al color (daltonismo) y otros problemas de baja visión como las cataratas. No es la solución total, pero es interesante.

Webinar: Accesibilidad web: claves y consejos

Un repaso a los webinars que he realizado este año:

Accesibilidad web: claves y consejos (25/6/2015)

XIII Congreso Iberoamericano de Informática Educativa y Discapacidades

Mañana martes 17 de noviembre comienza el XIII Congreso Iberoamericano de Informática Educativa y Discapacidades en el que participaré con la conferencia magistral "Soluciones Tecnológicas para Apoyar la Educación de las Personas con Discapacidad".

Webinar: E-learning, Recursos Educativos Abiertos y MOOCs

Un repaso a los webinars que he realizado este año:

E-learning, Recursos Educativos Abiertos y MOOCs (4/6/2015)

Ocho proyectos para mejorar la accesibilidad

Un lector de este blog me ha pasado la noticia 8 brilliant new accessibility inventions en la que se describen ocho proyectos innovadores para mejorar la accesibilidad:

1. KenesicMouse, control del ordenador con gestos faciales.
2. AVA, transcripción en tiempo real de la voz a texto.
3. LOLA, muestra recordatorios a las personas con asperger o autismo para que realicen ciertas actividades sociales.
4. DrumPants, conmutador para personas con movilidad reducida.
5. EnLight, navegador de interiores para personas con problemas de visión.
6. MySupport, para conectar las personas con discapacidad con las personas que ofrecen servicios de asistencia.
7. InstaAid, aplicación para solicitar ayuda para las personas con discapacidad neurológica.
8. Braci, "oído inteligente" que avisa a las personas sordas de los sonidos de emergencia que se produzcan.

Ejemplo de audiodescripción (2)

Un ejemplo de vídeo con audiodescripción para ciegos, Audiodescripción Amelie:

Resumen de ARIA

Accessible Rich Internet Applications (WAI-ARIA) 1.0 es una recomendación del W3C que tiene como objetivo mejorar la accesibilidad de las interfaces web avanzadas.

En The ARIA Role Conformance Matrices se resumen los roles con sus atributos, obligatorios y opcionales, junto con una nota sobre la implementación.

Uso correcto de los botones y enlaces

Si algo es un botón, utiliza las etiquetas para crear botones.

Si algo es un enlace, utiliza la etiqueta para crear un enlace.

Por favor, no cambies la semántica de los componentes de la interfaz de usuario: Proper Use of Buttons and Links.

Webinar: Accesibilidad web

Un repaso a los webinars que he realizado este año:

Accesibilidad web (7/5/2015)