Pruebas de accesibilidad con automatización del navegador

Las pruebas de accesibilidad de automatización del navegador son más útiles cuando verifican el mismo recorrido que una persona debe completar: encontrar un control, acceder a él sin un puntero, comprender su nombre y estado, completar una tarea y recuperarse de un error. Una ejecución automatizada no puede certificar todos los aspectos de la accesibilidad, pero puede proteger contratos repetibles que, de otro modo, serán fáciles de revertir. El objetivo práctico es una prueba pequeña y observable que explique qué se verificó y qué aún necesita revisión humana.

Comience con una página sintética autorizada o una cuenta de prueba. El navegador puede observar la semántica representada, el movimiento del foco, el comportamiento del teclado y el estado visible. No puede establecer que una persona real con una tecnología de asistencia particular experimentará cada interacción correctamente, ni puede probar que un servicio procesó una mutación remota. Mantenga esos límites en el resultado para que una afirmación de navegador verde no se presente como una afirmación de conformidad completa. Las Pautas de accesibilidad al contenido web proporcionan criterios de éxito; la especificación ARIA explica funciones, estados y propiedades.

Las pruebas de accesibilidad también deben incluir los estados en los que los clientes se encuentran con mayor frecuencia: un usuario que regresa, una ventana de visualización estrecha, un idioma cambiado, un permiso bloqueado y una respuesta de la red que llega tarde. Para cada estado, defina el enfoque, el nombre, el estado y la acción de recuperación esperada. Esto mantiene la prueba cerca de la promesa del producto y deja espacio para la revisión manual del habla, la ampliación y la carga cognitiva.

Una ejecución de accesibilidad es más sólida cuando su alcance es visible antes de comenzar. Nombra la ruta, los datos sintéticos, la ventana gráfica, el modo de entrada, el punto de referencia esperado y el propietario de la limpieza. Decida si la ejecución es una verificación de componentes, una tarea completa o una muestra de compatibilidad. Esto evita que una afirmación limitada del teclado se informe como una auditoría de todo el producto y brinda a los revisores una razón clara para agregar verificaciones manuales.

Convertir un requisito de accesibilidad en un contrato observable

Escriba el resultado del usuario antes de elegir un localizador. "Un usuario de teclado puede abrir los filtros, elegir un valor y comprender que la lista cambió" es un contrato. "Haga clic en el botón de filtro y espere dos segundos" es un detalle de implementación. Una prueba útil nombra el estado inicial, la secuencia de acción, el propietario del foco esperado, el resultado visible o anunciado y la evidencia limitada retenida cuando falla un paso.

Separe las observaciones del navegador del significado de la aplicación. Un botón puede exponer un nombre accesible mientras se rechaza la solicitud del servidor. Una región de estado puede recibir texto mientras una cola de lector de pantalla lo presenta más tarde o no lo presenta en absoluto. Afirme los datos del navegador que posee y luego haga una declaración de aplicación separada para el resultado visible para el usuario. Esta separación permite al propietario de una página corregir la semántica sin implicar que la prueba inspeccionó datos de servicios privados.

Prefiere un viaje por prueba. Una prueba de inicio de sesión no debería verificar también un cuadro de diálogo de configuración y una exportación de archivos porque una falla de enfoque en el primer paso oscurecería los contratos posteriores. Dale a cada viaje un insumo sintético, un dueño y un camino de limpieza. Mantenga el resultado breve: etiqueta del escenario, versiones del navegador y del marco, nombre del contrato fallido y una captura de pantalla permitida o una referencia de seguimiento. Nunca serialice tokens, texto de página completo o una sesión privada simplemente porque el conductor puede hacerlo.

Verifique nombres, roles y estados sin sobreajuste

Los localizadores accesibles describen lo que una persona puede identificar. Un rol con un nombre accesible, una etiqueta asociada con un control de formulario o un identificador de prueba estable puede hacer que la prueba sea legible. Una clase generada o una ruta CSS profunda dice poco sobre la interacción y tiende a romperse durante el trabajo de diseño inofensivo. Cuando un control intencionalmente no tiene texto visible, documente su nombre accesible y pruebe el nombre como parte del contrato del componente.

Los nombres y descripciones no son intercambiables. Un diálogo necesita un nombre que identifique su propósito; una descripción puede agregar contexto. Un campo obligatorio debe exponer su estado requerido y un campo no válido debe exponer una relación de error que apunte a texto útil. Pruebe la transición de estado, no solo el marcado inicial. Un formulario puede representar "aria-invalid="true"` y dejar el antiguo mensaje de error en el DOM, lo que es un resultado confuso tanto para la automatización como para la tecnología de asistencia.

Evite afirmar atributos ARIA incidentales cuando el HTML nativo ya proporciona el comportamiento. Un botón, una etiqueta, un encabezado, una lista y un enlace nativo tienen una semántica y un comportamiento de teclado bien definidos. ARIA puede describir un widget personalizado, pero el propietario del widget debe implementar su modelo de interacción. Una verificación automática que solo ve un role="button" no puede confirmar que Space y Enter lo activen, que el foco permanezca visible o que un estado deshabilitado evite la activación accidental.

Ejercer el enfoque del teclado como una ruta de primera clase

La cobertura del teclado debe seguir la tarea, no una secuencia aleatoria de pulsaciones de tabulador. Comience en un punto de enfoque conocido, avance por los controles significativos, active una acción y registre hacia dónde se dirige el enfoque a continuación. Un modal debe mover el foco a su contenido, evitar que el foco se escape mientras está abierto y devolver el foco a un disparador sensible cuando esté cerrado. Un enlace para saltar debería hacerse visible cuando esté enfocado y moverse al punto de referencia deseado.

Compruebe si hay un indicador de enfoque visible sin necesidad de un color o valor de píxel exacto. El contrato es que un usuario puede identificar el control enfocado frente al tema aprobado. Una captura de pantalla puede respaldar una revisión, pero no es una prueba de contraste universal entre pantallas. Utilice CSS y aserciones de estilo computarizado solo para las propiedades que posee el componente y deje el juicio visual matizado a una revisión humana que incluya alto contraste y zoom.

Pruebe alternativas de teclado para widgets personalizados. Un menú, cuadro combinado, lista de pestañas, árbol o cuadro de diálogo tiene un conjunto documentado de claves y cambios de estado. Pruebe las claves admitidas, el estado seleccionado o expandido y el siguiente objetivo de enfoque. Incluye Escape o la ruta de cancelación documentada. No presione teclas arbitrarias hasta que algo cambie; eso convierte un contrato determinista en una investigación y puede hacer que una falla sea difícil de clasificar.

Una prueba de teclado también debería cubrir el camino bloqueado. Si un campo obligatorio está vacío, envíelo con el teclado y verifique que el error sea visible, asociado con el campo y accesible en un orden lógico. Si se niega un cuadro de diálogo de permiso, verifique que la página proporcione una alternativa utilizable. Una prueba que solo cubre el camino feliz puede dejar a los usuarios del teclado varados exactamente donde la aplicación necesita explicar un problema.

Verificar anuncios y contenido dinámico

Las interfaces dinámicas necesitan una estrategia de anuncio. Un mensaje de estado cortés puede utilizar una región en vivo; una interrupción urgente puede requerir una política diferente. La prueba puede afirmar que la región existe, tiene el papel o la cortesía prevista y recibe el breve texto esperado después de la acción. No se debe afirmar que cada lector de pantalla, configuración de voz o cola del sistema operativo presentará el mensaje de manera idéntica.

Mantenga estables las afirmaciones de la región activa. Espere a que cambie el estado nombrado y luego lea el texto accesible de la región una vez. No realice una encuesta activando repetidamente la acción y no acepte ninguna cadena que no esté vacía como exitosa. Si la aplicación actualiza intencionalmente la misma región varias veces, haga valer el mensaje final relevante para el usuario y registre la transición que se dirigió allí. Un tiempo de espera debería identificar el anuncio que falta, no simplemente decir que la página era lenta.

Los estados de carga y error merecen el mismo trato. Es posible que una rueda giratoria por sí sola no explique el progreso a un usuario no visual, mientras que un botón desactivado sin ningún motivo puede parecer un control roto. Pruebe la relación entre el estado de ocupación, el texto de estado y el contenido final. Cuando falla una solicitud, verifique que el error se anuncie o se coloque donde el usuario lo encontrará, y que se pueda acceder al reintento o a acciones alternativas mediante el teclado.

No utilice la automatización para recolectar árboles de accesibilidad de sitios no relacionados o sesiones de usuarios reales. En un dispositivo controlado, una instantánea de accesibilidad puede ayudar a comparar un componente antes y después de un cambio. Conserve solo los nodos necesarios para explicar la afirmación, redactar el contenido del usuario y aplicar la misma política de retención que las capturas de pantalla y los seguimientos. La instantánea es evidencia de una observación del navegador, no un registro de una persona o una puntuación de accesibilidad universal.

Hacer que los accesorios y las carreras paralelas sean inclusivos

Un dispositivo de accesibilidad posee más que un contexto de navegador. Posee la ventana gráfica inicial, la configuración de zoom o tamaño de texto, la preferencia de movimiento reducido cuando sea relevante, la configuración regional, la cuenta sintética y el directorio de artefactos. Declare qué valores son fijos para el escenario y cuáles varían en una matriz separada. Un trabajador nunca debe heredar el estado de enfoque, el almacenamiento, la ruta de descarga o el nombre del archivo de captura de pantalla de otro trabajador.

Utilice un contexto limpio para cada viaje independiente cuando las cookies, los permisos o las preferencias almacenadas afecten el resultado. Un contexto aísla el estado administrado por el navegador, pero no es un entorno limitado del sistema operativo y no elimina un registro del servidor. Si una aplicación almacena una preferencia de forma remota, solicite al propietario de la aplicación la operación de restablecimiento admitida. El dispositivo puede informar lo que supervisa el navegador antes y después de esa operación.

Los trabajadores paralelos deben utilizar registros sintéticos y rutas de salida privadas. Si dos trabajadores modifican un registro, un contexto limpio no puede evitar una carrera por el servicio. Prefiere registros independientes o serializar la mutación específica. Un reintento es un nuevo intento: cierre el contexto antiguo cuando su estado sea incierto, cree un contexto nuevo de propiedad e informe que la primera acción puede haber llegado a la aplicación. Nunca ocultes un posible envío duplicado detrás de una espera más larga.

Incluir un caso de falla intencional en el conjunto de accesorios. Retener un punto de referencia, retrasar una actualización de estado o devolver un error de validación documentado desde la página sintética. El resultado esperado es una falla limitada al nombrar el contrato faltante seguido de una limpieza determinista. Esto verifica el arnés de prueba, no un servicio de producción, y mantiene la evidencia de accesibilidad proporcional a la pregunta que se hace.

Separate tool support from conformance claims

Playwright y Selenium pueden controlar la entrada del teclado, inspeccionar nombres accesibles y esperar el estado visible o semántico. Sus API difieren y la compatibilidad del navegador con funciones relacionadas con la accesibilidad puede variar según la versión. Registre el marco, el controlador, el navegador, el sistema operativo y las preferencias relevantes con el resultado. Una ejecución aprobada de una tupla es prueba de esa tupla; no es una promesa de que todos los navegadores y tecnologías de asistencia se comportan de manera idéntica.

Los motores de reglas automatizados pueden detectar nombres faltantes, identificaciones duplicadas, riesgos de contraste y algunos problemas estructurales. Utilícelos como ayuda para la revisión, no como sustituto de la exploración con el teclado, el zoom, el reflujo, las comprobaciones del lector de pantalla o la investigación de usuarios de dominios específicos. Un informe de reglas debe identificar el nodo y la regla, mientras que la prueba de viaje debe explicar si el usuario puede completar la tarea. Mantenga separadas las fallas de ambas herramientas para que una advertencia de regla no se malinterprete como un resultado comercial fallido.

Cuando un navegador muestra una instantánea de accesibilidad o una función calculada, compare solo campos estables y relevantes para el usuario. Los formatos de instantáneas pueden cambiar entre las versiones del marco. Prefiera una afirmación como "el botón Guardar se llama Guardar perfil y se habilita después de una entrada válida" a una comparación de árbol byte por byte. Almacene una pequeña diferencia o una referencia de elemento y revise los cambios más importantes intencionalmente cuando se rediseñe la semántica de un componente.

La especificación W3C WebDriver define el límite de la automatización, mientras que las WCAG definen resultados que involucran a personas y contenido. Ninguna fuente dice que un producto, perfil o controlador de automatización en particular pueda certificar la conformidad. Redacte su informe en consecuencia: enumere los recorridos probados, los entornos, las fallas observadas y las verificaciones manuales que aún se requieren.

Capacidad y limitación de BotBrowser

BotBrowser proporciona BrowserContexts aislados con cookies, almacenamiento y estado de sesión separados, lo que ayuda a los equipos a repetir los recorridos de accesibilidad autorizados desde puntos de partida conocidos del lado del navegador. BotBrowser no reemplaza las afirmaciones de accesibilidad de Playwright o Selenium, la política de teclado o lector de pantalla, la semántica de aplicaciones, la revisión de WCAG ni la limpieza del lado del servidor. No puede garantizar que una aplicación de destino exponga un nombre accesible correcto, que una tecnología de asistencia pronuncie una actualización de región en vivo o que una sesión y un registro remoto queden invalidados. El propietario del dispositivo aún elige el marco, crea y cierra contextos, controla los datos sintéticos y obtiene evidencia fuera de los límites del navegador del propietario de la aplicación.

Mantenga la capacidad y la limitación juntas en los informes. Registre el propósito del contexto, la versión del navegador, las entradas de preferencias, el contrato de viaje, el resultado observado y las comprobaciones manuales restantes. No describa un perfil aislado como prueba de accesibilidad o como una forma de evitar los controles de una aplicación. Un estado local limpio hace que una prueba sea repetible; no cambia las responsabilidades de la página, el servicio o la tecnología de asistencia.

Revisar fallas y mantener el conjunto de pruebas

Clasifique una falla antes de cambiar un localizador o tiempo de espera. Un nombre accesible que falta es un defecto del componente. Una trampa de enfoque que nunca se libera puede ser un defecto en el ciclo de vida del widget. Un anuncio que falta puede ser un problema de integración de tecnología de asistencia o del estado de la página. Una desconexión del conductor es evidencia de infraestructura. El rechazo del servidor es el resultado de una aplicación. La prueba del navegador debe preservar el primer contrato faltante y dirigir la siguiente acción al propietario, quien puede cambiarlo.

Revise las rutas negativas después de cada cambio de componente. Pruebe un formulario vacío, un valor rechazado, un permiso denegado, una respuesta lenta, un diálogo cerrado y una navegación interrumpida donde esos estados son parte del viaje. Verifique que cada error tenga una explicación legible y una siguiente acción accesible. Mantenga el mismo límite de evidencia para aprobación y falla para que una falla no recopile inesperadamente más contenido de página privada.

Antes de fusionar, ejecute un recorrido de teclado de contexto limpio, un recorrido sensible a las preferencias cuando corresponda y un error de desmontaje forzado. Confirme que el foco vuelve a un propietario intencional, que los artefactos son específicos del trabajador y que la limpieza se ejecuta después de errores de afirmación y configuración. Vuelva a verificar la tupla del navegador y del marco cuando cambien las versiones. Una prueba estable no es aquella que nunca falla; es aquel cuyo fallo identifica un contrato de cara al usuario y no deja ningún estado que pueda distorsionar la siguiente ejecución.

La automatización de la accesibilidad funciona mejor como una práctica en capas: los localizadores semánticos protegen el significado de los componentes, los recorridos del teclado protegen la finalización de las tareas, los anuncios y los estados de error protegen la comunicación y la revisión humana protegen las experiencias que el código no puede modelar. Mantenga cada capa limpia, delimitada y honesta sobre lo que observa. Esa disciplina brinda a los equipos de productos evidencia de regresión útil sin convertir la capacidad de un navegador en una garantía de conformidad no respaldada.

Los controles de accesibilidad se vuelven más fáciles de mantener cuando cada resultado menciona el viaje, el entorno, el propietario y la incertidumbre restante. Mantenga un breve historial de las versiones probadas del navegador y del marco, observe si una revisión humana cubrió el zoom o un lector de pantalla, y revise el contrato cuando cambie un componente. Este registro ayuda a los clientes a comparar versiones, priorizar correcciones y evitar tratar un único pase automatizado como una promesa universal.

Sources

Consulta también ciclo de vida de BrowserContext y validación de interacción del navegador.

BotBrowser proporciona BrowserContexts aislados para repetir recorridos autorizados con cookies y almacenamiento separados. No sustituye las aserciones de Playwright o Selenium, la revisión WCAG, el lector de pantalla ni la limpieza del servidor.

• W3C Web Content Accessibility Guidelines 2.2
• W3C Accessible Rich Internet Applications
• W3C WebDriver
• BotBrowser multi-account isolation