Cómo una persona con ceguera al color trabajo con el color

Muy interesante lo que se explica en Cómo interpretar los códigos hexadecimales de color incluso siendo daltónico:

David DeSandro de Metafizzy explica en esta presentación de las dotConferences cómo desarrollar el superpoder de interpretar los códigos de color hexadecimales que habitualmente se usan en HTML/CSS/Photoshop. La técnica no es complicada, aunque requiere conocer algunos detalles. En el caso del propio DeSandro tiene más mérito porque además es daltónico: "No puedo fiarme de mi percepción visual del color a la hora de trabajar con los diseños, así que desarrollé esta habilidad como una forma de cubrir esa necesidad".

La accesibilidad de los videojuegos: ¿por qué me debería preocupar?

Conferencia impartida en el Tercer Congreso Internacional en Sistemas de Información y Ciencias de la Computación, INCISCOS 2018, celebrado en Quito (Ecuador) del 14 al 16 de noviembre de 2018.

La industria de los videojuegos es en la actualidad la principal industria del entretenimiento a nivel mundial. Esta situación no es coyuntural, sino que se espera que siga siendo así durante los próximos años.

Desgraciadamente, los videojuegos suelen presentar numerosas barreras de accesibilidad que dificultan o impiden que las personas con discapacidad puedan disfrutar de ellos. Además de la situación de discriminación que supone esto en general, la falta de accesibilidad de los videojuegos puede ser un problema muy grave en el caso de los videojuegos llamados "serios" que son empleados en la enseñanza y en la capacitación profesional.

El objetivo principal de la conferencia es concienciar a los estudiantes de informática, computación y estudios similares que estarán entre el público de la importancia de tener en cuenta la accesibilidad durante el desarrollo de los videojuegos.

Entrevista a Jonathan Chacón

Entrevista a Jonathan Chacón, desarrollador e investigador en accesibilidad, usabilidad y nuevas tecnologías; defiende los conceptos de diseño universal y accesibilidad como criterios de calidad en el software y el hardware.

Defiende la idea de un diseño accesible desde la base evitando parches y mantiene la idea de la tecnología como único camino para alcanzar una sociedad realmente inclusiva para todos ya que todos tenemos capacidades y discapacidades.

Busca divulgar y compartir la idea de una tecnología responsable por y para las personas ejerciendo su cargo de comisionado del colegio de ingeniería en informática de Cataluña para la accesibilidad y usabilidad.

Ha trabajado como consultor, desarrollador e investigador tecnológico en proyectos de biometría, visión artificial, interfaces de usuario inteligentes siempre siguiendo la filosofía del diseño para todos.

Actualmente es responsable de accesibilidad y experiencia de usuario en la startup Tech4Freedom.

Ha publicado varias aplicaciones en la AppStore bajo su sello Tyflos Accessible Software y artículos sobre accesibilidad, usabilidad y tecnología en su sitio web Programar a ciegas así como colaborador en artículos y libros de investigación, diseñador y desarrollador para proyectos educativos e inclusivos.

Playboy denunciado por falta de accesibilidad en su sitio web

Hace unos días se publicó la noticia Playboy.com Sued by Blind Man Who Says He Can’t Fully ‘Enjoy’ the Website, en la que podemos leer:

Playboy.com was sued Wednesday by a legally blind man who says that the site, as well as Playboyshop.com, aren’t equally accessible to the blind and visually impaired.

In the class-action suit, filed Wednesday in federal court in New York, Donald Nixon says that he and other visually-impaired customers are unable to “fully and equally use or enjoy” the site’s offering. And that definitely goes on the Turn-Offs list.

“Due to the inaccessibility of Defendant’s Website, blind and visually-impaired customers such as Plaintiff, who need screen-readers, cannot fully and equally use or enjoy the facilities, products, and services Defendant offers to the public on its Website,” the suit reads. “The access barriers Plaintiff encountered have caused a denial of Plaintiff’s full and equal access in the past, and now deter Plaintiff on a regular basis from visiting the Website, presently and in the future.”

According to the suit, Nixon employs screen-reading software to access the internet. During his visits to the site, the lawsuit says, Nixon “encountered multiple access barriers” that “denied Plaintiff full and equal access to the facilities, goods and services offered to the public and made available to the public; and that denied Plaintiff the full enjoyment of the facilities, goods and services of the Website, by being unable to learn more information, the ability to browse products available for delivery, find information on promotions and coupons, and related goods and services available online.”

Cómo crear una declaración de accesibilidad web

El W3C ha publicado HOW TO CREATE ACCESSIBILITY STATEMENTS, que describe el uso de la nueva herramienta Developing an Accessibility Statement para crear una declaración de accesibilidad web.

El Real Decreto 1112/2018, de 7 de septiembre, establece en el Artículo 15:

Artículo 15. Declaración de accesibilidad.
1. Las entidades responsables de las webs y aplicaciones para móviles
proporcionarán una declaración de accesibilidad detallada, exhaustiva y clara sobre la
conformidad de sus respectivos sitios web y aplicaciones para dispositivos móviles con lo
dispuesto en este real decreto. Dicha declaración será actualizada periódicamente, como
mínimo una vez al año, o cada vez que se realice una revisión de accesibilidad conforme
a lo especificado en el artículo 17.
Esta declaración de accesibilidad se proporcionará en un formato accesible haciendo
uso de las instrucciones y del modelo de declaración de accesibilidad que se establezca
conforme a lo dispuesto en el apartado 3.
En el caso de los sitios web, la declaración se publicará en el sitio web
correspondiente estando disponible su acceso desde todas las páginas del sitio web con
un enlace denominado «Accesibilidad» o su equivalente en el idioma en el que se
encuentre disponible la página.
En el caso de las aplicaciones para dispositivos móviles, la declaración estará
disponible en el sitio web de la entidad obligada que haya desarrollado la aplicación
concreta para dispositivos móviles junto con el enlace para su descarga o bien se
facilitará junto con otra información disponible al descargar la aplicación de las
plataformas de distribución de aplicaciones.

2. La declaración de accesibilidad comprenderá, como mínimo, la siguiente
información:
a) Una explicación sobre aquellas partes del contenido que no sean accesibles y
las razones de dicha inaccesibilidad, así como, en su caso, las alternativas accesibles
que se ofrezcan.
b) Un enlace y descripción del mecanismo de comunicación en los términos que se
establecen en los artículos 10, 11 y 12 del presente real decreto.
c) Un enlace al procedimiento de reclamación regulado en el artículo 13 al que
cualquier persona interesada pueda recurrir en caso de que la respuesta a la
comunicación o a la solicitud sea insatisfactoria.

3. Mediante Orden de la Ministra de Política Territorial y Función Pública se
aprobarán instrucciones específicas para la generación y puesta a disposición de las
declaraciones de accesibilidad de aplicación en todo el territorio nacional de acuerdo con
los requisitos especificados en el modelo europeo.

Día Internacional de las Personas con Discapacidad

El Día Internacional de las Personas con Discapacidad se observa en todo el mundo cada 3 de diciembre de acuerdo a la resolución 47/3 de la Asamblea General adoptada el 14 de octubre de 1992, con el objetivo de llamar la atención y movilizar apoyos para aspectos clave relativos a la inclusión de personas con discapacidad en la sociedad y en el desarrollo.

Libro "Accesibilidad Web. WCAG 2.1 de forma sencilla"

Olga Revilla y Olga Carreras han publicado el libro Accesibilidad Web: WCAG 2.1 de forma sencilla.

El contenido del libro es:

1. Introducción a la Accesibilidad Web donde se explican los orígenes, los perfiles implicados y cómo implantar una política de Accesibilidad Web en una Organización.
2. Las Pautas WCAG: qué son y cómo se organizan, qué novedades hay de la versión 2.0 a la versión 2.1 y motivaciones para seguirlas.
3. Requisitos de Conformidad: los 5 requisitos que toda página debe cumplir, los niveles de conformidad, y cómo comunicar que tu sitio es accesible.
4. Evaluar la accesibilidad con la metodología WCAG-EM: qué pasos hay que dar y cómo declarar la conformidad según este análisis.
5. Principio 1: Perceptible. Nuestro sitio web puede ser visitado por personas con muy diferentes necesidades y preferencias perceptivas, pero también por robots (buscadores, traductores automáticos...).
6. Principio 2: Operable. Los diseñadores web somos conscientes de los diferentes ispositivos, productos de apoyo y contextos de uso de los usuarios para manejar el sitio web, por lo que debemos crear los elementos que componen la interfaz de tal manera que cualquiera pueda utilizarlos.
7. Principio 3: Comprensible. Si los usuarios no comprenden lo que les decimos, o les hacemos sentirse perdidos, tenemos un problema.
8. Principio 4: Robusto. La evolución de la tecnología nos obliga a adaptarnos tanto a nosotros como a nuestros sitios web.
9. Documentos PDF accesibles. Técnicas específicas de esta tecnología y cómo implementarlas paso a paso.
10. ARIA, el aliado (casi) desconocido. Aprende a aplicar correctamente el estándar WAI-ARIA, imprescindible para comprender e interactuar mediante un lector de pantalla con componentes como acordeones, menús desplegables o pestañas. Incluimos diferentes ejemplos de código.
11. Recursos y Herramientas. Selección de validadores y asistentes para revisar el cumplimiento de las pautas.
12. Resúmenes y esquemas. Diagramas conceptuales y tablas resúmenes para avanzar más rápido.
13. Glosario. Definiciones de los términos más complejos utilizados en el libro.

Los captchas de Google

Los captchas de Google son bastante curiosos, y claro está, no accesibles:

Comparativa de tres herramientas de evaluación de la accesibilidad web

En Comparing 3 Top Automated Accessibility Testing Tools: WAVE, Tenon.io, and Google Lighthouse, se comparan tres herramientas de evaluación automática de la accesibilidad web. La conclusión es:

The advantages and limitations of automated tools: a few examples

Automated Tools Will Suffice for the following:

• Does the image have alt text?
• Does the form field have a label and description?
• Does the content have headings?
• Is the HTML valid?
• Does the application UI follow WCAG guideline X?

Human Intervention Is Required for the following:

• Is the alt text accurate given the context?
• Is the description easy to understand?
• Do the headings represent the correct hierarchy?
• Is the HTML semantic?
• Does the application UI behave as expected?

While automated tools can discover many critical issues, there are even more issues that need human analysis. If there is a vague or misleading alt tag, that is just as bad from a usability standpoint as a missing alt tag, and an automated tool won’t catch it. You need someone to go through the site with a sharp and trained eye.

In the end, to fully test for accessibility issues, a combination of automated and manual testing is required. Automated testing tools provide a good starting point for testing, point to patterns of errors that humans can then look out for, and can catch issues before they go to production.

Accesibilidad en vídeos y contenidos multimedia

En Accesibilidad en vídeos y contenidos multimedia se explica lo siguiente sobre los subtítulos:

• Transcripción de los diálogos: los subtítulos deben ser fieles y equivalentes al diálogo de los personajes y en el mismo orden de reproducción, por lo tanto se deben transcribir de forma adecuada y sincronizada con el vídeo para evitar la pérdida de coherencia.
• Tipografía: debe ser legible (como por ejemplo la Helvética o la Lucida grande), con un tamaño de fuente mediano (entre 18 y 22 pt) que optimice su lectura, con un interlineado sencillo, y que ocupen como máximo dos líneas de 35 o 37 caracteres en cada una de ellas. Debemos asegurarnos también que son compatibles y se visualizan correctamente tanto para Windows como Mac.
• Tiempo de exposición: Hay que tener en cuenta que los espacios en blanco, los signos de puntuación y los emoticonos, cuentan también como caracteres. Como regla general se define que se deberían mostrar entre 12 y 19 caracteres por segundo (52 milisegundos de exposición para un carácter y unas 150 palabras por minuto). En todo caso, no debería ser inferior a 0,7 para frases cortas (entre 10 y 12 caracteres).
• Textos: no se deben separar las palabras, mientras que las líneas deberán separarse preferiblemente cuando coincidan con comas, puntos, conjunciones o con las pausas que marque el personaje al hablar.
• Ubicación: centrados y en la parte inferior del vídeo. Si en el propio vídeo ya sale algún tipo de contenido en esa ubicación, los subtítulos se pondrían en la zona superior a estos.
• Contraste: deben tener un contraste suficiente con el vídeo, de tal forma que sean perfectamente legibles. Se recomienda el color blanco, amarillo, verde o cian sobre fondo negro.
• Si existen dos interlocutores, personajes, narradores o voz en off: cada uno de ellos tendrá un color diferente e identificativo, y el texto de cada uno de ellos deberá ocupar una línea.
• Si existen efectos sonoros: deberán describirse y mostrarse entre paréntesis cuando corresponda.
• Destellos y parpadeos: hay que tener en cuenta que los contenidos con parpadeos o destellos, pueden causan ataques de epilexia fotosensitiva a ciertos usuarios , por lo tanto hay que cumplir lo siguiente:
• Destellos: no se pueden provocar más de 3 por segundo a no ser que el área de destello sea inferior al 25% del área central de la visión del ojo (10 grados del campo visual).
• Parpadeo: como máximo puede durar 5 segundos.

Por qué modificar el valor de tabindex no es una buena idea

En Why using `tabindex` values greater than “0” is bad, Karl Groves realiza un análisis del uso del atributo tabindex en HTML:

Recently Tenon received a support request from a customer complaining that their site had thousands of issues in Tenon about their use of tabindex. The customer believed that their use of tabindex was a good thing because the tab order made sense. Here’s a cleaned-up version of the response I sent to them:

It creates maintenance headaches

The longer the tabindex values exist on the site, the more likely that maintenance of the site will cause the tabindex values to become inaccurate. Websites are never really “done”. Once they go into production, maintenance, changes, and bug fixes happen. Along the way, things move around, new links are added, old links are removed and over time someone slips and the tabindex values become out of sync with the desired interaction order.

It strips away user control

The use of an explicit tab order undermines the user’s ability to control their interaction with the site. Web pages that dictate an explicit tab order tend to do so for one of two reasons: to overcome a bad tab order or due to a misunderstanding of how the tab order should work. Using tabindex to fix a bad tab order is the wrong approach. Modifying DOM order so that the tab order matches the visual order might be difficult, but the pay off is much greater than using tabindex.

There’s another piece of using explicit tabindex that people often misunderstand when they use it: Users don’t just load up the site and start tabbing through the page. While sighted keyboard-only users might do this, the reality is that very few of the so-called “sighted keyboard-only users” truly use only the keyboard. People with motor impairments might do other things, such as use specialized pointing devices or voice dictation software. Depending on the UI and the tasks they’re there to perform, they might swap back and forth between voice dictation and keyboard. Or they might use their specialized pointing devices and keyboard.

Blind screenreader users don’t just load the page and start tabbing through it, either. Again, depending on the UI and the tasks they’re there to perform, they might pull up a list of headings on the page in order to see what the page is about. Or, they might even just hit “H” to get taken to the first heading on the page. In fact, I’d argue that they’re just as likely to hit the “H” key as they are to hit the “Tab” key as their first keystroke on the page.

It may cause a mismatch between visual order and interaction order

An element with an explicit tabindex value greater than “0” will receive keyboard focus before focusable elements with no tabindex value (or tabindex="0"). In other words, tabindex="0" says “put this in the tab order where it would normally occur based on its source order” while an explicit tabindex value greater than “0” causes the item to be placed at that number within the tab order (barring any gaps in the order, which will be ignored).

After tabbing through all of the things that have a tabindex greater than “0” the user will navigate to all other focusable elements in the order in which they appear in the DOM. In doing so, they will skip over the things that have already received focus. In some cases, this may cause a mismatch between the visual order and the focus order. For a sighted/ partially sighted keyboard-only user, this mismatch between what get focus vs. what they expect to get focus will be confusing.

It may make user support difficult

Last, an explicit tab order can cause frustration when doing user support. Customers with disabilities who reach out to the company for support may be given directions for workarounds that don’t match reality. Well-meaning support staff might say “The X-link is the 5th link on the page” when in reality it isn’t the 5th but something else.

We feel that the above reasons make it clear that tabindex creates more problems than it solves and that the use of tabindex should be avoided.

Accesibilidad de los diagramas de flujo realizados con SVG

En Accessible SVG flowcharts se explica cómo crear diagramas de flujo accesibles realizados con SVG.

Ejemplo de uso de un sistema de reconocimiento de voz

¿Se puede usar el ordenador solo con la voz? El siguiente vídeo lo muestra:



Además, este vídeo también tiene audiodescripción, es decir, aprovecha los silencios para explicar lo que se está viendo en la imagen. Y también tiene subtítulos. Y también una persona que interpreta el audio a la lengua de signos española. Con todo esto, el vídeo es accesible.

Un botón es un botón, un enlace es un enlace y lo demás no debe ser ni un botón ni un enlace

En You can’t create a button se explica un error de accesibilidad tremendamente común: tratar un enlace como si fuera un botón, un botón como si fuera un enlace, o cualquier otra cosa como un div o un span en un enlace o un botón.

Una buena accesibilidad no asegura que el sitio web sea también usable

Accesibilidad y usabilidad son cosas distintas, pero que también están relacionadas. En el artículo Websites and apps: How to make accessibility user-friendly se comentan algunos aspectos de esta relación de opuestos y semejantes que se atraen y repelen a la vez.

Nueva herramienta de accesibilidad de Firefox

Las herramientas de desarrollador del navegador Firefox han incorporado una nueva opción, Accessibility Inspector.

Esta herramienta permite acceder a la información de una página web que es expuesta a los productos de apoyo con los lectores de pantalla.

Resultados de la segunda encuesta dirigida a usuarios con baja visión

WebAIM ha publicado los resultados de su segunda encuesta dirigida a usuarios con baja visión: Survey of Users with Low Vision #2 Results.

Los resultados más interesantes son:

• 75% of respondents report multiple types of visual impairment. 61.3% have light or glare sensitivity and 46.8% have contrast sensitivity.
• 51.4% of respondents report using some type of high contrast mode. 71.2% of users that adjust page contrast prefer light text on a dark background.
• 45.2% of respondents use a screen reader, 48.4% screen magnification software, and 44% browser zoom controls. Other types of settings and AT are commonly used.
• JAWS is the most common screen reader, followed by NVDA and VoiceOver. Narrator is rarely used (.8%).
• Only 8% were detected as having increased the default text size. Very few respondents adjust paragraph, line, word, or letter spacing.
• 60.4% always or often use a keyboard for web page navigation. This is a very high number of users that rely on keyboard accessibility.
• 22% of respondents don’t enlarge web content, while 18% of respondents enlarge to over 400%.
• Dedicated screen magnification software is not highly common. Most users rely on OS settings for magnification.
• 64.3% use iOS devices. Only 7.8% don’t use a mobile device at all.

Los resultados de la primera encuesta se publicaron en mayo de 2013.

La Web y las personas sordociegas (2): Entrevista a Sonnia Margarita Villacrés

La Web y las personas sordociegas (1): Entrevista a Sonnia Margarita Villacrés

Los nuevos criterios de WCAG 2.1 para las personas con baja visión

En Understanding WCAG 2.1 – Reviewing Low Vision Success Criteria explican los nuevos criterios de WCAG 2.1 relacionados con la baja visión.

El artículo incluye un vídeo: