
Cómo contratar a un freelancer para una auditoría de accesibilidad web
Una auditoría de accesibilidad web no es un trámite para marcar una casilla. Es una revisión práctica de cómo personas reales navegan por tu sitio con teclado, lector de pantalla, texto ampliado o entrada por voz. Si te preguntas cómo contratar freelancer auditoría accesibilidad web, empieza por definir qué problema quieres resolver, porque una revisión previa al lanzamiento, una auditoría para detectar incidencias y una revisión centrada en cumplimiento no son exactamente lo mismo.
Un proyecto puede necesitar una revisión rápida antes de salir a producción, mientras que otro requiere un análisis completo de un sitio ya existente con decenas de plantillas y años de contenido. Un tercero puede centrarse en un solo flujo, como el pago o la recuperación de cuenta, donde una sola etiqueta rota puede bloquear a un cliente. Un detalle pequeño. Una consecuencia enorme.
Esa distinción importa cuando das instrucciones al freelancer. Una revisión solo de la página de inicio pasará por alto problemas ocultos en formularios, ventanas modales y páginas de usuarios conectados, y precisamente ahí es donde muchas veces los usuarios se encuentran con una barrera. Si puedes indicar la audiencia, el tipo de página o el flujo que más te preocupa, le das al freelancer un objetivo mucho mejor definido.
Define el alcance según los requisitos de WCAG y ADA
El alcance no debería empezar con “revisarlo todo”. Debería empezar con el estándar que quieres que use el freelancer. En la mayoría de los proyectos, eso significa WCAG, pero aun así debes indicar qué nivel esperas: A, AA o un objetivo interno más exigente. Si tu objetivo es una auditoría accesibilidad web WCAG 2.2 AA, dilo así desde el primer momento.
Muchas empresas también quieren que el freelancer tenga en cuenta la reducción de riesgo relacionada con la ADA, sobre todo si el sitio atiende a clientes en Estados Unidos. Eso no sustituye a WCAG. Sirve para perfilar el motivo de negocio de la auditoría, la urgencia de las correcciones y la forma en que se presentan los hallazgos a los equipos legales, de producto y de desarrollo.
Pide el estándar en lenguaje claro. Si necesitas WCAG 2.2 AA, dilo así. Si quieres que el freelancer señale en qué puntos el sitio queda por debajo de ese nivel aunque el problema parezca menor, dilo también. Una frase ambigua en el briefing puede convertirse en tres semanas de discusiones.
En algunos proyectos, el estándar debe vincularse al riesgo. En otros, al momento de salida. Esa diferencia cambia la auditoría. Una campaña de landing pages tolera menos retraso que un rediseño que aún está en borrador. Si necesitas ayuda para integrar el trabajo de accesibilidad dentro de un flujo de proyecto más amplio, la nota sobre normas de colocación y publicación recuerda que las reglas escritas ahorran tiempo después.
Decide qué partes del sitio deben probarse
Un freelancer no puede probar todas las páginas con la misma profundidad salvo que el presupuesto sea alto y el sitio sea pequeño. Lo más sensato es enumerar las plantillas y recorridos que más importan. Cinco o seis áreas concretas suelen ser mucho más útiles que una frase que diga “todas las páginas”.
Empieza por las plantillas: inicio, ficha de producto, categoría, artículo, landing page, pago, configuración de cuenta y páginas de soporte. Luego añade componentes: navegación, búsqueda, filtros, acordeones, ventanas emergentes, banners de cookies y contenido incrustado. Si tu sitio depende de un inicio de sesión, incluye restablecimiento de contraseña y verificación por correo. Si el sitio vende algo, incluye el carrito y el flujo de pago. Esos 2 o 3 recorridos críticos suelen revelar más que 20 páginas decorativas.
No olvides tipos de contenido que pueden dar problemas. Los PDF, los subtítulos de vídeo, los carruseles de imágenes y los gráficos son fáciles de pasar por alto en una revisión superficial y dolorosos de corregir después. Un freelancer debería saber dónde buscar, pero aun así conviene que nombres las áreas de riesgo. Una sola frase puede ahorrar mucho tiempo de suposiciones.
Si gestionas un marketplace o catálogo, comparte los recorridos exactos que más te importan. Una página de resultados con 14 filtros plantea un problema muy distinto al de un sitio corporativo estático. Para equipos con necesidades de búsqueda de producto, el artículo sobre filtro y búsqueda de productos con un freelancer es un recordatorio útil de que la búsqueda y el filtrado merecen su propio alcance.
Elige un freelancer con el método de accesibilidad adecuado
El mejor freelancer no es el que dice “uso Lighthouse”. Los análisis automáticos detectan incidencias útiles, pero no te dicen si una persona que usa solo teclado puede completar un formulario o si un lector de pantalla anuncia correctamente el nombre de un botón. Necesitas a alguien que combine pruebas automáticas con pruebas manuales y revisión con tecnologías de asistencia.
Busca señales prácticas. ¿El freelancer menciona pruebas solo con teclado, comprobaciones con lector de pantalla, orden de enfoque, estados de foco visibles, mensajes de error y HTML semántico? ¿Nombra herramientas como VoiceOver, NVDA o JAWS? ¿Explica por qué un problema importa al usuario, y no solo por qué falla un comprobador? Esos detalles separan a un verdadero freelancer de accesibilidad de alguien que solo exporta un informe. Si además necesitas trabajar con un freelancer accesibilidad web español, conviene verificar que su documentación, comunicación y ejemplos estén alineados con tu equipo.
Pide ejemplos de orientación para la corrección. Un buen freelancer no se limita a decir “fallo de contraste en el texto del botón”. Explica la solución, el componente afectado y la vía probable de implementación. Eso le importa a tu equipo porque un informe sobre el que diseñadores puedan actuar vale más que una lista de avisos. Dos líneas claras de orientación pueden ser mejores que diez páginas de ruido.
Revisa trabajos anteriores con cuidado. Si el freelancer ha auditado sitios gubernamentales, flujos de comercio electrónico, paneles SaaS o medios con mucho contenido, pregúntale qué hizo diferente en cada caso. El método de auditoría debe cambiar según el sitio. Una plantilla no sirve para todo.
Pide un plan de auditoría y un formato de evidencias
Antes de contratar, solicita un plan de auditoría breve. Debe indicar qué se probará, cómo se probará y qué evidencias recibirás. Si no puede resumir el plan en una página, es una señal de alerta.
El plan debería nombrar las herramientas y dispositivos usados, pero no depender solo de ellos. Las pruebas manuales deben ser visibles en el proceso. Pregunta si usarán lectores de pantalla de escritorio, navegación solo con teclado, pruebas de zoom y comprobaciones móviles. Si esperan revisar un flujo con sesión iniciada, pregunta cómo gestionarán las cuentas, los datos de prueba y el acceso por roles. Son preguntas normales, no caprichosas.
El formato de las evidencias importa tanto como el resto. Quieres saber si los hallazgos se agruparán por página, componente o tipo de problema. También quieres saber si cada incidencia incluirá el criterio WCAG incumplido, una descripción breve, el impacto para el usuario, pasos para reproducirlo y una captura o grabación. Así tus desarrolladores podrán trabajar con hechos y no con suposiciones.
Conviene preguntar también cómo priorizará los problemas el freelancer. Algunos equipos quieren “crítico, alto, medio, bajo”. Otros prefieren “bloqueante antes del lanzamiento” y “corregir en el siguiente sprint”. Cualquiera de las dos opciones está bien si el freelancer la explica con claridad. Un informe ordenado es útil; un informe ordenado con prioridades es mejor.
Comprueba cómo comunica las correcciones a tu equipo
Una auditoría de accesibilidad web solo sirve si tu equipo puede actuar sobre ella. Algunos freelancers escriben para abogados. Otros escriben para desarrolladores. Los mejores hacen ambas cosas sin perder al lector en jerga.
Pide un ejemplo de redacción de una incidencia. Una buena explicación debería incluir el problema, dónde aparece, por qué importa y cómo podría ser la solución. Si el freelancer puede nombrar el componente, el patrón de código y el impacto en el usuario con lenguaje claro, probablemente encaje bien. Si la explicación se va hacia abstracciones, espera confusión más adelante.
Aquí es donde importa la colaboración. Los diseñadores necesitan saber si debe verse un indicador de foco, los desarrolladores necesitan suficiente detalle para corregir plantillas o componentes, y los editores de contenido necesitan saber cuándo el texto alternativo o la estructura de encabezados forman parte del problema. Un informe que ofrezca a cada persona un camino claro vale más que un PDF pulido sin siguiente paso.
Comprueba si el freelancer puede hablar de compensaciones. Algunas correcciones son sencillas. Otras afectan al diseño, a la marca o al calendario de lanzamiento. Un freelancer sensato no fingirá que todo es fácil. Te dirá cuándo una solución es directa y cuándo exige decisiones de producto. Esa honestidad ahorra reuniones después.
Acuerda la revisión, la validación y el seguimiento
El trabajo de accesibilidad rara vez termina en una sola pasada. Las correcciones hay que revisarlas. Aparecen regresiones. Un botón puede arreglarse en un sprint y volver a romperse en el siguiente. Incluye eso en el contrato antes de empezar.
Pregunta si el freelancer incluye una nueva validación después de que tu equipo aplique las correcciones. Si la incluye, aclara cuántas rondas entran, qué cuenta como validación y si comprobará solo los problemas originales o también áreas cercanas. Una ronda puede ser suficiente para un sitio pequeño; un rediseño grande puede necesitar dos. Déjalo por escrito.
También deberíais acordar qué pasa con los puntos no resueltos. Algunos problemas no pueden corregirse de inmediato porque dependen de un widget de terceros, de una limitación del CMS o de una decisión de producto. El freelancer debería identificar esos casos y documentar la consecuencia. Eso mantiene la auditoría honesta. Y también ayuda cuando tengas que explicar el riesgo a las partes interesadas.
Para equipos que gestionan freelancers mediante un marketplace, la fase de seguimiento es más sencilla cuando las expectativas quedan escritas con claridad desde el principio. Si tu proceso incluye anuncios públicos o normas de publicación, la página sobre ubicación de anuncios en un marketplace freelance puede servir como punto de referencia sobre cómo una publicación estructurada reduce la confusión.
En algunos casos, una segunda revisión debería hacerse después del lanzamiento, no antes. Esto es especialmente cierto cuando la primera auditoría revela un patrón en formularios, menús o cuadros de diálogo modales. Corrige el patrón una vez, vuelve a probarlo una vez y luego revisa las páginas cercanas. Ese orden evita que el trabajo se convierta en una revisión interminable.
Si tu equipo quiere pasar de una inspección básica a una relación más disciplinada con proveedores, se aplica el mismo principio que cuando trasladas trabajo entre proveedores. Las notas de traspaso claras ayudan a todos. El artículo sobre cómo migrar un proyecto de un estudio web a un freelancer aborda la misma idea: cuanto más limpia es la transferencia, menos sorpresas hay en la entrega.
Un último punto. Pregunta al freelancer qué necesita de ti antes de empezar: acceso al entorno de pruebas, credenciales de prueba, un mapa de roles de usuario o una lista de incidencias conocidas. Si puede nombrar esos 4 elementos sin dudar, probablemente sabe cómo llevar a cabo una auditoría de accesibilidad que genere correcciones y no solo hallazgos.

Comentarios 0
No hay comentarios aún — sé el primero.