Todo tipo de información sobre accesibilidad en la Web: errores de accesibilidad, ejemplos de páginas inaccesibles, noticias, software, hardware, productos de apoyo, consejos, pautas y guías de accesibilidad, WAI, WCAG, Norma EN 301 549, legislación, etc.
10 years ago, I was front-end web developer who was working directly on a map-module component that helped users find a specific location for insurance needs. While I built it at what I felt like was record time, I got to the end, ready to deliver and got a lovely hashtag#Accessibility audit sent to me. My initial thought? "What in the hell is this?!!".
But that moment, was the moment that opened my eyes and my mind up to hashtag#A11y. After sitting with many users and getting mentored by many folks such as Birkir Gunnarsson and Tim Harshbarger (to name a few, there are so many more!) I realized how much my own code was causing people frustration and pain.
I share this story because every year around this time, I am reminded how much that moment has changed me. My own personal mission has been to tell my story of my own stubborn, arrogant mind not realizing the impact of my own development and get more people to begin giving even the littlest bit of a damn about making their content accessible.
As I always say, you accessibility folks are amazing. Keep fighting. Keep pushing. Accessibility always and forever!
Y traducido al español:
Hace 10 años, era desarrollador web front-end y trabajaba directamente en un módulo de mapas que ayudaba a los usuarios a encontrar una ubicación específica para sus necesidades de seguros. Aunque lo desarrollé en lo que yo consideraba un tiempo récord, al terminarlo, listo para su entrega, recibí una auditoría de accesibilidad (#Accessibility). ¿Mi primera reacción? "¿¡Qué demonios es esto!?".
Pero ese momento me abrió los ojos y me hizo comprender la importancia de la accesibilidad (#Accessibility). Tras reunirme con muchos usuarios y recibir mentoría de personas como Birkir Gunnarsson y Tim Harshbarger (por nombrar solo algunos, ¡hay muchísimos más!), me di cuenta de cuánta frustración y dificultades les causaba mi propio código.
Comparto esta historia porque cada año por estas fechas recuerdo cuánto me cambió ese momento. Mi misión personal ha sido contar mi historia sobre mi propia terquedad y arrogancia, que me impedía darme cuenta del impacto de mi propio desarrollo, y lograr que más personas se preocupen, aunque sea un poco, por hacer que su contenido sea accesible. Como siempre digo, ¡sois increíbles los que trabajáis por la accesibilidad! ¡Seguid luchando! ¡Seguid adelante! ¡Accesibilidad siempre y para siempre!
Los emojis cada vez se usan más y no solo en las conversaciones de WhatsApp y plataformas similares. Las páginas web, los correos electrónicos e incluso las comunicaciones institucionales cada vez tienen más emojis.
¿Los emojis plantean problemas de accesibilidad? Sí, unos cuantos.
En el caso de las personas con discapacidad que emplean un lector de pantalla, ¿qué anuncia el lector de pantalla cuando se encuentra un emoji?
Where do screen readers get the alternative text for unicode characters from?
Steve Faulkner shares that the text alternatives for Unicode symbols are usually contained within a text file in screen reading software’s program files directory.
Emojis, like other unicode characters, also have default text alternatives that may differ slightly across platforms, as Steve demonstrates in his article.
The text alternatives of emojis usually describe what the emoji is, not necessarily what you might be using it for. As Craig Abbott mentions in his recent writeup about integrating AI into screen readers, the “red flag” emoji is actually announced as “triangular flag on post”, which does not usually provide enough context for the way that emoji is used in our culture.
Not to mention that the same emoji may be interpreted differently by different sighted users!
This is why using emojis to communicate meaningful information is generally not recommended.
Steve Faulkner tiene la página web Symbol text descriptions in NVDA en la que recoge lo que NVDA anuncia para más de 3900 símbolos.
Lo que NVDA anuncia para los símbolos se puede configurar a través de Preferencias > Pronunciación de Símbolos:
En Optimizing GitHub Copilot for Accessibility with Custom Instructions se explica cómo emplear las "custom instructions" para adaptar el comportamiento de GitHub Copilot a las necesidades específicas de una organización o repositorio, garantizando que sus sugerencias se alineen con los estándares, flujos de trabajo y objetivos de accesibilidad del equipo. Para ello hay que tener en cuenta que existen tres niveles de configuración:
Organización: define las directrices generales de accesibilidad que se aplican a todos los repositorios.
Repositorio: permite establecer excepciones o requisitos específicos para un proyecto concreto.
Personal: ajusta el comportamiento de Copilot Chat según las preferencias individuales, teniendo prioridad sobre las demás instrucciones.
En el artículo se explican buenas prácticas (Do’s) y malas prácticas (Don’ts).
Muy buena la reflexión de Karl Groves, gurú de la accesibilidad web a nivel mundial, sobre WCAG 3: Why Now Is Not the Time to Think About WCAG 3. Para mí, todo lo que explica se puede resumir en esto que dice:
WCAG 3 is basically still research.
[WCAG 3 sigue siendo básicamente investigación.]
Así que, básicamente mejor esperar a intentar realizar cualquier cambio.
Hola, soy Sergio Luján Mora, profesor de informática de la Universidad de Alicante, y en este vídeo que forma parte del curso “Introducción al desarrollo web”, te voy a hablar de la importancia de ofrecer estilos alternativos en una página web.
Si se les pregunta a los usuarios de la Web cómo es una página web “buena”, probablemente la mayoría pensará en un diseño visual atractivo, con colores armónicos, tipografías modernas y animaciones, muchas animaciones. Y no les faltaría razón. Pero ¿qué pasa cuando este diseño, pensado para la mayoría, no funciona para todos?
A las páginas web acceden miles de millones de usuarios, muchos de ellos con necesidades, preferencias y contextos de uso diferentes. En especial, las personas con discapacidad muchas veces experimentan problemas, barreras, al navegar por las páginas web.
Por ejemplo, este artículo del prestigioso periódico The New York Times tiene un importante problema de contraste en el título del artículo y en la entradilla. [P] Una persona sin discapacidad seguramente leerá con algunos problemas el título y la entradilla. Pero una persona con discapacidad visual o discapacidad cognitiva quizás sea incapaz de leerlo y entenderlo.
Este problema es muy fácil de resolver.
Los diseñadores web del periódico The New York Times podrían simplemente añadir un fondo semitransparente al título y a la entradilla que aumentase el contraste entre el texto y la fotografía de fondo.
¿Y esto cómo se hace? Seguramente pensarás que es difícil o requiere mucho tiempo y por eso no lo han hecho. Bueno, en realidad, en lo que he tardado en sacarme un moco de la nariz he añadido el código necesario para resolver este problema.
Y entonces, ¿por qué no lo han hecho? Bueno, podemos pensar en muchas razones, pero por mi experiencia, normalmente, el propietario o el diseñador del sitio quiere que su sitio web se vea exactamente de una forma concreta, aunque eso sea negativo para muchos usuarios.
La solución a esta situación es sencilla, podemos diseñar nuestro sitio web con un estilo principal y con todas las mierdas que queramos, aunque nos estemos pegando un tiro en el pie.
Pero a la vez, también debemos ofrecer estilos alternativos para desarrollar una web verdaderamente universal y robusta.
Los estilos alternativos son versiones de nuestra hoja de estilos principal que ofrecen una experiencia de usuario diferente. No son un sitio web nuevo, sino una adaptación del mismo contenido. Los más comunes son:
Estilo oscuro: para reducir la fatiga visual en entornos con poca luz o por preferencia personal.
Estilo de alto contraste: para usuarios con baja visión.
Estilo texto grande: para usuarios con baja visión.
Estilo daltonismo: que ajusta la paleta de colores para garantizar que la información se perciba correctamente.
Estilo de lectura: que elimina elementos superfluos como menús y publicidad para concentrarse en el contenido principal.
Estilo para impresión: elimina elementos superfluos como menús y adapta el contenido al tamaño de una hoja de papel.
Hoy en día, muchos sitios web ofrecen algunos de estos estilos alternativos. Por ejemplo, en mi sitio web sobre accesibilidad web ofrezco una opción de configuración que permite que el usuario seleccione un estilo que se adapte mejor a sus necesidades: el estilo principal, dos estilos de alto contraste (amarillo sobre negro y verde sobre negro), colores de bajo contrate y estilos con diferentes tipos de letra.
Aquí tenemos otro ejemplo, la web de La Moncloa, que por defecto aparece con el modo claro, pero que tiene una opción para cambiar al modo oscuro.
¿Y cómo se ofrecen los estilos alternativos en un sitio web? Existen varias formas, en el vídeo “CSS: definición y uso de estilos alternativos” te explico una forma que se puede emplear en Mozilla Firefox, de forma nativa, y en otros navegadores web con alguna extensión. Pero en la mayoría de los casos, tendrás que proporciona un selector de estilos como el que hemos visto en la web de La Moncloa.
Sobre el estilo para impresión te recomiendo los siguientes vídeos. Por un lado, te recomiendo que veas el vídeo “CSS: hoja de estilo para impresión”, del estudiante Samuel López Brufal. En este vídeo se enseña a crear un CSS correcto para imprimir las páginas web.
Muchos diseñadores no optimizan las páginas web para impresión, lo que genera confusión al imprimir.
Samuel propone los siguientes consejos para una correcta hoja de estilo para impresión:
Diseño adaptativo para impresión.
Uso de tonos blancos y negros (o colores originales si es necesario).
Incluir las URLs visibles para referencia posterior.
Y aplicar filtros CSS para mejorar los resultados.
En el vídeo de Samuel también se explica que se deben evitar las divisiones en tablas y listas con las siguientes propiedades de CSS: page-break-inside, page-break-before y page-break-after.
En realidad, estas propiedades de CSS están obsoletas y en su lugar se deben emplear las propiedades break-after, break-before y break-inside.
El tema de evitar las divisiones en tablas y listas lo tienes desarrollado con más profundidad en los siguientes vídeos. “CSS: cómo controlar los puntos de corte cuando se imprime una página”, parte 1 y parte 2. Y con esto finaliza este vídeo en el que te he explicado la importancia de los estilos alternativos en las páginas web.
Recuerda que este vídeo forma parte del curso “Introducción al desarrollo web” que está disponible en la dirección idesweb.es.
La publicación de WCAG 2.2 como estándar ISO supone un importante respaldo para su implantación, ya que W3C no está reconocido como un organismo estandarizador, pero ISO sí que lo es.
Esperemos que este estándar ISO se convierta en un estándar UNE, con su correspondiente traducción al español, lo que ayudará a su empleo en España y muchos países de Latinoamérica.
En aria-label or title? Screen Reader Behaviour Explained se explica la diferencia entre los atributos aria-label y title, su importancia para la accesibilidad web y consejos para su correcto uso.
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.
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.
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.
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.
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.
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:
Lenguaje claro y directo: Se evitan las palabras rebuscadas, jergas, tecnicismos o frases demasiado formales.
Frases cortas: Se prefieren oraciones simples y de longitud moderada para facilitar la comprensión.
Estructura lógica y ordenada: Las ideas se presentan de forma coherente, con buena organización del contenido.
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.
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.
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.
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.
