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.

Ejemplo de sitio web accesible y no accesible

Accessible University 3.0 es un sitio web de demostración que incluye un sitio web con problemas de accesibilidad y el mismo sitio web con esos problemas corregidos.

Además, se incluye una lista de los problemas que existen en el sitio web (Accessible University: List of Accessibility Issues).

Usar Google Calendar con un lector de pantalla

Google tiene la página Usar Google Calendar con un lector de pantalla que ofrece consejos para usar Google Calendar con un lector de pantallas. No ofrece muchos consejos, quizás lo más interesante es la opción de utilizar las combinaciones de teclas.