Una crítica a los sistemas que prometen accesibilidad web con una sola línea

 Según Eric Eggert, los accessibility overlay basados en inteligencia artificial no cumplen lo que prometen. Lo cuenta en su vídeo 5 False Claims 1-Line “AI” Accessibility Script Vendors Make:

Y el inicio de la transcripción:

They claim to be the be-all and end-all of all accessibility worries: “AI” accessibility tools. They say they provide “100% WCAG 2.1 compliance”. They say it only takes one line of JavaScript to “fix your website for accessibility”.

Who are “they”? VC-backed companies that promise affordable, effortless compliance for your website. If you think “that sounds too good to be true”, you’re right. It is indeed quite the opposite of true.

Here are five claims that “AI” accessibility script vendors make that are misleading or completely untrue.

(Intro.)

I’m Eric Eggert, a Web Accessibility Expert. You can follow me as @yatil — Y-A-T-I-L — on social media. If you have questions about this or other videos, or want to propose a topic, ask in the comments, or use the hashtag #askYatil on Twitter.

Before we get into it, whenever I say AI, please imagine the most expressive air-quotes gesture possible.

Okay!

Seminario Permanente sobre Discapacidad PUDH-FCPyS UNAM

 El próximo 17 de noviembre de 2020 participaré en el Seminario Permanente sobre Discapacidad PUDH-FCPyS UNAM Discapacidad y TIC's: ¿Exclusión virtual y digital? organizado por la Universidad Nacional Autónoma de México. Este seminario comienza el 3 de noviembre.

Más información en la página de Facebook.

Semántica, ARIA y lectores de pantalla

En Semantics to Screen Readers se explica:

Assistive technologies (ATs), which are hardware and software that help us perceive and interact with digital content, come in diverse forms. ATs can use a whole host of user input, ranging from clicks and keystrokes to minor muscle movements. ATs may also present digital content in a variety of forms, such as Braille displays, color-shifted views, and decluttered user interfaces (UIs). 

One more commonly known type of AT is the screen reader. Programs such as JAWS, Narrator, NVDA, and VoiceOver can take digital content and present it to users through voice output, may display this output visually on the user’s screen, and can have Braille display and/or screen magnification capabilities built in. 

If you make websites, you may have tested your sites with a screen reader. But how do these and other assistive programs actually access your content? What information do they use? We’ll take a detailed step-by-step view of how the process works.

Un 6,1% de los empleados de Microsoft presenta algún tipo de discapacidad

 Este dato se puede leer en el artículo Microsoft Reveals 6.1% Disability Representation For The First Time:

A newly released report from Microsoft reveals that 6.1 % of the company’s U.S. employees self-identify as disabled, meaning they have a physical, mental or cognitive disability. If you’re not quite sure how to put that number in context, that’s because few companies ever disclose similar numbers. This is the first time Microsoft has included disability in their annual diversity and inclusion report—and although the number may be modest, its significance will be understood worldwide.

[...]

Microsoft already employs people with all types of disabilities and is actively looking for new ways to be inclusive. The company has slowly and persistently chipped away at the issue since Satya Nadella became CEO in 2014. It takes patience and persistence to move the needle. Even the basics can’t be taken for granted. Many Americans don’t know that most disabilities are not visible, likely because they are not openly discussed and can be a source of shame or stigma. “Diabetes, dyslexia, and depression are three great examples of this. To understand our representation, we need data which means cultivating a workplace where employees can be confident, have pride in their disability and ultimately, confidentially self-identify whether they have a disability or not,” says Lay-Flurrie. 

[...]

Microsoft defines disability, using the definition of disability from the World Health Organization in both in internal conversation and external conversations: “Disability is not just a health problem. It is a complex phenomenon, reflecting the interaction between features of a person’s body and features of the society in which he or she lives.”

Accesibilidad de los reproductores multimedia

En How accessible is the HTML video player? han analizado la accesibilidad de los reproductores multimedia. La conclusión es:

In case you don’t make it all the way to the bottom, I feel, based on the results of testing each player (and comparing to my own Accessible Video Player project), that relying on native video players should be used with caution. This is my opinion stemming from experience, but I found most to have poor keyboard and screen reader support, which may lead to frustrated users. 

There were a lot of inconsistencies across the board as far as keyboard and screen reader support. Some lose focus when the video controls receive focus then fade away, forcing the user to re-position themselves to adjust playback. Others did not trap keyboard focus in full-screen mode, leading to a similar situation as an inaccessible modal window allowing content to be accessed "behind" the window. One player in particular featured very awkward keyboard support where controls were visible on the screen but could not be focused.

Curso gratuito "¿Cómo diseñar y programar sitios web accesibles?"

 El curso gratuito ¿Cómo diseñar y programar sitios web accesibles? tiene el siguiente contenido:

• Introducción a la accesibilidad web
• Estándar WCAG 2.1.
• Organización del estándar
• Tecnologías de asistencia
• Destinatarios del WCAG
• Principios, pautas y criterios
• Niveles de conformidad.
• Accesibilidad en elementos gráficos.
• Accesibilidad en hipervínculos.
• Accesibilidad en controles de formulario.
• Accesibilidad en tablas
• Accesibilidad en la estructura de una página.
• Accesibilidad en el contenido.

El curso tiene estos prerrequisitos:

• Estar matriculado en alguna institución educativa de educación superior.
• Tener conocimientos de HTML, CSS y JavaScript.
• Disponer de 6 horas por semana durante tres semanas, para el estudio de los contenidos y la realización de las prácticas y tareas.

Cómo diseñar para lectores de pantalla

En Designing Layouts for Screen Readers se explica:

It’s easy to think about a layout as being a primarily visual concern. The header goes up top, the sidebar is over here, the call to action is in an overlay on top of the content (just kidding). Grids, borders, spacing and color all portray valuable visual data, but if these hints to the structure of a page are only visible, some users may find your content unintelligible.

You can experience this first hand if you try using a screen reader on the web. When I fired up VoiceOver on my Mac and took it out for a test drive, I realized that to a screen reader user, a lot pages are just a big heap of ‘content’, missing helpful organizational cues. 

The experience can be kind of like listening to a long rambling story without any indication to what details are important or related to the main thread of the story. Halfway through the story, you aren’t sure whether it’s worth it to keep listening because you don’t know if you’ll even find what it is you’re looking for. In the context of a website, your screen reader might be halfway through reading you a list of 50 sidebar links when you start wondering if there is any valuable content on the site at all.
Experiences like this are caused by websites that are built with layouts that are only visual. Ideally, however, our visual layouts should point to an underlying organizational model of our content. They should be visual indicators for a conceptual model. The visual indicators are just one way of revealing this model. The Web Accessibility Initiative’s ARIA (Accessible Rich Internet Applications) project provides alternative indicators to users who may need them. 

I’ll walk through how to make use of these indicators to make a simple web page easy to use, navigate and read for users of assistive technology. All the example code is available on github.

Las novedades de WCAG 2.2

En Web Content Accessibility Guidelines (WCAG) 2.2 Draft for Review, el W3C explica las novedades de WCAG 2.2:

• 2.5.7 Dragging
• 2.5.8 Pointer Target Spacing
• 2.4.11 Focus Appearance (Minimum)
• 2.4.12 Focus Appearance (Enhanced)
• 2.4.13 Fixed Reference Points
• 3.2.6 Findable Help
• 3.2.7 Hidden Controls
• 3.3.7 Accessible Authentication
• 3.3.8 Redundant Entry

En What’s New in WCAG 2.2 y WCAG 2.2 Overview and Feedback se analizan las novedades que tiene WCAG 2.2 hasta el momento actual, ya que todavía es un borrador, no es la recomendación final.

Una introducción a WCAG 2.x

 Interesante el vídeo A WCAG Overview — Web Content Accessibility Guidelines (WCAG) 2.1 and 2.0 Explained:

Y la transcripción del vídeo en A WCAG Overview — Web Content Accessibility Guidelines (WCAG) 2.1 and 2.0 Explained.

Accessibility Maze, un juego accesible sobre accesibilidad

Accessibility Maze es un juego serio accesible sobre accesibilidad:

For people who do not experience barriers, it can be difficult to empathize with the challenges that people with disabilities often face when navigating the Web. The Accessibility Maze was created to help those new to web accessibility experience firsthand what it is like to encounter those barriers. The game introduces a number of common barriers players must work around, mirroring the experience of those who encounter these obstacles daily, and provides quick lessons on how to avoid or correct them. 

In creating the game we wanted to ensure it would be accessible. Gaming being one of the more challenging areas in which to address accessibility, the Accessibility Maze has been created to be playable with a current screen reader, using only a keyboard, and to demonstrate strategies for making games accessible.

Ejemplo de uso de un lector de pantalla

El vídeo Enciende tu ordenador. Desenchufa el ratón. Desconecta la pantalla... ¡Y ponte a trabajar,! dice:

¿Te has planteado qué pasaría si de repente no pudieras utilizar la pantalla de tu ordenador? ¿Te ves capaz de manejarlo sin poder verlo? ¿Y un iPhone? ¿Es eso posible?
En este vídeo veremos cómo las personas ciegas hacemos uso de la tecnología, y cómo ésta nos permite ser mucho más independientes siempre que sea accesible. Adéntrate conmigo en una realidad diferente que seguro te sorprenderá.

Nueva ley sobre accesibilidad web en EEUU

Según Introduced Online Accessibility Act Would Amend ADA, Clarify Web Accessibility Compliance Standards, en EEUU se ha propuesto Online Accessibility Act, una nueva ley sobre accesibilidad web que se añadirá a la famosa Americans with Disabilities Act (ADA) de 1990.

El borrador de la ley añadirá un nuevo título de sección:

TITLE VI—CONSUMER FACING

WEBSITES AND MOBILE APPLICATIONS OWNED OR OPERATED BY A PRIVATE ENTITY

Que entre otras cosas, dice:

(1) IN GENERAL.—A consumer facing website or mobile application shall be considered compliant under the requirements of this section if such website or mobile application is in substantial compliance with the Web Content Accessibility Guidelines (referred to in this title as WCAG) 2.0 Level A and Level AA standard established by the Accessibility Guidelines Working Group, or any subsequent update, revision, or replacement to the WCAG 2.0 Level A and Level AA standard published by the World Wide Web Consortium or successor organization.

Personas con discapacidad se reconvierten en programadores

 Según una nota de prensa de la Fundación Once y Por Talento Digital:

Un total de veintiséis personas con discapacidad de Madrid, Barcelona y Valencia han finalizado el curso ‘Programación para No Programadores’, que se lleva a cabo dentro de la iniciativa Por Talento Digital (http://www.portalentodigital.es/) de Fundación ONCE, con la colaboración de Inserta Empleo y el proveedor de formación OPINNO.

El curso comenzó el pasado mes de diciembre con medio centenar de alumnos de los que la mitad lo han terminado. En total han sido 800 horas de formación, desarrollada en tres ciudades como son Madrid, Barcelona y Valencia. Además, ha contado con el apoyo de Fundación Vodafone España y Mastercard.

El curso Programación Web Full-Stack para no programadores no requería formación previa en programación precisamente para dar una oportunidad de reciclar profesionalmente a las personas que no venían del terreno tecnológico, ofreciéndoles así el reto de formarse en una de las profesiones tecnológicas más demandadas actualmente en el mercado laboral.

Tuvo dos fases. La primera contaba con la cofinanciación de la Fundación Vodafone España, y durante sus 250 horas sirvió para fijar los conceptos y tecnologías básicas de programación, a través de lenguajes como c# o java.

La segunda fase, que comienza ahora, es una formación especializada de 550 horas en programación web, front y backend, donde los alumnos aprenderán fundamentos web basados en estándares como Javascript, CSS, html, Angular o next js.  

Para esta nueva modalidad online se está utilizando la plataforma Discord (que permite crear grupos de trabajo, aulas, etc.), así como la extensión Visual Studio Code para compartir el código de desarrollo. Ha sido necesario implementar algunas adaptaciones de accesibilidad para asegurar el acceso en igualdad de condiciones a todo el alumnado en este nuevo formato. 

Por ejemplo, para una alumna con discapacidad auditiva en la sede de Madrid se ha incorporado una herramienta de subtitulado automático que permite seguir las explicaciones del profesor. Además, para otro alumno sordo signante de Barcelona se ha dispuesto una herramienta para que pueda contar con la intérprete de lengua de signos en remoto.

Además de la formación teórica, ha habido un fuerte componente de toma de contacto con el mundo empresarial. Así, han impartido masterclasess a los beneficiarios responsables de Microsoft, Between, Avanade, El Corte Inglés, Deloitte, Souji y Nutrilieve.  

Por otro lado, se organizaron 3 sesiones de Speed Dating a través de Zoom, en las que participaron profesionales de Everis, Avanade, BMAT, RECUBIK, Super Squad Interactive, Pavapark, ALZIS, KIWA, Everycode, GFI, Fundación Universia, Nutrilieve, Go Zero Waste, Smart Monkey, Jump Data Driven, It Will Be y Voices of Leaders. El objetivo de estas sesiones era que las empresas conociesen a los alumnos para poder ofrecerles prácticas no laborales que completen la formación teórica que han recibido. 

Vïdeos sobre accesibilidad de Google

En Google Accessibility hay una enorme colección de vídeos sobre accesibilidad.

Seminario Permanente sobre Discapacidad PUDH-FCPyS UNAM

 El próximo 17 de noviembre de 2020 participaré en el Seminario Permanente sobre Discapacidad PUDH-FCPyS UNAM Discapacidad y TIC's: ¿Exclusión virtual y digital? organizado por la Universidad Nacional Autónoma de México. Este seminario comienza el 3 de noviembre.

Más información en la página de Facebook.

Cuidado con las herramientas automáticas de revisión de la accesibilidad web

En Use Caution with Automated Tools that Promise 100% Accessibility Compliance se explica:

Automated accessibility testing tools, powered by artificial intelligence (AI) and code-scanning technology, can be an important part of an accessibility testing plan — but, they must remain just a part. Automated testing on its own should not replace manual testing by an accessibility expert and should not be used as the only way to show compliance.

Y avisa del peligro del texto alternativo generado de forma automática mediante inteligencia artificial:

As technology advances, there are even image-recognition programs that can with some accuracy guess what an image depicts and generate alt text. On one hand, it's incredible that this technology exists. On the other, it presents an additional layer of review required by human beings. The real purpose of an image in the context of a web page, the real feeling somebody is supposed to be exposed to, the real information conveyed by an image can't be decided by a machine — at least not yet.

Experiencia equivalente

Muy interesantes, llenos de ejemplos, los artículos Equivalent Experiences: What Are They? y Equivalent Experiences: Thinking Equivalently publicados en Smashing Magazine.

El resumen dice:

An equivalent experience is one that has been deliberately conceived of and built to be able to be used by the widest possible range of people. To create an equivalent experience, you must understand all the different ways people interact with technology, as well as common barriers they experience. 

Constructing an equivalent experience may mean changing the way you think about development and design, and potentially reevaluating your existing work. In this article, we’ll address common accessibility issues, and how to best go about improving them so everyone can effortlessly access your content.

¿Qué son las características accesibles de un sitio web?

En What Are Accessibility Features of a Website? explican qué son las características accesibles que ofrecen algunos sitios web:

Website accessibility features are the elements of a site designed to improve the ability of people with disabilities to independently use it. Sometimes websites include extra options specifically to enhance some people's use, but usually accessibility features are integrated into a well-coded website that is accessible by default.

Aunque normalmente estas características que se añaden con muy buenas intenciones, a veces pueden causar problemas a ciertos usuarios:

Sometimes, extra accessibility features are added with the best of intentions, but in practice can actually cause new problems. For example, some websites or digital tools will include their own screen reading technology with the goal of providing easy access to people who are blind, have low vision, or otherwise benefit from hearing content instead of or in addition to seeing it. However, many people who need to use screen readers already use one and likely have a go-to screen reader they prefer for that particular type of content, web browser, or device. In this example, the extra screen reader might interfere with the native screen reader, or vice versa, and accessibility will have been compromised, not improved.

Another common example are keyboard shortcuts. Some websites will offer custom keystroke combinations designed to save the user time or make interaction easier, and sometimes these can be helpful. Other times, however, keyboard shortcuts might interfere with screen reader or other assistive technology commands, or with keyboard shortcuts that users who need them most already have programmed. Again, in this example, something intended to improve accessibility can make the website unusable if not done carefully.

Los enlaces "saltar a" son importantes

Muy interesante la explicación y el código que se ofrece en Skip links are important:

"Skip links" are important. They allow keyboard-only users, sighted or not, to bypass large or repetitive blocks of content. You may have heard of them and wondered what the big deal is. Or your design team may have refused to implement one because they look “ugly”. But they are important, and they don’t have to break the design. 

Lots of links
Many sites have a lot of links at the top of the page. The mega menu isn’t dead! It seems like news websites are particularly bad with this. The Montreal Gazette has over 175 links before reaching the main content. CNN does better, with only 19 links. The Austin Statesman “only” has 18 or so, but the very first link isn’t keyboard-friendly, and it’s the “navigation menu”. The navigation menu has nearly 60 links! Perhaps it’s just as well it’s not keyboard accessible? Stuff has a couple dozen links (and no focus visible - but that’s a story for another day).
All these links before the main content mean that a keyboard-only user has to tab through every single link before they can reach or interact with the main content. This is not a great experience.
Screen reader users are keyboard-only users. Their assistive technology allows them to navigate to different areas of a page, by using landmarks or headings, for example (if they’ve been implemented on the site). But sighted keyboard-only users don’t have that luxury, because browsers don’t (yet?) allow this kind of navigation.

Not just top content
Another area of concern can be social media embeds, such as Twitter feeds. These may have as many as 200 links to tab through before being able to get to the other content. 

Compliance
It’s important to make your visitor’s life easier by allowing them to bypass blocks of links. But it’s not just about making their life easier. It’s also about compliance. WCAG success criteria 2.4.1 Bypass Blocks requires this. I generally don’t like to push accessibility from a compliance perspective. But it’s important to note that factor.

En el artículo se ofrece el código para implementar correctamente los "skip links".

Accesibilidad en Android

Para los usuarios ciegos o con baja visión:

• Talk Back 
• Braille Back
• Color Inversion
• Magnification

Para los usuarios con problemas de movilidad:

• Switch Access
• Voice Access 

Para los usuarios sordos o con problemas de audición:

• YouTube Captions (including YT Live)
• Live Transcribe
• Sound Amplifier
• Play Movie Captions
• Live Captions for slides
• Mono audio support

Para los usuarios con problemas cognitivos o de aprendizaje:

• Select to Speak
• Material Design (consistent, clean User Interface)