Claves para integrar la accesibilidad y la seguridad informática

Si diriges un proyecto digital, puede que ya te hayas topado con el siguiente dilema: ¿debo priorizar la seguridad reforzada de mi web frente a experiencia inclusiva? Por suerte, la accesibilidad en la seguridad informática no es una elección binaria. 

La normativa exige ambas y las diferentes soluciones tecnológicas te permiten compatibilizarlas. Te contamos cómo lograrlo dentro del marco normativo español y europeo, todo de la mano de las soluciones que integramos en nuestros servicios de accesibilidad digital.

El conflicto entre seguridad web y accesibilidad digital

La accesibilidad en la seguridad informática se enfrenta a un problema estructural: muchos mecanismos de seguridad se diseñaron sin pensar en usuarios con discapacidad. CAPTCHAs visuales, códigos SMS con tiempo limitado, preguntas de seguridad basadas en memoria. Cada capa añadida introduce potencialmente una barrera. Y bajar el listón para “facilitar el acceso” abre riesgos reales.

Por qué los mecanismos de seguridad generan barreras

Los mecanismos clásicos parten de tres supuestos que discriminan: que el usuario ve la pantalla, que memoriza contraseñas complejas y que responde en tiempos rápidos. Eso se traduce en:

• Un CAPTCHA visual excluye a personas ciegas. 
• Un token SMS con caducidad de 60 segundos excluye a personas con discapacidad motora. 
• Una pregunta como “tu primer coche” excluye a personas con daño cerebral adquirido.

Impacto real en usuarios con discapacidad

En España hay 4,38 millones de personas con discapacidad y el 39,4% tiene dificultades con las TIC. Cuando la banca online, la Seguridad Social o un ecommerce imponen barreras de autenticación, esa población queda fuera. En términos legales, es discriminación directa. En términos de negocio, un mercado que se descarta.

Marco normativo: criterios de accesibilidad y ciberseguridad

Tres normas establecen los criterios a los cuales tu proyecto debe adaptarse: la Ley 11/2023, las normas técnicas WCAG y el ENS con NIS2.

Ley 11/2023 y la EAA: seguridad como parte del cumplimiento

La European Accessibility Act (EAA) es la directiva europea que extiende las obligaciones de accesibilidad digital al ámbito privado, alcanzando a sectores clave como banca, comercio electrónico, transporte o telecomunicaciones. 

La Ley 11/2023 es la norma española que la transpone. Ninguna dedica capítulo específico a ciberseguridad, pero exigen interoperabilidad con productos de apoyo y accesibilidad del proceso completo de servicio. La autenticación forma parte de ese proceso. Un login inaccesible es incumplimiento.

WCAG y los nuevos criterios de autenticación

Las WCAG (Web Content Accessibility Guidelines) son las pautas internacionales de accesibilidad web publicadas por el W3C, el consorcio que estandariza la web. Definen los requisitos técnicos que debe cumplir un sitio para ser usable por personas con discapacidad, y son la base de casi toda la regulación europea. 

En la UE, la versión armonizada vigente es EN 301 549 v3.2.1, que integra las WCAG 2.1 nivel AA. WCAG 2.2 (aprobada por el W3C en octubre de 2023) introduce dos criterios específicos de autenticación que se incorporarán a la norma técnica europea con EN 301 549 v4.1.1, prevista para 2026:

• 3.3.8 Autenticación accesible (mínimo), nivel AA. Los procesos no pueden depender exclusivamente de una prueba cognitiva (memorizar, transcribir, resolver un puzzle) salvo alternativa accesible.
• 3.3.9 Autenticación accesible (mejorada), nivel AAA. Prohíbe cualquier prueba cognitiva salvo excepciones limitadas.

Importante: ambos criterios pertenecen a WCAG 2.2, no a 2.1. Aplicarlos hoy anticipa el marco armonizado que llega en 2026. Puedes profundizar en pautas de accesibilidad para el contenido web.

ENS, NIS2 y accesibilidad: obligaciones paralelas

El Esquema Nacional de Seguridad (ENS) es el marco español de ciberseguridad para sistemas de información. Regulado por el Real Decreto 311/2022, obliga al sector público y a sus proveedores a implantar controles graduados según el nivel de riesgo.

Por su parte, la Directiva NIS2 (2022/2555) es la norma europea equivalente para servicios digitales críticos, transpuesta en España por el Real Decreto-ley 7/2025. Impone requisitos de ciberseguridad a operadores esenciales e importantes de sectores como banca, sanidad, energía o transporte. Ninguna exime del cumplimiento de accesibilidad: coexisten.

CAPTCHA accesible: alternativas que cumplen WCAG 2.1

El CAPTCHA es el punto donde antes se rompe la accesibilidad. Existen alternativas técnicas que cumplen el mismo objetivo de seguridad.

Tipos de CAPTCHA y sus problemas de accesibilidad

No todos los CAPTCHA generan las mismas barreras. Estos son los tres formatos más comunes:

• CAPTCHA visual clásico. Texto distorsionado o selección de imágenes. Barrera absoluta para personas ciegas o con baja visión.
• CAPTCHA de audio. Alternativa habitual con calidad pobre. Excluye a personas sordas o con procesamiento auditivo alterado.
• CAPTCHA cognitivo (“marca las señales de tráfico”). Barrera para personas con discapacidad intelectual o deterioro cognitivo.

Cualquier CAPTCHA basado en un único canal sensorial o en una prueba cognitiva deja fuera a parte de tu audiencia.

Alternativas accesibles: CAPTCHA invisibles, lógicos y biométricos

Estos son los cuatro mecanismos maduros y usados en producción hoy:

1. CAPTCHA invisible basado en comportamiento (reCAPTCHA v3, hCaptcha Enterprise). Analiza patrones sin exigir acción del usuario.
2. Passkeys y WebAuthn. Autentican al usuario sin pruebas cognitivas.
3. Verificación de contexto (honeypots, timestamps, análisis de red). Detecta bots por comportamiento.
4. CAPTCHA lógico simple con alternativa accesible garantizada. Nunca como único método.

Combinar dos o tres de estos mecanismos ofrece seguridad equivalente sin penalizar a ningún usuario.

Autenticación multifactor (MFA) accesible

La autenticación multifactor (MFA) suma robustez frente a suplantación, pero añade fricción. Si no se diseña con criterio inclusivo, deja fuera a personas que sí deberían poder acceder.

Barreras de los SMS, apps y tokens físicos

Los tres factores más extendidos parten del mismo supuesto: un usuario que ve, oye y responde rápido.

• SMS con código de 6 dígitos y ventana de 30-60 segundos: excluye a personas con discapacidad motora o cognitiva.
• Apps autenticadoras: usabilidad limitada para lectores de pantalla y sin alternativa por audio.
• Tokens físicos: interacción precisa que no todo el mundo puede realizar.

Basta con relajar tiempos, ofrecer alternativas equivalentes y aceptar productos de apoyo para eliminar la mayoría.

Cómo implementar MFA sin excluir usuarios

Estos son los cuatro principios que permiten desplegar MFA sin dejar fuera a nadie:

1. Ofrecer múltiples factores alternativos: SMS, email, app autenticadora, passkey y llamada de voz.
2. Permitir ampliar el tiempo de introducción del código sin cortar la sesión.
3. Compatibilidad total con gestores de contraseñas y autocompletado.
4. Interfaz con etiquetas claras, contraste alto y navegación por teclado completa.

Aplicados en conjunto, convierten la MFA en un proceso robusto y accesible.

Passkeys y WebAuthn como solución inclusiva

Las passkeys y el estándar WebAuthn son la respuesta técnica más limpia al criterio 3.3.8. Sustituyen la contraseña por una credencial criptográfica ligada al dispositivo, desbloqueada con biometría o PIN. 

No hay puzzle, no hay código que transcribir, no hay memorización. Se está convirtiendo en estándar en banca, ecommerce y administración pública.

Seguridad en formularios y procesos críticos

Más allá del login, hay dos puntos donde la seguridad choca con la accesibilidad: los tiempos de sesión y la verificación de identidad.

Tiempos de sesión y accesibilidad (criterio 2.2.1 WCAG)

El criterio WCAG 2.2.1 “Tiempo ajustable” (nivel A) obliga a que el usuario pueda desactivar, ajustar o ampliar cualquier límite temporal, salvo excepciones muy tasadas.

En seguridad web, esto significa notificar el vencimiento de sesión con al menos 20 segundos de antelación, permitir prolongar con un clic y no perder los datos ya introducidos. Es una de las barreras más frustrantes en tramitación pública y banca digital.

Verificación de identidad sin barreras cognitivas o sensoriales

Cuando rediseñamos un flujo de verificación con criterio inclusivo aplicamos estas cuatro pautas:

• Ofrecer múltiples canales: videollamada con intérprete de lengua de signos, verificación asíncrona documental, atención presencial.
• Diseñar guías paso a paso con lectura fácil y pictogramas.
• Aceptar productos de apoyo durante todo el proceso.
• No condicionar la verificación exclusivamente a biometría facial o dactilar.

En estos casos no estás relajando la exigencia probatoria: ofreces varias vías equivalentes para superar el mismo control.

Cómo implementar seguridad accesible en tu web

Toca aterrizar todo en un plan de acción con dos palancas que aceleran el proceso. La forma más eficiente de integrar la accesibilidad en la seguridad informática es una única auditoría combinada. 

Un equipo mixto revisa el flujo con dos perspectivas: seguridad (OWASP, ENS, NIS2) y accesibilidad (EN 301 549, WCAG 2.1/2.2). Detecta los conflictos antes de desarrollar tus activos digitales, no después. En muchos proyectos, este enfoque reduce a la mitad el coste total frente a hacer dos auditorías separadas.

Plataforma inSuit: accesibilidad compatible con tus sistemas de seguridad

En inSuit ofrecemos accesibilidad compatible con los sistemas de seguridad que ya tienes desplegados. Nuestra plataforma cuenta con certificación ENS e ISO 27001, y se integra sin fricción con SSO, MFA, WAF y CDN corporativos.

Auditamos combinando criterios de accesibilidad y de seguridad, y trabajamos con clientes como la Seguridad Social, Cajamar, Bankinter o el Gobierno de Canarias, donde ambos requisitos son innegociables. 

¿Quieres conocer más acerca de nuestras soluciones de accesibilidad digital? En inSuit, te ofreceremos toda la información que necesites sobre nuestros servicios. ¡No dudes en contactarnos!