Tecnología cívica y prestaciones digitales — cómo los portales de desempleo fallan a los solicitantes con discapacidad

Los portales estatales de seguro de desempleo, los sitios de solicitud de SNAP, las herramientas de elegibilidad de Medicaid y la interfaz de cara al ciudadano del SSDI de la SSA son los servicios esenciales de acceso público de la red de protección social estadounidense. También son algunas de las superficies de accesibilidad con peor rendimiento de la web pública. Se auditaron los portales primarios de prestaciones operados por los diez estados más poblados de EE. UU. —California, Texas, Florida, Nueva York, Pensilvania, Illinois, Ohio, Georgia, Carolina del Norte y Míchigan—, junto con la capa de autenticación federal (Login.gov) y los sistemas de cara al solicitante de la SSA en SSA.gov, frente a WCAG 2.1 Nivel AA y la norma final del DOJ del Título II del 24 de abril de 2024 que vincula legalmente al gobierno estatal y local al mismo estándar. En las doce superficies auditadas se registraron aprox. 217 fallos distintos de WCAG 2.1 AA, una media de aprox. 18 por portal, y solo uno de los doce superó los cuatro criterios de paso de nuestra auditoría. Este expediente nombra los portales, los clasifica y concluye con lo que implica la norma del DOJ para los peores.”

01. Metodología y criterios de auditoría

La auditoría se realizó del 7 de marzo al 12 de mayo de 2026. Dos auditores recorrieron el itinerario canónico del solicitante en cada uno de los doce portales desde una sesión en frío —sin cookies previas, sin extensiones auxiliares instaladas, sin autocompletar—. El itinerario fue: llegar a la página de inicio, registrar una nueva cuenta, autenticarse, presentar una reclamación inicial de prestaciones por desempleo (o, en el caso de las superficies de SSA y SNAP-Medicaid, el flujo equivalente de primera solicitud), llegar al punto de envío y, a continuación, certificar una semana posterior o cargar un documento de apoyo.

Cada superficie se evaluó frente a los criterios de conformidad WCAG 2.1 Nivel AA usando axe-DevTools Pro 4.10 más un recorrido manual con NVDA 2024.4 en Windows 11 y VoiceOver en macOS 14.7. Los flujos móviles se volvieron a probar en iOS 18.2 con VoiceOver y en Android 15 con TalkBack. Cualquier PDF servido durante el itinerario fue extraído y analizado por separado con PAC 2024 y la comprobación de accesibilidad de Acrobat Pro DC.

A continuación se aplicaron cuatro criterios de paso binarios —más gruesos que la escala WCAG completa, pero los criterios que le importan realmente a un solicitante con discapacidad en activo—: operable con teclado (¿puede un usuario solo de teclado llegar a una solicitud enviada?), recuperación de errores por lector de pantalla (cuando algo falla, ¿anuncia el lector de pantalla qué y dónde?), extensión del tiempo de sesión (¿el mecanismo de aviso y extensión es alcanzable y operable mediante tecnología de apoyo?), y carga de archivos accesible (¿el éxito o fracaso de la carga se anuncia programáticamente?). Una superficie supera la auditoría solo si pasa los cuatro criterios.

02. La clasificación portal a portal

Clasificar las doce superficies por su puntuación de accesibilidad normalizada —la proporción de páginas del itinerario que superaron axe en WCAG 2.1 AA, ponderada por si se cumplieron los cuatro criterios— produjo la tabla siguiente. Login.gov encabeza la lista porque fue diseñado como primitiva de autenticación con accesibilidad como primer requisito desde su concepción, y el equipo vuelve a probarlo en cada lanzamiento. Las superficies de solicitantes de SSA.gov están en segundo lugar porque la Oficina de Sistemas y Tecnología Accesibles de la SSA opera un programa de monitorización continua. A partir del tercer puesto, la distancia hasta el fondo es pronunciada.

Login.gov muestra la forma de un portal de prestaciones accesible. Florida CONNECT muestra la forma de uno que no puede presentarse sin ayuda visual.

03. Trampas del CAPTCHA

El criterio del CAPTCHA es la superficie de fallo más visible porque se sitúa al principio del flujo —normalmente en el formulario de registro o inicio de sesión, a veces de nuevo en el envío de la reclamación inicial como medida antifraude—. Ocho de los doce portales auditados sirven un desafío de reCAPTCHA v2 solo de imagen cuya alternativa de audio está o bien rota (se carga en silencio, sin archivo de audio reproducible) o bien redirige al solicitante a un 404 genérico. Dos de los ocho bloquean todo el flujo de reclamación inicial detrás del CAPTCHA: el portal UI de la Texas Workforce Commission y Florida CONNECT. Un solicitante ciego en esos dos estados, que trabaje sin un asistente visual, no puede presentar una reclamación desde esas interfaces. Tiene que llamar por teléfono al estado, donde la cola supera varias horas de espera.

La ironía de la tecnología cívica es que reCAPTCHA v3 —invisible, basado en el comportamiento, sin desafío para la gran mayoría de los usuarios— existe, es gratuito en los volúmenes que maneja un portal estatal y resolvería el problema al coste de una tarde de trabajo de integración. La inercia de la contratación pública, no la dificultad técnica, mantiene el desafío v2 en su lugar.

04. Tiempos de sesión que no se extienden

Once de los doce portales auditados —cada superficie estatal de desempleo e iClaim de la SSA— imponen un tiempo de sesión de entre 10 y 20 minutos de inactividad. El criterio de conformidad WCAG 2.2.1 (Tiempo ajustable) exige que cualquier límite de tiempo pueda desactivarse, ajustarse o extenderse por el usuario antes de que expire, con al menos 20 segundos de aviso y una interacción sencilla de «extender». De los once, tres no dan ningún aviso: la sesión simplemente expira a mitad del formulario y el solicitante vuelve al inicio de sesión con todos los datos ingresados perdidos.

Cinco más muestran un modal visual con cuenta atrás pero nunca anuncian el modal mediante aria-live, de modo que un usuario de lector de pantalla que lee el formulario subyacente no tiene idea de que ha aparecido el aviso. Los tres restantes anuncian el modal pero atrapan el foco de manera que el botón «Extender sesión» no puede alcanzarse con el tabulador: una tecla Tabulador en el formulario subyacente no mueve el foco al modal. El usuario sabe que el aviso está ahí. El usuario no puede actuar sobre él.

05. Formularios solo en PDF dentro de un itinerario HTML

Nueve de los diez portales estatales de desempleo redirigen al solicitante, en algún momento del itinerario, a un PDF. Los más habituales son el formulario de apelación, la certificación de semana parcial, el registro de búsqueda de empleo y la declaración de subsidio por dependientes. De los PDF servidos, menos de la mitad incluyen un árbol de estructura de PDF etiquetado. El resto son imágenes escaneadas de formularios en papel —a veces la plantilla mecanografiada original de los años noventa, fotocopiada una y otra vez— sin ninguna capa de texto.

Un PDF de imagen escaneada servido como formulario obligatorio no es un defecto de accesibilidad marginal. Es una exclusión categórica. El lector de pantalla informa de un documento vacío. Las herramientas OCR fallan porque el formulario tiene campos que la capa de reconocimiento óptico no puede reconstruir. El solicitante tiene dos opciones: imprimir, rellenar a mano, escanear de vuelta y enviar por correo electrónico; o llamar por teléfono a la agencia. Ambas opciones presuponen una impresora-escáner y ayuda visual. Muchos solicitantes con discapacidad no tienen ninguna de las dos.

06. Cargas de archivos sin retroalimentación al lector de pantalla

Diez de los doce portales requieren, en algún punto del itinerario, una carga de archivos: una notificación de despido, un documento de identidad, una certificación médica, un documento de elegibilidad de SNAP-Medicaid. El patrón que falla sistemáticamente en la auditoría es: el elemento input de archivo es un input HTML nativo envuelto en un botón personalizado con estilo «Seleccionar archivo» que absorbe el evento de teclado y nunca anuncia el nombre del archivo seleccionado, nunca anuncia el progreso de la carga, nunca anuncia el éxito y (lo peor de todo) nunca anuncia el fracaso. El usuario selecciona un archivo. Algo ocurre. No se anuncia nada. El usuario continúa, sin saber si la carga se realizó correctamente, y descubre tres días después que la reclamación fue rechazada por falta de documentación.

La corrección más barata de todo el expediente se encuentra aquí. Una única región live oculta visualmente junto al input de archivo, polite, actualizada en la selección y al finalizar con el nombre del archivo y un estado de una sola palabra, cuesta una hora de trabajo de front-end y resuelve el patrón de fallo completo. Se vio implementado correctamente en exactamente una de las doce superficies.

07. Mensajes de error sin aria-live

El fallo más frecuente en las doce superficies —presente en aproximadamente tres de cada cuatro estados de error que se provocaron— fue un error de validación en línea representado como un span rojo con estilo junto a un campo de entrada, sin región aria-live, sin puntero aria-describedby del input al texto de error y sin movimiento programático del foco al error. El error es visible. El error no se anuncia. El usuario del lector de pantalla envía el formulario, la página no se recarga, el usuario no sabe por qué no ha ocurrido nada y vuelve a enviar.

El patrón se agrava con el fallo del tiempo de sesión: un solicitante con discapacidad recorre errores de validación no anunciados a la velocidad de la relectura humana, alcanza el tiempo límite de 15 minutos, pierde el formulario y empieza de nuevo. La corrección son dos líneas por error: una región aria-live cerca de cada fieldset, polite, en la que la rutina de validación escribe cuando se activa. Ninguna de las superficies auditadas hace esto de forma consistente.

La parte más costosa de subsanar estos portales no es la ingeniería. Es el contrato de contratación pública que hay que reabrir.

08. Implicaciones para la aplicación del Título II del DOJ

La norma final del Título II del DOJ del 24 de abril de 2024 —codificada en el 28 CFR Parte 35, Subparte H— adopta WCAG 2.1 Nivel AA como estándar federal de accesibilidad para el contenido web y las aplicaciones móviles del gobierno estatal y local. Las grandes entidades públicas (poblaciones de 50.000 o más) tenían un plazo de cumplimiento del 24 de abril de 2026; las entidades más pequeñas tienen hasta el 24 de abril de 2027. Todos los estados de esta auditoría sirven a una población muy por encima del umbral de 50.000 personas. El plazo de abril de 2026 ya ha pasado.

La norma prevé excepciones —contenido archivado, documentos individualizados, contenido no público protegido por contraseña, contenido de terceros no publicado por la entidad—, pero el itinerario canónico de solicitud de desempleo no encaja en ninguna de ellas. Un formulario de reclamación inicial en un portal UI estatal es actual, de acceso público, proporcionado por la entidad y utilizado por el público. Está claramente dentro de la superficie regulada.

La aplicación del Título II se lleva a cabo mediante investigaciones iniciadas por el DOJ (la Sección de Derechos de Discapacidad de la División de Derechos Civiles), quejas individuales presentadas en civilrights.justice.gov y litigios privados en virtud del mismo estatuto. Los remedios que contempla la norma incluyen planes de cumplimiento, acuerdos de supervisión, daños compensatorios a los denunciantes identificados y —en el patrón de decreto de consentimiento que el Departamento ha utilizado desde el acuerdo de 2014 con H&R Block— calendarios de subsanación a nivel nacional con objetivos de conformidad WCAG nominados. Para más información sobre lo que atrae específicamente la atención del DOJ, véase el artículo complementario sobre la norma del DOJ del Título II, dos años después.

09. El itinerario del solicitante con discapacidad es la experiencia de usuario de tecnología cívica de mayor riesgo, y la más importante de corregir

El desempleo es por definición un momento de presión financiera aguda. El solicitante no tiene ingresos, tiene reservas limitadas y una ventana fija para presentar la solicitud. Un no-solicitante abandona un proceso de pago de comercio electrónico roto y compra en otro sitio. Un solicitante de seguro por desempleo con discapacidad no puede hacerlo. El servicio es obligatorio, el plazo es fijo, la alternativa es la indigencia.

Eso es lo que convierte a un portal de prestaciones en la superficie de accesibilidad de mayor riesgo de la web pública. Los diez portales estatales auditados están, con dos o tres excepciones, actualmente en incumplimiento de la norma federal que entró en vigor en abril de 2026. También eran, antes de que existiera esa norma, los fallos de accesibilidad más consecuentes de la tecnología cívica estadounidense. La norma del DOJ no hizo que estos portales fueran importantes. Los hizo jurídicamente cognoscibles.

Lo que cambia a continuación es la aplicación, no la tecnología. Las correcciones —aria-live en los errores en línea, un control de extensión de sesión enfocable, PDF etiquetados, un estado de carga de archivos anunciado, una alternativa CAPTCHA que funcione— son individualmente pequeñas, bien documentadas y están dentro del presupuesto de mantenimiento rutinario de todos los organismos de la lista. Lo que ha faltado es la presión regulatoria, la atención política y el lenguaje del contrato de contratación pública para hacer que la subsanación ocurra. El primero ya está presente.