Cómo la tecnología me permitió leer

En TED he encontrado el vídeo How technology allowed me to read:

Months after he was born, in 1948, Ron McCallum became blind. In this charming, moving talk, he shows how he is able to read — and celebrates the progression of clever tools and adaptive computer technologies that make it possible. With their help, and that of generous volunteers, he's become a lawyer, an academic, and, most of all, a voracious reader. Welcome to the blind reading revolution.


Más vídeos en TED sobre discapacidad: Designing for disability

La accesibilidad web ayuda a todo el mundo

El artículo Why web accessibility benefits us all muestra cuatro escenarios en los que la accesibilidad ayuda a todos los usuarios:

Provide captions for video and audio
Captions for audio and video don’t just help the hearing impaired. For example if your first language isn’t the one being spoken or the presenter has a strong regional accent, captions can help.
You could even be in a situation where the device you are using doesn’t have any working speakers or you are in a location where the speaker isn’t loud enough to be heard over the background noise.

Content distinguishable between the foreground and background
Having a high contrast between the text and background will help make it easier for low vision users to read the copy on your website. High contrast also helps users trying to view a website on a screen in bright sunlight, or when a user has battery saver mode on or basically any scenario where the screen isn’t being viewed in the best conditions.


Make all functionality available from a keyboard
The mouse or trackpad is utterly useless if you are blind and use a screen reader to navigate your way around the web. Being solely able to navigate the web using just the keyboard is essential.
If you don’t require a screen reader being able to navigate the web with the keyboard is still really useful. Some users prefer to tab up and down content with the keyboard instead of taking their hand away to use the mouse. But it really helps when you are using a wireless mouse and the batteries fail. It means you can still carry on using the web with just the keyboard (albeit a little slower).


Make text content readable and understandable
Any effort to make your site technically accessible will be wasted unless your content is written as clearly and simply as possible.
People with disabilities experience text in many different ways but so does everyone else. The steps you should follow to create accessible copy will help everyone.

Diseña pensando en los ciegos

En TED he encontrado el vídeo Design with the blind in mind:

What would a city designed for the blind be like? Chris Downey is an architect who went suddenly blind in 2008; he contrasts life in his beloved San Francisco before and after — and shows how the thoughtful designs that enhance his life now might actually make everyone's life better, sighted or not.


Más vídeos en TED sobre discapacidad: Designing for disability

Las imágenes de fondo

Las imágenes de fondo son una mala idea en la web, tal como podemos ver en la siguiente imagen:

Creación de documentos accesibles con Microsoft Word

El artículo Microsoft Word: Creating Accessible Documents explica cómo crear documentos accesibles con Microsoft Word. Los principales temas que trata son:

• Headings
• Alternative Text for Images
• Data Tables
• Links
• Lists & Columns
• Accessibility Checker
• Converting to HTML
• Converting to PDF

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