Preparar una prueba de accesibilidad en navegador

1. Define la entrega

Para quién: Consultores de producto y equipos de calidad que quieren revisar un recorrido concreto con evidencia reproducible.

Tarea: Preparar una prueba del formulario de solicitud de un portal ficticio. La preparación puede hacerse con texto; el resultado requiere observación en navegador.

Consulta la ficha, el acceso y los requisitos del recurso antes de elegir el entorno. El archivo gratuito no incluye un motor de IA; el servicio elegido puede tener cuotas o coste.

2. Prepara la entrada ficticia

CASO FICTICIO — no hay una web ejecutable adjunta.
Recorrido: abrir el diálogo «Solicitar informe», recorrer Nombre, Correo y Enviar; intentar enviar vacío, corregir y cerrar.
Al cerrar, se espera que el foco vuelva a «Solicitar informe».
Se quiere comprobar orden y visibilidad del foco, acceso por teclado y asociación de errores.
Entorno y versión de la aplicación: pendientes. No hay resultados ni observaciones de lector de pantalla.

En un caso real, utiliza solo materiales que puedas compartir con el asistente elegido y retira datos confidenciales o personales innecesarios.

3. Prepara el Markdown y el entorno

1. Descarga el paquete desde la ficha y lee source/accessibility-runtime-tester.agent.md. Declara GPT-5 y alias de herramientas; confirma que tu anfitrión dispone del modelo y resuelve esos alias.
2. La ejecución requiere aplicación accesible, permisos para iniciarla y navegador controlable. El original prefiere Chrome DevTools MCP; esa conexión se configura aparte. Playwright solo se plantea para automatización repetible cuando sea necesaria.
3. Para preparar el plan puedes adjuntar el Markdown o pegarlo en un asistente que lea texto. Si no hay navegador, solicita un plan con resultados pendientes. Cargar el archivo no ejecuta el flujo ni prueba tecnología asistiva.

4. Pide un borrador en español

Con el caso ficticio, prepara en español una tabla con paso, tecla o acción, comportamiento esperado, observación pendiente y evidencia a guardar. Incluye Tab, Shift+Tab, activación, envío vacío, corrección y cierre. No declares aprobados o fallidos: no se ha abierto una aplicación. Para una ejecución posterior pide URL autorizada, versión, navegador y alcance. No modifiques código ni atribuyas comportamiento de lector de pantalla sin observarlo.

El botón copia la solicitud y la entrada completa del paso 2. Conserva la respuesta íntegra si haces un intento propio.

5. Revisa antes de usar el resultado

• El plan debe cubrir la apertura y el retorno del foco al cerrar, además de recorrer campos.
• Distingue el error visible de su relación con el campo y de lo que anuncia un lector de pantalla.
• Todas las observaciones deben seguir pendientes en este ejemplo. Un resultado automático no basta para declarar accesible el recorrido.
• Al ejecutar de verdad, registra pasos, resultado esperado y real, entorno y evidencia; conserva fallos y lo no probado. Una captura aislada no demuestra todo el recorrido.

Si falla un criterio, conserva la diferencia y corrige el borrador. Si falta evidencia, déjala pendiente; superar este ejercicio no demuestra eficacia general.

Límites y procedencia

Esta página no ha ejecutado una aplicación ni realiza una auditoría o certificación de accesibilidad. Las correspondencias con criterios WCAG deben justificarse con el comportamiento observado y el criterio aplicable; no se infiere conformidad de una puntuación automática.

Fuente: Accessibility Runtime Tester, de github / awesome-copilot. Revisión consultada: 613efc8c21d9b3ce642dff361d17006cd9967e28. Licencia original: MIT.

Las funciones y requisitos descritos proceden de ese original; el caso, la solicitud y los criterios son aportación editorial de peopleofthe.ai. Consulta la metodología y la distinción entre documentación, ejemplo y ensayo.

Volver a la ficha del recurso · Elegir otro recorrido para consultorías