Cómo crear un programa de pruebas de accesibilidad web por funciones

Convierta las pruebas de accesibilidad en un sistema de trabajo distribuido, no en una auditoría que aparece cuando el lanzamiento ya está comprometido. Antes de comenzar un cambio, identifique los recorridos, componentes, plantillas y contenidos afectados; después asigne a cada método un detonante, una etapa, una persona preparada para ejecutarlo, una autoridad que acepte el resultado y un responsable de repetir la prueba. Así, el equipo no llega a la revisión final con un escaneo automatizado como única evidencia mientras nadie ha completado la tarea con teclado, revisado la redistribución, evaluado el significado de las etiquetas ni documentado quién corregirá los hallazgos.

¿Qué convierte las pruebas de accesibilidad en un programa y no en una auditoría final?

Un programa distribuye distintas clases de evidencia a lo largo del diseño, el desarrollo, la producción de contenido, QA y la preparación del lanzamiento, sin diluir quién acepta el riesgo. W3C recomienda evaluar temprano y durante el desarrollo porque entonces resulta más fácil atender los problemas. También advierte que ninguna herramienta determina por sí sola si un sitio satisface las normas: se necesita evaluación humana informada. Los ejemplos de Section508.gov muestran cómo repartir actividades entre producto, diseño, desarrollo, contenido, QA, especialistas y supervisión, aunque sus asignaciones federales no son requisitos universales para empresas privadas.

• Detección automatizada: encuentra de forma repetible condiciones que pueden comprobarse mediante software; un resultado limpio no decide la conformidad.
• Comprobación manual: examina comportamiento, estructura y significado que requieren criterio humano, incluidas tareas completas y estados de interacción.
• Pruebas con tecnologías de asistencia: investigan compatibilidad en tareas representativas dentro de entornos definidos y reproducibles.
• Evaluación con personas discapacitadas: revela fricciones de uso y necesidades no cubiertas que los otros métodos pueden pasar por alto.

¿Cómo debe cambiar la profundidad de las pruebas según el trabajo que se lanzará?

La profundidad debe crecer con la interacción, la reutilización, la novedad, la importancia del recorrido y el posible impacto sobre usuarios. Primero inventaríe las vistas, componentes, documentos, medios, controles y tecnologías afectadas; luego seleccione evidencia proporcional. La siguiente clasificación es un modelo editorial adaptable, no una escala oficial ni una base para declarar conformidad fuera de lo evaluado. Section508.gov documenta profundidades distintas y recomienda monitoreo continuo y evaluación con personas discapacitadas. Para una evaluación de conformidad más amplia, WCAG-EM propone definir alcance, explorar funciones clave, seleccionar cobertura representativa, evaluar y documentar resultados.

• Cambio solo de contenido: revisión humana y automatización aplicable; agregue estructura, teclado, ampliación o tecnología de asistencia si cambian controles, medios, documentos o el significado de la tarea.
• Cambio visual o de distribución: revisión de diseño, comprobaciones automatizadas y pruebas de ampliación o redistribución; revise el foco cuando también cambie la interacción.
• Componente o interacción: criterios de aceptación antes de construir, comprobaciones locales del desarrollador, ejecución independiente de QA, estados relevantes y regresión cuando el componente se reutiliza.
• Plantilla nueva, recorrido crítico o lanzamiento mayor: todas las capas pertinentes, tareas representativas, pruebas especializadas, evaluación de conformidad por muestreo y participación temprana de personas discapacitadas.

¿Qué debe incluir la matriz de propiedad de pruebas y quién controla cada entrega?

La matriz debe convertir cada capa de prueba en un acuerdo operativo visible: detonante y alcance, primera etapa útil, ejecutor, autoridad de aceptación, preparación y entorno, evidencia conservada, efecto sobre el lanzamiento y dueño de la repetición. Diseñadores, autores y desarrolladores siguen respondiendo por sus decisiones; QA agrega planificación y revisión independiente. La persona líder de accesibilidad administra políticas, métodos, capacitación e interpretaciones difíciles sin convertirse en ejecutora universal. En un equipo pequeño, alguien puede usar varios sombreros, pero la matriz debe nombrar cuál usa y reservar evaluación preparada o independiente para el trabajo de mayor riesgo.

La accesibilidad deja de ser el control final de otra persona cuando cada cambio llega con evidencia, responsables y una ruta de repetición.

¿Qué debe examinar cada comprobación principal de accesibilidad?

Cada comprobación debe ejecutar tareas y estados relevantes, no limitarse a confirmar que una herramienta abrió o que una regla pasó. La automatización debe registrar su alcance y detectar condiciones programáticamente comprobables. La revisión humana debe decidir si títulos, encabezados, etiquetas, enlaces, instrucciones, mensajes de error, subtítulos, transcripciones y alternativas de texto comunican significado útil en contexto. WCAG 2.2 incluye requisitos sobre estos elementos, además de operación mediante teclado, salida del foco, foco visible y foco no oculto por completo en el nivel AA. La revisión debe conservar pasos, resultado, impacto y contexto suficientes para reproducir el hallazgo.

• Complete tareas con teclado: opere cada control pertinente, siga el orden esperado, entre y salga de componentes, observe cambios de estado y recupérese de errores.
• Confirme que el indicador de foco sea visible y que contenido creado por el autor no oculte por completo el elemento enfocado.
• Amplíe el texto hasta 200 %, con las excepciones del criterio, y compruebe que no se pierdan contenido ni funcionalidad.
• Para redistribución, pruebe por separado el equivalente de 320 píxeles CSS de ancho sin desplazamiento horizontal y 256 píxeles CSS de alto sin desplazamiento vertical.
• Respete la excepción para diseños que necesitan dos dimensiones por su significado o uso y busque pérdidas, obstrucciones, foco oculto y cambios fuera de la vista.

¿Cuándo se necesitan tecnologías de asistencia, personas discapacitadas y evaluación de conformidad?

Agregue estos métodos cuando el cambio, la importancia de la tarea o la incertidumbre exijan más seguridad, pero mantenga clara la pregunta que responde cada uno. GOV.UK recomienda pruebas de tecnologías de asistencia durante el desarrollo y después de cambios importantes mediante tareas representativas. Seleccione navegadores, sistemas operativos y tecnologías actuales según evidencia de la audiencia, arquitectura del producto, compromisos de soporte y riesgos conocidos; no copie una matriz universal. Un lector de pantalla es un método de compatibilidad, no una simulación de todas las personas ciegas ni una prueba suficiente de conformidad.

• Registre tarea afectada, impacto, comportamiento esperado, navegador, sistema operativo, tecnología y versión, evidencia, responsable de corrección y resultado de la repetición.
• Involucre a personas discapacitadas en prototipos y recorridos críticos mientras los hallazgos todavía puedan cambiar el trabajo; atienda primero barreras obvias importantes sin posponer toda participación.
• No generalice la experiencia de una persona a una población. La investigación puede ir desde comentarios sobre un prototipo hasta estudios formales de tareas.
• Combine evaluación con usuarios y evaluación basada en normas: una revela fricciones de uso; la otra examina conformidad. Incluso la máxima conformidad no cubre cada necesidad individual.

¿Cómo debe la evidencia controlar el lanzamiento y mejorar el programa?

La decisión de lanzamiento debe basarse en la evidencia exigida para la clase de cambio, no en una puntuación global. Las comprobaciones aplicables deben estar completas; los hallazgos definidos como bloqueantes, corregidos y repetidos; y el registro debe identificar alcance, método, entorno, resultado, responsable, disposición y estado de repetición. La autoridad de producto o lanzamiento acepta la decisión, mientras QA y especialistas aportan evidencia independiente y los creadores conservan la responsabilidad de corregir. Los ejemplos de Section508.gov conectan planes, defectos, pruebas, registros, preparación del lanzamiento y comentarios posteriores, pero cada organización debe autorizar sus propias reglas.

1. Pruebe primero un recorrido crítico y complete su rastro de evidencia.
2. Capacite a cada responsable en el método que ejecutará o aceptará.
3. Incorpore plantillas de hallazgos y automatización pertinente al flujo habitual.
4. Calibre reglas de bloqueo con las autoridades de producto, QA y accesibilidad.
5. Conecte defectos recurrentes con regresión, capacitación, componentes y plantillas.
6. Amplíe la cobertura solo después de que el piloto produzca decisiones trazables.

Si la política permite una excepción, conserve autoridad, justificación, usuarios afectados, mitigación, fecha de vencimiento y seguimiento. La excepción no cambia el resultado ni establece conformidad. Después del lanzamiento, use barreras reportadas y defectos repetidos para actualizar la matriz y la capacitación. Recurra a evaluación especializada para interacciones complejas, cobertura representativa o hallazgos disputados; a investigación experimentada para estudios con personas discapacitadas; y a asesoría legal calificada para interpretaciones de cumplimiento propias de una jurisdicción.