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.

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.

Un juego para ciegos

No lo he podido probar, pero me parece curiosa la propuesta descrita en Audio Game Review: A Blind Legend from DOWiNO and France Culture.

UdeG, líder en accesibilidad web entre 18 IES mexicanas

El mes pasado leí la noticia UdeG, líder en accesibilidad web entre 18 IES mexicanas:

Prueba de ello es que la página de inicio del portal de la Universidad de Guadalajara es 100 por ciento accesible para personas con distintos tipos de discapacidad; entre 18 instituciones de educación superior públicas y privadas, ocupa el primer lugar en el Ranking de Accesibilidad Web Universidades, según un estudio publicado por la empresa Hearcolors, el cual es una medición elaborada a partir del análisis de la página de inicio de cada portal.

“Dice que somos 100 por ciento accesibles. Las otras universidades evaluadas se encuentran de 54 por ciento hacia abajo”, dijo el doctor Luis Alberto Gutiérrez Díaz de León, coordinador general de Tecnologías de Información (CGTI) de la UdeG.

La base de la accesibilidad web

The web accessibility basics es una pequeña guía que explica lo más importante de la accesibilidad web:

• Alternative text for images
• Labeling form fields
• Document structure: heading structure, landmarks, lists
• Tables
• Color contrast

¿Qué es un Director de accesibilidad?

En What Being A Chief Accessibility Officer Means se explica en qué consiste el cargo de Director de accesibilidad:

In my role, I will manage internal and external accessibility projects.  I will ensure that accessibility best practices will be followed within the company and help clients meet their accessibility needs, including website and product accessibility.  I will consult on accessibility and inclusion issues that clients face from the employee to the customer level.

Cómo usar ARIA de forma efectiva con HTML5

El artículo How to Use ARIA Effectively with HTML5 explica cómo se debe usar ARIA con HTML5.

En este artículo se repasa el uso de los roles, de los atributos y unas reglas básicas:

• Utiliza la semántica de HTML siempre que sea posible.
• Un elemento sólo puede tener un role.
• No cambies la semántica nativa de los elementos.

Nivel de lectura adecuado

Web Content Accessibility Guidelines (WCAG) 2.0 indica en la pauta 3.1.5:

3.1.5 Nivel de lectura: Cuando un texto requiere un nivel de lectura más avanzado que el nivel mínimo de educación secundaria una vez que se han eliminado nombres propios y títulos, se proporciona un contenido suplementario o una versión que no requiere un nivel de lectura mayor a ese nivel educativo. (Nivel AAA)

El contenido web se debe crear para que se pueda entender por todo el mundo. La pauta 3.1.5 establece que se debe emplear un nivel de lectura equivalente al mínimo de educación secundaria. ¿Qué nivel es ese?

En el glosario de WCAG se define:

nivel de educación primarioPeriodo de seis años que empieza a las edades de entre cinco y siete, posiblemente sin ninguna educación previa.
Nota: Esta definición está basada en la Clasificación Internacional Normalizada de la Educación.
nivel mínimo de educación secundariaLos dos o tres años de educación que se inician al término de seis años de escuela y finalizan nueve años después del comienzo de la enseñanza primaria.
Nota: Esta definición se basa en la Clasificación Internacional Normalizada de la Educación.

Las edades de inicio de la educación primaria y secundaria varían de un país a otro, pero tomando que la primaria comienza a los cinco años y dura 6 años, la secundaria comienza a los 11 años, y ese es el nivel de lectura que se debe garantizar.

Para medir el nivel de lectura necesario para comprender un texto existen algunas métricas y herramientas basadas en esas métricas. Para el inglés, una herramienta que se puede utilizar es Readibility-Score.

Curiosidades sobre el Braille

En 10 things you probably don't know about braille se explican algunas cosas sorprendentes sobre el Braille:

1. Braille started out as a military code.
2. There’s an asteroid named Braille.
3. Braille takes up more space than the traditional alphabet.
4. Braille is not a language.
5. Most people who are blind don’t know braille.
6. There’s a braille “Olympics.”
7. There’s a special version of braille just for mathematics called the Nemeth Code.
8. Braille is the surprise plot twist in the 2010 movie “The Book of Eli.”
9. There are two versions of braille – contracted and uncontracted.
10. There’s a good reason why braille is on the keypad buttons of drive-through ATMs.

Herramientas de evaluación de la accesibilidad web que comprueban el DOM

Hoy en día, el contenido de muchas páginas web no se basa únicamente en el código HTML, sino que también depende de código JavaScript que añade de forma dinámica contenido a la página. Debido a esto, es importante que una herramienta de evaluación de la accesibilidad web sea capaz de analizar el DOM y no sólo el HTML de una página web.

En Web Accessibility Testing Tools: Who tests the DOM? podemos encontrar una comparativa de herramientas automáticas de evaluación de la accesibilidad web. De las herramientas analizadas, sólo las siguientes comprueban el DOM: Opquast, SortSite, Tenon y WAVE.

Resumen de denuncias sobre accesibilidad web

En Website Accessibility Lawsuits By the Numbers se recoge información sobre las denuncias sobre accesibilidad web presentadas en Estados Unidos.

Desde el 1 de enero de 2015 se han presentado 61 denuncias que se distribuyen en los siguientes sectores:

Curso Web Accessibility

En Udacity está disponible el curso gratuito Web Accessibility: Developing with Empathy. El contenido del curso es:

Lesson 1: Overview

In this lesson you’ll learn why accessibility matters, and who it affects. You’ll also get a first look at the web accessibility guidelines (WAI – Web Accessibility Initiative), understand what “POUR” means for accessibility, and locate checklists to help make your own sites accessible.

Lesson 2: Focus

In this lesson you’ll learn how to make a page usable for anyone navigating with the keyboard. This starts with an introduction to the concept of focus (the element on the page to which keyboard events will be targeted), how to make elements focusable and when, and the order in which focusable elements will be traversed when exploring the page with the keyboard. You’ll also learn how to manage focus in forms, in custom components, pop-ups, and off-screen content.

Lesson 3: Semantics Basics

In this lesson you’ll build on keyboard navigation to make a page work for people who are unable to use a standard user interface, including users who can't see the screen. This requires ensuring assistive technology (such as screen readers) has sufficient information to present an alternative UI. You’ll use a screen reader to try out ordinary form elements and add markup to make them work even better. You’ll understand the accessibility tree the browser constructs from the DOM. Finally, you’ll learn how to built-in HTML features to ensure the accessibility tree accurately reflects the visual UI.

Lesson 4: Semantics Extras

In this lesson, you’ll dive deeper into the screen-reader experience to add hyper-fast navigation. You’ll learn how to arrange headings and label links so screen reader users can fly through your pages! You’ll also learn how to call out “landmarks” into your page to speed up navigation even more. (As a bonus, this “semantic markup” also makes your markup more readable!)

Lesson 5: Semantics - ARIA

In this lesson, you’ll move beyond the native elements of HTML into building custom controls and interactions. Of course you want these to be accessible, and that’s where ARIA comes in – Accessible Rich Internet Applications. You’ll learn how to add attributes to your custom interactions to make them as accessible as native elements. You’ll also learn how to manage these attributes from Javascript as the user interacts with your page.

Lesson 6: Style

In this lesson, you’ll learn the third pillar of Accessibility (after Focus and Semantics): Styling. Your page’s styles need to support highlighting the focus, indicating ARIA states, being zoomed in or out, and viewed by people with limited color or contrast vision. You’ll learn how to audit your page with the Chrome Accessibility Tools and correct any styling issues that pop up, as well as designing with accessibility in mind.

Sobre las demandas por falta de accesibilidad en Estados Unidos

Muy interesante el artículo Troubling Web Accessibility Trends in the U.S. que explica las razones de que en Estados Unidos haya tantas demandas sobre falta de accesibilidad.

La web de ALSA obtiene el nivel AA de accesibilidad web

Hace unos días se anunció que la web de ALSA, la compañía de autobuses, obtuvo el nivel AA de accesibilidad web:

• La Web de ALSA obtiene la Certificación de Accesibilidad AA
• ILUNION concede la Certificación de Accesibilidad nivel 'AA' a la web de ALSA

El anuncio se puede leer en la propia web de ALSA: La web de ALSA obtiene la Certificación de Accesibilidad AA.

En la web de ALSA podemos encontrar el sello otorgado por Ilunion (Technosite):

El sello enlaza a la página web con la información sobre el certificado de accesibilidad web:

Cómo incorporar la accesibilidad web de forma efectiva en la enseñanza del desarrollo web

Como profesor, me ha parecido muy interesante el artículo Effectively including accessibility into web developer training. Los consejos que desarrolla son:

• Do not treat accessibility as its own topic
• Discuss the role of "markup" in Hypertext markup language
• Discuss the Document Object Model, including Object-Oriented Principles like Abstraction, Inheritance, and Encapsulation
• Discuss user input devices
• Discuss quality
• Discuss basic user expectations, including predictability of the interface

¿Usabilidad, accesibilidad? (parte 6)

En el año 2014, a través de una organización llamada CIESPAL impartí un webinar sobre las diferencias y semejanzas de la usabilidad y accesibilidad. Ese webinar fue retirado de Internet, así que lo he rescatado y editado, he mejorado el material audiovisual de apoyo y lo he publicado dentro de mi curso iDESWEB.

La parte 6 incluye: preguntas y respuestas sobre desarrollo web, usabilidad web y accesibilidad web.



Nota: la grabación del webinar que me pasaron no tenía mucha calidad, es lo mejor que me pudieron dar.

¿Usabilidad, accesibilidad? (parte 5)

En el año 2014, a través de una organización llamada CIESPAL impartí un webinar sobre las diferencias y semejanzas de la usabilidad y accesibilidad. Ese webinar fue retirado de Internet, así que lo he rescatado y editado, he mejorado el material audiovisual de apoyo y lo he publicado dentro de mi curso iDESWEB.

La parte 5 incluye: principios de WCAG 2.0 (perceptible, operable, comprensible y robusto), ejemplo de accesibilidad web, definiciones formales de usabilidad y accesibilidad web, referencias a más información.



Nota: la grabación del webinar que me pasaron no tenía mucha calidad, es lo mejor que me pudieron dar.

¿Usabilidad, accesibilidad? (parte 4)

En el año 2014, a través de una organización llamada CIESPAL impartí un webinar sobre las diferencias y semejanzas de la usabilidad y accesibilidad. Ese webinar fue retirado de Internet, así que lo he rescatado y editado, he mejorado el material audiovisual de apoyo y lo he publicado dentro de mi curso iDESWEB.

La parte 4 incluye: accesibilidad web, productos de apoyo, línea braille y lector de pantalla, W3C, WAI, pilares básicos de la accesibilidad web, WCAG 1.0 y 2.0, ISO/IEC 40500:2012, NTE INEN ISO/IEC 40500:2012.



Nota: la grabación del webinar que me pasaron no tenía mucha calidad, es lo mejor que me pudieron dar.

¿Usabilidad, accesibilidad? (parte 3)

En el año 2014, a través de una organización llamada CIESPAL impartí un webinar sobre las diferencias y semejanzas de la usabilidad y accesibilidad. Ese webinar fue retirado de Internet, así que lo he rescatado y editado, he mejorado el material audiovisual de apoyo y lo he publicado dentro de mi curso iDESWEB.

La parte 3 incluye: usabilidad web, ejemplos reales de falta de usabilidad, consejos básicos de Jakob Nielsen y Steve Krug.



Nota: la grabación del webinar que me pasaron no tenía mucha calidad, es lo mejor que me pudieron dar.

¿Usabilidad, accesibilidad? (parte 2)

En el año 2014, a través de una organización llamada CIESPAL impartí un webinar sobre las diferencias y semejanzas de la usabilidad y accesibilidad. Ese webinar fue retirado de Internet, así que lo he rescatado y editado, he mejorado el material audiovisual de apoyo y lo he publicado dentro de mi curso iDESWEB.

La parte 2 incluye: definición de accesibilidad, diseño inclusivo, diseño universal, diseño para todos, accesibilidad en la vida diaria, soluciones erróneas, la accesibilidad ayuda a todas las personas.



Nota: la grabación del webinar que me pasaron no tenía mucha calidad, es lo mejor que me pudieron dar.

¿Usabilidad, accesibilidad? (parte 1)

En el año 2014, a través de una organización llamada CIESPAL impartí un webinar sobre las diferencias y semejanzas de la usabilidad y accesibilidad. Ese webinar fue retirado de Internet, así que lo he rescatado y editado, he mejorado el material audiovisual de apoyo y lo he publicado dentro de mi curso iDESWEB.

La parte 1 incluye: presentación del webinar, orígenes de la usabilidad, usabilidad en la vida diaria.



Nota: la grabación del webinar que me pasaron no tenía mucha calidad, es lo mejor que me pudieron dar.

Prioridad y nivel de conformidad

En el curso Accesibilidad web avanzada: Análisis y corrección de problemas de accesibilidad en páginas y aplicaciones web en el que participo como tutor, un alumno ha planteado la siguiente pregunta:

De acuerdo a la fuentes de información proporcionadas al parecer la mayoría de las legislaciones adoptan como requisito la Prioridad 2 con un Nivel de Conformidad AA.

Con esto se estaría asegurando una accesibilidad en la cual algunos usuarios experimentarían "ciertas dificultades" para acceder a la información. Este punto es el que cubre el Nivel AAA.

Si se opta por diseñar la página para cumplir el Nivel AAA, ¿se vuelve mucho más complejo el código si se hubiese elegido cumplir el Nivel AA?

Mi respuesta ha sido:

Muy interesante la pregunta y la discusión. Mi respuesta es un poco larga, si quieres la respuesta rápida, ve al último párrafo.

En WCAG 1.0, los niveles de prioridad de los puntos de verificación estaban muy bien explicados:

[Prioridad 1]
Un desarrollador de contenidos de páginas Web tiene que satisfacer este punto de verificación. De otra forma, uno o más grupos de usuarios encontrarán imposible acceder a la información del documento. Satisfacer este punto de verificación es un requerimiento básico para que algunos grupos puedan usar los documentos Web.

[Prioridad 2]
Un desarrollador de contenidos de páginas Web debería satisfacer este punto de verificación. De otra forma, uno o más grupos encontrarán dificultades en el acceso a la información del documento. Satisfacer este punto de verificación eliminará importantes barreras de acceso a los documentos Web.

[Prioridad 3]
Un desarrollador de contenidos de páginas Web puede satisfacer este punto de verificación. De otra forma, uno o más grupos de usuarios encontrarán alguna dificultad para acceder a la información del documento. Satisfacer este punto de verificación mejorará la accesibilidad de los documentos Web.

Las prioridades 1 y 2 establecían lo que era obligatorio realizar para eliminar las barreras de accesibilidad. La prioridad 3 establecía problemas secundarios, que podían plantear alguna dificultad, pero que podían ser salvados por el usuario. Los puntos de verificación de prioridad 3 estaban más orientados a mejorar la usabilidad más que la accesibilidad.

¿Y qué ha pasado en WCAG 2.0?

Desgraciadamente, el W3C no ha definido claramente los niveles. En Understanding WCAG Level, Karl Groves, uno de los gurús de la accesibilidad web a nivel mundial, explica que en los borradores previos de WCAG 2.0 sí que se definían los niveles, pero que luego desapareció la definición:

I’ve become increasingly aware of people’s frequent misunderstanding of the purpose of what the term ‘Level’ represents in the Web Content Accessibility Guidelines (WCAG). I hope to help clarify this in this post. Keep in mind, this is my interpretation, because as I’ll mention later, the WCAG Working Group hasn’t been as clear as they should have been.

En Understanding Levels of Conformance del W3C podemos encontrar una definición de los niveles y de que todos son importantes, lo que tampoco aclara mucho.

En What are the Web Content Accessibility Guidelines? de WUHAG podemos encontrar la siguiente explicación:

The Web Content Accessibility Guidelines 2.0 are organised into three levels of conformance:

• Level A – the most basic web accessibility features 
• Level AA – deals with the biggest and most common barriers for disabled users 
• Level AAA – the highest (and most complex) level of web accessibility 

For most websites, Level AA plus some Level AAA is the best target. That’s because some of the highest level guidelines simply can’t be applied to all websites. However, one of the problems with the three-tier structure is that if people know they can’t attain AAA, they won’t even look through the guidelines to see where they can improve accessibility. With all of your projects, you should comply with all the guidelines you can, whether you want Level AAA or not.

Respuesta corta

Por último, en WCAG 2.0 Conformance Requirements podemos leer:

Note 2: It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content.

Intentar lograr el nivel AAA puede ser contraproducente.

Sobre los API de accesibilidad

El artículo Accessibility APIs: A Key To Web Accessibility explica que son los API de accesibilidad, su origen y su evolución a lo largo de los últimos años.

Extensiones a WCAG 2.0

En octubre de 2015, W3C anunció que comenzaba el trabajo en el desarrollo de una recomendación para la extensión de WCAG 2.0: Work Begins on Extensions to WCAG 2.0.

En enero 2016 se publicó el primer borrador de Requirements for WCAG 2.0 Extensions.

¿Se complica el uso de WCAG 2.0? Sí, un poco, así que recomiendo la lectura de Extensions to WCAG 2.0 para entenderlo un poco.

Postgrado en Accesibilidad y Diseño para Todos

La Universitat Internacional de Catalunya organiza la sexta edición del Postgrado en Accesibilidad y Diseño para Todos. El curso se desarrollará de octubre de 2016 a julio de 2017.

El curso abarca diferentes temas de la accesibilidad, pero tiene dos módulos relacionados con la accesibilidad web:

1: INTRODUCCIÓN A LA ACCESIBILIDAD Y EL DISEÑO PARA TODOS

1. ¿Qué es la accesibilidad?
   • Concepto de barreras arquitectónicas y en la comunicación.
   • Las barreras más usuales.
   • Principales dificultades: Maniobra, Alcance, Desnivel y Control.
2. Concepto de accesibilidad Universal.
3. Conceptos de normalización técnica
4. Legislación y Normativa:
   • Revisión crítica de la normativa de Accesibilidad
   • Análisis comparado de normativas vigentes. (Nacionales y Europeas)
   • Normas de Accesibilidad en América.
   • Resolución de buenas prácticas.
5. Fundamentos, estudio y promoción de la accesibilidad:
   • Los fundamentos: dimensiones de la accesibilidad y principios del Diseño Universal (Diseño para Todos).
   • La accesibilidad como bien económico y social: contexto, investigación y aplicaciones.
   • Instrumentos y gestión para la promoción de la accesibilidad:
   • Planes de acción: Planes nacionales / Incentivos y ayudas
   • Concienciación y capacitación
   • En balance: una perspectiva multidisciplinar de la promoción de la accesibilidad.
6. La Autonomía como principio en el Marco legal universal.
   • Concepto de Inclusión
   • La autonomía humana: Concepto y características
   • IAFUSS: Criterios básicos de diseño universal que promueven la autonomía humana: Identidad, Accesibilidad, Funcionalidad, Usabilidad, Seguridad y Sostenibilidad.

6: NUEVAS TECNOLOGÍAS: DOMOTICA Y ACCESIBILIDAD A LA SOCIEDAD DE INFORMACIÓN: MULTIMEDIA, CONTENIDOS WEB Y AUDIOVISUALES

1. Accesibilidad a la sociedad de la tecnología de la información (TIC)
2. Páginas y contenido web A, AA y AAA
3. Accesibilidad en las Redes sociales, Aplicaciones y en aplicaciones tecnológicas
4. Accesibilidad audiovisual: Subtitulación y Audiodescripción
5. Nuevas tecnologías: Domótica y Control del entorno
6. Requerimientos de pre-instalación de elementos tecnológicos.
7. Accesibilidad a la Comunicación sensorial en el ocio y la cultura.
   Ejemplos de buenas prácticas: Últimos avances.

Webinar sobre gestión inclusiva del riesgo de desastres

A raíz del reciente terremoto de Ecuador, la Secretaría Técnica para la Gestión Inclusiva en Discapacidades (SETEDIS) organiza el webinar Gestión inclusiva del riesgo de desastres.

El webinar, y si la madre naturaleza lo permite, tendrá lugar este martes 31 de mayo a las 9:30 hora de Ecuador.

La historia de Tobii

Tobii es el sistema de eye tracking más popular. En el artículo "Nos ha llevado 15 años lograr que cualquiera controle un ordenador con la mirada" se explica su historia:

“El dispositivo emite una luz como la del mando a distancia y luego un sensor infrarrojo apunta a la cara de la persona para ver dónde están sus pupilas y hacia adónde apuntan”, explica Skogö. No son sólo palabras, porque lleva orgulloso su propio portátil para apoyarlas con una pequeña dosis de realidad. El gadget consiste en una pequeña barra con varias luces rojas colocada bajo la pantalla que recuerda a una de sonido. Lo comprobamos con nuestros propios ojos y funciona a la perfección: cambiar entre ventanas, cerrarlas y hacer scroll resulta tan rápido y sencillo como parpadear. 

En el momento en el que es posible controlar un ordenador, aunque sea con los ojos, es posible hacer cualquier cosa: desde cambiar de canal en la televisión y apagar las luces de casa a navegar por internet y controlar un programa de sintetizado de voz. Gracias al sistema de seguimiento de la vista es posible que estas personas puedan interactuar con el mundo que les rodea. “La gente que no puede caminar sabe que puede conseguir una silla de ruedas, pero no sabe que podría comunicarse por sí misma”, explica Skögo. Y ellos quieren cambiar eso.

Cómo forzar los subtítulos en YouTube

El artículo Cómo forzar los subtítulos de YouTube al insertar un vídeo nos explica:

Para lograr que los subtítulos de un vídeo integrado queden en un idioma en concreto hay que añadir unos parámetros a la URL final del código de inserción, aquí tienes unos ejemplos de como quedarían:

• hl: Establece el idioma para los controles del vídeo de YouTube.

• cc_lang_pref: Establece el idioma para los subtítulos del vídeo.

• cc_load_policy: Fuerza a que el vídeo se muestre con subtítulos.

Learning Tools para OneNote

Álvaro, un lector de este blog, me ha pasado esta información, Herramientas de aprendizaje de OneNote.

La descripción de la herramienta dice:

Herramientas de escritura y lectura integradas para mejorar los resultados de aprendizaje de todos los alumnos.

• Los alumnos pueden adquirir una mayor comprensión lectora.

• Los estudiantes de inglés pueden mejorar su fluidez.

• Los lectores emergentes pueden sentirse más seguros al leer material de un nivel más alto.

• Los alumnos con dificultades de aprendizaje, como la dislexia, pueden descodificar el texto con más facilidad.

He incluye las siguientes funciones:

• Dictado mejorado: Mejora la redacción de textos.
• Modo de concentración: Mantiene la atención y mejora la velocidad de lectura.
• Lectura absorbente: Mejora la comprensión y mantiene la atención.
• Espaciado de fuente y líneas cortas: Improve reading speed by addressing "visual crowding".
• Partes del discurso: Es compatible con la instrucción y mejora la calidad de redacción.
• Silabificación: Mejora el reconocimiento de palabras.
• Modo de comprensión: Mejora la comprensión en una media del 10 %.

Curso sobre productos de apoyo

En Introduction to Assistive Technology podemos encontrar un curso, en inglés, sobre los productos de apoyo que emplean las personas con discapacidad. Este curso está elaborado por la Universidad de Iowa.

El curso tiene 12 módulos y también tiene ejercicios.

Menuda mierda de colores en el periódico El Mundo

Sí, una auténtica mierda los colores que utilizan en artículos como ¿Alergia o catarro? Identifica las diferencias:

¿Puedes ver algo en la imagen? ¿A qué no? No, no te preocupes, no tienes problemas de visión, el problema son los colores que ha utilizado el diseñador de esa página web, una mierda de colores, el gris #9a9da5 para el texto y el blanco #ffffff para el fondo:

Esa combinación de colores no es accesible:

La relación de contraste es 2.71:1, no alcanza ni el mínimo de 3 para texto grande, y mucho menos 4.5 para texto normal.

En definitiva, una mierda de colores.

Hace tiempo hice un vídeo porque el periódico El País también presentaba un problema de contraste:

¿Un sitio web accesible tiene que ser feo?

En Fact or Fiction? Accessible Websites Are Ugly by Design se explica que es un mito que un sitio web tenga que ser feo para ser accesible:

This myth is based on the technology limitations that existed years ago. At that time, the limitations were much more prohibitive for designers and text-only was often considered the best way to achieve accessibility. Today, accessible websites can be rich with images and videos, as long as you include alt text and captions. 

It is true that accessibility places a few design limitations on websites. But that doesn’t mean the only alternative is an ugly site. It just means you might have to make a few adjustments. For example, you might not have your first choice of font size, or your color palette might be a little constrained. But there are plenty of examples of beautifully designed accessible sites.

Creación de documentos digitales accesibles

Muy buena la Guía para elaborar documentación digital accesible de CENTAC, elaborada por Lourdes Moreno, Paloma Martínez y Yolanda González de la Universidad Carlos III de Madrid.

La guía también se puede descargar desde esta otra dirección:

http://ocw.uc3m.es/recursos/Guia-Accesibilidad-Documentacion-Digital.pdf

El sistema que emplea Stephen Hawking para comunicarse

En How Stephen Hawking communicates se explica el sistema que Stephen Hawking emplea para comunicarse. El artículo incluye este vídeo:


En realidad, Stephen Hawking ya no emplea el sistema que aparece en el vídeo, emplea un sistema más moderno y mejorado, pero el concepto sigue siendo el mismo:

• Las ayudas técnicas de Stephen Hawking
• Así funciona la voz de Stephen Hawking

Error de internacionalización en los contactos de Google

El idioma puede ser otra barrera en la accesibilidad de un sitio web. Cuando se internacionaliza/localiza un sitio web, está claro que se tienen que traducir los textos que se ven. Pero, ¿qué pasa con los textos que no se ven?

En los contactos de Google he encontrado un error importante:

Como se puede ver en la imagen, el valor del atributo title de la bandera de España pone "Country Code: España (+34)". Seguramente, al realizar la internacionalización tradujeron correctamente la lista de países ("España" lo sacan de una tabla de una base de datos), pero "Country Code" que debe ser un texto estático en la propia página se les olvidó.

Aplicación para analizar la accesibilidad de aplicaciones móviles

En Google’s new tool to help create accessible applications se explica que Google ha desarrollado una aplicación para analizar la accesibilidad de aplicaciones móviles. La aplicación se llama Accessibility Scanner.

Cómo verificar la accesibilidad web con NVDA

Un pequeño artículo sobre el uso de NVDA: Testing with the NVDA Screen Reader.

Me ha llamado la atención descubrir que NVDA tiene add-ons (plug-ins), y tiene uno para resaltar un elemento cuando recibe el foco.

La tecnología permite a una persona ciega correr un maratón solo

El artículo How One Blind Marathon Runner Is Using Technology To Run Solo explica cómo se ha logrado que una persona ciega corra sola un maratón.

Y unos vídeos sobre ello:

Los sitios web de la Comisión Europea deben ser accesibles desde enero de 2010

El sitio web Information Providers Guide proporciona información para cualquiera que vaya a crear contenido para los sitios web de la Unión Europea:

The INFORMATION PROVIDERS GUIDE is for everyone who develops and publishes material on EU websites, including webmasters, editors, content providers, web developers and contractors. The guide covers all aspects of publishing on the EUROPA site, describing the relevant editorial, technical and presentation standards in force.
The rules set out in the IPG are compulsory in order to ensure a coherent and user-friendly service to the users. The IPG is freely available on EUROPA in English, and is a living document which is regularly updated.

Una de las cosas que se definen en esta guía es la accesibilidad web (Web accessibility):

As from January 2010, all new EUROPA websites have to be created in compliancy with the Web Content Accessibility Guidelines 2.0, level AA.
Advice on how to meet the standard is detailed in these pages.

También se explica cómo se debe incluir el logo WAI de cumplimiento de la accesibilidad web.

Y existe un FAQ de preguntas y respuestas sobre accesibilidad web.

Primera norma a nivel de la Unión Europea sobre la accesibilidad de los sitios web y las aplicaciones móviles

Cuidado, cuidado, cuidado, que ya he leído en algún sitio que en la Unión Europea aprueba la primera norma de accesibilidad web para toda la Unión Europea. Esa interpretación no es correcta.

Lo que podemos leer en el comunicado de prensa La Comisión, satisfecha del acuerdo para una mayor accesibilidad de los sitios web y las aplicaciones del sector público de la Comisión Europea es:

Los negociadores del Parlamento Europeo, el Consejo y la Comisión aprobaron esta noche las primeras normas a nivel de la UE para aumentar la accesibilidad de los sitios web y las aplicaciones móviles de los organismos del sector público, especialmente para las personas ciegas, sordas o con dificultades auditivas.
[...]
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, en particular a los ciegos, los sordos o las personas con dificultades auditivas, visuales o funcionales.
[...]
Tras el acuerdo político alcanzado esta noche (en el «triálogo» de negociación entre el Parlamento Europeo, el Consejo y la Comisión), el texto deberá ser formalmente aprobado por el Parlamento Europeo y el Consejo. A continuación se publicará en el Diario Oficial y entrará en vigor de forma oficial. Los Estados miembros dispondrán de veintiún meses para transponer el texto en su legislación nacional.

Es decir, todavía falta un poco, pero ya falta un poco menos.

En el año 2012 se presentó una directiva del Parlamento Europeo para la accesibilidad de los sitios web del sector público: Proposal for a Directive of the European Parliament and of the Council on the accessibility of public sector bodies' websites. En el artículo 5 se indicaba:

As long as the references of the European standards referred to in paragraph 1 have not yet been determined, the websites concerned that meet the parts of the ISO/IEC 40500:2012 covering the Success Criteria and Conformance Requirements for Level AA conformance, shall be presumed to be in conformity with the web-accessibility requirements set out in Article 3. 

Por tanto, es de esperar que la norma europea exija el cumplimiento de WCAG 2.0 AA.

Por cierto...

Lo mismo ha pasado con la Ley europea de accesibilidad (European Accessibility Act). El 2 de diciembre de 2015 se anunció a "bombo y platillo", pero no. Ese día se propuso la ley, pero la ley no está aprobada todavía. Otra vez, lo que debemos leer es el comunicado de prensa oficial La Comisión propone hacer más accesibles los productos y los servicios para las personas con discapacidad del 2 de diciembre de 2015:

La Comisión Europea ha propuesto hoy una ley europea de accesibilidad que establecerá requisitos comunes de accesibilidad para determinados productos y servicios clave que ayudarán, a nivel de la UE, a que las personas con discapacidad participen plenamente en la sociedad.

Dos de cada tres personas con discapacidad consideran que las nuevas tecnologías pueden ayudar a mejorar su bienestar

Eso dice el informe Discapacidad, integración y el papel de las TIC, investigación liderada por el Observatorio de la Discapacidad Física y COCEMFE Barcelona, en colaboración con la Fundación VODAFONE.

La muestra del estudio fue:

De las 1.039 personas que se han entrevistado, el 9,4% tienen una discapacidad visual, un 5,9% auditiva y el 84,7% restante alguna otra discapacidad física. En el 51% de los casos la discapacidad tiene origen en una enfermedad, en un 26,5% en un accidente (la mitad de ellos de tráfico) y en el 22% restante es congénita o de nacimiento. Un 12% de los entrevistados no tiene un certificado de discapacidad que reconozca el grado.

Algunas de las conclusiones del estudio:

Dos de cada tres personas con alguna discapacidad física creen que las tecnologías ayudan o pueden ayudar a la mejora de su bienestar. Cuanto más joven y más formado, más convencido está de las ventajas de las tecnologías. Los que tienen una discapacidad visual o auditiva son los más convencidos. Asimismo, el 68,6% se conecta con alguna frecuencia a internet, casi un 50% diariamente (lo que representa veinte puntos menos que la población general). La edad, la formación y los ingresos son las variables que generan mayores diferencias. Así, cuanto más joven, más formado y con más ingresos, más conexión a internet. De hecho, el acceso a la red es prácticamente universal entre los menores de 45 años, pero, en cambio, la mayoría de los que tienen más de 65 no usan internet. 

Casi uno de cada cuatro dice que internet le proporciona autonomía e independencia. Pero es el acceso a la información y la facilidad para las relaciones lo que más se destaca como aportaciones de internet en la vida diaria. Los más grandes son los que ponen un mayor énfasis en las facilidades que supone para su vida cotidiana, y el 62,2% de los entrevistados dispone de un teléfono móvil inteligente (Smartphone). Un 13,1% de los consultados no dispone de teléfono móvil y más del 20% tiene un móvil convencional. El nivel de ingresos, los estudios pero sobretodo la edad son las variables en las que se aprecian más diferencias en el hecho de disponer o no de Smartphone: así, entre los más jóvenes casi el 90% dispone de un teléfono inteligente, el doble que entre los entrevistados de más edad.

Dos cursos en inglés sobre accesibilidad web

Dos cursos de tipo MOOC y gratuitos, alojados en la plataforma Canvas, sobre accesibilidad web:

• Web Accessibility MOOC for Educators
• Professional Web Accessibility Auditing Madre Easy

Y claro, no puedo dejar de recomendar el curso sobre accesibilidad web que yo coordino, Aprende Accesibilidad Web paso a paso.

Accessibility Support Database

Accessibility Support Database es un proyecto del W3C que tiene como objetivo crear una base de datos de pruebas de accesibilidad en la que se refleje la accesibilidad que presentan diferentes combinaciones de navegadores y productos de apoyo.


Por ejemplo, una prueba fácil de entender es Test Case H45_35: Screen readers can follow the longdesc of an img to an external source:

Esta prueba verifica si se puede navegar a la fuente externa que indica el atributo longdesc en una imagen.

Según los resultados, que son incompletos porque este proyecto parece colaborativo, NVDA 2013 con Firefox 25 sí que lo permite.

En la descripción de la prueba se puede acceder a la página que se puede emplear para verificar la prueba.

Accesibilidad de la aplicación móvil de Renfe

Accesibilidad para personas con discapacidad visual en la app Renfe Ticket resume un análisis realizado para evaluar la accesibilidad de la aplicación móvil de Renfe Ticket.

La evaluación fue realizada por el Centro de Investigación, Desarrollo y Aplicación Tiflotécnica (CIDAT) y el Depto. de Autonomía Personal y Accesibilidad de ONCE.

La conclusión para la versión para iOS:

Renfe Ticket tiene bastantes problemas de accesibilidad. Adquirir billetes mediante la aplicación, función que se entiende como la más importante, resulta muy dificultoso, además de inseguro.
Por todo ello, solo se recomienda el uso de esta aplicación a personas con mucha destreza en el manejo de VoiceOver par iOS.

La conclusión para la versión para Android:

El cierre inesperado que se produce durante el proceso de compra de billetes no permite realizar la función más importante de esta aplicación. Además, Renfe Ticket presenta problemas de accesibilidad a la hora de utilizar el resto de las opciones que ofrece. Por todo ello, no se recomienda el uso de esta aplicación a personas que utilicen TalkBack.

Norma sobre accesibilidad web en Chile

Con un año de retraso me he enterado de la aprobación del Decreto N° 1, 2015. Aprueba norma técnica sobre sistemas y sitios web de los órganos de la administración del Estado.

Los artículos más importantes respecto a la accesibilidad web son:

Artículo 1º.- Las normas técnicas sobre sistemas y sitios web establecidas en el presente decreto serán aplicables a los órganos de la Administración del Estado que se encuentran señalados en el inciso segundo del artículo 1º de la ley Nº 18.575, Orgánica Constitucional de Bases Generales de la Administración del Estado, cuyo texto refundido, coordinado y sistematizado ha sido fijado mediante el decreto con fuerza de ley Nº1, de 2001, del Ministerio Secretaría General de la Presidencia, con excepción de las empresas públicas creadas por ley.

Artículo 3º.- Los sistemas web y sitios web deberán ser desarrollados o implementados de manera tal que garanticen la disponibilidad y la accesibilidad de la información, así como el debido resguardo a los derechos de los titulares de datos personales, y asegurando la interoperabilidad de los contenidos, funciones y prestaciones ofrecidas por el respectivo órgano de la Administración del Estado, con prescindencia de las plataformas, hardware y software que sean utilizados.

Artículo 5º.- Para el desarrollo o implementación de los sistemas web y sitios web deberán aplicarse estándares de desarrollo, compatibilidad y las principales directrices de las normas internacionales y nacionales sobre accesibilidad universal, de manera de permitir su acceso, en igualdad de oportunidades, a personas en situación de discapacidad. Para dichos efectos, se deberá considerar las normas sobre accesibilidad establecidas en la Convención sobre los Derechos de las Personas con Discapacidad del año 2006 y ratificada por Chile en el año 2008; lo prescrito en la ley Nº 20.422, del año 2010, que establece normas sobre igualdad de oportunidades e inclusión social de las personas con discapacidad; y, los estándares internacionales definidos por la W3C.

Por tanto, aunque no se indique explícitamente, como se señala que se deben emplear los estándares internacionales definidos por la W3C, se debe emplear WCAG 2.0.

Accesibilidad y optimización web

Hace un par de semanas, Chris Heilmann, uno de los gurús del desarrollo web y la accesibilidad web, presentó Accessibility and Web Optimization en Awwwards Conference Amsterdam 2016.

Las diapositivas y algo más de información se puede encontrar en Accessibility and Web Optimization with Chris Heilmann @Awwwards Conference.

¿Cómo navega un ciego por Internet?

La semana pasada se creo un poco de polémica por la publicación del artículo De Cómo Usan Los Ciegos Internet, O Cómo La Información Desinforma. En este artículo, un usuario ciego afirmaba:

“La navegación es bastante distinta, mucho más lenta, que para una persona que ve, porque para la que no lo hace se ve obligada a leer la página completa y depende mucho de su desarrollo”, comenta. “No tienes una visión global en ningún momento […] me lo tengo que tragar todo de cabo a rabo y no me lo puedo saltar hasta que el ordenador empieza a hablar”.
"Es viable y es posible navegar por Internet pero procuramos evitarlo en la medida de lo posible porque es un coñazo […] aunque comparativamente a lo que era antes con Flash al menos tenemos esa posibilidad”, remata.

Alguien que no sepa del tema se puede quedar con la impresión de que las personas ciegas "huyen de la Web" porque es un "coñazo", y no es así.

En De Cómo Usan Los Ciegos Internet, O Cómo La Información Desinforma podemos encontrar una explicación de todo lo contrario. Por ejemplo:

Los usuarios que interactúan a través de un lector de pantalla (producto de apoyo utilizado por ciegos y algunos deficientes visuales) no están obligados a escuchar toda una web para acceder al contenido de la misma. Dichas herramientas cuentan con atajos de teclas que facilitan la navegación y permiten acceder a diferentes zonas de la web. De hecho, debido al ruido que puede ocasionar escuchar el motor de voz durante la carga de una web, lo más frecuente es detener la verbalización y luego intentar ubicar encabezados, listas o listar enlaces.

Algunos piensan que la accesibilidad web es un privilegio

En Cuando la inclusión se hace añicos frente al mundo real, Juanjo nos cuenta la mala experiencia que ha tenido con un grupo de "podemistas" (seguidores del grupo político Podemos) en Twitter.

Juanjo tiene problemas de visión y descubrió que la web de Podemos para realizar votaciones no era accesible. Lo comentó en Twitter y estas son algunas de las respuestas que recibió:

@kastwey @ahorapodemos @Pablo_Iglesias_ Pide ayuda a un familiar.

— Vikingr (@VandalViking) 16 de abril de 2016



@kastwey @VandalViking @ahorapodemos @Pablo_Iglesias_ te entiendo, pero esas cosas cuestan dinero, sé comprensivo…

— Vanesa Mis Opiniones (@Vane_y_sus_opis) 16 de abril de 2016



@kastwey @VandalViking @ahorapodemos @Pablo_Iglesias_ y como has escrito y respondido el tuit?

— Uri_Dovah (@byOriol99) 16 de abril de 2016



@kastwey @ahorapodemos @Pablo_Iglesias_ igual q has escrito aquí y te han dicho lo q dice pablo has podido votar

— Ripy Mari (@MariaMarmar46) 16 de abril de 2016



@kastwey @ahorapodemos @Pablo_Iglesias_ y como lees los tweet y contestas?una contradicción no?

— isabel1953 (@isabel19531) 16 de abril de 2016



@kastwey @Fonta49 tío…participa en lugar de quejarte.ofrécete para hacerlo y ya…es 1 pena q no haya pero lo puedes hacer tú!!

— didac (@DidacDidactis) 17 de abril de 2016



@kastwey @Vane_y_sus_opis @VandalViking @ahorapodemos @Pablo_Iglesias_ pues si es así, no entiendo los problemas que tienes sí dedicas a eso

— rompiendo reglas (@rompienreglas) 17 de abril de 2016



@kastwey @Fonta49 no hablo de favores. Creo que estás en 1 posición de víctima. Solo te sugerí que sería bueno que si sabes…te ofrezcas

— didac (@DidacDidactis) 17 de abril de 2016



@kastwey @Fonta49 pero me reafirmo que estás en una posición de víctima ante esta situación. Puedes sumarte y lograr que se haga la web

— didac (@DidacDidactis) 17 de abril de 2016



@kastwey @Fonta49 lo confirmo.. Eres un quejica… Ayuda hombre… Aquí lo dejo… No continúo. Tienes razón

— didac (@DidacDidactis) 17 de abril de 2016



@kastwey @ahorapodemos @Pablo_Iglesias_ hijo mío haz una solicitud a ver si te la aceptan y si no lo hacen quejate entonces no antes

— Rebeca (@Osetepanda) 17 de abril de 2016



@kastwey @VandalViking @ahorapodemos @Pablo_Iglesias_ eres pesao

— dana ruiz blanco (@laroja57) 17 de abril de 2016



@kastwey Tu estas aquí para votar y aportar soluciones o estas en plan niño rata?aportar si.criticar no https://t.co/0ncgI0tbNd

— Llorens Escriva (@LlorensEA) 18 de abril de 2016


Espectacular, fascinante, sorprendente, me han hecho reír, "Víctima, quejica, pesao, niño rata", jajaja, ¡menudos payasos, cuánta estupidez concentrada en menos de 140 caracteres!

Dos cursos sobre accesibilidad de la Universidad de Alcalá

El Curso Accesibilidad web avanzada: Análisis y corrección de problemas de accesibilidad en páginas y aplicaciones web (75h, 3 créditos ECTS) se imparte en modalidad online. El temario del curso es:

• Tema 1. Estándares y legislación sobre accesibilidad web.
• Tema 2. Pautas de accesibilidad para el contenido web (WCAG 2.0)
• Tema 3. Evaluación de la accesibilidad de sitios web (WCAG-EM 1.0)
• Tema 4. Accesibilidad web avanzada (WAI-ARIA 1.0 y ATAG 2.0).

El curso Desarrollo de aplicaciones móviles accesibles (25h, 1 crédito ECTS) se imparte en modalidad semipresencial:

• Fundamentos de accesibilidad
• Medidas concretas para evaluar/corregir el nivel de accesibilidad de una aplicación móvil
• Puesta en común de resultados y entrega de diplomas

El futuro de las pautas de accesibilidad

En el congreso Web for All 2016 se ha presentado el trabajo Web Accessibility Guidelines for the 2020, de Michael Cooper. Michael Cooper es un especialista de la Web Accessibility Initiative del W3C.

En este trabajo se repasa el trabajo desarrollado por WAI para crear sus tres conjuntos de pautas (ATAG, UAAG, WCAG) y se explican los pasos que se están dando para avanzar en el desarrollo de las futuras pautas.

¿Es accesible un captcha con 2 modalidades (imagen y audio) en una web que debe cumplir el nivel AA (de acuerdo a las WCAG 2.0)?

Hace unos días recibí esta pregunta:

Hay un tema que no consigo aclarar, y como experto quería consultarte, ya que me ha surgido a partir de este artículo: http://accesibilidadweb.dlsi.ua.es/?menu=que-es-un-captcha-problemas-accesibilidad

Mi duda es: ¿Es accesible un captcha con 2 modalidades (imagen y audio) en una web que debe cumplir el nivel AA (de acuerdo a las WCAG 2.0)?

Según tu texto entendí que hay que buscar otra solución, sin embargo la técnica G144 de las WCAG 2.0 habla sobre la opción de incluir dos modalidades para hacer accesible el capcha... He intentado buscar referencias/ejemplos en otras webs accesibles pero no he encontrado nada claro al 100%.

¿Cuál es tu opinión sobre esto? ¿Me recomiendas que use otra opción?

Mi respuesta:

La técnica G144: Ensuring that the Web Page contains another CAPTCHA serving the same purpose using a different modality indica que si una página web contiene un captcha, se debe proporcionar una alternativa. ¿Cómo? Por ejemplo, si una página contiene el típico captcha de introducir los caracteres que aparecen en una imagen, se debe proporciona una alternativa, como por un ejemplo un captcha auditivo.

¿Por qué?

Porque si una persona es ciega, no puede ver el captcha, pero podrá escuchar el captcha y problema resuelto. ¿Seguro?

En G144 ya no avisan de que hay que llevar cuidado:

Because there are alternate CAPTCHA tasks that use different modalities, a user is more likely to be able to complete one of the tasks successfully.

"A user is more likely", es más probable que un usuario pueda completar una tarea, pero más probable no significa más seguro al 100%.

Y en realidad, en WCAG 2.0 1.1.1 Non-text Content está más claro:

CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.

Las pautas hablan de "alternative forms of CAPTCHA", formas alternativas de captcha, pero no indica que dos formas sea suficiente.

En el caso de un captcha visual, que representa un problema para una persona ciega o con baja visión, un captcha auditivo es una alternativa válida. Pero, ¿qué ocurre con una persona sordociega?

Por tanto, un captcha con 2 modalidades (imagen y audio) no garantiza que el captcha sea accesible y que el sitio web lo pueda ser.

La mejor solución es prescindir de los captchas. En el vídeo ¿Qué es un CAPTCHA? Problemas de accesibilidad (2/2) presento algunas alternativas que permiten prescindir de los captchas:

WebReader

En el congreso Web for All 2016 se ha presentado el trabajo WebReader: a screen reader for everyone, everywhere, de Aurelio De Rosa y Donovan Justice. WebReader es:

WebReader is a free and open source JavaScript library developed for modern web browsers. Built using emerging functionality, WebReader can be integrated into any web page.
Underneath, WebReader relies on the Web Speech API to offer speech recognition and speech synthesis functionality.
It integrates a subset of the features provided by classic screen readers.
A major advantage of WebReader is that it does not require any additional software to be installed on a user's machine, apart from a supported web browser.

WebReader está disponible en https://web-reader.digital-detox.co.uk/

En el congreso Web for All

Estos días estoy en Montreal, asistiendo al congreso Web for All. Este congreso se celebra conjuntamente con el congreso WWW, el congreso más importante sobre la Web. En este congreso estoy presentando el trabajo de tres de mis doctorandas:

• Editor for Accessible Images in e-Learning Platforms, Sandra Sanchez-Gordon, Juan Estevez (National Polytechnic School of Ecuador), Sergio Luján-Mora (University of Alicante)
• Accessible Map Visualization Prototype, Tania Calle-Jimenez (National Polytechnic School of Ecuador), Sergio Luján-Mora (University of Alicante)
• Improving OER Websites for Learners with Disabilities, Rosa Navarette (National Polytechnic School of Ecuador), Sergio Luján-Mora (University of Alicante)

¿El fin del texto alternativo?

En los últimos días he comentado un par de sistemas de reconocimiento automático de imágenes:

• Microsoft presenta un sistema automático que describe imágenes
• Facebook también genera un texto alternativo automático

Además, hace un par de años hablé del sistema de Google: Dentro de poco me tendré que comer mis propias palabras como si fueran dos pizzas.

¿Será el fin del texto alternativo manual escrito por el desarrollador de una página web?

No creo, a estos sistemas todavía le queda bastante por mejorar. Además, aunque funcionen y logren describir una imagen con todo lujo de detalles, el texto alternativo de una imagen depende tanto de su contenido como del contexto de uso de la imagen. De cualquier forma, cuando funcione, será una gran ayuda, ya que se podrá utilizar para definir un texto alternativo de emergencia.