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:

Los nuevos criterios de WCAG 2.1 para las personas con discapacidad que acceden desde dispositivos móviles

En Understanding WCAG 2.1 – Reviewing Mobile Success Criteria se explican los nuevos criterios de WCAG 2.1 que tienen como objetivo mejorar la accesibilidad para las personas con discapacidad que acceden desde dispositivos móviles.

El artículo incluye un vídeo:

Los nuevos criterios de WCAG 2.1 para las personas con discapacidad cognitiva o del aprendizaje

En Understanding WCAG 2.1 – Reviewing Cognitive Success Criteria, se explican los nuevos criterios de WCAG 2.1 para mejorar la accesibilidad para las personas con discapacidad cognitiva o del aprendizaje.

El artículo incluye un vídeo:

Curso gratuito "Diseño accesible, diseño para todas las personas"

Según información que he recibido:

La Universidad de Jaén, con el apoyo de Fundación ONCE y el Real Patronato sobre Discapacidad, organiza el II curso Diseño accesible, diseño para todas las personas, que se impartirá online, abierto y con carácter gratuito. Se trata de un curso de capacitación, innovador y abierto, dirigido a todos los interesados en la accesibilidad universal y el diseño para todas las personas.

El curso pretende dar a conocer, desde una perspectiva general, el nuevo paradigma de accesibilidad universal y diseño para todas las personas; identificar los problemas de accesibilidad relacionados con los entornos físicos, virtuales y sociales; difundir buenas prácticas en la accesibilidad universal y el diseño para todas las personas en diferentes países latinoamericanos, y conocer la implicación del tercer sector en la facilitación de la aplicación del nuevo paradigma, el caso de Fundación ONCE.

Diseñando para las diferencias cognitivas

La introducción del artículo Designing for Cognitive Differences dice:

Inclusive design is designing to be inclusive of as many users as possible, considering all aspects of diversity in users. With increased understanding, compassionate discussions around how to design for disabilities are becoming increasingly common in the web industry. But even with this growth, there are misconceptions: accessibility is still frequently thought of as “design for blind people” when it’s so much more than that. Users with limited motor functions and those who are hearing-impaired require separate considerations, for instance. But accessibility and inclusiveness also mean considering more than just physical symptoms. What about users with cognitive differences like inattention, anxiety, and depression? 

Many affective and anxiety disorders qualify as disabilities, with inattention causing challenges on the web as well. Whatever the cause, inattention, anxiety, and depression can have a major impact on internet usage for users dealing with them. The unique issues presented by cognitive differences and the design considerations they require can be tricky to understand for people who have never dealt with them. Through this article, I’ll share some methods to accommodate these users’ unique needs.

Tú no tienes problemas de accesibilidad, tienes problemas de calidad

Visto hace pocos días en Twitter, una fotografía de una presentación de Karl Groves:

Los límites de las herramientas automáticas

Muy interesante el artículo The Power (and Limits) of Automated Accessibility Testing:

For WCAG 2.0 AA conformance testing (the generally-accepted goal for accessibility compliance) automated tests represent only 10 percent of our test plan, 6 percent when you factor in tests across multiple browsers or screen readers.
[...]
Automation is a good way to tell if "something" is wrong, but it won't find all the compliance issues on a site, especially a complex one. There are only two WCAG 2.0 guidelines that we rely on automation alone to test: Page Titled and Parsing. All other guidelines may require manual review depending on the setup of your site.
[...]
What does automation miss? It's terrible at simulating keyboard and screen reader navigation, which may mean that a site passes automation but can't be used at all by someone with motor or visual disabilities. (We see that a lot.) Automation is terrible at telling what you can see when the site is zoomed. It can't tell where you need headers, or if a link has a clear enough description, or if you're moving around a navigation element that needs to be in a predictable place. Automation can't tell if you're relying on color to indicate something a color blind user won't be able to see. It's terrible with error messages, because it isn't entering anything into your forms. It won't tell you if your captcha makes your form impossible for a screen reader user to submit. Automation probably won't bother testing your site in a mobile view.
Automation should be your first attack. It's ours. But it's not enough. Don't trust anyone who tries to convince you it is. Double check the site with a free screen reader like VoiceOver or NVDA, tab through it with your keyboard, zoom in and see what happens. It’s the users of your site, not the robots, that need accessibility.

Curso gratuito "Digital Accessibility: Enabling Participation in the Information Society"

Un curso gratuito, de tipo MOOC, sobre accesibilidad digital: Digital Accessibility: Enabling Participation in the Information Society.

El contenido del curso es:

• What is digital accessibility?
• Digital accessibility and business
• Relationship between ‘usability’, ‘accessibility’ and ‘user experience’
• Challenges and barriers met by disabled people
• Video and audio barriers and subtitles, captioning and audio description
• Desktop, laptop, mobile and self-service terminal accessibility
• Creating, checking and evaluating document, web and self-service terminal accessibility
• Input and output devices e.g. screen reader, Braille, switch access technologies
• Digital and web accessibility guidelines, standards and principles of Universal Design

"personas con discapacidad", expresión recomendada

Hace un par de días, Fundéu publicó la aclaración personas con discapacidad, expresión recomendada:

La expresión personas con discapacidad es la preferible para referirse a aquellas personas que tienen algún tipo de limitación física, intelectual o sensorial.

Según la Convención Internacional sobre los Derechos de las Personas con Discapacidad de la Organización de la Naciones Unidas, personas con discapacidad es la expresión adecuada para referirse a quienes «tengan deficiencias físicas, mentales, intelectuales o sensoriales a largo plazo que, al interactuar con diversas barreras, puedan impedir su participación plena y efectiva en la sociedad, en igualdad de condiciones con las demás».

Como se ve en esa convención y en los documentos de las organizaciones que representan a estas personas, se prefiere en general la fórmula persona con discapacidad al uso del sustantivo discapacitado, que, si bien no es reprochable desde el punto de vista lingüístico, supone aludir a la persona por una sola de sus características, en este caso la discapacidad.

Tampoco se recomienda la voz minusválido, utilizada durante mucho tiempo y aún presente en documentos y trámites diversos. Aunque se trata de una palabra correctamente formada, se desaconseja su uso en los medios de comunicación, ya que en la actualidad se interpreta, en especial por los colectivos citados, como peyorativa. 

Asimismo se desaconsejan palabras o expresiones con matiz claramente despectivo (como anormal, subnormal, deficiente, incapaz, inválido, impedido), así como las que denotan sufrimiento (como sufre, padece o arrastra una discapacidad).

Sobre el uso correcto del lenguaje he escrito un par de veces en el pasado:

• ¿Minusválido, inválido, disminuido, incapacitado o discapacitado? (12/1/2006)
• People-first language (8/10/2013)
• Cómo escribir con un lenguaje inclusivo (19/9/2014)
• Guía de Lenguaje Positivo y Comunicación Incluyente (23/10/2017)
• Guía APA el uso de lenguaje no discriminatorio e inclusivo (6/11/2017)

Qué esperar de WCAG 2.1

WCAG 2.1 se publicó en junio de 2018, ya no es algo nuevo, pero vale la pena releer cosas como Understanding WCAG 2.1: What to Expect, donde se explican las novedades de WCAG 2.1.

El artículo incluye un vídeo:

Chrome DevTools Accessibility Reference

En Accessibility Reference se explica el funcionamiento del módulo de revisión de la accesibilidad web que existe en Chrome DevTools:

Centro de Normalización Lingüística de la Lengua de Signos Española

El Centro de Normalización Lingüística de la Lengua de Signos Española  (CNLSE) tiene como objetivo:

que todas las personas, independientemente de tener una discapacidad, de la edad o de acceder a la web desde tecnologías poco convencionales, puedan navegar por las páginas de este sitio web sin encontrar dificultades de acceso.

Sin embargo, una vez más, en casa del herrero, cuchara de palo, y el sitio web de CNLSE no es accesible para todas las discapacidades. Digo una vez más porque ya escribí sobre este problema, pero de otro sitio web, en Unas personas con discapacidad que se olvidan del resto de las personas con discapacidad.

En la siguiente imagen podemos ver cómo se han olvidado de poner un texto alternativo correcto en las imágenes del panel de navegación de la izquierda:

En concreto, han puesto:

• "Imagen del banner" en el title del enlace.
• "Imagen del banner" en el title de la imagen.
• "Imagen del banner" en el alt de la imagen.

Publicado el libro "Formación básica de NVDA"

En Libro “Formación básica de NVDA” podemos leer:

El libro oficial de formación básica de NVDA, que incluye conceptos que van desde los primeros pasos para empezar con Windows y NVDA hasta explorar la web o usar el navegador de objetos (ebook, publicado el 14 de junio de 2018).
El libro de formación básica de NVDA es el primer módulo del conjunto oficial de material de formación de NV Access para aprender a usar el lector de pantalla libre NVDA. Ideal para nuevos usuarios o usuarios existentes que quieran mejorar sus habilidades.
Entre los temas incluidos se encuentran: primeros pasos con NVDA y Windows, configuración básica, redacción y edición de texto, formateado de documentos, gestión de archivos, multitarea, exploración de la web, y utilización del cursor de revisión y el navegador de objetos. Formatos incluidos en el paquete: ePub, HTML, Docx (Microsoft Word) y KFX (Amazon Kindle).
Al adquirir el libro de nuestra web, ayudas a mantener la comunidad de NVDA en español y permites que podamos descubrir complementos, traducir documentación y ofrecer un punto de encuentro único y robusto para todos los usuarios de habla hispana de NVDA.
Si quieres ver algunas muestras del libro antes de animarte a comprarlo, te dejamos el capítulo 1, con la introducción, y el capítulo 12, que habla sobre el cursor de revisión.

Cursos en línea sobre accesibilidad web

Algunos cursos sobre accesibilidad web:

Web Accessibility

Start Building Accessible Web Applications Today

Web Accessibility for Developers

Professional Web Accessibility Auditing Made Easy

Digital Accessibility: Enabling Participation in the Information Society

Webinar "Usabilidad y accesibilidad en la enseñanza online: Plataformas y recursos de aprendizaje fáciles de usar y para todos"

La Universidad Internacional de Andalucía organiza el webinar Usabilidad y accesibilidad en la enseñanza online: Plataformas y recursos de aprendizaje fáciles de usar y para todos (Webinar) el próximo 15 de octubre. Su contenido es:

1. ¿Qué es la usabilidad?
2. El papel de la usabilidad en la docencia online: Plataformas y contenidos
3. Principales barreras de usabilidad en el aprendizaje online.
4. Más allá de la usabilidad: Mejorando la experiencia de usuario en el aprendizaje en línea
5. Accesibilidad y diseño para todos en la docencia y aprendizaje online
6. Técnicas rápidas de evaluación de la usabilidad y accesibilidad.

Sématos

Sématos es un banco de palabras y expresiones en la lengua de signos alemana, catalana, española, francesa e internacional.

Este sitio web incluye secciones organizadas por temas, por ejemplo informática.

Herramienta para evaluar la accesibilidad de todo un sitio web

Dinolytics es una nueva herramienta, basada en WAVE de WebAIM, que permite evaluar la accesibilidad de todo un sitio web.

Nueva herramienta para evaluar el contraste del color de los enlaces

El WebAIM ha lanzado una nueva herramienta para evaluar el contraste del color de los enlaces:

Link Contrast Checker

La explicación de la necesidad de esta nueva herramienta se encuentra en:

• Understanding WCAG 2 Contrast and Color Requirements
• WCAG 2.0 and Link Colors

Diseño accesible, universal o inclusivo, ¿es lo mismo?

En el artículo The Same, But Different: Breaking Down Accessibility, Universality, and Inclusion in Design explican las diferencias y semejanzas de tres términos relacionados, accesible, universal e inclusivo:

Accessibility is a goal
We use the term accessibility to describe a vast network of activity, but, in the most basic terms, when we talk about a site or an app, we describe its progress toward accessibility in basic terms — it’s good, it’s bad, it’s ugly. The goal of everyone I know in the accessibility community is to make things better for as large an audience as possible. So here’s definition number one:

Accessibility is the goal to ensure that products support each individual user’s needs and preferences.


Universal design is for everyone, literally
Universal design is the design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design.


Inclusive design expands with your audience
Unlike universal design, there are not yet generally agreed-upon definitions for inclusive design, or the practices it encompasses. Some attempts borrow heavily from the above definition of universal design. Some are more mission statements than definitions. Some are explicitly connected with disability, while others are broader in scope. All of them have some value, in that they confront the reader with the idea that it is always within their capacity to do more.

The definition of inclusive design that I identify most with comes from the Inclusive Design Research Centre at OCAD U in Toronto:

We have defined Inclusive Design as: design that considers the full range of human diversity with respect to ability, language, culture, gender, age and other forms of human difference.

Inclusive design is a term that leads people to think about an expanding audience, with expanding wants and needs, which, in turn, gives them more to think about as they design products. When I say, “I’m working on inclusive design,” I get substantially fewer blank stares than when I said, “I work on accessibility.” More often than not, the connection to the needs of people with disabilities comes through on its own.

Accesibilidad al 90%

Visto en Twitter en un mensaje de la Fundación Once:

La accesibilidad web a veces se queda así, a medias.

Lenguaje inclusivo

En Teaching Students with Disabilities se puede leer:

In order to create an inclusive classroom where all students are respected, it is important to use language that prioritizes the student over his or her disability. Disability labels can be stigmatizing and perpetuate false stereotypes where students who are disabled are not as capable as their peers.  In general, it is appropriate to reference the disability only when it is pertinent to the situation. For instance, it is better to say “The student, who has a disability” rather than “The disabled student” because it places the importance on the student, rather than on the fact that the student has a disability.

En Disability Language Style Guide y Terms to Avoid When Writing About Disability se puede encontrar más información sobre los términos que se puede o no se puede usar.

Compatibilidad de WAI-ARIA y los lectores de pantalla

En WAI-ARIA - Screen reader compatibility han recogido información sobre la compatibilidad de WAI-ARIA con los lectores de pantalla más populares:

La mejor combinación es JAWS con Internet Explorer 11.

Making Accessible Web Apps Using HTML5 and ChromeVox

Un excelente vídeo, Making Accessible Web Apps Using HTML5 and ChromeVox:

Entrevista a Santi Trigueros, una persona sordociega (parte 3)

Real Decreto 1112/2018, de 7 de septiembre, sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público

Ayer se publicó en el Boletín Oficial del Estado el Real Decreto 1112/2018, de 7 de septiembre, sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público.

Este Real Decreto surge a partir de la Directiva (UE) 2016/2102 del Parlamento Europeo y del Consejo, de 26 de octubre de 2016, sobre la accesibilidad de los sitios web y aplicaciones para dispositivos móviles de los organismos del sector público, que tiene como objetivo (artículo 1):

La presente Directiva tiene por objeto aproximar las disposiciones legales, reglamentarias y administrativas de los Estados miembros relativas a los requisitos de accesibilidad de los sitios web y aplicaciones para dispositivos móviles de los organismos del sector público, permitiendo así que dichos sitios y aplicaciones sean más accesibles para los usuarios, en particular para las personas con discapacidad.

El artículo 2 indica a quién se aplica:

Artículo 2. Ámbito subjetivo.

1. Este real decreto se aplica al sector público que comprende:
a) La Administración General del Estado.
b) Las Administraciones de las comunidades autónomas.
c) Las entidades que integran la Administración Local.
d) El sector público institucional, en los términos establecidos en el artículo 2.2 de
la Ley 39/2015, de 1 de octubre, del Procedimiento Administrativo Común de las
Administraciones públicas
e) Las asociaciones constituidas por las Administraciones, entes, organismos y
entidades que integran el sector público.

2. Lo dispuesto en este real decreto también será de aplicación a la Administración
de Justicia.


El artículo 3 indica a qué se aplica:

Artículo 3. Ámbito objetivo de aplicación.

1. Este real decreto se aplica tanto a los sitios web, independientemente del
dispositivo empleado para acceder a ellos, como a las aplicaciones para dispositivos
móviles de los organismos del sector público y otros obligados incluidos en el ámbito de
aplicación del artículo 2.

2. El contenido accesible de los sitios web y de las aplicaciones para dispositivos
móviles incluye la información tanto textual como no textual, los documentos y formularios
que se pueden descargar, los contenidos multimedia pregrabados de base temporal, las
formas de interacción bidireccional, el tratamiento de formularios digitales y la
cumplimentación de los procesos de identificación, autenticación, firma y pago con
independencia de la plataforma tecnológica que se use para su puesta a disposición del
público.

3. Están excluidos de este real decreto y se regularán por su normativa específica
los contenidos multimedia en directo y pregrabado de base temporal de los sitios web y
aplicaciones para dispositivos móviles de prestadores del servicio público de
radiodifusión y sus filiales, así como los de otros organismos o sus filiales que cumplan
un mandato de servicio público de radiodifusión.

4. Asimismo, quedan excluidos del ámbito de aplicación del presente real decreto
los siguientes contenidos:
a) Formatos de archivo de ofimática publicados antes de la entrada en vigor de este
real decreto, salvo que los mismos sean necesarios para tareas administrativas activas
relativas a las funciones realizadas por los sujetos obligados por este real decreto.
b) Contenido multimedia pregrabado de base temporal publicado antes de la
entrada en vigor de este real decreto.
c) Contenido multimedia en directo de base temporal salvo lo dispuesto en otra
legislación específica que obligue al respecto.
d) Servicios de mapas y cartografía en línea, siempre y cuando la información
esencial se proporcione de manera accesible digitalmente en el caso de mapas
destinados a fines de navegación.
e) Contenidos de terceros que no estén financiados ni desarrollados por el sujeto
obligado ni estén bajo su control.
f) Reproducciones de bienes de colecciones del patrimonio que no puedan hacerse
plenamente accesibles por alguna de las siguientes causas:
1.° Incompatibilidad de los requisitos de accesibilidad con la conservación del bien
de que se trate o con la autenticidad de la reproducción.
2.° Indisponibilidad de soluciones automatizadas y rentables que permitan extraer
el texto de manuscritos u otros bienes de colecciones del patrimonio y transformarlos en
contenidos compatibles con los requisitos de accesibilidad.
g) Contenidos de extranet e intranet entendidos como sitios web accesibles
únicamente para un grupo restringido de personas y no para el público en general,
publicados antes del 23 de septiembre de 2019, hasta que dichos sitios web sean objeto
de una revisión sustancial.
h) Contenidos de sitios web y aplicaciones para dispositivos móviles que tengan la
condición de archivos o herramientas de archivo por contener únicamente contenidos no
necesarios para el desarrollo de cualesquiera tareas administrativas activas, siempre que
no hayan sido actualizados ni editados con posterioridad a la entrada en vigor de este
real decreto.

El artículo 6 indica los requisitos que se deben cumplir:

Artículo 6. Presunción de conformidad con los requisitos de accesibilidad.

1. Se presumirá que el contenido de los sitios web y aplicaciones para dispositivos
móviles que cumpla las normas armonizadas o partes de éstas cuyas referencias hayan
sido publicadas en el «Diario Oficial de la Unión Europea» es conforme a los requisitos
de accesibilidad establecidos en el artículo 5 que estén cubiertos por dichas normas o
partes de ellas.

2. En caso de que no se hayan publicado las referencias de las normas
armonizadas a que se refiere el apartado 1, se presumirá que el contenido de las
aplicaciones para dispositivos móviles que cumpla las especificaciones técnicas o partes
de éstas, que la Comisión haya adoptado mediante los correspondientes actos de
ejecución, es conforme a los requisitos de accesibilidad establecidos en el artículo 5 que
estén cubiertos por dichas especificaciones técnicas o partes de ellas.

3. En caso de que no se hayan publicado las referencias de las normas
armonizadas a que se refiere el apartado 1, se presumirá que el contenido de los sitios
web que cumpla los requisitos pertinentes de la norma EN 301 549 V1.1.2 (2015-04) o
partes de estos, es conforme a los requisitos de accesibilidad establecidos en el
artículo 5 que estén cubiertos por dichos requisitos o partes de ellos.
En caso de que no se hayan publicado las referencias de las normas armonizadas a
que se refiere el apartado 1, y en ausencia de las especificaciones técnicas a que se
refiere el apartado 2, se presumirá que el contenido de aplicaciones para dispositivos
móviles que cumpla los requisitos pertinentes de la norma EN 301 549 V1.1.2 (2015-04)
o partes de estos, es conforme a los requisitos de accesibilidad establecidos en el
artículo 5 que estén cubiertos por dichos requisitos o partes de ellos.

4. Se aplicarán directamente las actualizaciones de referencias a la norma EN 301
549 V1.1.2 (2015-04) que la Comisión adopte mediante actos delegados para hacer
referencia a una versión más reciente de dicha norma o a una norma europea que la
sustituya.

5. El órgano encargado de realizar el seguimiento y presentación de informes ante
la Comisión Europea mantendrá disponible en su sitio web la referencia concreta a las
normas armonizadas, normas y especificaciones técnicas que sean de aplicación en
cada momento.


La disposición final quinta indica cuándo entrará en vigor:

Disposición final quinta. Entrada en vigor.
El presente real decreto entrará en vigor el día siguiente al de su publicación en el
«Boletín Oficial del Estado» con las siguientes excepciones:

Para los sitios web, las disposiciones previstas en los artículos 10.2.b), 12 y 13 serán
de aplicación al año de la entrada en vigor de este real decreto, y a los dos años para los
sitios web ya publicados.

Todas las disposiciones relativas a aplicaciones para dispositivos móviles serán de
aplicación desde el 23 de junio de 2021.

Entrevista a Santi Trigueros, una persona sordociega (parte 2)

Entrevista a Santi Trigueros, una persona sordociega (parte 1)

¿Nueva página del Congreso de los Diputados?

El pasado viernes 7 de septiembre se publicó en el Boletín Oficial del Estado el Anuncio del Congreso de los Diputados de formalización del contrato de servicios para el desarrollo de una página web y la infraestructura que la debe soportar para el Congreso de los Diputados.

El anuncio dice:

Objeto del contrato:

a) Tipo: Servicios.

b) Descripción: Servicios para el desarrollo de una página web y la

infraestructura que la debe soportar.

g) Medio de publicación del anuncio de licitación: DOUE, BOCG, BOE y Perfil

del Contratante.

h) Fecha de publicación del anuncio de licitación: 28/11/2017

5. Presupuesto base de licitación. Importe total: 1.846.218,79 euros.

6. Formalización del contrato:

a) Fecha de adjudicación: 25/07/2018.

b) Fecha de formalización del contrato: 29/08/2018.

c) Contratista: Grupo Corporativo GFI Informática, S.A.

d) Importe o canon de adjudicación: Importe total: 1.597.051,36 euros.

Un millón y medio de euros para el desarrollo de una página web, ¿una página web? Un poco cara, ¿no?

Habrá que investigar más este contrato, ¿estará la accesibilidad web en la lista de requisitos a cumplir? ¿Se les habrá olvidado?

Real Decreto para mejorar la accesibilidad a los sitios web y aplicaciones para dispositivos móviles del sector público

El pasado viernes 7 de septiembre, el Consejo de Ministros aprobó un Real Decreto para mejorar la accesibilidad a los sitios web y aplicaciones para dispositivos móviles del sector público. Este Real Decreto "garantiza la igualdad y no discriminación de acceso a toda la ciudadanía, en particular a las personas con discapacidad y a las personas mayores".

Este Real Decreto "traspone al ordenamiento jurídico español la Directiva (UE) 2016/2102 del Parlamento Europeo y del Consejo, de 26 de octubre de 2016, sobre la accesibilidad de los sitios web y aplicaciones para dispositivos móviles de los organismos del sector público".

Al gobierno español "le ha pillado el toro" una vez más, porque el plan establecía julio 2018 para que los países de la Unión Europea trasladasen la directiva europea al marco legislativo de cada país.

Más información en Luz verde al real decreto sobre accesibilidad de las web y apps para dispositivos móviles del sector público.

2acces

Según el sitio web de 2acces:

2ACCES es una herramienta creada para la integración de las personas sordas. Este software facilita la accesibilidad para poder estar en igualdad de condiciones con el resto de los usuarios de cualquier sala.
Funciona mediante un software que transcribe en tiempo real todo lo que una persona comunica oralmente.


Este no es el primer sistema que conozco con esta funcionalidad, otros dos gratuitos son Web Captioner y Voice Dictation.

Segunda encuesta del WebAIM dirigida a usuarios con baja visión

El WebAIM ha lanzado la encuesta Survey of Users with Low Vision #2. Esta encuesta está destinada a los usuarios con baja visión y estará abierta hasta el 30 de septiembre de 2018.

La primera encuesta se celebró en el año 2013 y los resultados no fueron concluyentes.

Curso gratuito "Web Accessibility for Developers"

El 24 de septiembre comienza el curso Web Accessibility for Developers:

• Understanding WAI-ARIA (What is does and does not do)
• WCAG 2 and WAI-ARIA
• WAI-ARIA relation to HTML 5
• Static vs dynamic WAI-ARIA
• Cross browser support for WAI-ARIA
• Screen reader compatibility (JAWS, NVDA, ChromeVox)
• Screen reader testing for WAI-ARIA
• WAI-ARIA validation tools
• WAI-ARIA roles, states, and properties
• Navigation with WAI-ARIA landmarks
• Live regions, alerts, and message dialogs
• WAI-ARIA libraries
• WAI-ARIA application and presentation roles
• Keyboard interaction for WAI-ARIA enabled widgets and applications
• WAI-ARIA for toggle buttons, progress bars, suggestion forms, and tooltips
• WAI-ARIA for sliders, accordions, tab panels, and carousels
• WAI-ARIA for menu bars, tree menus, and sortable drag and drop lists

Mauve

Mauve es una herramienta de revisión de la accesibilidad web de origen italiano.

He analizado con ella la accesibilidad de mi sitio web y me saca un error muy raro:

La técnica H50 no la conozco y no la encuentro en Techniques for WCAG 2.0. ¡Esa técnica no existe!

Existía en versiones anteriores: H50: Using map to group links. Pero eso de usar map para agrupar enlaces como un elemento de navegación nunca lo había visto. Así que, esta herramienta de evaluación automática de la accesibilidad web no sé si es de fiar.

Denuncia por falta de accesibilidad contra Apple

En Apple sued over claims website is inaccessible to visually impaired users, se explica que Apple ha sido denunciada en Estados Unidos porque su sitio web no es accesible para las personas ciegas o con baja visión:

Filed in the U.S. District Court of the Southern District of New York on Sunday, the complaint from the plaintiff Himelda Mendez is said to be filed on behalf of other users in a similar accessibility situation. Apple is the sole defendant in the lawsuit.

According to the filing, Mendez is described as a "visually impaired and legally blind person" who uses screen-reading software to access the internet. The software is able to either read out information seen on the screen or outputs it to a refreshable Braille display, and typically relies on the website being constructed in ways that it can read the contents.

In the case of a website that isn't produced in this way, such as one that doesn't follow the Web Content Accessibility Guidelines from the World Wide Web Consortium, the readers may be unable to read content that could be useful for the user, or read it in an unintentional way that would be difficult to parse.

Mendez, said to be a proficient user of the Jobs Access With Speech (JAWS) screen reading program, visited the Apple website earlier this month but encountered "multiple access barriers" that denied "full and equal access to the facilities, goods, and services offered to the public," such as being able to browse and purchase products, make service appointments, or learn of the facilities available in Apple Stores in New York, the city where Mendez is resident.

The filing provides a long list of issues with the website that it believes needs fixing, in order to comply with the ADA, in relation to screen readers. The list includes the lack of alternative text for graphics, empty links containing no text, redundant links, and linked images missing alternative text.

It is asserted these issues caused a denial of "full and equal access" to the plaintiff, deterring future use of the site in the process. If it were fully accessible, the filing believes those using screen-reading software would be able to independently navigate the site and perform the same transactions as those with sight.

It is also alleged the lack of compliance with WCAG 2.0 guidelines means Apple has "engaged in acts of intentional discrimination," under the belief the site was not produced with visually-impaired individuals in mind, nor has it been corrected.

The suit demands a permanent injunction requiring Apple to retain a qualified consultant to help the company comply with WCAG 2.0 guidelines for the site, including training its web developers on accessibility compliance, regularly checking the site's compliance, regular testing by blind and visually-impaired users, and the development of an accessibility policy posted on all of its websites. Also sought are "compensatory damages in an amount to be determined by proof, including all applicable statutory and punitive damages and fines," plus legal fees incurred by the filer.

AppleInsider has asked Apple for comment, and will provide an update if there is a response.

Apple prides itself on including accessibility features in its products, highlighting them in marking Global Accessibility Awareness Day each year. The company has also worked with other companies and organizations in producing accessibility aids, including developing a hearing implant sound processor with Cochlear, and participating in the USB Implementers Forum to produce a new interface standard for braille displays.

Atajos de teclado de NVDA

Una buena referencia que ocupa una sola página, NVDA Keyboard Commands
Quick Reference Guide:

Un sitio web es accesible cuando es accesible para todas las discapacidades

Un error muy común que muchas veces he notado es pensar centrarse en resolver los problemas de accesibilidad para solo unos tipos de discapacidad.

En el año 2015 escribí la entrada Unas personas con discapacidad que se olvidan del resto de las personas con discapacidad en la que comentaba que el sitio web de la Confederación Estatal de Personas Sordas no era accesible para otras discapacidades.

Tres años después, ¿este sitio web es accesible?

Tres años después este sitio web sigue con los mismos problemas, por ejemplo:

Un captcha en el formulario de contacto:

Imposibilidad de navegar con el teclado porque no se muestra el foco de los elementos de la interfaz, ¿cuál de los siguientes botones tiene el foco?

Enlaces y botones que realmente no lo son, ¿por qué la siguiente botonera son imágenes sin texto alternativo y con el evento onclick?

Evaluación semisupervisada de sitios web

Un sitio web puede tener miles o incluso millones de páginas web. ¿Cómo se puede evaluar la accesibilidad de todo un sitio web? Es una tarea desafiante.

En el artículo Using Semi-supervised Group Sparse Regression to Improve Web Accessibility Evaluation se presenta una posible solución:

Web accessibility evaluation checks the accessibility of the website to help improve the user experiences for disabled people. Due to the massive number of web pages in a website, manually reviewing all the pages becomes totally impractical. But the complexities of evaluating some checkpoints require certain human involvements. To address this issue, we develop the semi-supervised group sparse regression algorithm which takes advantages of the high precision of a small amount of manual evaluation results along with the global distribution of all the web pages and efficiently gives out the overall evaluation result of the website. Moreover, the proposed method can tell the importance of each feature in evaluating each checkpoint. The experiments on various websites demonstrate the superiority of our proposed algorithm.

Lo que pasa cuando usas el teclado por un día

En I Used The Web For A Day With Just A Keyboard, una persona explica lo que descubrió cuando estuvo todo el día navegando por la Web solo con el uso del teclado. Su resumen final es:

This experiment has been a mixed bag of great keyboard experiences and poor ones. I have three main takeaways.

KEEP IT STYLISH
By far the most common keyboard accessibility issue I’ve faced today is a lack of focus styling for tabbable elements. Suppressing native focus styles without defining any custom focus styles makes it extremely difficult, even impossible, to figure out where you are on the page. Removing the outline is such a common faux pas that there’s even a site dedicated to it.

Ensuring that native or custom focus styling is visible is the single most impactful thing you can do in the area of keyboard accessibility, and it’s often one of the easiest; a simple case of doubling up selectors on your existing :hover styling. If you only do one thing after reading this article, it should be to search for outline: 0 and outline: none in your CSS.

SEMANTICS ARE KEY
How many times have you tried opening a link in a new tab, only for your current window to get redirected? It happens to me every now and again, and annoying as it is, I’m lucky that it’s one of the only usability issues I tend to face when I use the web. Such issues arise from misusing the platform.

CONTENT IS KEY
You may be required to display cookie notices, subscription forms, adverts or adblock notices.

Do what you can to make these experiences unobtrusive. If you can’t make them unobtrusive, at least make them dismissible.

Users are there to see your content, not your banners, so put these dismissible elements first in your DOM so that they can be quickly dismissed, or fall back to using tabindex="1" if you can’t move them.

Finally, support your users in getting to your content as quickly as they can, by implementing the Holy Grail of ‘skip to main content’ links.

Creación de formularios accesibles

Los formularios en las páginas web suelen tener graves problemas de accesibilidad. ¿Por qué? ¿Será porque es difícil? No, normalmente es porque la gente no sabe hacer bien las cosas.

En Anatomy of Creating Accessible Forms: Practice the best se ofrecen algunos consejos:

In today’s post we will go through all the ingredients of creating an accessible form that provides the best user experience for all the users. We will go through each aspect of creating an accessible form & understand why a particular step is important & how it affects people with disabilities or users in general.

WebAIM's WCAG 2 Checklist

WebAIM ha actualizado su WCAG 2 Checklist para que incluya las novedades de WCAG 2.1. La lista de verificación de WebAIM explica de una forma más sencilla los criterios de WCAG.

Herramientas gratuitas para convertir voz en texto

Hace unos días, el periódico El País publicó Cuatro herramientas gratuitas para convertir voz en texto:

Cada vez es menos habitual usar el teclado del móvil. Basta con echar un vistazo alrededor para comprobar el auge de las notas de voz frente a los mensajes de texto o las nuevas formas de preguntar a Google desde estos dispositivos. En concreto, comsCore vaticina que en 2020 la mitad de las búsquedas en Internet se harán con la voz, algo para lo que contaremos con la ayuda de asistentes personales como Siri, Sherpa, Google Now, Amazon Echo o Cortana. 

Bastará con dar una orden con la voz para obtener al instante lo que queremos, sin tener que escribir esa petición. Ahora bien, de momento estos asistentes pueden quedarse cortos si necesitamos dictarles textos para ser más rápidos a la hora de redactar largos emails, preparar discursos o ponencias o incluso transcribir automáticamente mensajes de voz (por ejemplo, la grabación de una charla que queremos tener por escrito). Para este tipo de casos, existen aplicaciones web gratuitas, basadas en tecnología de Google, que es posible utilizar sin tener que instalarlas y que además cumplen con su cometido: transformar voz en texto de forma automática. 

Eso sí, conviene repasar el texto final para pulirlo o corregir posibles errores, porque aunque estas herramientas cada vez están más afinadas y también se presentan como “asistentes personales”, al fin y al cabo siguen siendo máquinas. Además, al estar basadas en Google, sólo funcionan correctamente si utilizamos el navegador de esta compañía, es decir, Chrome.

Las herramientas son:

• Google Docs
• Dictation
• Speechnotes
• Speechlogger Personal

Algunas herramientas de evaluación automática de la accesibilidad web

En Web Accessibility Evaluation Tools List hay un listado actualizado de las herramientas automáticas de evaluación de la accesibilidad web. Algunas herramientas que acabo de descubrir son:

• AccessMonitor
• European Internet Inclusion Initiative del proyecto Tingtun.
• Vamolà

Orbit Reader 20, anotador braille de bajo costo

En Orbit Reader 20, ya está disponible el esperado y asequible anotador con teclado estilo Perkins y línea Braille patrocinado por la TBG se explica:

Os presentamos un revolucionario, asequible y portátil anotador Braille con teclado estilo Perkins y una línea Braille de 20 celdas dinámicas que se ha desarrollado gracias a la unión de la TBG (Transforming Braille Group) y Orbit Research. Un dispositivo que levantó muchas expectativas cuando se presentó hace algo más de dos años, pero que hasta este verano del 2018 no se ha empezado a comercializar a un precio realmente interesante, 449$. En efecto. Habéis leído bien. Orbit Reader 20 se ha desarrollado con el objetivo de conseguir un producto económico, compacto y sencillo, pero con una funcionalidad y conectividad más que satisfactorias que permitan acceder a la educación y a la información a todas aquellas personas que no se pueden permitir el alto coste de las líneas Braille tradicionales.

La página oficial del anotador es Orbit Reader 20.

El tamaño de los controles y los enlaces

En Web Content Accessibility Guidelines (WCAG) 2.1 podemos leer:

Success Criterion 2.5.5 Target Size
(Level AAA)
The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when:

• Equivalent: The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels;
• Inline: The target is in a sentence or block of text;
• User Agent Control: The size of the target is determined by the user agent and is not modified by the author;
• Essential: A particular presentation of the target is essential to the information being conveyed.

Este criterio ayuda a los usuarios con discapacidad motora que carezcan de un buen control, que necesitan un área de interacción con suficiente tamaño en los enlaces y los controles de los formularios.

Un área de interacción de tamaño adecuado también puede ser útil para quienes utilizan pantallas pequeñas o de alta resolución. WCAG 2.1 sugiere que el área sea de un mínimo de 44 x 44 píxeles para los elementos interactivos.

Principios de diseño inclusivo

Inclusive Design Principles presenta unos principios a tener en cuenta cuando se quiera hacer un diseño inclusivo:

• Provide comparable experience
• Consider situation
• Be consistent
• Give control
• Offer choice
• Prioritise content
• Add value

Todos estos principios se pueden resumir en "poner a las personas lo primero":

These Inclusive Design Principles are about putting people first. It's about designing for the needs of people with permanent, temporary, situational, or changing disabilities — all of us really.

Adiós a las abreviaturas y acrónimos en los sitios web oficiales del Reino Unido

Hace unos días se publicó la noticia Goodbye, etc: why the UK government will stop using Latin abbreviations online:

RIP eg, ie and etc. Henceforth the three abbreviated Latin phrases – which stand for exempli gratia (for the sake of example), id est (that is) and et cetera (and the rest) – will stop being used on Britain’s .gov.uk websites. Eventually they will be replaced in toto by English alternatives such as such as, that is, and so on and so on.

En WCAG 2.1, el criterio de éxito 3.1.4 Abbreviations está dedicado a este problema:

(Level AAA)
A mechanism for identifying the expanded form or meaning of abbreviations is available.

inSuit, competencia de Inclusite

A través de la noticia El Ayuntamiento de Alcalá de Henares instala en su web una herramienta de accesibilidad me he enterado de la existencia de inSuit, un producto similar a Inclusite:

La mejora de la navegación con la herramienta Insuit está destinada a personas con disminución o falta de visión, dificultad o falta de movilidad en manos y brazos, incluso cuando están combinadas con dificultades para el habla o discapacidad cognitiva/intelectual. También se ha hecho más sencilla la navegación para personas mayores con dificultades para la lectura o con pocas capacidades digitales. 

Para la concejala de Transparencia, Brianda Yáñez, "es una prioridad la accesibilidad universal a los servicios municipales, un condicionante para garantizar los derechos de todas las personas sea cual sea su situación. Las herramientas digitales se están implantando a gran velocidad pero deben ser accesibles para no generar más barreras sino todo lo contrario, debemos lograr que sean facilitadoras". 

La puesta en funcionamiento de esta nueva herramienta facilitará además la navegación de todas las personas usuarias de la web, que podrán establecer algunas preferencias a la hora de consultar los contenidos. 

El usuario de la página sólo tiene que utilizar el enlace o pestaña habilitada en la página web para la activación de inSuit y tiene acceso instantáneo al conjunto de herramientas para la navegación, con un intuitivo sistema de configuración, una sencilla barra que permite adaptar las ayudas a sus necesidades y preferencias.

[Actualización 29/11/2018]

El Ayuntamiento de Elche también lo tiene instalado:

Deja de usar PDF en las páginas web

Por fin alguien dice algo que llevaba tiempo queriendo leer: deja de usar PDF en las páginas web.

En los últimos años, el uso y abuso de PDF para publicar contenido en los sitios web es impresionante. Y es un error, porque una cosas es un PDF y otra una página web. Me recuerda a la "epidemia" que se vivió en la primera década del siglo XXI cuando lo "cool" era usar Flash para crear sitios web, o mejor dicho, falsos sitios web.

En Why GOV.UK content should be published in HTML and not PDF se proporcionan varias razones para dejar de usar PDF en los sitios web:

• They do not change size to fit the browser
• They’re not designed for reading on screens
• It’s harder to track their use
• They cause difficulties for navigation and orientation
• They can be hard for some users to access
• They’re less likely to be kept up to date
• They’re hard to reuse

Y si PDF es tan malo ¿por qué se usa tanto? Algunas razones son:

• They’re quick and easy to create
• Control over the design
• They’re easy for people to download and print
• They have the feel of a stand-alone product

Curso "Start Building Accessible Web Applications Today"

Start Building Accessible Web Applications Today es un excelente curso sobre accesibilidad web:

• Accessible Icon Buttons
• Accessible Button Events
• Building Forms with Accessibility in Mind
• Headings and semantic structure for accessible web pages
• Focus management using CSS, HTML, and JavaScript
• What is the Accessibility Tree?
• Intro to ARIA
• How Visible vs. Hidden Elements Affect Keyboard/Screen Reader Users
• Using the Voiceover screen reader to test for accessibility
• Testing for Accessibility with the NVDA Screen Reader on Windows
• Creating visual skip links in HTML and CSS
• Accessible modal dialogs
• Using the tabindex attribute for keyboard accessibility
• Basic accessibility testing
• Accessibility testing with axe-cli

Formulario de acceso con captcha, ¿para qué?

El usuario @begoodness de Twitter me ha avisado del siguiente error.

La página web Te damos la bienvenida al Área Personal del Demandante (el título de la página ya es malo) presenta un formulario de acceso con usuario y contraseña que además añade un captcha:

Esto supone un grave problema de accesibilidad.

¿Para qué el captcha si tienes usuario y contraseña?

Seguramente lo han puesto para evitar ataques masivos. Pero en ese caso hay formas más inteligentes y menos perniciosas para el usuario: controlar la dirección IP, controlar el número de accesos en un período de tiempo, etc.

Ejemplos de textos alternativos de risa en el periódico El País

Estos ejemplos son de risa, si digo que son una mierda seguro que alguien se queja por usar un lenguaje inapropiado.

El primer ejemplo entra dentro de lo esperable, es un error típico: una imagen que es un enlace y tiene como texto alternativo el mismo texto que el enlace textual asociado a la fotografía. Resultado: el lector de pantalla leerá dos veces el mismo texto; molestia, confusión, desorientación para el usuario. Pero además, como no se ha modificado el color del texto, el texto alternativo es muy difícil de leer. Doble error.

El segundo error no entra dentro de lo esperable y nunca había visto algo así: ¿qué es ese texto alternativo en inglés cuando el periódico está en español? Una posible explicación es fácil de entender (el texto alternativo lo han tomado de la descripción de la fotografía que han tomado de un banco de imágenes o de un boletín de una agencia de noticias), pero no es perdonable. Al revés, es completamente condenable.

Cómo joder a la gente con el placeholder

En Don’t Use The Placeholder Attribute el resumen es claro y rotundo:

The placeholder attribute contains a surprising amount of issues that prevent it from delivering on what it promises. Let’s clarify why you need to stop using it.

Pues eso, DEJA DE USAR EL PLACEHOLDER, DEJA DE JODER A LA GENTE, o mejor dicho, DEJA DE USARLO MAL.

Esto ya lo he comentado varias veces en este blog:

• Ejemplo de que usar el placeholder es una mala idea
• Diez razones por las que los placeholders son problemáticos

Y aquí, unos ejemplos que aparecen en el artículo Don’t Use The Placeholder Attribute:

* El formulario de registro de Facebook con un abuso de del uso de placeholder:

* Tienes que introducir tu fecha de nacimiento, pero ¿el formato era MM/DD/YY, MM/DD/YYYY, DD/MM/YY o DD/MM/YYYY? ¿No te acuerdas? Pues te jodes, así de sencillo:

* Tiene que introducir una contraseña que debe cumplir una serie de requisitos. ¿Empiezas a escribir la contraseña y no te acuerdas de los requisitos? Pues ya sabes, te jodes una vez más:

 * ¿No sabes dónde puedes encontrar el código YAMA? Pues te rejodes:

Problema de accesibilidad para las personas que usan el control por voz

Olga Carreras ha publicado el artículo WCAG 2.1 Comprende el criterio "2.5.3 Etiqueta en el nombre" en el que comenta un nuevo criterio de WCAG 2.1:

En este vídeo explico algunos de los problemas que pretende evitar el nuevo criterio "2.5.3 Etiqueta en el nombre (A)" de las WCAG 2.1, el cual dice así: "Para los componentes de la interfaz de usuario con etiquetas que incluyen texto o imágenes de texto, el nombre accesible contiene el texto que se presenta visualmente".

Además ha hecho un vídeo para explicar la importancia de este criterio: