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

 

¿Qué es un CAPTCHA? Problemas de accesibilidad (1/2)

 

Proceso para evaluar la accesibilidad de una página web

Propuesto por Crystal Scott en Linkedin:

 

 Por si no funciona lo anterior:

🔍 My Process for Testing a Web Page for WCAG Conformance Ensuring web accessibility goes beyond automated testing—it’s about a detailed, methodical approach. Here’s how I test a webpage for WCAG conformance: 1️⃣ Start with the Basics - Double-check I’m testing the correct URL, component, and page state. - Open the page in my browser, set the screen width to 1280px, and open developer tools. (I live in developer tools!) 2️⃣ Inspect Elements - Work top-down, element by element, component by component. - Use developer tools to inspect elements and select shortcut “Expand recursively” to easily view the complete code structure. -Check each element’s HTML semantic structure, name, role, value, aria and functionality. ***Ask questions like: *What is this element? *What’s its role? *What is it's name and where is the name coming from? *Does it have supporting attributes for different states? *Does it pass color contrast requirements? *Is this an interactive element? 3️⃣ Interactivity and State Testing - For interactive elements, test with a mouse first, then the keyboard (Tab, Enter, Space) to ensure equitable functionality. - Ensure all interactive elements have a non-obscured color contrast conforming focus indicator. - Check hover, focus, active, pressed, selected, expanded, and collapsed states. - Ensure the element remains conformant, maintains color contrast, and performs its intended functionality in all states across all input devices. 4️⃣ Comprehensive Component Review Apply this process to all elements within a chosen component or page. Switch to Accessibility Tree View for new fresh perspective. 5️⃣ Screen Reader Testing Use NVDA to do a pass-through, ensuring I haven’t missed anything important. 6️⃣ Responsive Testing Test at 1280px for desktop, zoom to 200% for resizing, and zoom to 400% for reflow to check responsiveness and look for cutoff or missing meaningful content. 7️⃣ ARC Toolkit Analysis - Use ARC Toolkit to run tests with all topics selected. Manually review errors, alerts, and best practices by toggling disclosure panels. - Use highlight tools to quickly check: Page titles, iframes, lists, forms, tables, language attributes, buttons, links, tab order, tab index values, landmarks, and headings. - Leverage the text spacing tool at 1280px, 200%, and 400% to ensure compliance with resizing and reflow requirements. Accessibility isn’t just a checkbox—it’s a commitment to inclusivity and usability for all. This thorough (but not exhaustive) testing process ensures every page and component is tested against the WCAG success criteria. Now knowing how to fix the failures... DM me for help! What’s your favorite step or tool for accessibility testing? Let’s discuss in the comments! #AccessibilityTesting #WCAG #WebDevelopment #Accessibility #A11y

Cómo corregir la accesibilidad de un documento PDF con PAVE

 

Día Internacional de las Personas con Discapacidad

Hoy 3 de diciembre se celebra el Día Internacional de las Personas con Discapacidad:

El Día Internacional de las Personas con Discapacidad fue declarado en 1992 por la Asamblea General de las Naciones Unidas mediante la resolución 47/3. El objetivo es promover los derechos y el bienestar de las personas con discapacidades en todos los ámbitos de la sociedad y el desarrollo, así como concienciar sobre su situación en todos los aspectos de la vida política, social, económica y cultural.

¿Cómo un dispositivo móvil puede ayudar a nuestros estudiantes con discapacidad?

En el marco del Seminario sobre Discapacidades en la Educación Media Superior, organizado por la Universidad Nacional Autónoma de México, el día 27/11/2024 impartí la conferencia "¿Cómo un dispositivo móvil puede ayudar a nuestros estudiantes con discapacidad?":

Desafíos de accesibilidad en las single-page applications

En el vídeo Accessibility Challenges with Single Page Applications se explican algunos de los problemas de accesibilidad que presentan las single-page applications.

La descripción del vídeo dice:

Have you been tempted to use the WordPress API to drive a SPA (Single Page Application)? SPAs are notorious for being inaccessible, and for good reason. Tutorials introducing developers to frameworks like React, Vue, and Angular seem like they never take accessibility into consideration at all and teach some less than ideal practices. It is absolutely true that SPAs have a lot of accessibility challenges around things like dynamic content updates and managing focus. But with some smart choices and careful coding, it is possible to make SPAs more accessible. We’ll step through planning and building an accessible SPA, including best practices, accessibility testing tools, manual testing, and integrating accessibility into your development workflow.