Declaración de accesibilidad
Última actualización: 2026-09-01
Talaskill se compromete a ser utilizable por todas las personas, incluidas quienes usan tecnología de asistencia como lectores de pantalla, magnificadores de pantalla, control por voz o navegación solo con teclado.
Nuestro compromiso
Trabajamos para cumplir con las Pautas de Accesibilidad para el Contenido Web (WCAG) 2.1, Nivel AA. Este es el estándar más exigido por la legislación de accesibilidad en todo el mundo, y el que nos aplicamos en toda la plataforma, no solo en un puñado de páginas de muestra.
Cómo lo comprobamos
Ejecutamos una auditoría automatizada real — axe-core, impulsada por Playwright — sobre un conjunto representativo de páginas de la plataforma: la página de inicio pública, las páginas de registro, inicio de sesión y restablecimiento de contraseña, el listado público de empleos y las páginas legales, y las páginas del panel de control, empleos, credenciales, contratación, apelaciones, privacidad, evaluaciones, creador, guía de habilidades, juego de descubrimiento y administración una vez iniciada la sesión.
Cada página se analiza en tres idiomas: inglés (de izquierda a derecha), árabe (de derecha a izquierda, la dirección con más probabilidad de exponer un fallo que una auditoría solo en inglés pasaría por alto) y español (un segundo idioma de izquierda a derecha, para detectar algo específico de la longitud del texto y no del contenido en inglés). Las páginas con sesión iniciada se analizan tanto como una cuenta de candidato normal como, cuando corresponde, como administrador de la plataforma.
El script de auditoría está incluido en el código en scripts/a11y-audit.mjs y se ejecuta con un solo comando, npm run check:a11y, para poder volver a ejecutarlo antes de cualquier lanzamiento en lugar de confiar en que siga siendo preciso con el tiempo.
Qué encontró la auditoría más reciente
A la fecha indicada arriba, la auditoría analizó 54 combinaciones de página/idioma (18 páginas distintas × 3 idiomas) y encontró inicialmente tres defectos reales y distintos:
- Contraste de color insuficiente en texto atenuado y en los enlaces de Privacidad/Términos del pie de página del sitio — 441 elementos afectados en 41 de los 54 análisis.
- Varios campos de formulario en las páginas de inicio de sesión, registro, restablecimiento de contraseña y perfil cuya etiqueta visible no estaba asociada programáticamente con su campo, por lo que un lector de pantalla no podía anunciar para qué servía el campo — 57 elementos afectados en 15 análisis.
- Dos menús desplegables — el selector de nivel de requisito de habilidad en la página de contratación y el selector de visibilidad del perfil en la página de privacidad — sin ningún nombre accesible — 153 elementos afectados en 6 análisis.
Qué hicimos al respecto
Los tres defectos se corrigieron directamente en el código fuente: los colores de texto y enlaces se cambiaron a tonos que cumplen la relación de contraste de 4.5:1 que exige WCAG 2.1 AA para texto de tamaño normal, cada etiqueta afectada se conectó a su campo, y ambos menús desplegables recibieron un nombre accesible real que describe lo que controlan.
Después se volvió a ejecutar la misma auditoría automatizada en las 54 combinaciones de página/idioma y no se encontró ninguna infracción. Ese resultado — no solo esta declaración — es lo que significa aquí "respaldado por una auditoría real".
Qué no cubre esto
Queremos ser directos sobre los límites de las pruebas automatizadas en lugar de dejar que un análisis limpio se interprete como algo más de lo que es. Herramientas como axe-core detectan de forma fiable una parte importante de los defectos de accesibilidad — etiquetas faltantes, contraste insuficiente, ARIA no válido y similares —, pero, según la propia documentación de la herramienta, las comprobaciones automatizadas por sí solas solo pueden detectar entre un tercio y dos quintas partes de los criterios de éxito de WCAG. No pueden juzgar si el texto alternativo de una imagen realmente la describe, si el contenido se lee en un orden sensato para alguien que navega solo con teclado o lector de pantalla, ni si un usuario de teclado puede quedar atrapado en alguna parte de la página.
Todavía no hemos completado una revisión manual dedicada con un lector de pantalla (como NVDA o VoiceOver), un recorrido completo solo con teclado de cada flujo, ni pruebas con personas que usan tecnología de asistencia a diario. Son carencias reales y reconocidas en nuestro proceso actual, no las ocultamos: cerrarlas es trabajo de seguimiento independiente.
Mantener esto al día
La lista de páginas del script de auditoría crece a medida que lo hace la plataforma, y tenemos la intención de ejecutarlo antes de publicar cualquier cambio en una página que cubra. A la fecha de esta declaración, ejecutarlo es un paso manual, no una puerta automática en integración continua — este proyecto todavía no cuenta con un pipeline de CI en absoluto, lo cual es en sí una carencia conocida en cómo publicamos cambios en general, no específica de la accesibilidad.
Cuéntanos qué no funciona
Si usas tecnología de asistencia y encuentras algo en Talaskill que no funciona como debería, queremos saberlo. Escribe a Talaskill1@gmail.com indicando la página en la que estabas y qué ocurrió, y lo trataremos como un error real, con la misma seriedad que daríamos a cualquier otro defecto reportado de esta manera.