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.

Máster Universitario en Tecnologías Accesibles: Web, Aplicaciones y Dispositivos

La Universidad Internacional de La Rioja (lo de poner "internacional" en el título de algo siempre queda bien) organiza el Máster Universitario en Tecnologías Accesibles: Web, Aplicaciones y Dispositivos.

El inicio es el 27 de octubre de 2016.

En la descripción dice:

El máster prestará especial atención a la accesibilidad en la Web, pero también cubrirá otras tecnologías, como son:

• Dispositivos de acceso (móviles, cajeros automáticos, etc.)

• Aplicaciones informáticas (software de escritorio, aplicaciones para móviles, etc.)

• Tendencias tecnológicas (tecnologías basadas en interoperabilidad, adaptabilidad y ubicuidad), etc.

El máster cuenta con dos itinerarios:

Itinerario profesional

PRIMER CUATRIMESTRE (30 ECTS)

Introducción a la Accesibilidad, Usabilidad y Diseño para Todos
Diseño de Contenidos Web Accesibles
Gestión de la Calidad en Materia de Accesibilidad TIC
Accesibilidad de Aplicaciones Informáticas de Distinta Naturaleza
Accesibilidad de los Dispositivos de Acceso a la Sociedad de la Información
El Usuario como Centro de la Innovación

SEGUNDO CUATRIMESTRE (30 ECTS)

Evaluación de la Accesibilidad de Contenidos Web
Accesibilidad en Documentos Electrónicos
Desarrollo de Planes de Accesibilidad TIC
Prácticas Profesionales en Empresa
Trabajo Fin de Máster

Itinerario académico

PRIMER CUATRIMESTRE (30 ECTS)

Introducción a la Accesibilidad, Usabilidad y Diseño para Todos
Diseño de Contenidos Web Accesibles
Investigación en Accesibilidad y Discapacidad
Razonamiento y Redacción Científicos
Accesibilidad de Aplicaciones Informáticas de Distinta Naturaleza
Gestión de la Calidad en Materia de Accesibilidad TIC
El Usuario como Centro de la Innovación

SEGUNDO CUATRIMESTRE (30 ECTS)

Evaluación de la Accesibilidad de Contenidos Web
Accesibilidad en Documentos Electrónicos
Interoperabilidad, Adaptabilidad y Multimodalidad para Potenciar la Accesibilidad
Metodología y Práctica de Investigación
Diseño y Gestión de Proyectos de I+D
Trabajo Fin de Máster

ChromeLens

ChromeLens es una extensión para el navegador Google Chrome que ofrece tres herramientas integradas (por ahora):

• Filters to experience a website as a blind or colorblind person: To help developers make their web pages friendly to the visually impaired, we created ChromeLens, an extension to Chrome that changes the look of web pages to reflect what they see.
• Scanners to audit the accessibility readiness of a website: The ChromeLens Scanner will scan your webpage and assess how well it is designed for people with vision impairment.
• Trackers to visually show the path of a tab/shift-tab navigation flow with the keyboard: ChromeLens Tracker is a blindness simulator that shows the pathway by which a blind user will go through when browsing your web page with a screen reader. You can check if your web page goes through a logical flow and that the important content is included for the screen reader to narrate.

Modos de funcionamiento de un lector de pantallas

En How Windows Screen Readers Work on the Web se explican los diferentes modos de funcionamiento de un lector de pantallas:

• Document mode: The most common mode used to access web pages using Windows screen readers will be referred to here as “document” mode. This is also often called “virtual” or “browse” mode, used as proprietary terminology by specific screen readers. This is the default mode that is invoked when a page loads in the browser. This mode may be overridden by web pages who auto focus a form field or apply certain WAI-ARIA roles.
• Application mode: When users need to interact with web pages such as entering text into a form field, document mode must be disabled and the screen reader must be switched into “application mode.” This mode also goes by the proprietary screen reader terms of “Forms” and “Focus” mode. Application mode is necessary to interact with forms, dialogs and web applications. In application mode, all of the keystrokes which would normally manipulate the invisible document cursor are instead passed through to the web page. This allows a user to enter text into a form field or use the arrow keys to traverse the options in a drop-down. Application mode is usually invoked by placing focus on a form field and pressing a keystroke such as the Enter key. Some screen readers will automatically switch into application mode when a form field is encountered. Application mode can also be invoked by web page authors through the application of certain WAI-ARIA roles such as role="dialog" or role="application" to page elements.

Ejemplo de sitio web con características para mejorar la accesibilidad

Fluid es un proyecto colaborativo que tiene como objetivo mejorar la experiencia de usuario y la inclusión de las personas con discapacidad en los proyectos de open source software.

En la siguiente dirección:

http://build.fluidproject.org/prefsEditors/demos/explorationTool/

podemos encontrar un ejemplo de panel con opciones para mejorar la accesibilidad de un sitio web.

aXe 2.0

En Introducing aXe 2.0! se presenta la nueva versión de esta herramienta "open source":

We’re excited to announce the launch of aXe 2.0, an updated version of our open source accessibility testing engine! Since the initial announcement last year, we’ve made improvements to many rules and checks, introduced a plugin system, added configuration options, and enhanced our project’s infrastructure. We’ve seen adoption among developers and QA’s with our Chrome and Firefox extensions, plus new integrations with notable development tools. We’ve also grown our core team and held our first hackathon!
I wrote this post to recap our efforts this year and introduce you to the newest version of aXe. Read on to learn more about the evolution of our accessibility testing engine, and how you can get involved.

Ejemplo de asistente para configurar la accesibilidad de un sitio web

Floe (flexible learning for open education) es un proyecto que tiene como objetivo mejorar el aprendizaje en línea para que sea inclusivo.

En la siguiente dirección:

http://first-discovery.floeproject.org/demos/prefsServerIntegration/

se encuentra un ejemplo de asistente que ayuda a configurar la accesibilidad de un sitio web.

Entre otras cosas, el asistente permite elegir el idioma,

la combinación de color y

el tamaño del texto.

La accesibilidad web resumida en un gráfico

Me encontré este gráfico en Twitter, no sé cuál es la fuente original:

El texto alternativo para esta imagen podría ser: representación gráfica de cuatro tipos de discapacidades (cognitiva, motora, visual y auditiva) con los elementos de una página web (interfaz, texto, multimedia) que pueden suponer una barrera de accesibilidad.

Ejemplo de sitio web con y sin accesibilidad

Acme Widgets es un sitio web de demostración de cómo crear un sitio web accesible. La descripción dice:

This web site includes sets of pages to test accessible and non-accessible methods for writing HTML. This will allow us to test patterns on multiple devices and assistive technologies. It will also give us controls for doing automated testing. The menu to the left will contain the test pages.