Actualizado: .
La accesibilidad básica no debería exigir activar un modo especial. Una persona debe poder encontrar información, comprenderla y realizar una acción en la interfaz habitual. Los ajustes personales son útiles cuando amplían esa posibilidad, no cuando disimulan su ausencia.
Al hablar de accesibilidad con especialistas que evalúan y certifican sitios web de organismos públicos, llegué a una conclusión sencilla: hay que evaluar si las personas pueden utilizar el servicio. Una persona debe poder leer las condiciones, rellenar un formulario y obtener un resultado sin tener que buscar primero una versión especial del sitio.
Que me resulte fácil no significa que sea accesible
Imaginemos la reserva de una consulta. Texto grande, colores definidos y un botón claro. Sin embargo, la fecha solo se puede elegir arrastrando, los errores se señalan únicamente con un borde rojo y la confirmación aparece durante dos segundos sin anunciarse. Una pantalla visualmente cuidada impide que algunas personas completen la reserva.
La accesibilidad va más allá de la visión. Importan el manejo sin movimientos precisos, el acceso a la información sin sonido, las instrucciones comprensibles, la posibilidad de leer al propio ritmo y el uso de tecnologías de apoyo. Las limitaciones circunstanciales hacen que muchas de estas decisiones beneficien a un público más amplio. Pero no justifican diluir las necesidades de las personas con discapacidad en la frase genérica «fácil para todos».
Tres capas que no pueden sustituirse entre sí
Base: el contenido, la semántica, los controles y la respuesta a las acciones son accesibles en la interfaz principal. Compatibilidad: el sitio sigue funcionando con ampliación, cambios en los colores del sistema y lectores de pantalla. Personalización: cada persona elige una presentación cómoda, como el tema o la densidad del texto.
Este es nuestro modelo de trabajo para diseñar, no una nueva clasificación de WCAG. Su idea es sencilla: un selector de tema no arregla un botón que no se puede activar con el teclado. Del mismo modo, un botón correctamente implementado no elimina la utilidad de los ajustes individuales.
¿Qué problema tiene una «versión para baja visión»?
El problema empieza cuando un modo separado sirve de excusa para mantener inaccesible la versión principal. Primero hay que encontrar el selector, comprender para qué sirve y poder activarlo. Si está oculto en un menú inaccesible, la solución ya está fuera de alcance antes de empezar.
Sin embargo, la mera existencia de ajustes no demuestra nada sobre la competencia del equipo. No podemos afirmar que todas las personas con deficiencias en la visión del color ya hayan configurado filtros del sistema, ni que nadie necesite ampliar el texto desde el sitio. Las necesidades, los dispositivos y las habilidades varían. Nuestra posición de diseño es corregir primero la interfaz básica y ofrecer después una personalización útil.
Tampoco conviene presentar esta posición como una prohibición literal de WCAG de ofrecer presentaciones alternativas. El estándar establece condiciones para las versiones alternativas conformes. Es un concepto más exigente que un botón para cambiar de tema: hay que verificar la equivalencia de la información y la funcionalidad, además de la accesibilidad del acceso a esa versión.
Cuatro mitos que dificultan mejorar un producto
- «Añadimos un widget y ya tenemos accesibilidad». Primero comprobemos qué ha cambiado en las tareas reales. Un filtro de color, por sí solo, no explica un error del formulario ni da un nombre significativo a un botón.
- «Solo hace falta buen contraste». Una etiqueta legible no resuelve un control que funciona exclusivamente con el ratón.
- «Cuanto más ARIA, mejor». Un rol incorrecto puede ocultar el significado original del elemento. Es preferible un HTML correcto con los añadidos necesarios, en lugar del mayor número posible de atributos.
- «La prueba automática sale en verde: hemos terminado». La automatización comprueba algunas condiciones. No sustituye a una persona completando la tarea.
Estas dos últimas limitaciones se explican directamente en ARIA Authoring Practices y en la guía de WAI sobre herramientas de evaluación.
¿WCAG es realmente un estándar oficial?
W3C publica WCAG. La categoría W3C Recommendation identifica una especificación madura recomendada como estándar web. WCAG 2.2 también se adoptó como ISO/IEC 40500:2025, según anunció W3C el 21 de octubre de 2025. No es simplemente el consejo de un bloguero o de un fabricante de lectores de pantalla.
Un estándar y una ley, sin embargo, son cosas distintas. La versión aplicable, el nivel de conformidad, las organizaciones afectadas y los plazos dependen de la jurisdicción, el contrato o el procedimiento de contratación. No se puede afirmar universalmente que «todos los sitios están obligados por ley a cumplir WCAG 2.2 AA».
En un desarrollo nuevo, es razonable fijar WCAG 2.2 AA como objetivo técnico si los requisitos del proyecto no indican otra cosa. AA incluye los criterios aplicables de nivel A y AA; no es una nota media ni un porcentaje de comprobaciones superadas. Además, cumplir el estándar no significa satisfacer absolutamente todas las necesidades individuales.
Cómo convertir el principio en una decisión práctica
Para cada acción importante, anote cuatro cosas: qué quiere hacer la persona, qué barrera se lo impide, qué cambiaremos y cómo comprobaremos el resultado. Por ejemplo: «Elegir fecha → el calendario solo funciona con ratón → añadir manejo por teclado y una entrada de fecha clara → completar la reserva sin ratón y comprobar que se anuncia el día seleccionado».
Así se obtiene un requisito comprobable en lugar de una promesa decorativa. Empiece por iniciar sesión, buscar, enviar una solicitud, pagar, cancelar y recuperarse de un error. El éxito se mide por la posibilidad de completar todo el recorrido de forma autónoma, no por el número de botones especiales.
Accessible UI para Codex y Claude Code
A partir de esta investigación, creamos skills abiertos para Codex y Claude Code que ayudan a analizar y mejorar sitios web y aplicaciones. Accessible UI guía la revisión de la semántica, el teclado, el foco, los formularios y el contraste; Adaptive Interfaces ayuda a adaptar la interfaz al tamaño de la ventana, la escala del texto, el teclado y los dispositivos plegables. El agente examina el proyecto real, propone mejoras fundamentadas y verifica los cambios acordados. Estos skills no sustituyen las pruebas con usuarios y tecnologías de asistencia.
Si desarrolla interfaces con asistentes de IA, puede obtener el skill Accessible UI en GitHub. Este paquete de instrucciones reúne las reglas prácticas de la serie: semántica, teclado, foco, formularios, contraste y verificación. Las instrucciones están en inglés.
Instalación desde GitHub: en Codex, envíe este comando al instalador de skills integrado:
$skill-installer install https://github.com/wladislaw353/agent-skills/tree/main/skills/accessible-uiEn Claude Code, la colección se puede instalar como plugin desde el mismo repositorio. Las instrucciones para Claude Code en GitHub explican la instalación, las actualizaciones y cómo invocar cada skill. Un skill instalado mediante el plugin usa un nombre como /agent-skills:accessible-ui; instalado por separado, usa /accessible-ui.
Para instalarlo manualmente, clone el repositorio de GitHub. Coloque el contenido de skills/accessible-ui en el directorio de la herramienta que utilice:
- Codex:
~/.agents/skills/accessible-ui/ - Claude Code:
~/.claude/skills/accessible-ui/
El archivo SKILL.md debe quedar directamente dentro de accessible-ui. Abra una sesión nueva después de instalarlo. Para invocarlo explícitamente, use $accessible-ui en Codex CLI o en la extensión para el IDE, o /accessible-ui en Claude Code.
Fuentes y estado de los estándares verificados el 5 de noviembre de 2026.