Una lista de herramientas de evaluación interesante

En My Favorite Tools for Web Accessibility Testing se presenta una lista de herramientas de evaluación de la accesibilidad web muy interesante. Las herramientas se clasifican en las siguientes categorías y para cada categoría se indican los criterios de WCAG que ayudan a evaluar:

• Structure and Semantics
• Keyboard Operability
• Responsive Content
• Target Size of Interactive Elements
• Minimum Contrast

La accesibilidad de Figma

Muy interesante todo lo que se dice sobre la accesibilidad del generador de código de Figma:

• Figma Releases New AI-Powered Tools for Creating Sites
• The True Path to Garbage Code: Figma Sites
• Do Not Publish Your Designs on the Web with Figma Sites…
• Figma Sites is Worse Than You Might Have Thought
• Figma Dreamweaver

Parece que esta herramienta, que debe ser la leche, genera código que recuerda a Dreamweaver y FrontPage... ¡ejem, ejem!

¿Para cuándo EN 301 549 actualizado para cumplir con EAA?

En EN 301 549 V3 the harmonized European Standard for ICT Accessibility podemos leer:

EN 301 549 will be revised with the aim to publish V4.1.1 in 2025 in support of the European Directive (EU)2019/882 on the accessibility requirements for products and services (the European Accessibility Act), as a response to the European Commission Mandate 587. The revision work item of ETSI Technical Committee Human Factors (TC HF) can be seen via the Portal, along with its target schedule.

Pero ya estamos a mediados de 2025, quizás sea mejor pensar en el 2026. 

Día Mundial para Promover la Concienciación sobre la Accesibilidad Web (Global Accessibility Awareness Day)

Hoy, el tercer jueves de mayo, se celebra el Global Accessibility Awareness Day.

Carruseles con CSS

En marzo 2025, Google anunció Carruseles con CSS:

A partir de Chrome 135, puedes usar funciones de la especificación CSS Overflow 5 que se diseñaron para crear experiencias de desplazamiento y carrusel.

En Are 'CSS Carousels' accessible? se presenta un análisis de la accesibilidad de esta nueva característica de CSS.

Uso de perfiles de personas para evaluar la accesibilidad web

El Gobierno del Reino Unido tiene publicados unos recursos sobre cómo emplean los perfiles de personas para evaluar la accesibilidad de los sitios web que desarrollan:

• Using persona profiles to test accessibility
• Experience the web as personas with access needs

Diferencias entre WCAG, EAA y EN 301 549

En What’s the Difference Between WCAG, the EAA, and EN 301 549? se explican las diferencias entre WCAG, EAA y EN 301 549.

En ese artículo se incluye la siguiente tabla:

	WCAG (Web Content Accessibility Guidelines)	EN 301 549 (Standard)	EAA (European Accessibility Act)
Type	Global standard and technical guidance (also an ISO standard)	Voluntary European standard for ICT accessibility	Legally Blind EU directive
Purpose	Defines how to make web content and apps accessible	Defines accessibility requirements for ICT: websites, software, hardware, and documents	Requires accessibility of key digital and physical services
Legal Staus	Not a law, but widely referenced in regulations and policies	Not a law, but used to demonstrate conformance with EU accessibility requirements	Enforceable law across all EU member states
Scope	Web content: text, images, forms, navigation, etc.	ICT: websites, documents, software, mobile apps, hardware, telecoms	Consumer-facing products and services (e.g., banking, e-commerce, terminals)
Relationship	Referenced by EN 301 549 and often cited in laws like the EAA	References WCAG for web content; supports public procurement and regulatory alignment	References standards like EN 301 549 and WCAG to define accessibility

Un buen ejemplo de "saltar a"

El sitio web del banco HSBC tiene un buen ejemplo de enlaces "saltar a":

Multa a accessiBe por publicidad engañosa

En FTC Approves Final Order Requiring accessiBe to pay $1 Million podemos leer:

The Federal Trade Commission has approved a final consent order against accessiBe Inc. and accessiBe Ltd. (accessiBe). AccessiBe claimed the plug-in accessWidget can make any website compliant with Web Content Accessibility Guidelines (WCAG). The order prohibits accessiBe from making misleading claims and requires the company to pay $1 million.

The FTC’s January 2025 proposed complaint alleged that despite the company’s claims, accessWidget did not make all user websites WCAG-compliant and these claims were false, misleading, or unsubstantiated. In addition, the complaint alleged that accessiBe deceptively formatted third-party articles and reviews to appear as if they were independent opinions and failed to disclose the company’s material connections to the supposedly objective reviewers.

Nuevos criterios de accesibilidad para dispositivos móviles en WCAG 2.2

 

Android 16 y las aplicaciones adaptativas

En Android 16's Transition to Adaptive Apps: A Major Victory for Accessibility se explica que Android 16 eliminará la capacidad de que las aplicaciones puedan bloquear el modo de visualización a una orientación (vertical u horizontal) y se espera que todas las aplicaciones se adapten perfectamente a distintos tamaños y orientaciones de pantalla:

The upcoming Android 16 update introduces a significant change to how applications handle screen orientation and resizability. Previously, apps could restrict their behavior - for example, locking themselves to portrait mode or being non-resizable at the platform level. However, Android 16 is removing this ability, moving toward a consistent model where all apps are expected to seamlessly adapt to various screen sizes and orientations.

This initiative aligns with Android’s broader vision of supporting a diverse ecosystem of devices, from foldables to tablets to desktop-like experiences. While this is a positive step forward, especially for accessibility and usability, it brings both challenges and opportunities for app developers.

Nuevos criterios de accesibilidad para dispositivos móviles en WCAG 2.1

 

Resultados del estudio The WebAIM Million 2025

Este es el séptimo año que WebAIM publica The WebAIM Million. Los resultados son similares a los años anteriores.

El principal resultado es:

94.8% of home pages had detected WCAG 2 failures. This improved slightly from 95.9% in 2024. Over the last 6 years, the pages with detectable WCAG failures have decreased by only 3.1% from 97.8%. These are only automatically detected errors that align with WCAG conformance failures with a high level of reliability which suggests that the rate of full WCAG 2 A/AA conformance was certainly lower.

¿Qué se puede evaluar de WCAG 2.2 con herramientas automáticas?

En A tool's errand, Steve Faulkner explica qué criterios de WCAG 2.2 se pueden evaluar con herramientas automáticas. Según él, solo 6 de 55 criterios de nivel A y AA se pueden evaluar con esas herramientas, los otros 49 criterios requieren una revisión manual.

La Audiencia Nacional ratifica la multa a Vueling por tener una web inaccesible para las personas con discapacidad

El periódico 20 Minutos publicó la noticia La Audiencia Nacional ratifica la multa a Vueling por tener una web inaccesible para las personas con discapacidad el 28/02/2025. Esto creo que debe ser un error, porque el año pasado en marzo publiqué la entrada Confirmada la sanción a Vueling. Pero bueno, puede ser Vueling presentase un segundo recurso (¿eso se puede hacer?) y lo que ahora se anuncia es el resultado de ese segundo recurso.

La noticia dice:

La Sala de lo Contencioso-administrativo de la Audiencia Nacional (AN) ha ratificado la multa de 90.000 euros y la prohibición de concurrir a procedimientos de concesión de ayudas oficiales durante seis meses impuestas en 2020 a Vueling por la Secretaría de Estado de Derechos Sociales por no tener adaptada su web a las personas con discapacidad.

Así lo ha determinado el tribunal, que ha rechazado el recurso de la aerolínea y le obliga a pagar, además, 3.000 euros por las costas del proceso judicial. 

Ejemplo de cómo la administración pública exige accesibilidad, pero luego no la aplica

En el siguiente vídeo se explica cómo la administración pública exige una accesibilidad que luego ella misma no cumple. El vídeo habla de la accesibilidad física, pero lo mismo se puede decir de la accesibilidad digital, es decir, de los sitios web y las aplicaciones para dispositivos móviles.

Cuando poner una rampa es más complicado de lo que parece

El siguiente vídeo explica muy bien lo complicado qué puede ser poner una rampa para hacer accesible una escalera de simplemente seis peldaños. En el mundo digital, en los sitios web y las aplicaciones para dispositivos móviles ocurre algo parecido: solucionar algo que está mal hecho y no es accesible puede suponer mucho trabajo.

Elementos nativos de HTML que mejoran la accesibildiad

En Cool native HTML elements you should already be using se presentan algunos elementos nativos de HTML que no requieren montañas de código adicional y que, si son aceptados por el navegador web, deberían mejorar la accesibilidad de las páginas web:

I’m constantly surprised by the native HTML spec. New features are regularly added, and I often stumble on existing, handy elements. While often not as versatile as their JS counterparts, using them avoids bloating your app with extra Javascript libraries or CSS hacks.

If this article helps just a single developer avoid an unnecessary Javascript dependency, I’ll be happy. Native HTML can handle plenty of features that people typically jump straight to JS for (or otherwise over-complicate).

I cover some great HTML elements in this article — modals, accordions, live range previews, progress bars and more. You might already know some of these, but I bet there’s something new here for you too.

Inteligencia artificial y accesibilidad

La conferencia "AI and Accessibility: the Good, the Bad, and the Bollocks" se impartió en el marco de FFCONF 2024:

La descripción de esta conferencia es:

Depending on what you read, and who you believe, AI is either the ultimate solution or armageddon in motion, so in this talk, Léonie is going to cut through the clickbait, dodge the doomscrollers, and focus on the facts to bring you the good, the bad, and the bollocks of AI and accessibility.

Treinta años de JAWS for Windows

En Vispero Announces Year-Long Celebration for JAWS’ 30th Anniversary, Beginning at CSUN 2025 se anuncia el 30 aniversario de JAWS for Windows, ya que fue lanzado al mercado en el año 1995. Sin embargo, en Jaws for Windows - a Short History Lesson se cuenta que JAWS para DOS fue lanzado en 1989.

Inteligencia artificial para la escritura de los textos alternativos de las imágenes

El artículo Comparing local large language models for alt-text generation presenta una comparación de modelos de lenguaje de gran tamaño (LLMs) para la generación de texto alternativo (alt text). Este tipo de análisis no es nuevo.

A la hora de comparar los modelos se deben tener en cuenta diferentes aspectos:

• Precisión: Qué tan bien los modelos describen el contenido de las imágenes.
• Velocidad: El tiempo que tardan en generar el texto.
• Eficiencia: El uso de recursos computacionales.
• Facilidad de implementación: Qué tan sencillo es integrar estos modelos en sistemas existentes.
• Coste: El gasto asociado con el uso de cada modelo.

En este artículo no se analiza todo esto, pero la información que presenta es muy interesante.

Cómo comprobar y garantizar la accesibilidad de una página web

 

Un poco de historia sobre WCAG

En The politics of accessibility se cuenta un poco de la historia de WCAG:

The first iteration of WCAG was published in 1999, just eight years after Tim Berners-Lee published the initial draft specification for HTML and just six years after the MOSAIC web browser was first released. Two of WCAG 1.0’s three editors, Wendy Chisholm and Gregg Vanderheiden, were at the Trace R&D Center, at the time affiliated with the University of Wisconsin-Madison.

Before work began on WCAG under the auspices of the W3C, Chisholm and Vanderheiden had already created eight iterations of what they called the Unified Web Site Accessibility Guidelines. Prior to those guidelines, Vanderheiden had published an article in January 1995 titled “Design of HTML (Mosaic) Pages to Increase their Accessibility to Users with Disabilities Strategies for Today and Tomorrow,” which identifies a series of common accessibility barriers and provides design or code solutions. (Incidentally, some of the problems identified remain things the web struggles with.)

But it’s important to understand that Vanderheiden, Chisholm, and the Trace Center weren’t unique visionaries who stood separate from the world. They were part of a community that, from its earliest days, understood and valued accessibility.

Vanderheiden had attended at the Second International WWW Conference: Mosaic and the Web in beautiful Chicago, Illinois in October 1994 — just a few months before his January 1995 article. So did Paul Fontaine and Mike Paciello, both also speaking on disability and accessibility. At that conference, Tim Berners-Lee identified accessibility as an important focus area as the web continued to grow and develop. Accessibility was very much in the air in the formative stages of the web.

That was a quick-and-dirty history — a too-short narrative that absolutely leaves out a ton of people and details. It’s not the whole story by any measure, and crucially it glosses over the contributions of a large and diverse community that includes a lot of people with disabilities.

Las pautas de accesibilidad antes que las WCAG

Unified Web Site Accessibility Guidelines (enero 1998) son las pautas de accesibilidad que se convirtieron posteriormente en Web Content Accessibility Guidelines 1.0 (mayo 1999). Los dos autores del documento inicial, Gregg C. Vanderheiden y Wendy A. Chisholm, fueron luego editores de WCAG 1.0.

La introducción del documento dice:

The 8 series of website accessibility guidelines is the final set of unified guidelines prepared by the Trace Center. The Web Access Initiative (WAI) of the World-Wide-Web Consortium (W3C) has been launched, and the development of HTML guidelines is being transferred to that body. The Trace Center will be continuing to work with and as a part of the WAI. As a result, the Trace Center will no longer be developing or maintaining this Unified Website Accessibility Guideline series. Readers are referred to the W3C site (http://www.w3.org/wai) for the latest version of the guidelines.

Nuevos criterios de accesibilidad para dispositivos móviles en WCAG 2.2

 

Nuevos criterios de accesibilidad para dispositivos móviles en WCAG 2.1

 

Control mediante EMG: una herramienta para mejorar la accesibilidad en personas con discapacidad

 

Curso de especialización en Accesibilidad Digital

La Universidad de Lleida ha lanzado el Curso de especialización en Accesibilidad Digital. Me cuentan lo siguiente:

Es un curso que puede hacerse completo (de 6 créditos) o bien cursando solo los módulos por separado (para perfiles más especializados). Es completamente online y en horario tarde (hora española) para que pueda asistir también alumnos de otros países.

Curso completo de especialista en accesibilidad digital  (6 créditos ECTS). 

Del 04 de febrero y al 11 de abril de 2025. 

 

Módulos formativos independientes dirigidos a perfiles como diseñadores y UX, programadores web y evaluadores de calidad de sistemas:

• Módulo 1. Sensibilización (1 crédito ECTS) del 04 al 16 de febrero de 2025 
• Módulo 2 Diseño (1,5 créditos ECTS) del 18 de febrero al 2 de marzo de 2025 
• Módulo 3. Codificación (2 créditos ECTS) 4 de marzo al 23 de marzo de 2025 
• Módulo 4. Evaluación (1,5 créditos ECTS) del 25 de marzo al 6 de abril de 2025 

Principales aspectos a tener en cuenta en la accesibilidad web

 

Daltonismo: Problemas de accesibilidad