Desarrollo de una extensión TTS para Chrome

En Create a Text-to-Speech Chrome Extension se explica cómo crear una extensión TTS para Chrome. TTS es la conversión de texto a voz mediante un sintetizador de voz. El desarrollo de esta extensión se basa en el uso de Web Speech API, una especificación desarrollada por el W3C.

Por ahora, el API Speech Synthesis no está disponible en todos los navegadores:

¿Quieres experimentar la dislexia?

Si quieres experimentar que es la dislexia, navega a la página web Dyslexia y presta atención.

Sitio web con características accesibles

El sitio web Trace Research and Development Center ofrece algunas características para mejorar la accesibilidad de la página web.

Permite seleccionar un estilo de alto contraste:

Cuando se selecciona el estilo de alto contraste además aparece un enlace de "skip to main content".

Y también permite modificar el tamaño del texto:

Cambio de idioma en un lector de pantallas

El atributo lang se debe emplear para indicar el idioma principal de una página y los cambios de idioma que se produzcan. Esta técnica está explicada en el principio 3 comprensible de WCAG 2.0:

Guideline 3.1 Readable: Make text content readable and understandable.

3.1.1 Language of Page: The default human language of each Web page can be programmatically determined. (Level A)

3.1.2 Language of Parts: The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text. (Level AA)

Como no todos los desarrolladores cumplen lo anterior, algunos navegadores de pantalla pueden aplicar técnicas para detectar los cambios de idioma. En el siguiente vídeo se muestra el comportamiento de SuperNova:

Las 10 de reglas de oro para el diseño web accesible (según la Comisión Europea)

En 10 golden rules in accessible Web design encontramos:

1. Provide text alternatives
1. Non-text content (images, audio and video…)
2. Equivalent purpose
3. Multiple ways of providing alternatives
4. CAPTCHA needs accessible alternatives
5. Decorative content
6. Images of text
2. Structure contents
1. Headings
2. Lists
3. Data tables
4. Markup vs. style sheets
5. Resize text
6. Bypass blocks
3. Avoid dependence on a single sense
1. Captions and audio descriptions
2. Use of colour
3. Sensory characteristics
4. Contrast
5. Background audio
4. Make all functionalities keyboard accessible
1. Keyboard access
2. No keyboard trap
3. Focus order and visibility
4. Unexpected behaviour
5. Drop down menus, accordions, carousels…
5. Give users enough time
1. Timing adjustable
2. Automatic redirections
3. Long processes
4. Banners
6. Avoid interferences
1. Seizures and flashes
2. Audio control
3. Blinking, moving, auto-updating
4. Opening new windows
5. Unexpected behaviour
7. Identify hyperlinks and contents
1. Link purpose
2. Page titles
3. Language of page and parts
4. Form labels
5. Section headings
6. Opening new windows
8. Make navigation interfaces consistent
1. Consistent navigation
2. Consistent identification
3. Multiple ways
4. Information architecture
9. Help users avoid mistakes
1. Labels and instructions
2. Error identification
3. Error suggestion
4. Error prevention
5. Good information architecture
10. Ensure compatibility
1. Web standards and code validation
2. Accessible use of technologies
3. User tests
4. JavaScript, PDF and Flash
5. WAI-ARIA: Accessible Rich Internet Applications

Sitio web con vídeos con lengua de signos (o de señas)

Curioso el sitio web los Testigos de Jehová. Dispone de 835 idiomas:

Entre los idiomas se pueden elegir aquellos que se basen en la utilización de la lengua de signos:

Y también dispone de un modo accesibilidad que parece que activa o desactiva el subrayado de los enlaces:

Mejoras en Narrator

Narrator es el lector de pantallas de Microsoft que está disponible por defecto en su sistema operativo Windows.

Nunca ha sido un serio competidor frente a otros lectores de pantalla como JAWS, Window-Eyes, VoiceOver o NVDA, pero esto parece que está cambiando.

En Improvements to Narrator in Windows 10 explican que están mejorando sus características y su funcionamiento con Microsoft Edge en Windows 10.

Herramienta para automatizar análisis de accesibilidad

TheA11yMachine es una herramienta automática de evaluación de la accesibilidad web que rastrea y evalúa las páginas de un sitio web para generar un informe detallado.

Enlaces accesibles sin el subrayado

Quitarle el subrayado a los enlaces no es una buena práctica, ni desde el punto de vista de la usabilidad ni desde el punto de vista de la accesibilidad. Sin embargo, es algo que todos hemos hecho, hacemos y seguiremos haciendo.

En Accessible links without underlines se explica lo que se debe tener en cuenta para garantizar que los enlaces seguirán siendo accesibles aunque se elimine el subrayado.

Perfil para personas con discapacidad

Global Public Inclusive Infrastructure (GPII) es una propuesta de desarrollo de un perfil de usuario para la Web y para cualquier tipo de dispositivo que incorpore el perfil de discapacidad del usuario. De este modo, cuando un usuario acceda a un dispositivo que no sea el suyo, al identificarse con su perfil el dispositivo se adaptará a sus necesidades.

Una gran solución a un problema actual. Esperemos que sea adoptado, aunque lo veo difícil por las inercias que suele tener la industria a este tipo de propuestas.

Controla el ordenador con la mente

En TED he encontrado el vídeo A headset that reads your brainwaves:

Tan Le's astonishing new computer interface reads its user's brainwaves, making it possible to control virtual objects, and even physical electronics, with mere thoughts (and a little concentration). She demos the headset, and talks about its far-reaching applications.



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

El uso del atributo title

El atributo title, ese atributo que se puede utilizar para añadir información a cualquier cosa de una página web suele causar bastante confusión.

Ya he escrito sobre su uso anteriormente:

• El atributo title (2/2/2007)
• Sobre el atributo alt y title, ¿cumplen la misma función? (4/3/2011)
• El uso del atributo title (10/10/2013)

El atributo title realiza unas funciones especiales en los elementos abbr, dfn, input, link y style. En el resto de elementos su función es proporcionar advisory information (3.2.5.2 The title attribute), que se traduce por "información de asesoramiento", lo cual no se entiende muy bien. Quizás sea mejor decir "información adicional o complementaria".

"Información adicional o complementaria" deja bien claro que debe ser usado para añadir información a alguna información que ya se ha proporcionado previamente. Si no se ha hecho, como por ejemplo cuando se usa el atributo title en vez del atributo alt, se está haciendo muy mal.

El W3C ya avisa de ello con una advertencia:

Relying on the title attribute is currently discouraged as many user agents do not expose the attribute in an accessible manner as required by this specification (e.g. requiring a pointing device such as a mouse to cause a tooltip to appear, which excludes keyboard-only users and touch-only users, such as anyone with a modern phone or tablet).

Como me siguen preguntando por su uso, ahí van algunos consejos:

• No se debe emplear para proporcionar información vital o necesaria para la accesibilidad. Por tanto, no se debe emplear como sustituto del texto alternativo (alt), de las etiquetas de los controles de formulario (label), de los encabezados de tabla (th), etc.
• No se debe emplear para proporcionar la misma información que esté disponible como texto o texto alternativo.
• No se debe emplear para presentar información obvia.
• Se debe usar con cuidado en los enlaces y botones pequeños, porque al mostrarse el tooltip puede cubrir el elemento asociado.
• Siempre se debe emplear en la etiqueta frame para definir el propósito de un marco en una página web (aunque el uso de los marcos está desaconsejado desde hace tiempo).
• La regla básica para su uso es sencilla: la página web se debe emplear sin ningún problema si el atributo se elimina.

Podcasts sobre accesibilidad web (2)

El segundo podcast de Rob Dodson publicado hasta ahora:

Podcasts sobre accesibilidad web (1)

Rob Dodson, desarrollador de Google, ha iniciado una serie de podcasts sobre accesibilidad web:

La accesibilidad de reCAPTCHA

El artículo reCAPTCHA Accessibility reVISTED analiza la accesibilidad de reCAPTCHA, el sistema de captcha de Google.

Las conclusiones son que tiene problemas y no es accesible:

1. People who are deaf-blind cannot complete the secondary CAPTCHA. Neither the visual nor audio CAPTCHA is accessible to them. The only hope for them is if they never have to proceed beyond the simple checkbox. The checkbox itself is accessible.
2. The secondary CAPTCHA is language and culture-specific. Take, for example, the visual CAPTCHA shown above which asks users to identify the sandwiches. Users must understand English well enough to understand the question, and they must be familiar with sandwiches. (And anyone who attended HighEdWeb 2015 knows that sandwich is not an indisputable concept).
3. Keyboard users with eyesight can't access the visual challenge. They can access the audio challenge, but how would they know to pursue that option? It's not at all intuitive, plus visible keyboard focus is dubious.

Accesibilidad web para autores de contenido

El artículo How to Convince Writers to Write for Accessibility proporciona los siguientes consejos dirigidos a los autores o escritores de contenido:

• Write a Unique Title for Every Page
• Use True Headings and Use Them in Order
• Highlight Key Information with Lists
• Use Keywords in Image File Names
• Write a Meaningful Text Equivalent for Images
• Write Link Text That Makes Sense Out of Context and the Destination Clear

Cómo analizar la accesibilidad de una página web con NVDA

Muy interesante el artículo y el vídeo Accessibility Testing with the NVDA Screenreader.

Este es el vídeo Accessibility Testing with the NVDA Screenreader:

Lista de verificación para diseñadores, ingenieros, gestores de proyectos, aseguradores de calidad y creadores de contenido

Muy interesante el recurso The Checklist, que plantea diferentes listas de verificación según el perfil del implicado en un desarrollo web:

Designers
Make sure there is enough contrast between text and its background color
Don't indicate important information using color alone
Pair values of colors together (not only hues) to increase contrast
Don't rely on sensory characteristics as the sole indicator for understanding and operating content
Design focus states to help users navigate and understand where they are
Help users understand inputs, and help them avoid and correct mistakes
Write good alt text for your images
If an experience cannot be made accessible, create another route for users to get that information
Be as consistent and clear as possible in layout and copy

Engineers
Use the correct HTML element for your content
Support keyboard navigation
Understand and use HTML landmarks
Write good alt text for your images
Design focus states to help users navigate and understand where they are
Help users understand inputs, and help them avoid and correct mistakes
Use ARIA attributes when applicable
Give users a way to skip top level navigation to access main content
Make links descriptive
Avoid text in pseudo elements
Make SVGs accessible to assistive technology
Hide decorative elements from screen readers
Create alternate routes for users to access information
Links should be visually identifiable and have clear :focus and :active states

Project Managers
Familiarize yourself with the work associated with making content accessible
Build in time for accessibility during project planning and sprint planning
When sharing good work done by your team, praise efforts to increase accessibility
The tools and products that you create should make accessibility easier to achieve
Be an advocate for accessibility

Quality Assurance
Run through each page with the WAVE Chrome Extension
Users should be able to navigate through content using their keyboard
Users should be able to navigate content using a screen reader
The general architecture and hierarchy of the content should make sense
Charts and images should all have alt-text so that users with screen readers or users on a slow connection will still be able to understand the images
Decorative images should not be visible to screen readers

Editorial
Write good alt text for your images
Editorial Engineers: think about how custom experiences can be made accessible
Be as consistent and clear as possible
Links should be descriptive
Important information should not be conveyed through images, color, or sensory characteristics alone

Expediente sancionador contra Vueling

El 23 de octubre de 2014 se inició un expediente sancionador contra VUELING AIRLINES S.A. "por incumplimiento de las condiciones de accesibilidad para personas con discapacidad de su página web oficial". El proceso fue iniciado por J.A.C.

El 2 de marzo de 2015 el Ministerio de Sanidad, Servicios Sociales e Igualdad (MSSSI), a través del Real Patronato sobre la Discapacidad, solicita al Centro Nacional de Tecnologías de la Accesibilidad (CENTAC) un informe de accesibilidad del portal web de VUELING. El CENTAC remite dicho informe el 14 de octubre de 2015.

Sí, el Ministerio solicita el informe de accesibilidad el 2 de marzo de 2015 y el CENTAC lo remite el 14 de octubre de 2015, ¡¡10 meses después!!

Después de unas cuantas diligencias, envíos de correos electrónicos y algunas reuniones llegamos a:

RESUELVO

Imponer a VUELING la siguiente sanción: multa de TREINTA MIL UN EUROS (30.001 €), correspondiente a la infracción calificada como GRAVE EN SU GRADO MÍNIMO en función de las circunstancias concurrentes, considerando las dificultades para implantar nuevas soluciones tecnológicas y el alto coste en recursos humanos y materiales que comporta su cumplimiento dada la complejidad de la página web denunciada y su disposición manifestada de mejorar la accesibilidad en general, en virtud de lo establecido en los artículos 95.3.e), 96.b y 84 del citado Real Decreto Legislativo 1/2013, en lo que respecta a la calificación de la infracción y la determinación y graduación de la sanción.

Asimismo, tal y como establece el artículo 85 de la misma norma, como sanción accesoria y en la misma proporcionalidad expresada para la graduación de la sanción, se propone la prohibición de concurrir en procedimientos de otorgamiento de ayudas sociales, consistentes en subvenciones o cualesquiera otras ayudas en su sector de actividad de transporte aéreo por un período de UN MES.

Hace un año se confirmó la primera sanción por falta de accesibilidad web en España, que fue impuesta a Iberia. Y ahora, a Vueling.

NO se debe crear una versión accesible alternativa

El sitio web de la UEFA ofrece una versión estándar:

Y una versión accesible:

Esto no se debe hacer.