Castrillón Mata

El Centro Criptológico Nacional publicó en mayo de 2026 la Guía CCN-STIC 465 de Ciberaccesibilidad. Su tesis es contraintuitiva pero sólida: accesibilidad y ciberseguridad no se estorban, convergen. Un usuario que entiende lo que hace se equivoca menos y es más difícil de engañar.

La guía aplica a webs y servicios del sector público bajo el ENS, pero también a entidades privadas que quieran adoptarla como referencia. Está pensada para perfiles técnicos, de seguridad, de diseño y de cumplimiento normativo. Y se organiza en diez bloques temáticos en los que cada criterio WCAG se cruza con su equivalente de seguridad.

Vamos uno por uno, con ejemplos reales.

Bloque 1. Color

WCAG relacionados: 1.4.1 (uso del color), 1.4.3 y 1.4.6 (contraste), 1.4.11 (contraste no textual).

El color no puede ser el único canal de información. Para accesibilidad, porque hay personas que no lo distinguen. Para seguridad, porque un atacante puede imitar el color del sistema y fabricar un aviso falso.

Ejemplo de fallo: un formulario marca los campos obligatorios solo en rojo. Una persona con daltonismo no los identifica. Y un atacante que clona la web puede pintar avisos en rojo idénticos para inducir clics en enlaces maliciosos sin que el usuario los distinga del sistema real.

Solución convergente: color + texto + icono. «Campo obligatorio» escrito al lado, un asterisco con etiqueta accesible, un icono identificable. El color refuerza, pero no decide.

Otro caso típico: los captchas basados en distinguir colores. Excluyen a personas con problemas de visión y, además, son sorteables por bots modernos. Alternativa: captchas con respuesta háptica, audio, o preguntas de contexto lógico.

Bloque 2. Imágenes

WCAG relacionados: 1.1.1 (contenido no textual), 1.4.5 y 1.4.9 (imágenes de texto).

Cada imagen, icono o gráfico necesita una alternativa textual que comunique lo mismo. Para accesibilidad, porque un lector de pantalla la lee. Para seguridad, porque si el texto alternativo miente o engaña, se convierte en un vector de ataque.

Ejemplo de fallo: un botón gráfico con la imagen de un candado y el texto alternativo «Pulsa aquí para continuar». Una persona ciega no sabe qué está confirmando. Si el botón en realidad cierra sesión o transfiere dinero, el desajuste entre lo que la imagen sugiere y lo que el alt declara puede usarse para inducir acciones no deseadas.

Solución convergente: coherencia semántica estricta. La imagen, el alt, el title y la función real del elemento deben decir lo mismo. Y en procesos críticos (login, pago, confirmaciones), el texto manda sobre la imagen.

Mala práctica frecuente: incluir información sensible en el alt, como «Transferencia enviada correctamente a la cuenta ES12 3456…». Eso lo lee cualquiera que inspeccione el HTML. El alt es contenido público, no un campo de privacidad.

Bloque 3. Teclado

WCAG relacionados: 2.1.1 y 2.1.3 (operable por teclado), 2.1.2 (sin trampas de foco), 2.1.4 (atajos), 2.4.7 (foco visible).

Todo debe poder hacerse con teclado, y el usuario debe ver siempre dónde está su foco. Para accesibilidad, porque hay personas que no usan ratón. Para seguridad, porque un foco invisible o secuestrado es una puerta abierta a robo de credenciales y a ataques de focus hijacking.

Ejemplo de fallo: un formulario de pago donde, al pulsar Tab, el foco salta de un campo a otro sin indicador visible. El usuario escribe creyendo estar en el campo de la tarjeta y en realidad está en un campo oculto que captura su número.

Solución convergente: indicador de foco siempre visible (borde, sombreado, contraste mínimo 3:1), orden de tabulación predecible y sin saltos, y la posibilidad de salir de cualquier elemento con Esc o Tab.

Caso a vigilar: los atajos de teclado de una sola tecla. Mejoran la usabilidad pero pueden chocar con lectores de pantalla y, peor, ser reemplazados por scripts maliciosos que se hagan eco del evento. La solución es ofrecer atajos personalizables y activables/desactivables.

Bloque 4. Puntero

WCAG relacionados: 2.5.1 (gestos), 2.5.2 (cancelación), 2.5.5 y 2.5.8 (tamaño del objetivo).

Las acciones con ratón o táctil deben ser simples, reversibles y con respuesta visual clara. Para accesibilidad, porque hay personas con movilidad reducida. Para seguridad, porque las zonas activas pequeñas o invisibles son terreno fértil para el clickjacking.

Ejemplo de fallo: un banner con botones de 12 píxeles muy juntos. Una persona con temblor pulsa el botón equivocado. Un atacante superpone un botón invisible sobre el banner y el usuario, al intentar dar al correcto, activa el malicioso sin saberlo.

Solución convergente: tamaño mínimo de 24×24 píxeles (criterio WCAG 2.5.8), separación clara entre elementos, retroalimentación visual inmediata al hacer clic, y posibilidad de cancelar acciones críticas antes de que se ejecuten.

Recomendación práctica: sustituir gestos complejos (doble clic, arrastrar y soltar) por alternativas simples (un botón «Aceptar» o «Mover»). Mejora usabilidad y reduce errores explotables.

Bloque 5. Eventos (hover, focus, cambios de estado)

WCAG relacionados: 1.4.13 (contenido en hover/focus), 3.2.1 y 3.2.2 (al recibir foco o entrada), 2.4.13 (apariencia del foco).

Cualquier cambio que ocurra al pasar el puntero, recibir el foco o escribir, debe ser predecible y controlable. Para accesibilidad, porque cambios inesperados desorientan. Para seguridad, porque un cambio repentino puede ser una redirección camuflada o una superposición maliciosa.

Ejemplo de fallo: un menú desplegable que se cierra solo si el puntero se mueve un par de píxeles. Imposible de usar para alguien con problemas motores. Y un atacante puede aprovechar ese cierre brusco para colocar un elemento falso justo donde el usuario va a hacer clic.

Solución convergente: los tooltips y popups deben permanecer visibles hasta que el usuario los cierra. El foco debe poder activarlos también con teclado. Y al cerrar un modal, el foco debe volver al elemento que lo abrió, no perderse.

Buena práctica en campos críticos: al enfocar un campo de contraseña o pago, mostrar un borde destacado y, si procede, un aviso discreto. Refuerza la atención y reduce el riesgo de teclear credenciales en un campo equivocado.

Bloque 6. Tiempo

WCAG relacionados: 2.2.1 (tiempo ajustable), 2.2.3 (sin tiempo), 2.2.6 (tiempos de espera).

Los límites de tiempo no deben ser impuestos sin posibilidad de control. Para accesibilidad, porque excluyen a quien necesita más tiempo. Para seguridad, porque el estrés produce errores, abandono y búsqueda de atajos inseguros.

Ejemplo de fallo: una sesión bancaria que expira a los 5 minutos sin aviso. El usuario pierde los datos introducidos, repite el proceso con prisa, se equivoca al teclear el segundo factor, y termina llamando al servicio de atención al cliente. Ese contacto fuera de canal es justo donde la ingeniería social ataca.

Solución convergente: avisos previos a la expiración (al menos 60 segundos), botón claro para «extender sesión», y posibilidad de reanudar el flujo donde se quedó tras volver a autenticarse.

Punto técnico que la guía señala: revisar los setTimeout en JavaScript. Una mala gestión de temporizadores produce comportamientos impredecibles, y esos son terreno abonado para vulnerabilidades.

Bloque 7. Comprensión y propósito

WCAG relacionados: 1.3.5 y 1.3.6 (identificar propósito), 2.4.4 y 2.4.9 (propósito del enlace), 3.1.3, 3.1.4 y 3.1.5 (lenguaje claro).

Cada elemento debe dejar claro qué hace antes de que el usuario lo active. Para accesibilidad, porque la ambigüedad excluye. Para seguridad, porque la ambigüedad es la materia prima de la ingeniería social.

Ejemplo de fallo: un email con un botón que dice «Continuar». ¿Continuar qué? Si el usuario no entiende a qué proceso pertenece esa acción, hace clic por inercia. Es exactamente lo que busca un correo de phishing: que pulses sin pensar.

Solución convergente: botones con propósito explícito («Confirmar pago de 47€», «Guardar cambios en mi perfil», «Cerrar sesión»). Enlaces con texto descriptivo («Leer la política de privacidad» en lugar de «haz clic aquí»). Y en formularios, etiquetas que indiquen contexto («Correo electrónico profesional» en vez de solo «Email»).

Otra cuestión que afecta a las dos disciplinas: el uso correcto de terminología. Decir «cifrar» en lugar de «encriptar». No es purismo, es precisión. Una palabra mal usada en un contexto técnico puede llevar al usuario a aceptar condiciones que no entiende.

Bloque 8. Errores, validación y retroalimentación

WCAG relacionados: 3.3.1 (identificación de errores), 3.3.2 (etiquetas), 3.3.3 (sugerencias), 3.3.4 y 3.3.6 (prevención).

Este es el bloque más elegante de toda la guía. Los mensajes de error deben informar al usuario sin informar al adversario. Es decir: lo bastante claros para que la persona arregle el problema, lo bastante opacos para no revelar detalles internos del sistema.

Ejemplo de fallo: un formulario de login que responde «usuario no existe» cuando el correo no está registrado, y «contraseña incorrecta» cuando sí lo está. Para el usuario legítimo es útil. Para un atacante, es un regalo: le confirma qué correos existen en la base de datos y puede atacarlos por separado.

Solución convergente: un mensaje genérico, «credenciales incorrectas», para ambos casos. El usuario legítimo entiende. El atacante no obtiene información.

Reglas adicionales: los mensajes de error nunca deben revelar nombres de campos internos, estructuras de base de datos ni rutas del servidor. Las sugerencias de corrección deben guiar al usuario sin dar pistas técnicas. Y los mensajes de confirmación deben ser persistentes, no desaparecer en dos segundos.

Bloque 9. Autenticación

WCAG relacionados: 2.2.5 (re-autenticación), 3.3.8 y 3.3.9 (autenticación accesible).

La autenticación es donde el estrés y la confusión más daño hacen. La guía habla de «autenticación empática»: un sistema que entiende los límites humanos sin debilitar la integridad técnica.

Ejemplo de fallo: un segundo factor con una barra de tiempo agresiva que corre mientras tecleas el código. Genera ansiedad, errores, intentos fallidos. Y la fatiga de autenticación (recibir muchas peticiones de MFA en poco tiempo) es justo el vector que usan ataques como el «MFA fatigue», donde el atacante bombardea al usuario hasta que acepta sin pensar.

Solución convergente: tiempos razonables, mensajes tranquilos («tómate tu tiempo»), recordar dispositivos de confianza durante periodos limitados (15-20 días) para no pedir MFA cada vez, y notificar al usuario por qué y desde dónde se le está pidiendo autenticarse de nuevo.

Diseño constante: la pantalla de login debe ser siempre igual, en el mismo orden, con los mismos campos. Un login que cambia de aspecto cada vez confunde al usuario y, peor, facilita que un atacante monte una versión falsa creíble.

Bloque 10. Sintaxis y semántica

WCAG relacionados: 4.1.1 (análisis sintáctico), 4.1.2 (nombre, función, valor).

El bloque más invisible y, sin embargo, transversal a todos los demás. El código debe ser sintácticamente correcto y semánticamente preciso. Para accesibilidad, porque los lectores de pantalla y otras tecnologías de asistencia dependen de ello. Para seguridad, porque la ambigüedad estructural abre la puerta a errores de interpretación.

Ejemplo de fallo: un botón sin atributo ARIA o etiquetado como «botón1». El lector de pantalla lo lee así, literal. La persona ciega no sabe qué activa. Y un script malicioso puede sustituir esa etiqueta opaca por una falsa sin que nadie lo note.

Solución convergente: roles ARIA coherentes en cada elemento interactivo, etiquetas explícitas, HTML bien anidado, y consistencia en el nombre de las acciones a lo largo de toda la web (no llamar «enviar» en una pantalla y «guardar» en otra cuando hacen lo mismo).

Cuestión terminológica: usar «cifrar» en vez de «encriptar», «iniciar sesión» en vez de «logarse». Parece menor, pero genera confianza y reduce ambigüedad. La precisión del lenguaje también es seguridad.

El hilo común

Si recorres los diez bloques, hay un patrón que se repite: la claridad es defensa. Lo que hace una interfaz comprensible para una persona con discapacidad es lo mismo que la hace resistente a la manipulación: previsibilidad, propósito explícito, retroalimentación clara, ausencia de ambigüedad.

Que esto venga del Centro Criptológico Nacional, y no de un colectivo de accesibilidad, es lo más significativo. Es la propia comunidad de seguridad la que afirma que la confusión del usuario es una superficie de ataque, y que la claridad —esa que la accesibilidad lleva pidiendo décadas— es también una medida de defensa.

Accesibilidad y seguridad, resulta, siempre quisieron lo mismo.