Cómo escribir HTML accesible

Writing HTML with accessibility in mind explica varias cosas que se deben escribir HTML para mejorar la accesibilidad de las páginas web. Todos estos consejos no garantizan que la página sea totalmente accesible, pero sí que solucionan la mayoría de los problemas:

• It’s important to define the natural language of your document
• You can hide content using the hidden attribute
• Sometimes it’s better to add a blank alt attribute to an <img> element
• If you need a button, use the <button> element
• Structuring your markup correctly with headings is important
• Using landmarks helps people navigate your site
• The main page content, header, and footer are also landmarks
• Fieldsets are great for grouping form elements and giving them more context

¿El futuro será más accesible?

Esta semana he leído dos artículos que dibujan un futuro mucho más accesible para las personas con discapacidad:

• Un móvil para ‘ver’ y otros avances para personas con discapacidad: avances tecnológicos que mejoran la vida de las personas con discapacidad presentados en CES 2017.
• Consumer Technology Association Foundation Hops on Self-Driving Cars: los vehículos autónomos prometen ser una gran solución para las personas mayores o con discapacidad.

Son grandes avances, pero, pero... La tecnología avanza en todos los aspectos de nuestras vidas y está demostrado que en muchos casos aumenta la brecha digital entre diferentes comunidades y esto también afecta a las personas con discapacidad.

Por ejemplo, las pantallas táctiles han sido un gran problema para las personas ciegas. Ahora todo (lavadoras, microondas, terminales de checkin, etc.) usa pantallas táctiles. Una pantalla táctil sin un lector de pantallas no lo puede usar una persona ciega.

El futuro está por escribir, habrá que esperar para poder comprobar si los avances tecnológicos se transforman en una solución o en una barrera.

Accesibilidad TIC en compras públicas

El curso Accesibilidad TIC en compras públicas organizado por UNED y Fundación ONCE se ofrece de forma gratuita a través del canal de cursos abiertos UNED abierta.

El contenido del curso es:

• El temario del curso es:
• Sociedad de la Información ¿para todos?
• Accesibilidad y usabilidad TIC.
• Retos y estrategias.
• Conceptos básicos de las normas.
• Historia y ámbito de la norma europea de compras públicas.
• Ejemplos de aplicación de la norma EN 301 549.
• Árbol de decisión para el uso de la norma EN 301 549.

Los vídeos con subtítulos obligatorios en los aviones, en Estados Unidos, una vez más

Según la noticia Historic agreement reached: closed captions will be mandatory for US airline in-flight entertainment, los vídeos que se emitan en los aviones de las aerolíneas de Estados Unidos tendrán que tener subtítulos para las personas sordas y con problemas auditivos:

• All new in-flight entertainment systems, whether on newly delivered aircraft or newly-installed on existing aircraft, must be capable of supporting closed captions and audio descriptions as of the effective date of the final rule.
• If an aircraft has inaccessible seatback in-flight entertainment systems, it must provide an alternative personal entertainment device (PED) with accessible comparable video content.
• Airlines shall request from video content providers that 100% of covered in-flight entertainment content are closed-captioned and audio-described, and shall obtain such covered video content with closed captions and audio descriptions available from the content providers, including edited versions.
• Airlines will need to provide users the ability to customize closed captions (font sizes, colors, etc.)

Herramientas de código abierto para la revisión de la accesibilidad web

Open Source Tools for Web Accessibility Evaluation recopila información sobre herramientas para la revisión automática de la accesibilidad web de código abierto. Las herramientas que comenta son:

• OpenAjax Accessibility Evaluation Library
• AInspector Sidebar for Firefox
• Functional Accessibility Evaluator (FAE) 2.0

Google TalkBack

Google TalkBack es el lector de pantalla que incorpora por defecto los dispositivos Android:

TalkBack es un servicio de accesibilidad que ayuda a los usuarios ciegos o con deficiencias visuales a interaccionar con los dispositivos.
TalkBack incorpora respuestas por voz y con vibración al dispositivo. Es una aplicación del sistema preinstalada en la mayoría de los dispositivos que se actualiza cuando hay mejoras disponibles para el servicio de accesibilidad.

En la página TalkBack en smartphones, una ayuda a la discapacidad visual de Samsung se explica algo más:

Cuando TalkBack está activado, el dispositivo habla y describe cada uno de los elementos que son seleccionados o activados. Se trata de una ayuda por voz que es capaz de leer lo que ocurre en el teléfono e ir guiando al usuario en su navegación por los menús y las aplicaciones.
En ese momento, el smartphone te ofrece una sencilla y breve guía narrada de cómo sacar partido a la herramienta y cuáles son los gestos adecuados para desplazarte por la pantalla. Además, podrás definir algunos ajustes, como el volumen de la voz o en qué momentos no quieres que TalkBack esté activado (cuando acercas el teléfono al oído, gracias al sensor de proximidad, por ejemplo).
Por motivos de seguridad y para proteger datos sensibles, TalkBack no lee contraseñas o números de tarjetas de crédito.

¿Y cuál es mejor, TalkBack o VoiceOver? Un par de artículos sobre ello:

• A comparison of speech output of VoiceOver, TalkBack and Narrator
• Accessibility Head-To-Head: Android vs Apple

Ejemplo de sitio web con Certificación de Accesibilidad TIC de AENOR

En la web del Ayuntamiento de Madrid existe la página Accesibilidad:

Certificación de Accesibilidad TIC  de AENOR
Logo de certificación TIC AENOREste sitio web ha obtenido la certificación en accesibilidad TIC de AENOR, según la Norma UNE 139803, "Aplicaciones informáticas para personas con discapacidad. Requisitos de accesibilidad para contenidos en la Web" con fecha 07/12/2011. Esta certificación se renueva todos los años, habiéndose obtenido la última en diciembre de 2015.

Selector de fechas accesible

En Accessible Date Pickers han confeccionado un listado de selectores de fechas accesibles:

• AccDc date picker by Bryan Garaventa
• Accessible date picker by Deque Systems
• Athena date picker
• jQuery UI datepicker by Hans Hillen
• Datepicker widget by Assets.cms.gov
• OpenAjax date picker

Pruebas de accesibilidad remotas con usuarios de lectores de pantalla

Dos artículos que explican cómo realizar pruebas de usabilidad (o accesibilidad) remotas con usuarios de lectores de pantalla:

• Real-Time Remote Usability Testing with Screen Reader Users, Part 1: Practical Overview
• Real-Time Remote Usability Testing with Screen Reader Users, Part 2: Tips & Tricks

El sector privado europeo se prepara para la accesibilidad web

La Unión Europea lleva un tiempo trabajando en la primera norma a nivel de la Unión Europea sobre la accesibilidad de los sitios web y las aplicaciones móviles. A principios de diciembre se publicó la directiva de accesibilidad de los sitios web y aplicaciones móviles del sector público y el sector privado se está preparando para ello. ¿Por qué?

En EU ready to set laws for accessibility testing podemos leer:

The EU parliament is drafting a directive that will force private sector companies to accommodate disabled people when offering their goods and services. It has already adopted a directive requiring all public sector websites to adhere to accessibility guidelines.
The draft directive will specifically describe the standards banks and other financial services firms have to meet and references the international standard for online accessibility; the Web Content Accessibility Guidelines (WCAG) created by the World Wide Web Consortium.
[...]
The move seeks to harmonise pre-existing legislation across the continent, bringing it all up to a minimum standard. In the US, firms must comply with the Americans with Disabilities Act (ADA) of 1990, the equivalent to the incoming European Accessibility Act.

Libro: A Web for Everyone

El libro A Web for Everyone: Designing Accessible User Experiences, escrito por Sarah Horton y Whitney Quesenbery y publicado en enero de 2014 parece muy interesante.

La tabla de contenido del libro incluye 12 capítulos:

• Chapter 1: A Web for Everyone
• Chapter 2: People First: Designing for differences
• Chapter 3: Clear Purpose: Well-defined goals
• Chapter 4: Solid Structure: Built to standards
• Chapter 5: Easy Interaction: Everything works
• Chapter 6: Helpful Wayfinding: Guides users
• Chapter 7: Clean Presentation: Visual design supports meaning
• Chapter 8: Plain Language: Creates a conversation
• Chapter 9: Accessible Media: Supports all senses
• Chapter 10: Universal Usability: Creates delight
• Chapter 11: An Integrated Process
• Chapter 12: The Future: Design for all

Y hay dos apéndices que están disponibles en formato PDF para descargar:

• Accessible UX Principles and Guidelines
• WCAG 2.0 Cross-Reference

¿Qué dice WCAG 2.0 de la lengua de signos?

Alguna vez me he encontrado con un sitio web que ofrecía alguna parte del contenido con vídeos en la lengua de signos (o de señas, como se dice en algunos países de Sudamérica).

Por ejemplo, la Confederación Estatal de Personas Sordas tiene algunos vídeos en su web, por ejemplo, en la página Presentación:

Este sitio web está destinado a las personas sordas, ¿por qué no hay un vídeo con la lengua de signos para todo el contenido?

En la Confederación Española de Familias de Personas Sordas, después de navegar por varias páginas, no he encontrado ninguno:

Entonces, ¿es necesario?

En WCAG 2.0 tenemos el criterio de éxito 1.2.6 Sign Language (Prerecorded):

Sign language interpretation is provided for all prerecorded audio content in synchronized media. (Level AAA)

Es un punto de verificación de nivel AAA, por lo que normalmente no se tiene en cuenta, ya que la legislación de la mayoría de los países establece que el nivel mínimo que se debe alcanzar es AA.

Además, este punto de verificación se refiere a que hay que ofrecer un vídeo con la lengua de signos para todo el audio pregrabado (por ejemplo, para un vídeo), pero no es necesario para el texto que pueda tener una página web. Para cumplir lo que exige este criterio de éxito se puede aplicar una solución como la que muestro en mi entrada Subtítulos y lengua de signos todo junto.

Entonces, ¿por qué mucha gente tiene la idea de que hay que poner vídeos con la lengua de signos para que una página web sea accesible?

La explicación la tenemos en Understanding Success Criterion 1.2.6:

The intent of this Success Criterion is to enable people who are deaf or hard of hearing and who are fluent in a sign language to understand the content of the audio track of synchronized media presentations. Written text, such as that found in captions, is often a second language. Because sign language provides the ability to provide intonation, emotion and other audio information that is reflected in sign language interpretation, but not in captions, sign language interpretation provides richer and more equivalent access to synchronized media. People who communicate extensively in sign language are also faster in sign language and synchronized media is a time-based presentation.

Muchas personas sordas o con problemas de audición de nacimiento usan la lengua de signos como lengua materna, como primera lengua. Pueden aprender a leer y escribir en otra lengua, a priori no deben tener ninguna dificultad para ello, pero para ellos será una segunda lengua. Y como cualquiera de nosotros que aprendemos una segunda lengua, nos podemos comunicar, pero lo normal es que nuestra capacidad de comprensión y de comunicación nunca alcance el nivel de la lengua materna.

Otra cosa muy diferente es la que ocurre en algunos países de Sudamérica en los que las personas sordas no aprender a leer y escribir, pero eso es una cuestión de analfabetismo que no sólo existe entre las personas sordas, sino que todavía pervive en otros grupos desfavorecidos de la sociedad.

Volviendo a WCAG 2.0, el criterio de éxito 1.2.6 Sign Language tiene dos técnicas suficientes asociadas:

• G54: Including a sign language interpreter in the video stream
• G81: Providing a synchronized video of the sign language interpreter that can be displayed in a different viewport or overlaid on the image by the player

Cualquiera de las dos técnicas es suficiente para garantizar el cumplimiento de 1.2.6, pero la técnica G81 es mucho mejor que la G54.

Por un lado, en G54 todos los usuarios verán el vídeo con la lengua de signos, ya que se incluye mediante una técnica picture-in-picture en el vídeo principal. Pero ese no es el problema principal.

El uso de G81 puede permitir que el usuario haga más grande el vídeo con la lengua de signos. Eso es muy importante, ya que en la comunicación con la lengua de signos la posición y el movimiento de las manos, de la cara y de todo el cuerpo es muy importante. En un vídeo pequeño dentro del vídeo principal algunos detalles sutiles pero importantes pueden pasar desapercibidos.

Y por último, está el problema de ofrecer un contenido que sea multilingüe, porque, y esto mucha gente lo desconoce, la lengua de signos varía entre diferentes países, incluso entre países cuya lengua principal es la misma. Por ejemplo, la lengua de signos española no es igual a la lengua de señas ecuatoriana.

Diez razones por las que los placeholders son problemáticos

El artículo 10 reasons why placeholders are problematic explica situaciones problemáticas al usar el atributo placeholder en un control de un formulario. Estas situaciones pueden afectar de forma negativa a la usabilidad y accesibilidad de una página web:

1. Disappearing placeholder text is easy to forget
2. Not all browsers support placeholders
3. Pre-populated values are hard to understand
4. Reviewing a long form is difficult
5. Erroneous fields are harder to fix
6. Some browsers will remove placeholder text on focus
7. Placeholder text may be mistaken for a value
8. They have insufficient contrast
9. Screen readers may not announce them
10. A missing label reduces the size of the hit area

Ejemplo de que usar el placeholder es una mala idea

El siguiente formulario se encuentra en Mejor con lentillas:

El aviso "* Campos obligatorios" al final del formulario en vez de al principio no es muy adecuado, pero ese no es el problema más grave de este formulario.

Para indicar el contenido de cada campo del formulario se emplea el atributo placeholder en vez de una etiqueta con :

Lo podemos comprobar viendo el código fuente:

¿Por qué es una mala idea usar el placeholder? Imaginemos que me equivoco y en el campo para el teléfono escribo el DNI y en el campo para el DNI escribo el teléfono. El resultado será el siguiente:

¿Qué está pasando? ¿Cuál es mi error? Si no me he fijado bien al rellenar el formulario, no recordaré qué debo introducir en cada campo. Para saberlo deberé ¡¡borrar lo he escrito!!

Además, desde un punto de vista de la accesibilidad web, algunos lectores de pantalla no reconocen el atributo placeholder, así que los usuarios que dependen de su uso para poder navegar por la Web no podrán rellenar este formulario de forma autónoma.

Cómo mostrar mensajes de error que sean accesibles

El artículo How to Provide Accessible Error Identification explica las diferentes formas accesibles que existen para mostrar mensajes de error en un formulario.

El artículo indica que existen tres criterios de éxito de WCAG 2.0 que se deben tener en cuenta:

• SC 3.3.1 Error identification
• SC 3.3.3 Error suggestions
• SC 3.3.4 Error Prevention in legal and Financial transactions

YouDescribe y Amara

YouDescribe y Amara son dos herramientas muy útiles para lograr que los vídeos sean accesibles.

YouDescribe permite añadir una audiodescripción a cualquier vídeo publicado en YouTube. Por ejemplo (si no funciona el contenido embebido, navega a The Quiet Man - Kiss Scene):



Que se corresponde al vídeo:



Amara permite añadir subtítulos a cualquier vídeo publicado en YouTube. Por ejemplo, el siguiente vídeo tiene subítulos en 10 idiomas (si no funciona el contenido embebido, navega a  Honest Trailers - El Hombre de Acero):

Cómo mejorar la experiencia de usuario para las personas con ceguera al color

En Accessibility: Improving The UX For Color-Blind Users se explica cómo mejorar la experiencia de usuario para las personas con ceguera al color.

Según el artículo, un 4.5% de la población presenta algún grado de ceguera al color. Pero entre los hombres sube hasta un 8%.

En este artículo se proporcionan 13 consejos que no sólo benefician a las personas con ceguera al color:

1. Text Readability
2. Text Overlaid On Background Images
3. Color Filters, Pickers And Swatches Link
4. Photographs Without Useful Descriptions
5. Link Recognition
6. Color Combinations
7. Form Placeholders
8. Primary Buttons
9. Alert Messaging
10. Required Form Fields
11. Graphs
12. Zoom
13. Relative Font Size

SVG accesible

En Accessible SVGs se explican algunas cosas para lograr que las imágenes en formato SVG sean accesibles:

Scalable Vector Graphic (SVG) is emerging as the preferred graphic format to use on the web today. Are you abandoning the icon font or replacing old pg, gif and png graphics for the well-supported SVG, too? Let’s see how this will impact users of assistive technology (AT) and what is needed in order to ensure a great user experience for everyone.

El artículo incluye varios ejemplos.

Publicada la directiva de accesibilidad de los sitios web y aplicaciones móviles del sector público

Con fecha 2 de diciembre se ha publicado la noticia Publicada la directiva de accesibilidad de los sitios web y aplicaciones móviles del sector público en el portal de administración electrónica del Gobierno de España:

Se ha publicado en el Boletín oficial de la Unión Europea la Directiva (UE) 2016/2102 del Parlamento Europeo y del Consejo, de 26 de octubre de 2016, sobre la accesibilidad de los sitios web y aplicaciones para dispositivos móviles de los organismos del sector público(Abre en nueva ventana)

Tras el acuerdo político alcanzado el pasado mes de mayo por Comisión Europea, Parlamento Europeo y Consejo europeo (estados miembros) se publica esta directiva que entrará en vigor a los 20 días de su publicación en el DOUE.

La Directiva cubrirá todos los sitios web y aplicaciones móviles del sector público, desde los de las administraciones, tribunales y servicios de policía a los de los hospitales, universidades y bibliotecas públicas, y hará que sean accesibles a todos los ciudadanos, especialmente a aquellos con dificultades auditivas, visuales o funcionales.

En los próximos 21 meses se deberá trasponer a la legislación española y vendrá a sustituir y mejorar las condiciones ya exigidas a los portales de las administraciones públicas en el Real Decreto 1494/2007(Abre en nueva ventana) , es decir, que todos los portales cumplan los requisitos de prioridad 1 y 2 de la norma UNE 139803:2012 (equivalente a nivel AA en WCAG 2.0).

Algunos aspectos destacables con respecto a las exigencias actuales en España son:

• La inclusión de las aplicaciones móviles desarrolladas por las Administraciones Públicas.
• La inclusión de intranets o extranets nuevas o que se renueven sustancialmente.
• En cada portal deberá existir una declaración de accesibilidad, un mecanismo para reportar errores y solicitar a demanda contenidos no accesibles.
• Cada Estado Miembro deberá definir un mecanismo de supervisión y organismo encargado de ello.
• Se realizarán reportes públicos a la Comisión Europea cada 3 años del estado de aplicación de la directiva.

Las normas establecidas entrarán en vigor para los portales nuevos 12 meses después de la trasposición, para el resto de portales 24 meses después de la trasposición y para las aplicaciones móviles 33 meses después de la trasposición.

En los próximos 24 meses, según establece la propia directiva, los estados miembros deberán ponerse de acuerdo y definir la metodología de monitorización y reporte, los modelos de declaración de accesibilidad y unas especificaciones técnicas comunes para el ámbito de las aplicaciones móviles.

Día Internacional de las Personas con Discapacidad

El Día Internacional de las Personas con Discapacidad se observa en todo el mundo cada 3 de diciembre de acuerdo a la resolución 47/3 de la Asamblea General adoptada el 14 de octubre de 1992, con el objetivo de llamar la atención y movilizar apoyos para aspectos clave relativos a la inclusión de personas con discapacidad en la sociedad y en el desarrollo.