Cuatro razones por las que las capas de accesibilidad no funcionan

En 4 Reasons Why Accessibility Overlays Don’t Work se explican cuatro razones por las que las capas de accesibilidad no funcionan:

1. Accessibility overlays need to be found and activated
   For an accessibility overlay to even begin to be effective, the user must first be able to activate it. Occasionally, the activation and deactivation methods for accessibility overlays are not keyboard accessible, meaning only a mouse can turn them on and off. This design leaves mobile and keyboard-only users unable to access the overlay at all.
   
   Some overlays also can’t be found by screen readers and other assistive technologies. As a result, users relying on those technologies will not be able to find the overlay, rendering it useless.
2. Accessibility overlays may not be compatible with the user’s preferred settings
   People with disabilities usually have their own preferred assistive technologies to help them perform tasks. For example, a user with low vision who uses a screen magnifier probably uses that same screen magnifier when browsing any website and can turn it on and off easily.
   
   Accessibility overlays, however, have their own predefined actions and functions. They do not conform to the user’s preferred technologies and settings. In the example of the user with low vision, this user must figure out how to turn on and configure the overlay’s magnifier tool rather than being able to use the already-configured preferred tool.
3. Accessibility overlays are not universally consistent
   The incompatibility of accessibility overlays with individual user settings might not be as much of a problem if accessibility overlays were universally consistent. However, accessibility overlays created by different companies must each be used differently as well.
   
   Companies should not burden their customers with figuring out how to use each new accessibility overlay. Instead, company websites should be built to conform to current web and accessibility standards. These standards empower all users to access and navigate the website using their preferred devices.
4. Accessibility overlays can’t detect most accessibility issues
   To make a website accessible, a wide variety of criteria must be evaluated across the entire site. Some of these can be automatically evaluated, such as color contrast. However, many items must be evaluated manually to be fully tested.
   
   For example, automated testing can determine if all images across the website have alt tags or if any are missing alternative text. Unfortunately, automated testing cannot determine if the text within each tag is appropriate for each image or not, which is where accessibility overlays fall short and manual testing is required.
   
   Automated testing can usually detect about 20-30% of accessibility issues, meaning accessibility overlays can only detect and address 20-30% of issues. This leaves 70-80% of accessibility issues completely undetected, never mind remedied, posing a significant legal risk to your company.

Accesibilidad Web: Formularios (2)

 

Accesibilidad Web: Formularios (1)

 

Libro gratuito sobre tipografía

Butterick’s Practical Typography es un excelente libro gratuito sobre tipografía. En él podemos leer y aprender cosas muy interesantes como, por ejemplo:

• El subrayado (underlining) es de los tiempos de las máquinas de escribir y se debe emplear en contadas ocasiones.
• Todo el texto en mayúsculas (all caps) genera muchos problemas, también se debe emplear en contadas ocasiones.
• El texto justificado (justified text) siempre se debe emplear junto con la división de palabras. ¿No es posible la división de palabras, como en las páginas web? No uses el justificado.

Y así un montón de consejos más.

WCAG en lenguaje claro

WCAG in Plain English explica los criterios de Web Content Accessibility Guidelines en Plain English.

Plain English (en español, inglés claro o inglés llano) es una forma de redactar en inglés que busca comunicar ideas de manera clara, directa y sencilla, sin ambigüedades ni tecnicismos innecesarios. El objetivo principal es que cualquier persona, independientemente de su nivel educativo o experiencia, pueda entender el contenido en la primera lectura.

Algunas de las características del Plain English, que también se pueden aplicar al español, son:

1. Lenguaje claro y directo: Se evitan las palabras rebuscadas, jergas, tecnicismos o frases demasiado formales.
2. Frases cortas: Se prefieren oraciones simples y de longitud moderada para facilitar la comprensión.
3. Estructura lógica y ordenada: Las ideas se presentan de forma coherente, con buena organización del contenido.
4. Uso activo de los verbos: Se prefiere la voz activa en lugar de la pasiva. Por ejemplo:
• Voz pasiva: The form must be completed by the applicant.
• Voz activa: You must complete the form.
5. Diseño accesible: A menudo, el Plain English también considera la presentación visual del texto (títulos claros, listas, espacios en blanco).

En realidad, es muy fácil de entender qué es Plain English (o español claro): es justo lo contrario de lo que usan los políticos o la administración pública.

¿Y por qué es importante usar Plain English o español claro? Algunos de los beneficios son:

• Mejora la comunicación con públicos amplios y, en especial, con algunos grupos de personas con discapacidad.
• Facilita la comprensión de documentos legales, administrativos o técnicos.
• Aumenta la transparencia en la comunicación institucional.
• Es clave en ámbitos como el gobierno, la salud, las finanzas, la educación y la accesibilidad web.

Cómo conseguir accesibilidad web frente al daltonismo (3)

 

Cómo conseguir accesibilidad web frente al daltonismo (2)

 

Publicada una nueva versión de WCAG 3

El W3C ha publicado una nueva versión de WCAG 3: W3C Accessibility Guidelines (WCAG) 3.0 (W3C Working Draft 04 September 2025)

¿Y para cuándo la versión definitiva?

En WCAG 3 Introduction podemos leer:

Development

Timeline

WCAG 3 is not expected to be a completed W3C standard for a few more years.

WCAG 3 will not supersede WCAG 2 and WCAG 2 will not be deprecated for at least several years after WCAG 3 is finalized.

The Accessibility Guidelines Working Group (AG WG) previously created an initial set of guidelines and explored conformance models. In 2025, AG WG focused on progressing guidelines, requirements, assertions, and supporting material to Developing status. During the rest of 2025, the group will focus on completing the proposed guidelines and proposed conformance model for public review.

AG WG plans to develop a projected WCAG 3 timeline by December 2025.

We will update this section with more specific timeline information as it is available.

Consejos para formularios accesibles

En Accessible Forms: Tips and Techniques se proporcionan  buenas prácticas (consejos) interesantes para crear formularios accesibles:

Los formularios son fundamentales en la experiencia web (por ejemplo, para registros o compras), pero muchas veces presentan barreras para personas con discapacidad. Asegurar su accesibilidad es clave no solo para cumplir con normativas, sino también para garantizar una experiencia inclusiva.

1. Usa elementos semánticos de HTML

Utiliza etiquetas como <form>, <label>, <input>, <textarea> y <select> en lugar de <div> o <span>.

Relaciona cada <label> con su campo usando el atributo for.

2. Etiquetado e instrucciones claras

Todos los campos deben tener una etiqueta visible.

No sustituyas etiquetas con texto de marcador (placeholder), ya que este desaparece al escribir.

Proporciona instrucciones claras y mensajes de error descriptivos cerca del campo correspondiente.

3. Accesibilidad con teclado

Asegúrate de que el formulario pueda recorrerse con la tecla Tab en orden lógico.

Evita bloquear el enfoque (focus) en componentes personalizados.

Los botones deben ser operables con Enter o barra espaciadora.

4. Validación y retroalimentación clara

Usa atributos ARIA como aria-live y aria-describedby para comunicar errores o validaciones a los lectores de pantalla.

Realiza validaciones en tiempo real y mueve el foco al primer error detectado.

5. Agrupa campos relacionados

Usa <fieldset> y <legend> para agrupar controles relacionados (como botones de opción), lo cual mejora la comprensión para usuarios con lector de pantalla.

6. Mensajes de error accesibles

No uses solo el color para indicar errores; combina colores con mensajes textuales.

Asegura que los errores se lean en voz alta mediante ARIA y expliquen qué ocurrió y cómo solucionarlo.

7. Diseño para pantallas táctiles

Los botones deben ser lo suficientemente grandes (mínimo 44×44 px).

Asegura buena legibilidad de etiquetas en pantallas pequeñas.

Evita interacciones basadas en "hover", que no funcionan en dispositivos táctiles.

8. Prueba tus formularios

Evalúa con lectores de pantalla (NVDA, JAWS, VoiceOver).

Navega solo con el teclado.

Usa herramientas automáticas como Axe o WAVE, aunque no detectan todos los problemas.

Cómo conseguir accesibilidad web frente al daltonismo (1)

 

CAPTCHA: Análisis de su accesibilidad

Accesibilidad en el posicionamiento web

Animaciones accesibles en páginas web

Tablas de soporte de HTML en los lectores de pantalla

En Screen reader HTML support tables se pueden consultar tablas de soporte de HTML de los lectores de pantalla JAWS y NVDA.

Razones egoístas para desarrollar interfaces de usuario accesibles

En Selfish reasons for building accessible UIs:

• Debuggability
• Naming things
• Testability
• Power users

Focus priming

En Focus priming se explica algo que hacemos muchos de los que hacemos evaluaciones de sitios web. Cuando haces clic en algún lugar de una página web, puede parecer que no ocurra nada, pero en realidad estás determinando el punto de inicio del enfoque (focus) para la navegación con el teclado. Este detalle es importante al evaluar la accesibilidad.

¿Qué es el "focus priming"?

Es la acción de hacer clic en un punto específico de la página para establecer dónde comenzará el enfoque del teclado (por ejemplo, al presionar la tecla Tab). Aunque el enfoque inicial en la página no es visible (porque la página no es interactiva), existe y se puede modificar haciendo clic.

Ejemplos de cómo se mueve el enfoque:

• Al hacer clic en un campo de formulario o botón, el foco se mueve allí.
• Al hacer clic en un enlace, puede llevarte a otra parte de la página o del sitio.
• Al hacer clic en texto o imágenes no interactivas, simplemente se define un nuevo punto invisible de inicio del foco.

El término "focus priming" se refiere a esta técnica de establecer el foco antes de usar el teclado para realizar pruebas de accesibilidad.

Cómo la inteligencia artificial puede ayudar a las personas con discapacidad

 

Limitaciones de las herramientas automáticas de evaluación de la accesibilidad web

En Automated accessibility test tools find even less than expected se explica que, aunque muchas de las herramientas automáticas de evaluación de la accesibilidad web afirman cubrir entre el 30 % y el 50 % de los errores según WCAG, estudios y expertos como WebAIM, W3C, Karl Groves o Deque Systems confirman que esta cobertura es parcial y limitada.

El autor del artículo diseñó un conjunto de seis páginas HTML con 164 casos de prueba negativos (es decir, que deberían generar un error), centrados en el nombre accesible de los elementos interactivos (lo que lee un lector de pantalla cuando el foco llega a un botón, enlace, imagen, etc.).

El autor evaluó diferentes herramientas (gratuitas y comerciales) para ver cuántos errores detectaban, sobre elementos como <button>, <a>, <img>, <iframe>, formularios y elementos con roles ARIA.

Los resultados fueron:

• Ninguna herramienta superó el 40 % de cobertura, y muchas puntuaron por debajo.
• Algunas no reconocen elementos con role="button" u otros roles ARIA.
• Se observó gran variabilidad en el rendimiento dependiendo del tipo de contenido.
• No se evaluó el impacto del error (ej. falta de nombre en un botón de envío vs. en una imagen decorativa).

La conclusión del autor es que deberíamos matizar las cifras habituales de cobertura de herramientas automatizadas: cubren entre el 30 % y el 50 % de los problemas más comunes y fácilmente detectables, pero no todos. Además, el caso del nombre accesible indica que la cobertura real en casos prácticos puede ser incluso menor.

La accesibilidad de Samsung en los electrodomésticos

En [Interview] How Samsung Embeds Accessibility and User-Centered Values Into Its Home Appliances se explican algunas de las características de accesibilidad que incorporan los electrodomésticos de Samsung.

Todo lo que se cuenta está muy bien, pero ¿y las personas ciegas que no pueden ver y usar la pantalla táctil? Supongo que existirá la posibilidad de conectarse al electrodoméstico desde un teléfono móvil y emplear el lector de pantalla en el teléfono móvil, pero no se cuenta nada así en este artículo.

Herramientas de Windows para mejorar la accesibilidad

 

Índice de Confianza Digital 2025: El estado de la accesibilidad digital en Europa

Digital Trust Index 2025: The State of Digital Accessibility in Europe es un análisis del estado de la accesibilidad digital en Europa. Algunos de los datos que incluye son:

266,000 European homepages from 18 countries were tested for accessibility issues, slighty more than the 2024 study. 

The state of accessibility in Europe is poor:

• We found accessibility issues on 93% of tested pages (92.97%).
• That’s less than a 1% improvement compared to 2024 (-0.84%).

Herramientas automáticas para evaluar y mejorar la accesibilidad web

 

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

 

Sentencia judicial en lenguaje claro

En “Hemos estudiado tu caso y tienes toda la razón, Aureliano”: el voto particular de una jueza para que el niño a la que va dirigida la sentencia la entienda podemos leer:

“Nos dirigimos a ti, Aureliano. Formamos el equipo judicial elegido para decidir sobre lo que nos pides. Nos has contado que te cuesta un poco más que al resto de los niños y niñas atender en la clase, estudiar, obedecer a tu mamá y a tu papá, hacer caso a tu hermano, no enfadarte, de repente, sin saber por qué, y que también te es difícil seguir, en general, el ritmo de las actividades en casa, la calle o el cole. Hemos estudiado tu caso, y tienes toda la razón, Aureliano te vamos a apoyar porque ahora entendemos por qué te cuesta más hacer las cosas”.

Así comienza el voto particular que la jueza Gloria Poyatos, presidenta de la Sala Social del Tribunal Superior de Justicia de Canarias, ha introducido en una sentencia dirigida a un niño de diez años y que tenía que decidir sobre el recurso que la Consejería de Derechos Sociales, Igualdad, Diversidad y Juventud de Canarias había interpuesto porque no quería reconocer “la discapacidad del 45%”, probada y con un diagnóstico de TEA que tiene el niño.

Y, como es a él a quien se dirigía el fallo, Poyatos quiso que él también pudiera entender qué se decía en ese documento que tiene nueve páginas y que, en general y como en todas las sentencias, el lenguaje que utiliza es puramente jurídico, fácilmente comprensible para quienes trabajan en ese mundo pero no tanto para cualquier otra persona ―no solo menores― que no lo haga o que no esté relacionada o acostumbrada a tratar con esos textos judiciales.

La magistrada, que fue presidenta de la Asociación de Mujeres Juezas y que lleva años trabajando por hacer de la justicia no solo una justicia con perspectiva feminista sino un ámbito que sea siempre comprensible para la ciudadanía, emitió ese voto particular ―que tuvo que ser un voto particular porque el TSJC no quiso incluirlo en el fallo―, para cumplir, simplemente, con la ley.

Errores de accesibilidad en webs de transporte público: barreras para moverse por la ciudad

 

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

 

No eres un especialista en accesibilidad hasta que hayas experimentado estas cosas

En You’re not an accessibility specialist until you’ve… se recoge una lista de las cosas (o las desgracias) que debe experimentar alguien antes de considerarse un especialista en accesibilidad:

• presented an accessibility audit report to stakeholders, checked after a year and found same issues with new variations,
• used hours to document an accessibility issue and how to fix it, just to see the JIRA (or any other project management) task to disappear back into the black hole called backlog,
• heard that accessibility is constraining design too much and that they will add this as an known issue to their accessibility statement,
• had to explain that color contrast has nothing to do with screen readers when you pointed out poor contrast found on text,
• had to explain, for the thousand time, that icon buttons need to be named,
• pointed out that status messages need to work with a screen reader as well,
• had to show developers how to properly connect label to the input field,
• had to explain why “here” is a very poor link name, and sometimes its cousin “click here” can also fail WCAG,
• watched a blind screen reader user in a user test struggle because somebody used wrong ARIA attributes,
• seen an end user test discover basic issues that you have warned about months ago, but still got stakeholders surprised,
• had to remind people to test with keyboards, yes, even on their touch only devices,
• needed to remove over-engineered ARIA,
• needed to explain why div itself is not a good choice for any interactive element,
• had to remind people to use aria-expanded on the button and not on the target,
• been silenced when a feature release was not accessible, but had to be released in time, because shareholders demand it,
• argued with SEO about image alternative texts on stock images that were not adding anything to the content and lost,
• before even reading a page – opened developer tools to check for accessibility issues,
• started a screen reader to go through a site on mobile just to check if they know their accessibility that they “strive to conform to”,
• tried to use voice control and gave up as your English pronunciation triggered unplanned things,
• wanted to buy a refreshable braille display, but the one you wanted costed more than all your devices combined,
• presented accessibility to people and wanted to share too much information at the same time,
• dreaming of being proactive member instead of doing webpage and app autopsies,
• proving that AI is still not ready to implement accessibility on it’s own,
• reading poor contrast text from yet another company betting on accessibility just before European Accessibility Act,
• having to test yet another “AI powered automatic testing tool” that is just using axe and ChatGPT behind it’s new user interface,
• getting a “thank you, we are working on it” message (or not even that) from a company after sending them a gentle reminder that their website is not accessible and pointing out some issues.
• …

Índice de la accesibilidad del código HTML generado por los modelos grandes del lenguaje

AIMAC (AI Model Accessibility Checker) Leaderboard mide la eficacia de los modelos grandes de lenguaje (Large Language Models, LLM) para generar HTML accesible de forma inmediata mediante indicaciones neutrales sin guías específicas de accesibilidad. Las comprobaciones se realizan con axe-core, un motor de pruebas de código abierto.

Ya llegó la Ley Europea de Accesibilidad (European Accessibility Act)

La Ley Europea de Accesibilidad (European Accessibility Act, EAA), aprobada en 2019, entró en vigor el 28 de junio de 2025 y, se espera, que marcará un cambio significativo en todos los países que forman la Unión Europea.

Si todavía no sabes qué es la EAA, algunos recursos que puedes consultar son:

• Accessibility Legislation at European Level
• Accessibility Standards at European Level
• Conoce la legislación europea en materia de accesibilidad

Ya llegó el 28 de junio de 2025

Hoy es 28 de junio de 2025, lo que significa que la European Accessibility Act (EAA) entra en vigor.

¿Qué supone esto? Muchas cosas. Por ejemplo, en Sacar dinero en efectivo cambia a partir de este 28 de junio: los cajeros deben adaptarse a la nueva normativa podemos leer:

Sacar dinero en efectivo nunca había sido tan fácil como con la ley de accesibilidad. El propósito de esta nueva normativa es el de garantizar que las personas con alguna discapacidad puedan realizar operaciones bancarias sin enfrentarse a barreras por su condición física o intelectual. La ley entra en vigor el 28 de junio, obligando a todas las entidades bancarias a actualizar sus cajeros conforme a los requisito estipulados. 

Entre las principales novedades se encuentra la ampliación del tamaño de la letra, audioguías y un rediseño en la interfaz y el menú. Estos cambios también beneficiarían a toda la ciudadanía mejorando el servicio. La ley también contempla mejoras dentro de las entidades financieras, puesto que estas deben formar su personal con el objetivo de ofrecer atención a la 'diversidad funcional'.

En la ley se contempla la necesidad de múltiples canales para garantizar una experiencia accesible para quienes les cuesta por cuál sea que sea el motivo. Entre las exigencias se encuentra el adaptar los iconos, el texto y el brillo de la pantalla para una mejor visualización. También será necesario que los cajeros incluyan auriculares para instrucciones de voz y botones con relieve o disposición intuitiva. 

La transformación se hará de manera progresiva, porque la ley distingue los cajeros nuevos de los ya existentes. Las entidades bancarias deben avisarle a sus clientes sobre los cajeros que ya están adaptados y cuáles siguen pendientes de mejoras, para que sus clientes conozcan, de antemano, los puntos que les favorece para hacer trámites bancarios.

Aquellos cajeros automáticos que funcionan antes del 28 de junio de 2025 podrán seguir operando hasta que finalice su vida útil económica, es decir, un límite máximo de 10 años.  Actualmente, en España hay alrededor de 47.000 cajeros automáticos e introducir los cambios para conseguir la máxima accesibilidad está entre los 1.500 y los 3.000 euros por unidad.

Galería de sitios web accesibles

AAA11Y (Accessible Website Gallery) es una galería de sitios web (supuestamente) accesibles.

Se pueden filtrar por nivel (A, AA, AAA), tipo (marca, portafolio, promoción), categoría (educativo, entretenimiento, moda) y color.

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

 

Diseñar sin excluir: el deber de la web

El medio digital BioBioChile me solicitó hace unos días un artículo de opinión sobre la accesibilidad web. Mi colaboración Diseñar sin excluir: el deber de la web se publicó el 17/06/2025:

Hablar hoy de la Web o de lo digital como “nuevas tecnologías” resulta anacrónico. La digitalización se ha vuelto tan omnipresente y fundamental en nuestras vidas como la electricidad: está en nuestras formas de comunicarnos, de informarnos, de trabajar, de aprender y de ejercer la ciudadanía.

La Web ya no es una novedad: es una infraestructura básica de nuestra vida social. Los sitios web de los medios de comunicación y de las instituciones públicas o privadas son mucho más que plataformas de información: son puertas de acceso a derechos, servicios, cultura y participación.

Por eso, garantizar que todas las personas puedan navegar por estos sitios web sin barreras —independientemente de sus capacidades físicas, sensoriales o cognitivas— no debería ser un gesto de buena voluntad, sino un compromiso firme con la equidad. Eso es, precisamente, lo que persigue la accesibilidad web: así como nadie cuestiona la necesidad de que la electricidad llegue al pueblo más pequeño o que un edificio esté correctamente electrificado, tampoco deberíamos discutir que un sitio web deba ser accesible para todas las personas.

Accesibilidad es para todas las personas

Al oír hablar de accesibilidad, ya sea física o digital, muchas personas piensan que solo beneficia a las personas con discapacidad. Pero esto no es verdad. Un sitio web accesible de un medio de comunicación no solo permite que, por ejemplo, una persona ciega pueda leer una noticia con su lector de pantalla, o que alguien con movilidad reducida pueda interactuar sin dificultades, sino que también mejora la experiencia general de todos los usuarios.

Accesibilidad también significa usabilidad, claridad, compatibilidad con distintos dispositivos y contextos de uso. Accesibilidad significa audiencias más amplias, contenidos más sostenibles y una imagen institucional más comprometida. Más allá del deber ético, la accesibilidad también ofrece una dimensión estratégica y de oportunidad para cualquier organización.

Las leyes existen, pero no bastan

Las leyes sobre accesibilidad web son imprescindibles: establecen estándares mínimos, definen responsabilidades y ofrecen un marco común para la exigibilidad. Sin embargo, las leyes por sí solas no garantizan que se vayan a aplicar y cumplir, y así lograr sitios web verdaderamente accesibles.

Por ejemplo, si fijamos la mirada en España, la Ley 34/2002 de servicios de la sociedad de la información y de comercio electrónico fue una ley pionera a nivel mundial, que obligó a las administraciones públicas españolas a garantizar la accesibilidad de sus sitios web antes del 31 de diciembre de 2005.

Han transcurrido casi 20 años desde esa fecha límite y no resulta difícil encontrar un sitio web de la administración pública española que no sea accesible, mientras que sí que resulta muy difícil encontrar uno que sí sea plenamente accesible.

Europa como referente: directivas que empujan el cambio

No obstante, es justo reconocer que en los últimos años la accesibilidad web ha avanzado en España y en el resto de los países de la Unión Europea, gracias al impulso que han proporcionado dos directivas europeas.

Por un lado, la Directiva (UE) 2016/2102 sobre la accesibilidad de los sitios web y aplicaciones para dispositivos móviles de los organismos del sector público —también conocida como Web Accessibility Directive (WAD)— obliga a que los sitios web de las administraciones públicas y ciertos organismos vinculados cumplan con los requisitos de accesibilidad establecidos en la norma europea EN 301 549, que está alineada con las pautas internacionales Web Content Accessibility Guidelines (WCAG) del World Wide Web Consortium (W3C).

Por otro lado, la Directiva (UE) 2019/882 sobre los requisitos de accesibilidad de los productos y servicios —también conocida como European Accessibility Act (EAA)— amplía las exigencias de accesibilidad a determinados servicios y productos del sector privado, incluidos los medios de comunicación. La EAA entró en vigor en junio de 2019 y estableció como fecha límite para su aplicación obligatoria el 28 de junio de 2025, dentro de unos pocos días.

El sector privado ha tenido 6 años para garantizar su cumplimiento y, sin embargo, una evaluación rápida de la accesibilidad de algunos sitios web de empresas españolas importantes demuestra que su cumplimiento es desigual.

Pero no seamos pesimistas: aunque el vaso de la accesibilidad web esté medio vacío o medio lleno —según lo pesimista u optimista que uno sea—, con un poco de esfuerzo de todos lograremos que esté completamente lleno.

Más allá del marco legal: un cambio de mentalidad 

¿Pero además de las leyes, qué más necesitamos para avanzar hacia una accesibilidad web plena?

Debemos dejar de pensar en la accesibilidad web como un añadido o como una obligación incómoda. La accesibilidad web se debe incorporar desde el inicio del diseño de un sitio web, con una perspectiva inclusiva y centrada en las personas.

Esto implica formar a los equipos de trabajo, establecer políticas institucionales claras, revisar los sistemas de publicación de contenidos y contar con mecanismos de evaluación y mejora continua. Todo un reto, por supuesto, pero es posible lograrlo.

Asimismo, debemos escuchar activamente a las personas con discapacidad. Como nos suelen recordar: “Nada sobre nosotros sin nosotros”. Las personas con discapacidad no solo son beneficiarias de la accesibilidad: son expertas en identificar barreras, proponer soluciones y enriquecer la comprensión de lo que significa una experiencia digital verdaderamente universal.

Una oportunidad para liderar desde los medios

En definitiva, apostar por la accesibilidad web es construir una sociedad digital más justa, más eficiente y más conectada.

Los medios de comunicación, en particular, tienen una responsabilidad enorme: no solo por su rol informativo, sino porque modelan valores y prácticas. Hacer accesibles sus sitios web no es solo cumplir con la ley: es ejercer su liderazgo social y moral.

Nueva versión de ISO 40500

Existe un borrador de ISO 40500 para que se actualice a WCAG 2.2:  ISO/IEC DIS 40500 Information technology — W3C Web Content Accessibility Guidelines (WCAG) 2.2.

¿Te puedes fiar de ChatGPT para preguntarle cosas sobre accesibilidad web?

Yo no me fiaría: cualquier cosa que le pregunto a ChatGPT (o a cualquier otro modelo grande del lenguaje), luego voy y la compruebo.

El otro día puse a prueba a ChatGPT con la siguiente pregunta:

¿Qué criterio de accesibilidad WCAG 2.2 incumple una marquesina?

La respuesta que me devolvió fue casi correcta:

¿En qué falló?

Todo lo que me contó era correcto, excepto que Success Criterion 2.2.2 Pause, Stop, Hide no es de nivel AA, es de nivel A.

La forma debe seguir a la función en la accesibilidad web

El término "Form Follows Function" (en español, "la forma sigue a la función") es un principio fundamental del diseño moderno y la arquitectura. El concepto fue popularizado por Louis Sullivan, un arquitecto estadounidense pionero de los rascacielos y figura clave de la Escuela de Chicago a finales del s. XIX.

En su obra "The Tall Office Building Artistically Considered" del año 1896 podemos leer:

Ya sea el águila en pleno vuelo o la flor de manzano abierta, el incesante trabajo de los caballos, el cisne alegre, la ramificación del roble, el arroyo que serpentea en su base, las nubes a la deriva, sobre todo el sol que cursa, la forma siempre sigue a la función, y esta es la ley. Dónde la función no cambia, la forma no cambia. Las rocas de granito, las colinas siempre inquietantes, permanecen durante siglos; el rayo, viene, toma forma, y muere, en un abrir y cerrar de ojos.

Es la ley que prevalece a todas las cosas orgánicas e inorgánicas, de todas las cosas físicas y metafísicas, de todas las cosas humanas y todas las cosas sobrehumanas, de todas las verdaderas manifestaciones de la cabeza, del corazón, del alma, que la vida es reconocible en su expresión, esa forma siempre sigue a la función. Esta es la ley.

Esta es la ley, ¿se cumple esa ley en la accesibilidad web?

En las interfaces digitales, la accesibilidad exige que el diseño sirva a la funcionalidad para todos los usuarios. Un botón no solo debe verse bien, sino debe ser operable con teclado, leído por un lector de pantalla y claro en su propósito.

La forma debe seguir a la función nos recuerda que el diseño debe priorizar la usabilidad y el propósito antes que la estética.

¿Qué significa la forma debe seguir a la función en accesibilidad web?

En el contexto de las páginas web, la forma debe seguir a la función implica que:

• La estructura y el diseño deben servir a la funcionalidad, no al revés.
• La experiencia del usuario (incluyendo personas con discapacidad) debe ser la prioridad.
• El contenido debe ser accesible antes de ser visualmente atractivo.

Algunos ejemplos de su aplicación en las páginas web son:

1. Jerarquía clara y estructura semántica.
   Usa encabezados (<h1> a <h6>) correctamente para guiar a los usuarios, especialmente a quienes usan lectores de pantalla.
   Asegúrate de que el orden del DOM coincida con el flujo lógico de la información.
2. Contraste y legibilidad antes que estilo.
   Elige combinaciones de colores con alto contraste (mínimo 4.5:1 para texto normal, mínimo 3:1 para texto grande).
   Evita tipografías decorativas que dificulten la lectura.
3. Interacciones accesibles, no solo "bonitas".
   Los elementos interactivos (botones, enlaces) deben ser fáciles de identificar y usar, incluso sin ratón.
   Evita dependencia de gestos complejos que excluyan a usuarios con movilidad reducida.

Curso de verano "Sitios web usables y accesibles con Wordpress"

La Universidad de Lleida organiza el curso de verano "Sitios web usables y accesibles con Wordpress", del 30 de junio al 4 de julio de 2025. Para más información se puede consultar:

• Publicación en Linkedin de la coordinadora Afra Pascual
• Afiche del curso Sitios web usables y accesibles con Wordpress

Una tesis de maestría sobre las capas de accesibilidad

En The Impact of Web Accessibility Overlays on the Usability and User Experience for People with Permanent Visual Impairments podemos leer en el resumen la conclusión de esta tesis de maestría:

The research shows that accessibility overlays, in their current form, do not effectively improve the usability or UX for individuals with permanent visual impairments. Although there is a slight improvement when users are unaware of the overlay’s presence, overall, UX and usability are considered marginal at best and deteriorate upon recognition and interaction with an accessibility overlay. Furthermore, the research displays that accessibility overlays in their current form cannot meet WCAG 2.1 AA standards. The study also finds that users with permanent visual impairments are generally hesitant to engage with accessibility overlays and prefer to rely on their existing access technologies. However, they are willing to use accessibility overlays under improved conditions, which are discussed in the thesis. The empirical knowledge gained guides future technology, designs, policies, and research to create a more inclusive digital world.

La Casa Blanca denunciada porque en las ruedas de prensa no hay intérpretes de la lengua de signos

En The White House is sued over lack of sign language interpreters at press briefings podemos leer:

The National Association of the Deaf (NAD) has filed a federal lawsuit against the White House over a lack of American Sign Language interpreters at media briefings.

The NAD says the White House abruptly stopped providing ASL interpreters during press briefings and other public events when President Trump returned to office for a second term.

The lawsuit, filed on Wednesday, asks the court to require ASL interpreters be present at these events and that video of them be available for viewers.

ASL is distinct from English, with its own vocabulary and grammar. The NAD says "at least several hundred thousand" people in the U.S. communicate mainly in ASL, and many deaf and hard of hearing people know little English. That's why the group says English closed captioning of briefings is not sufficient.

[...]

The NAD says the White House ignored its repeated requests, including a letter sent to Wiles in January. According to the group, more than 48 million deaf or hard of hearing people live in the U.S.

¿Dónde está el último informe sobre el resultado del seguimiento de la accesibilidad web?

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 indica en el Artículo 8 Seguimiento y presentación de informes

4.   A más tardar el 23 de diciembre de 2021 y, posteriormente, cada tres años, los Estados miembros presentarán a la Comisión un informe sobre el resultado del seguimiento, en el que se incluyan los datos de las mediciones. Dicho informe se redactará basándose en las disposiciones para la presentación de informes a que se refiere el apartado 6 del presente artículo. El informe también incluirá información sobre el uso del procedimiento de aplicación establecido en el artículo 9.

En Web Accessibility Directive - Monitoring reports 2020-2021 podemos encontrar los informes que se presentaron la primera vez. El informe de España está disponible.

En Web Accessibility Directive - Monitoring reports 2022-2024 podemos encontrar los informes que se presentaron la segunda vez. El informe de España NO ESTÁ DISPONIBLE.

En Member States' bodies in charge of monitoring the Web Accessibility Directive se recogen los responsables en cada país de la Unión Europea de presentar los informes sobre el resultado de seguimiento. En el caso de España se indica que es el Observatorio de Accesibilidad Web.

En el Portal de administración electrónica sí que se puede localizar el Informe sobre el resultado del seguimiento. Periodo 2022-2024.

[30/05/2025]

He consultado al Observatorio de Accesibilidad lo siguiente:

¿España no ha presentado el informe a la Unión Europea? El informe veo que tiene fecha "Marzo 2025", ¿quizás se ha enviado recientemente y la Unión Europea todavía lo está procesando?

Y me han contestado:

Es como dices, el informe se presentó a la Comisión poco después de que saliera esa noticia y para entonces todavía no estaba disponible.

Currículo sobre accesibilidad web del W3C

El W3C ofrece el Curricula on Web Accessibility: A Framework to Build Your Own Courses como una ayuda para desarrollar cursos sobre accesibilidad web.

En el siguiente vídeo, Daniel Montalvo, miembro del W3C-WAI, explica las principales características y posibilidades de uso de este currículo:

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.

Más información: FTC Order Requires Online Marketer to Pay $1 Million for Deceptive Claims that its AI Product Could Make Websites Compliant with Accessibility Guidelines 

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

 

¿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.

No todos los errores de accesibilidad tienen el mismo impacto

En WebAIM han publicado Using Severity Ratings to Prioritize Web Accessibility Remediation:

When it comes to prioritizing web accessibility fixes, ranking the severity of each issue is an effective way to prioritize and make impactful improvements. In WebAIM’s accessibility audits, each issue we identify is assigned one of four levels of severity based on how it impacts end users. In this article, we’ll go over these severity ratings for accessibility and the types of issues that typically fall under these categories.

Comparativa de herramientas automáticas de evaluación de la accesibilidad web

En Comparing Manual and Free Automated WCAG Reviews podemos encontrar una pequeña comparativa de cuatro herramientas automáticas: axe DevTools, ARC Tookit, WAVE y Equal Access Accessibility Checker.

Análisis de la generación automática de descripciones de imágenes mediante inteligencia artificial

En AI-Generated Images from AI-Generated Alt Text se presenta un pequeño análisis de las descripciones que algunas herramientas generan de forma automática mediante inteligencia artificial. Además, después se emplean esas descripciones para generar imágenes de forma automática y comparar la imagen original con las imágenes generadas.

En la Generalitat de Cataluña todavía viven en la prehistoria de la accesibilidad web

El 30 de noviembre de 2023, en el número 9052 del Diari Oficial de la Generalitat de Catalunya se publicó el DECRETO 209/2023, de 28 de noviembre, por el que se aprueba el Código de accesibilidad de Cataluña.

Según la propia Generalitat de Catalunya, Cataluña se convertía en referente en accesibilidad universal.

¿Será verdad?

Bueno, en la página 373, la última página de este Decreto, podemos encontrar esta maravilla:

W

Web accesible: web que permite que las personas con discapacidad puedan percibir, entender, navegar e interactuar mediante páginas web accesibles que incluyan todos los contenidos y cumplen lo que establece la norma UNE 139803:2012 Requisitos de accesibilidad para contenidos en la web.

¿En serio? ¿La norma UNE 139803:2012?

Zac Browser, el navegador web para niños autistas, ha vuelto

Allá por el año 2008 (Un navegador web para niños autistas) y el año 2009 (El navegador para niños autistas triunfa) escribí sobre el navegador web Zac Browser, un navegador que un abuelo hizo para su nieto.

De casualidad me he topado con este producto en una página web y parece que todavía sigue existiendo. En el siguiente vídeo se muestran algunas de sus características.

Eye tracking en iPhone

En mayo 2024, Apple presentó algunas novedades de accesibilidad de su sistema operativo iOS para sus dispositivos móviles (Apple announces new accessibility features, including Eye Tracking, Music Haptics, and Vocal Shortcuts). Uno de los nuevos sistemas que incorpora es el seguimiento de la mirada o eye tracking (Control iPhone with the movement of your eyes).

Una vez calibrado el sistema, su manejo es muy sencillo (cuando funciona). Para ejecutar una pulsación simplemente hay que mantener la mirada sobre un punto de la pantalla durante varios segundos.

Ya hay varios vídeos que muestran su funcionamiento:

Consejos para definir un buen nombre accesible

En los artículos Good Intentions, Poor Context y Context is king: long live the king! se explican diferentes técnicas para escribir un buen nombre accesible para los elementos de una página web.