5 min de lectura
El BOE publicó el 3 de septiembre el Real Decreto 707/2026, que aprueba el Reglamento de las condiciones básicas de accesibilidad cognitiva. Entra en vigor el 2 de enero de 2027 y afecta a administraciones públicas, telecomunicaciones, justicia, sanidad, transporte, procesos electorales y servicios digitales. Su objetivo, en la propia norma: que la información, los trámites y los entornos sean comprensibles, no solo accesibles técnicamente. Y ahí está la parte que UX lleva años defendiendo sin que nadie la convirtiera en ley: cumplir una checklist técnica y que algo se entienda de verdad son dos cosas distintas.
Lo que dice la norma, resumido
El reglamento desarrolla el mandato de la Ley 6/2022 y fija condiciones mínimas comunes para todo el territorio español. Su artículo 6 obliga explícitamente a las administraciones públicas, los proveedores de telecomunicaciones y los prestadores de servicios de la sociedad de la información a garantizar la accesibilidad cognitiva de sus contenidos, documentos, formularios y sistemas de interacción, incluyendo los procesos de identificación, firma y pago. Las herramientas previstas son lenguaje claro, lectura fácil, pictogramas, formatos alternativos y sistemas aumentativos de comunicación.
Un matiz importante que la mayoría de cobertura pasa por alto: el reglamento no habla solo de discapacidad intelectual. Reconoce explícitamente que las dificultades cognitivas pueden derivar también de la edad, de situaciones de salud, de factores socioeconómicos o de circunstancias contextuales como no dominar el idioma. Dicho de otra forma: la norma protege tanto a alguien con discapacidad intelectual como a tu abuela rellenando un formulario de la Seguridad Social, o a un ciudadano extranjero navegando la web de Hacienda por primera vez.
Cumplir WCAG no es lo mismo que diseñar para accesibilidad cognitiva
Esta es la distinción que la ley acaba de reconocer y que en UX llevamos años intentando explicar a clientes que solo quieren «pasar la auditoría»: las WCAG (las pautas de accesibilidad web más usadas a nivel internacional) se centran en criterios perceptibles, operables y robustos: que haya suficiente contraste de color, que el texto alternativo describa una imagen, que se pueda navegar con teclado, que un lector de pantalla lea el contenido en el orden correcto. Un formulario puede cumplir el 100% de esos criterios técnicos y, aun así, ser completamente incomprensible: frases de veinte palabras con tres subordinadas, jerga legal sin explicar, un flujo de siete pasos sin indicar en cuál estás ni cuántos quedan. Eso pasa la auditoría de accesibilidad técnica sin ningún problema, y a la vez deja fuera exactamente a las personas que la ley acaba de decidir proteger.
La accesibilidad cognitiva vive en una capa distinta, mucho menos técnica y mucho más de contenido y arquitectura de la información: frases cortas con una sola idea, evitar la voz pasiva y los tecnicismos innecesarios, mostrar progreso claro en procesos de varios pasos, usar ejemplos concretos en vez de abstracciones, y apoyar el texto con pictogramas o imágenes cuando aporten algo real, no como decoración. No es un checklist que se pueda automatizar con una herramienta de escaneo, como sí ocurre en buena parte de WCAG. Requiere diseñar el contenido, no solo maquetarlo.
Dónde más se va a notar el cambio
Banca y seguros. Condiciones generales de 40 páginas, cláusulas de «subrogación» sin explicar, procesos de contratación con múltiples pantallas sin indicación de en qué paso estás. Es probablemente el sector con más distancia entre «cumple la normativa» y «se entiende».
Sanidad. Consentimientos informados redactados en lenguaje clínico, citas y volantes con terminología que ni el propio paciente sabe interpretar. El reglamento menciona explícitamente la sanidad como ámbito de aplicación obligatoria.
Formularios y trámites públicos. Este es probablemente el ejemplo más citado, y con razón: la propia norma regula detalles muy concretos, como que los impresos destinados a la ciudadanía reserven espacio suficiente para rellenarse con comodidad, eviten fondos con poco contraste, y vayan acompañados de instrucciones claras y concisas. Es la clase de detalle que un diseñador UX lleva años pidiendo y que, hasta ahora, dependía por completo de la buena voluntad de cada organismo.
Ecommerce. Procesos de pago con múltiples pasos ocultos, condiciones de devolución en letra pequeña, checkouts que cambian de diseño entre pantallas. Aunque la obligación legal recae sobre todo en el sector público y proveedores de telecomunicaciones/sociedad de la información, marca un estándar que empieza a hacer quedar mal, por comparación, a cualquier ecommerce que siga diseñando checkouts pensados solo para «el usuario medio». Es la misma idea que desarrollamos al hablar de cuánto cuesta un checkout mal diseñado.
¿Esto cambia cómo hay que diseñar, o solo añade otra checklist más?
Depende de quién lo implemente. Si las organizaciones tratan esto como un trámite más («añadimos un botón de lectura fácil y ya cumplimos»), el resultado será el mismo teatro de cumplimiento que ya hemos visto con WCAG en muchas webs: pasan el escaneo automático y siguen siendo un jeroglífico para cualquiera que no tenga ya el contexto necesario. Pero si se toma en serio, obliga a algo mucho más interesante: que el diseño de contenido y el redactado claro dejen de ser el último paso opcional de un proyecto y pasen a formar parte del proceso desde el principio, al mismo nivel que el contraste de color o la navegación por teclado. Esa es la verdadera novedad de esta ley, no el reglamento en sí: es la primera vez que comprender algo se reconoce, por escrito y con fuerza legal, como una forma de accesibilidad tan válida como poder verlo o poder navegarlo. Es el mismo principio que subyace en la ley de que aceptar y rechazar cookies sea igual de fácil: la claridad ya no es solo buena práctica de diseño, es un derecho exigible.
