Accesibilidad Digital para Equipos de RRHH: Haciendo que los Sistemas de Reclutamiento y Área de Trabajo Cumplan con WCAG

Introducción

Si su sitio de carrera profesional, formularios de solicitud o sistemas internos no son accesibles, está excluyendo a candidatos calificados y empleados con discapacidades — y puede estar violando la ley. Las Directrices de Accesibilidad para el Contenido Web (WCAG) 2.2, publicadas por W3C, es la versión actual del estándar, y el Nivel AA es el punto de referencia que la mayoría de las organizaciones buscan lograr. Cada vez está más escrito en la normativa: los organismos del sector público del Reino Unido deben cumplir con WCAG 2.2 AA, y la regla de la Ley de Estadounidenses con Discapacidades (ADA) Título II de 2024 del Departamento de Justicia de EE.UU. establece WCAG 2.1 Nivel AA como el estándar técnico para el contenido web y aplicaciones móviles de gobiernos estatales y locales.

Esta guía proporciona a los equipos de RRHH una hoja de ruta concreta y práctica para hacer que los sistemas de reclutamiento y área de trabajo sean accesibles.

Paso 1: Auditar su Sitio de Carrera Profesional

Su sitio de carrera profesional es la puerta de entrada a su organización para todos los candidatos. Un sitio de carrera profesional inaccesible envía un mensaje claro a los solicitantes con discapacidades: no son bienvenidos aquí.

Lista de Verificación WCAG 2.2 AA para Sitios de Carrera Profesional

Perceptible

• Todas las imágenes tienen texto alternativo significativo (las imágenes decorativas utilizan atributos alt vacíos)
• Los vídeos tienen subtítulos y descripciones de audio
• El contraste de color cumple con las proporciones mínimas (4,5:1 para texto normal, 3:1 para texto grande)
• El texto puede redimensionarse hasta un 200 % sin pérdida de contenido o funcionalidad, y el contenido se redistribuye sin desplazamiento bidimensional en un ancho de 320 píxeles CSS (equivalente a zoom del 400 % en una pantalla de 1280px de ancho)
• La información no se transmite únicamente por color

Operable

• Toda la funcionalidad está disponible a través del teclado (Tab, Enter, Espacio, teclas de flecha)
• Los indicadores de enfoque son visibles y distintos
• No existen trampas de teclado (los usuarios siempre pueden usar Tab para salir de cualquier elemento)
• Las páginas tienen enlaces de omisión de navegación
• Los usuarios tienen tiempo suficiente para completar tareas (o pueden extender los límites de tiempo)
• Ningún contenido parpadea más de tres veces por segundo

Comprensible

• El idioma de la página se declara en el HTML
• Las etiquetas de formulario se asocian mediante programación con las entradas
• Los mensajes de error son claros y específicos (por ejemplo, "La dirección de correo electrónico debe incluir un símbolo @" en lugar de "Entrada inválida")
• La navegación es consistente en todas las páginas

Robusto

• Las páginas utilizan HTML bien formado y semántico (WCAG 2.2 marca el antiguo criterio 4.1.1 Parsing como obsoleto y lo ha eliminado, pero el marcado limpio sigue ayudando a la tecnología de asistencia)
• Los widgets personalizados utilizan correctamente los roles, estados y propiedades de ARIA
• El contenido funciona con la tecnología de asistencia actual (lectores de pantalla, ampliadores, control de voz)

Paso 2: Hacer que los Formularios de Solicitud Sean Accesibles

Los formularios de solicitud son donde ocurren la mayoría de los fallos de accesibilidad. Problemas comunes y sus soluciones:

Etiquetas e Instrucciones

• Fallo: Texto de marcador de posición utilizado como la única etiqueta. Los lectores de pantalla pueden no anunciar el texto del marcador de posición de manera consistente.
• Solución: Utilice elementos `<label> visibles asociados con cada entrada a través de atributos for/id`.

Manejo de Errores

• Fallo: Los errores se muestran solo en texto rojo al lado del campo, sin asociación mediante programación.
• Solución: Utilice `aria-describedby para vincular mensajes de error a campos. Proporcione un resumen de errores en la parte superior del formulario. Utilice aria-invalid="true"` en campos con errores.

Navegación por Teclado

• Fallo: Menús desplegables personalizados y selectores de fecha que solo funcionan con un ratón.
• Solución: Utilice elementos nativos de HTML `<select>` cuando sea posible. Para widgets personalizados, implemente soporte de teclado completo siguiendo las Prácticas de Autoría de WAI-ARIA.

Cargas de Archivos

• Fallo: Carga de currículum solo por arrastrar y soltar sin alternativa.
• Solución: Proporcione siempre una entrada de archivo estándar (`<input type="file">`) junto con cualquier interfaz de arrastrar y soltar.

Indicadores de Progreso

• Fallo: Formularios de varios pasos que no indican la posición actual ni permiten la navegación hacia atrás.
• Solución: Utilice `aria-current="step"` y proporcione conteos de pasos claros (por ejemplo, "Paso 2 de 4"). Permita que los usuarios naveguen a pasos anteriores sin perder datos.

Paso 3: Configurar su ATS para Accesibilidad

Los Sistemas de Seguimiento de Candidatos (ATS) generan muchas de las páginas con las que interactúan los candidatos. Problemas comunes de accesibilidad de ATS:

• Páginas de ofertas de empleo generadas automáticamente pueden carecer de estructura de encabezados. Trabaje con su proveedor de ATS para asegurar que las etiquetas H1/H2/H3 se utilicen correctamente.
• Aplicar con LinkedIn u características similares de un clic pueden no ser accesibles por teclado. Pruebe cuidadosamente o proporcione una alternativa manual.
• CAPTCHA en formularios de solicitud pueden bloquear a usuarios de lectores de pantalla y personas con discapacidades cognitivas. Utilice métodos de verificación que no dependan de un acertijo visual o cognitivo, y tenga en cuenta que el Criterio de Conformidad 3.3.8 de WCAG 2.2 (Autenticación Accesible) restringe pruebas de función cognitiva en pasos de inicio de sesión.
• Tiempos de espera de sesión durante solicitudes largas penalizan a usuarios que escriben lentamente. Extienda o elimine los tiempos de espera, o advierta a los usuarios antes del tiempo de espera y permita la extensión.

Elemento de acción: Solicite un Informe de Conformidad de Accesibilidad (ACR) — un VPAT (Plantilla de Accesibilidad de Producto Voluntario) completado — a su proveedor de ATS. Si no pueden proporcionarlo, considere cambiar a un proveedor que se tome la accesibilidad en serio.

Paso 4: Crear Documentos de Incorporación Accesibles

Los nuevos empleados reciben una avalancha de documentos: contratos, manuales, guías de beneficios, materiales de capacitación. Todos estos deben ser accesibles.

Accesibilidad de PDF

• Utilice PDF etiquetados con un orden de lectura lógico
• Asegúrese de que todas las imágenes tengan texto alternativo
• Utilice texto real (no imágenes escaneadas de texto)
• Defina el idioma y el título del documento
• Pruebe con un lector de pantalla (el verificador de accesibilidad de Adobe Acrobat es un punto de partida, pero las pruebas manuales son esenciales)

Diapositivas y Materiales de Capacitación

• Utilice diseños de diapositivas (no cuadros de texto de formato libre) para que los lectores de pantalla sigan un orden de lectura lógico
• Agregue texto alternativo a todos los elementos visuales
• Asegúrese de suficiente contraste de color
• Proporcione notas del orador como narrativa de texto alternativa
• Grabe audio/video con subtítulos

Formularios y Encuestas

• Utilice constructores de formularios accesibles (Microsoft Forms, Google Forms son razonablemente accesibles; pruebe otros antes de implementarlos)
• Nunca utilice formularios PDF que requieran que el usuario imprima, escriba a mano y escanee

Paso 5: Hacer que las Comunicaciones Internas Sean Accesibles

Correo Electrónico

• Utilice HTML semántico en plantillas de correo electrónico (encabezados, listas, texto alternativo para imágenes)
• Evite enviar información crítica solo como adjuntos de imagen
• Proporcione alternativas en texto plano

Intranet

• Aplique los mismos estándares WCAG 2.2 AA que su sitio de carrera profesional
• Asegúrese de que la funcionalidad de búsqueda funcione con lectores de pantalla
• Haga que los repositorios de documentos sean navegables por teclado

Slack, Teams y Plataformas de Chat

• Fomente el uso de texto alternativo en imágenes compartidas en canales, donde su plataforma lo admita
• Utilice conversaciones en lugar de mensajes largos no estructurados (más fácil para la accesibilidad cognitiva)
• Habilite y promueva subtítulos en videollamadas
• Asegúrese de que los anuncios críticos también se publiquen en formato de texto, no solo como vídeo o audio

Herramientas de Prueba

Proceso de Prueba

1. Escaneo automatizado con axe o Lighthouse — detecta solo parte de los problemas, así que nunca confíe únicamente en él
2. Pruebas manuales de teclado — navegue por cada página utilizando solo Tab, Enter, Espacio y teclas de flecha
3. Pruebas con lector de pantalla — pruebe con NVDA (Windows) o VoiceOver (macOS) como mínimo
4. Pruebas de usuario — reclute usuarios con discapacidades para probar flujos de solicitud reales

Fallos Comunes y Soluciones

Conclusión

La accesibilidad digital para sistemas de RRHH no es un proyecto de una sola vez — es un compromiso continuo. Audite sus sistemas actuales, remedie las barreras más críticas primero, pruebe regularmente con tecnología de asistencia real, y responsabilice a sus proveedores. Cada mejora hace que su lugar de trabajo sea más inclusivo y su grupo de talentos más amplio.