Solicitud de empleo accesible: 12 pruebas de teclado en ATS

Una solicitud de empleo accesible permite que un candidato complete todos los pasos con un teclado y tecnología de apoyo. Los controles necesitan etiquetas claras, un foco lógico y visible, errores fáciles de corregir, alternativas al arrastre, conservación de los datos introducidos y una vía evidente para solicitar adaptaciones. WCAG 2.2 AA es una referencia práctica, pero solo una prueba del recorrido completo demuestra si el proceso funciona.

Todo el recorrido importa. Una página de empleo puede superar un análisis automático y, aun así, impedir que alguien presente su candidatura por culpa de la subida del CV, el selector de fechas, la zona horaria, un inicio de sesión externo o la página de confirmación.

¿Por qué el acceso mediante teclado es una cuestión de contratación y no una preferencia de usuarios avanzados?

El acceso mediante teclado determina si algunos candidatos cualificados pueden siquiera entrar en tu proceso de selección. No es solo una forma más rápida de moverse por una interfaz gráfica para usuarios expertos.

Un ensayo reciente que defendía que las interfaces gráficas deberían poder manejarse por completo con el teclado generó un amplio debate en Hacker News. La lección útil para la contratación es más concreta que el titular: todas las acciones necesarias para presentar una candidatura deben poder realizarse sin movimientos precisos del ratón, y quien las ejecute debe saber en todo momento dónde está el foco.

Esto ayuda a personas ciegas o con baja visión, a quienes emplean entrada por voz y a quienes tienen destreza limitada o no pueden usar un puntero. Pero no reduzcas estas necesidades a «la accesibilidad mejora la usabilidad». Una función puede ser imprescindible para una persona aunque la mayoría de los candidatos ni siquiera la perciban.

Los equipos de selección suelen medir la fricción de una candidatura por la longitud del formulario y la conversión. La accesibilidad cambia la pregunta. En vez de limitarte a «¿Cuántas personas terminaron?», pregunta: «¿Podría una persona que utiliza este método de interacción terminar sin ayuda?». Un candidato bloqueado nunca llega a convertirse en una fila del embudo, por lo que las métricas habituales del proceso no muestran a quienes jamás consiguieron entrar.

El riesgo va más allá del formulario inicial. Un candidato puede necesitar abrir un enlace mágico, corregir una subida no válida, elegir una franja de entrevista, cambiar de zona horaria, eliminar un archivo del portafolio, completar una autenticación externa y volver al punto correcto. La experiencia del candidato es la suma de todas esas transiciones, no el acabado de la primera pantalla.

¿Cuántas solicitudes de empleo en línea funcionan con lectores de pantalla?

En un estudio revisado por pares con 90 intentos de candidatura, los usuarios expertos de lectores de pantalla solo pudieron completar 50 de forma autónoma, es decir, el 55,6 %. El resultado se refiere a los sitios de empresas Fortune 500 y a las combinaciones tecnológicas de la muestra, no a todos los portales ni a todos los candidatos con discapacidad.

Reuschel, McDonnall y Burton seleccionaron a 30 empresas Fortune 500 y pidieron a tres expertos ciegos que presentaran una candidatura una vez en cada sitio mediante tres combinaciones distintas de navegador y lector de pantalla. Veintitrés de los 30 sitios bloquearon al menos una combinación. Solo en el 23,3 % de los sitios pudo completarse el proceso con las tres.

Los investigadores registraron 694 problemas de accesibilidad y usabilidad, entre ellos 73 bloqueantes o críticos. Tres categorías concentraron el 75 % de todos los problemas: accesibilidad mediante teclado, información y relaciones, y etiquetas. La accesibilidad mediante teclado apareció en el 53 % de los problemas bloqueantes; los selectores de fechas y los campos combinados, en el 34 %.

Estas cifras ofrecen la base empírica más sólida para revisar la accesibilidad de un ATS. No significan que el 44,4 % de los candidatos abandonara una candidatura. Los 40 intentos fallidos midieron la imposibilidad de completar el proceso de forma autónoma bajo unas condiciones de prueba concretas, no una decisión voluntaria de marcharse.

El estudio también detectó avances. La tasa de finalización pasó del 28,1 % en un estudio anterior de 2011 al 55,6 % en el trabajo posterior, y 26 de los 30 sitios funcionaron con al menos una de las combinaciones probadas. El problema es la falta de fiabilidad entre configuraciones. Un proceso que funciona con una combinación puede fallar con otra.

Hay límites importantes. El estudio contó con tres usuarios ciegos expertos, uno por combinación, y portales de grandes empresas. Un experto puede sortear defectos que detendrían a alguien con menos experiencia. Los hallazgos se refieren directamente al uso de lectores de pantalla, así que no deben presentarse como una tasa de fallo general de quienes navegan solo con teclado.

¿Qué significa WCAG 2.2 AA para un portal del candidato?

WCAG 2.2 AA es una referencia práctica de ingeniería para la accesibilidad de un portal del candidato, no una ley universal. En cuanto al teclado, plantea si todas las funciones operan sin puntero, si el foco sigue un recorrido con sentido y si el control enfocado permanece visible y utilizable.

Las Pautas de Accesibilidad para el Contenido Web 2.2 convierten una intención amplia en criterios verificables. En un proceso de selección, se concretan así:

La compatibilidad con el teclado no equivale a la compatibilidad con lectores de pantalla. Un selector de fechas personalizado puede responder a las flechas y no anunciar la fecha seleccionada. Los horarios de entrevista recién mostrados pueden ser accesibles con el teclado y, aun así, no ofrecer ninguna indicación sonora de que la página ha cambiado. Además de las pulsaciones, hacen falta nombres, roles, estados y relaciones semánticos, así como anuncios de estado.

Los controles HTML nativos reducen el comportamiento que debes recrear, pero no lo resuelven todo. Un campo puede seguir sin una etiqueta útil, y un formulario bien etiquetado puede borrar todas las respuestas tras un solo error de validación.

¿Cómo aplicar las 12 comprobaciones de una solicitud de empleo accesible?

Realiza estas 12 comprobaciones desde la oferta de empleo hasta el envío, el acceso al portal y la programación de la entrevista. Prueba tanto el recorrido normal como los estados de error: la validación, las subidas, los paneles dinámicos y los saltos a servicios de terceros suelen romper formularios que, por lo demás, parecen impecables.

1. Da prioridad a los controles nativos frente a los componentes personalizados

Utiliza campos de texto, botones de opción, casillas, botones, enlaces y campos de archivo nativos, salvo que un control personalizado aporte un comportamiento necesario. Los elementos nativos ya incorporan un comportamiento de teclado y una semántica de accesibilidad que un div con estilos no ofrece.

Documenta las teclas previstas y los estados anunciados de cada cuadro combinado, calendario o modal personalizado.

2. Asigna un nombre accesible y útil a cada control

Cada campo y cada botón que solo muestre un icono necesita un nombre que describa su finalidad. «Eliminar archivo del portafolio» es útil; «botón» o un icono de papelera sin etiqueta no lo son. Agrupa los botones de opción y las casillas relacionados bajo una pregunta con sentido.

No utilices el texto de ejemplo como etiqueta. La indicación de que el campo es obligatorio, los requisitos de formato y el texto de ayuda deben estar conectados mediante código al campo que explican.

3. Sigue un orden de foco lógico

Pulsa Tab desde la cabecera de la página hasta la acción final y vuelve atrás con Mayús+Tab. El foco debe respetar el orden de lectura y de la tarea, incluidas las preguntas condicionales que aparecen después de una respuesta.

Evita valores positivos de tabindex, que crean un segundo orden en la página. Cuando se abra un resumen o un modal, desplaza el foco de forma deliberada. Al cerrarlo, devuelve el foco a un control estable.

4. Mantén el foco del teclado visible y sin obstrucciones

Debes poder señalar qué elemento tiene el foco en cada paso. No elimines el contorno del navegador salvo que lo sustituyas por un indicador igual de claro en todos los fondos y estados.

Comprueba las cabeceras fijas, los avisos de consentimiento y las barras fijas para presentar la candidatura en diseños estrechos y ampliados. WCAG 2.2 añadió Foco no oculto al nivel AA porque un foco tapado no sirve de nada.

5. Elimina las trampas para el foco del teclado

Abre todos los diálogos, selectores de fechas, menús y componentes de terceros, y sal de ellos con los comandos de teclado esperados. Prueba Escape cuando sea lo habitual, pero no conviertas un atajo sin documentar en la única salida.

Repite la comprobación después de un error de validación. Las trampas suelen aparecer solo cuando cambia el estado de un componente.

6. Facilita localizar y corregir los errores

Al enviar, enfoca un resumen conciso de errores que enlace con los campos afectados. Cada campo debe identificar su propio error, conservar el valor del candidato y explicar con claridad cómo corregirlo.

No anuncies solo «no válido». Indica qué espera el campo y comprueba después si una persona que utiliza un lector de pantalla oye el resumen y si sus enlaces llevan a los controles correctos.

7. Anuncia los cambios dinámicos de estado

Cuando un candidato elija una fecha y aparezcan nuevas franjas horarias, haz que el estado seleccionado pueda identificarse mediante código y anuncia la actualización. La misma regla se aplica cuando termina una subida, se elimina un archivo, se despliega una sección o falla una comprobación asíncrona.

Anuncia lo que el candidato necesita para continuar y mueve el foco solo cuando el proceso requiera atención inmediata.

8. Haz operables las subidas de CV y portafolios

Mantén un botón convencional para seleccionar archivos aunque ofrezcas arrastrar y soltar. Muestra los formatos admitidos y los límites de tamaño antes de la selección, anuncia el progreso y los fallos, y proporciona una acción accesible para eliminar cada elemento subido.

Tras eliminarlo, devuelve el foco a un lugar previsible. Prueba un archivo rechazado, una subida interrumpida, un nombre de archivo duplicado y un nuevo intento.

9. Ofrece alternativas al arrastre y a los gestos de precisión

Cualquier interacción para ordenar mediante arrastre necesita controles Subir y Bajar o un método equivalente. Los carruseles de fechas deben ofrecer botones o campos normales en lugar de exigir un deslizamiento. Las áreas de interacción pequeñas deben cumplir el tamaño mínimo o las reglas de espaciado de WCAG.

La accesibilidad del puntero también abarca a quienes usan pantallas táctiles, dispositivos de conmutación u otros métodos de entrada.

10. Conserva los datos introducidos cuando haya errores o saltos a otros servicios

Un candidato no debería tener que volver a rellenar una candidatura porque falle un campo, caduque una sesión o se cancele una autorización externa. Conserva los campos válidos y el trabajo subido cuando sea seguro, y explica qué debe repetirse.

Hartwell, Orr y Edwards observaron que eliminar la repetición de datos del CV redujo el abandono de candidaturas sin reducir la calidad de los candidatos. El resumen público no aporta el tamaño del efecto ni un subgrupo de discapacidad, por lo que no debes inventar una afirmación sobre conversión.

11. Evita límites de tiempo inesperados

No dejes que la sesión del formulario caduque sin avisar. Si el límite es necesario, permite que el candidato lo amplíe cuando lo admitan las excepciones aplicables de WCAG, conserva su trabajo y explica cómo reanudarlo.

Prueba el estado caducado con teclado y lector de pantalla. El mensaje de recuperación debe ser alcanzable y comprensible.

12. Publica una vía humana para solicitar adaptaciones

Incluye una vía clara del tipo «¿Necesitas alguna adaptación para presentar tu candidatura?» antes de que el formulario pueda bloquear a alguien. Ofrece una dirección de correo atendida u otro método de contacto accesible, indica un plazo previsto de respuesta y proporciona una forma alternativa de presentar la candidatura.

No exijas información médica detallada ni que la persona complete primero el proceso defectuoso. Esta red de seguridad no sustituye la reparación del portal.

¿Por qué debes probar el recorrido en vez de confiar en un distintivo?

Un análisis automático, una capa superpuesta, un distintivo o un documento de conformidad aportan información, pero no demuestran que un candidato pueda presentar su candidatura. El W3C señala que las herramientas de evaluación no pueden comprobar todos los aspectos de la accesibilidad ni determinar por sí solas si un sitio es accesible.

La guía del W3C sobre herramientas de evaluación recomienda combinar las herramientas con una evaluación humana experta. Un analizador puede detectar enseguida etiquetas ausentes, algunos fallos de contraste y marcado no válido. No puede determinar de forma fiable si el foco llega a un lugar útil después de un error, si la actualización de una franja horaria tiene sentido al anunciarse o si un inicio de sesión externo devuelve al candidato al contexto adecuado.

El estudio de Reuschel añade una advertencia práctica: los portales creados con las mismas grandes plataformas comerciales arrojaron resultados distintos. Tu configuración, las preguntas personalizadas, la capa de marca, los scripts, los componentes de terceros y las integraciones pueden alterar la accesibilidad después de la compra. La afirmación de un proveedor no demuestra que el proceso que has configurado sea accesible.

Utiliza en su lugar una pequeña matriz repetible:

1. Traza los recorridos críticos: encontrar una oferta, presentar la candidatura, subir archivos, provocar un error de validación, corregir errores, enviar, conservar un justificante, entrar en el portal, programar, reprogramar y completar cualquier salto externo.
2. Recorre cada uno con Tab, Mayús+Tab, Intro, Espacio, las teclas de flecha y Escape cuando corresponda.
3. Prueba varias combinaciones de tecnologías de apoyo y registra el navegador, el lector de pantalla, la versión, la fecha y el resultado. Como punto de partida, puedes combinar NVDA con Chrome o Firefox, JAWS con Chrome o Edge cuando esté disponible, y VoiceOver con Safari.
4. Fuerza fallos fuera del recorrido ideal con archivos no válidos, franjas horarias no disponibles, sesiones caducadas, peticiones de red fallidas y autorizaciones canceladas.
5. Incluye a usuarios con discapacidad en evaluaciones por tareas, documenta el perfil de los participantes y las combinaciones probadas, y no extrapoles más allá de ellas.

Registra el recorrido, la combinación, el resultado, el bloqueo, la persona responsable, la corrección y la fecha de la nueva prueba. Ejecuta las comprobaciones de teclado en cada versión pertinente y repite después la evaluación con varias combinaciones cuando cambien los formularios, la programación, la autenticación, las subidas o las traducciones. La compatibilidad con varios idiomas ayuda a los candidatos a utilizar un idioma habilitado, pero la traducción y la accesibilidad siguen siendo líneas de prueba independientes.

¿Qué exigen realmente las normas de accesibilidad de Estados Unidos y la UE?

No existe una única norma que imponga WCAG 2.2 AA a todos los portales de selección. El tamaño del empleador, su carácter público o privado, el tipo de servicio, el contrato y la jurisdicción son determinantes. Considera esta sección una orientación práctica, no asesoramiento jurídico.

En Estados Unidos, el título I de la ADA abarca los procedimientos de solicitud de empleo de los empleadores sujetos a la norma, por lo general aquellos con 15 o más trabajadores. La guía de la EEOC para empleadores señala que los candidatos cualificados tienen derecho a adaptaciones razonables durante el proceso de candidatura, salvo que supongan una carga excesiva. Externalizar el portal no elimina la responsabilidad del empleador.

La norma web del título II del Departamento de Justicia de Estados Unidos es distinta. Adopta WCAG 2.1 AA, no 2.2, para el contenido web y las aplicaciones móviles que proporcionen o pongan a disposición las entidades públicas estatales y locales, también cuando intervengan proveedores. La guía vigente del Departamento de Justicia fija los plazos del 26 de abril de 2027 y del 26 de abril de 2028 según el tamaño y el tipo de entidad. No es una norma general para los sitios web de empleadores privados.

En la Unión Europea, el Acta Europea de Accesibilidad abarca determinados productos y servicios. Su definición de comercio electrónico se refiere a servicios ofrecidos con vistas a celebrar un contrato de consumo, por lo que no es prudente presentar el Acta como un mandato general para los portales de selección. Los sitios web del sector público pueden quedar sujetos a una directiva distinta, y las normas nacionales sobre igualdad, empleo, contratación pública y accesibilidad pueden añadir obligaciones.

Utiliza WCAG 2.2 AA porque es una referencia actual y práctica que incluye criterios útiles como el foco no oculto, las alternativas al arrastre y el tamaño mínimo del área de interacción. No presentes esta decisión de ingeniería como una ley universal. Solicita asesoramiento específico para las jurisdicciones, los empleadores, los sectores y los países a los que prestas servicio.

¿Cómo aborda Kit la accesibilidad del portal del candidato?

Kit trata la experiencia del candidato como un recorrido completo, no como una simple conversión aislada en un formulario. Su implementación actual ya incorpora buenas bases de accesibilidad, pero Kit no ha completado una auditoría pública integral ni afirma cumplir WCAG 2.2 AA.

El proceso de candidatura utiliza etiquetas y controles nativos para los campos principales. Los envíos fallidos muestran un resumen de errores al que puede trasladarse el foco y cuyos enlaces llevan a los campos, conservan los valores introducidos y el CV subido por el candidato cuando corresponde, y permiten corregir en lugar de empezar de nuevo. Las candidaturas enviadas correctamente reciben un justificante duradero y de solo lectura con una referencia que se puede conservar.

La programación de entrevistas emplea botones para elegir la fecha, botones de opción nativos para las franjas horarias, estilos de foco visibles y un diálogo nativo para reprogramar, identificado de forma accesible. Las pruebas en navegador verifican la interacción por teclado en ese flujo de programación. Las páginas del candidato también pueden ofrecer opciones en inglés, alemán, francés, español y polaco.

Queda trabajo por hacer. El portal del candidato necesita un enlace para saltar al contenido y un destino principal que pueda recibir el foco. Los paneles de fecha que aparecen necesitan una gestión del foco más sólida o anuncios mediante regiones dinámicas. La acción «Eliminar archivo», creada de forma dinámica, necesita un nombre accesible y una restauración deliberada del foco. El selector mejorado de zona horaria y el proceso de autorización con GitHub y el regreso al portal aún necesitan pruebas completas de teclado y lector de pantalla con las combinaciones admitidas.

Estas carencias son la razón por la que no convertiremos unos cuantos componentes bien resueltos en una afirmación general de accesibilidad. Los siguientes pasos responsables son corregirlas, realizar una auditoría con varias combinaciones, contar con usuarios con discapacidad, publicar el alcance e incorporar las pruebas resultantes al proceso de lanzamiento.

Una solicitud de empleo accesible no es un distintivo que se compra una vez. Es un recorrido que debe seguir siendo operable a medida que cambian los formularios, las integraciones, los idiomas y las etapas de contratación. Prueba todo el recorrido, registra los bloqueos, mantén una vía de contacto humano y corrige todo lo que impida que alguien cualificado llegue hasta tu equipo.