[Feature Request] Make scans against Chromium-based UIs more actionable about axe-windows HOT 9 CLOSED

After discussion in Windows triage, this will require some fundamental changes. We feel this needs to be treated as a full feature and not as a kluge fix.

from axe-windows.

This issue has been marked as ready for team triage; we will triage it in our weekly review and update the issue. Thank you for contributing to Accessibility Insights!

from axe-windows.

Triaged with the team.
We will show a Framework rule error and then eliminate or not scan the Chromium component

from axe-windows.

This issue requires additional investigation by the Accessibility Insights team. When the issue is ready to be triaged again, we will update the issue with the investigation result and add "status: ready for triage". Thank you for contributing to Accessibility Insights!

from axe-windows.

This issue requires additional investigation by the Accessibility Insights team. When the issue is ready to be triaged again, we will update the issue with the investigation result and add "status: ready for triage". Thank you for contributing to Accessibility Insights!

from axe-windows.

¿Su solicitud de función está relacionada con un problema? Sírvase describir.

Este problema se basa en la discusión con y después de varias interacciones con los clientes en las que los usuarios que intentan escanear aplicaciones basadas en Chromium se confunden.

El caso más común es un usuario que intenta escanear un navegador (Edge, Chrome, etc.) con su página cargada, pero también hemos visto casos en los que un usuario tiene su propia aplicación de Windows que incrusta Chromium (por ejemplo, a través de Electron o WebView2).

Hay dos problemas relacionados que ocurren cuando un usuario hace esto:

• La mayoría de los AT utilizan instancias especiales de Chromium, de modo que es mucho más útil para fines prácticos de accesibilidad escanear contenido web con un escáner web como Accessibility Insights for Web, en lugar de con axe-windows/Accessibility Insights for Windows. Sin embargo, los resultados de axe-windows no hacen ninguna mención de esto, aunque podríamos distinguir fácilmente estos casos mediante programación (buscando una propiedad UIA de FrameworkId de "Chrome").
• Incluso con un uso absolutamente mínimo de WebView2 que sirve una página vacía sin problemas, hay algunos problemas de baja gravedad que marcan axe-windows que son esencialmente problemas de marco (~ 10 violaciones). Los usuarios no pueden hacer nada al respecto, pero actualmente no los tratamos como problemas de marco.BoundingRectangleNotNull

Describa la solución que desea

Rob y yo creemos que idealmente manejaríamos esto en el lado de las ventanas de hacha de manera similar a cómo tratamos el borde antiguo: crear una regla que detecte específicamente una instancia de cromo incrustada (a través de FrameworkId "Chome") y presentar un error específico que indique directamente a los usuarios que escaneen el contenido del navegador con un escáner basado en la web. Tal regla probablemente debería suprimir de alguna manera cualquier error adicional en los descendientes del elemento raíz "Chrome"; esto requerirá una nueva forma de manejo, actualmente no tenemos ninguna otra regla que haga este tipo de supresión de subárbol.

Es un poco cuestionable llamar a esto un "Error", ya que realmente no queremos tratarlo como un error para usar un WebView2 en absoluto, pero realmente no tenemos un mejor medio para presentar comentarios procesables a un usuario sobre la necesidad de un paso adicional para escanear dicho componente. Sin embargo, creo que un solo error procesable sería claramente mucho mejor que el caso actual de "docenas o cientos de errores inaccionables".

Describa las alternativas que ha considerado

• El verdadero estándar de oro en términos de facilidad de uso para el cliente podría ser realizar un escaneo de núcleo de hacha dentro de la instancia de cromo detectada de alguna manera. Pero creemos que esto probablemente sería técnicamente inviable de hacer automáticamente a menos que la instancia de Chromium aceptara comandos del depurador CDP, y sería una gran cantidad de trabajo presentarlo razonablemente.
• Sería bueno investigar / archivar errores contra las violaciones que están constantemente presentes independientemente del contenido de la página. Hicimos una investigación inicial y creemos que esto es probablemente un problema en el lado de Chromium en lugar del lado de WebView2 / MSAA_Proxy, pero no definimos una ubicación exacta. Si quisiéramos hacer un seguimiento de esto, los buenos contactos a los que llegar para obtener más contexto serían las personas marcadas como PROPIETARIOS de la plataforma de accesibilidad de Windows de Chromium. Sin embargo, creemos que presionar sobre estos es una prioridad bastante baja; Los problemas en sí son de tan baja gravedad que creemos que sería difícil obtener tracción sobre ellos, por lo que si terminamos haciendo la regla propuesta arriba que los enmascararía de todos modos, no vale la pena el esfuerzo de tratar de llevarlos a la resolución.BoundingRectangleNotNull

Contexto adicional

n/d

Yo le cobraría

¿Su solicitud de función está relacionada con un problema? Sírvase describir.

Este problema se basa en la discusión con y después de varias interacciones con los clientes en las que los usuarios que intentan escanear aplicaciones basadas en Chromium se confunden.

El caso más común es un usuario que intenta escanear un navegador (Edge, Chrome, etc.) con su página cargada, pero también hemos visto casos en los que un usuario tiene su propia aplicación de Windows que incrusta Chromium (por ejemplo, a través de Electron o WebView2).

Hay dos problemas relacionados que ocurren cuando un usuario hace esto:

• La mayoría de los AT utilizan instancias especiales de Chromium, de modo que es mucho más útil para fines prácticos de accesibilidad escanear contenido web con un escáner web como Accessibility Insights for Web, en lugar de con axe-windows/Accessibility Insights for Windows. Sin embargo, los resultados de axe-windows no hacen ninguna mención de esto, aunque podríamos distinguir fácilmente estos casos mediante programación (buscando una propiedad UIA de FrameworkId de "Chrome").
• Incluso con un uso absolutamente mínimo de WebView2 que sirve una página vacía sin problemas, hay algunos problemas de baja gravedad que marcan axe-windows que son esencialmente problemas de marco (~ 10 violaciones). Los usuarios no pueden hacer nada al respecto, pero actualmente no los tratamos como problemas de marco.BoundingRectangleNotNull

Describa la solución que desea

Rob y yo creemos que idealmente manejaríamos esto en el lado de las ventanas de hacha de manera similar a cómo tratamos el borde antiguo: crear una regla que detecte específicamente una instancia de cromo incrustada (a través de FrameworkId "Chome") y presentar un error específico que indique directamente a los usuarios que escaneen el contenido del navegador con un escáner basado en la web. Tal regla probablemente debería suprimir de alguna manera cualquier error adicional en los descendientes del elemento raíz "Chrome"; esto requerirá una nueva forma de manejo, actualmente no tenemos ninguna otra regla que haga este tipo de supresión de subárbol.

Es un poco cuestionable llamar a esto un "Error", ya que realmente no queremos tratarlo como un error para usar un WebView2 en absoluto, pero realmente no tenemos un mejor medio para presentar comentarios procesables a un usuario sobre la necesidad de un paso adicional para escanear dicho componente. Sin embargo, creo que un solo error procesable sería claramente mucho mejor que el caso actual de "docenas o cientos de errores inaccionables".

Describa las alternativas que ha considerado

• El verdadero estándar de oro en términos de facilidad de uso para el cliente podría ser realizar un escaneo de núcleo de hacha dentro de la instancia de cromo detectada de alguna manera. Pero creemos que esto probablemente sería técnicamente inviable de hacer automáticamente a menos que la instancia de Chromium aceptara comandos del depurador CDP, y sería una gran cantidad de trabajo presentarlo razonablemente.
• Sería bueno investigar / archivar errores contra las violaciones que están constantemente presentes independientemente del contenido de la página. Hicimos una investigación inicial y creemos que esto es probablemente un problema en el lado de Chromium en lugar del lado de WebView2 / MSAA_Proxy, pero no definimos una ubicación exacta. Si quisiéramos hacer un seguimiento de esto, los buenos contactos a los que llegar para obtener más contexto serían las personas marcadas como PROPIETARIOS de la plataforma de accesibilidad de Windows de Chromium. Sin embargo, creemos que presionar sobre estos es una prioridad bastante baja; Los problemas en sí son de tan baja gravedad que creemos que sería difícil obtener tracción sobre ellos, por lo que si terminamos haciendo la regla propuesta arriba que los enmascararía de todos modos, no vale la pena el esfuerzo de tratar de llevarlos a la resolución.BoundingRectangleNotNull

Contexto adicional

n/d

Yo le cobraría 45000CLP por la suscripción y la pronta asesoría

from axe-windows.

¿Su solicitud de función está relacionada con un problema? Sírvase describir.

Este problema se basa en la discusión con y después de varias interacciones con los clientes en las que los usuarios que intentan escanear aplicaciones basadas en Chromium se confunden.

El caso más común es un usuario que intenta escanear un navegador (Edge, Chrome, etc.) con su página cargada, pero también hemos visto casos en los que un usuario tiene su propia aplicación de Windows que incrusta Chromium (por ejemplo, a través de Electron o WebView2).

Hay dos problemas relacionados que ocurren cuando un usuario hace esto:

• La mayoría de los AT utilizan instancias especiales de Chromium, de modo que es mucho más útil para fines prácticos de accesibilidad escanear contenido web con un escáner web como Accessibility Insights for Web, en lugar de con axe-windows/Accessibility Insights for Windows. Sin embargo, los resultados de axe-windows no hacen ninguna mención de esto, aunque podríamos distinguir fácilmente estos casos mediante programación (buscando una propiedad UIA de FrameworkId de "Chrome").
• Incluso con un uso absolutamente mínimo de WebView2 que sirve una página vacía sin problemas, hay algunos problemas de baja gravedad que marcan axe-windows que son esencialmente problemas de marco (~ 10 violaciones). Los usuarios no pueden hacer nada al respecto, pero actualmente no los tratamos como problemas de marco.BoundingRectangleNotNull

Describa la solución que desea

Rob y yo creemos que idealmente manejaríamos esto en el lado de las ventanas de hacha de manera similar a cómo tratamos el borde antiguo: crear una regla que detecte específicamente una instancia de cromo incrustada (a través de FrameworkId "Chome") y presentar un error específico que indique directamente a los usuarios que escaneen el contenido del navegador con un escáner basado en la web. Tal regla probablemente debería suprimir de alguna manera cualquier error adicional en los descendientes del elemento raíz "Chrome"; esto requerirá una nueva forma de manejo, actualmente no tenemos ninguna otra regla que haga este tipo de supresión de subárbol.

Es un poco cuestionable llamar a esto un "Error", ya que realmente no queremos tratarlo como un error para usar un WebView2 en absoluto, pero realmente no tenemos un mejor medio para presentar comentarios procesables a un usuario sobre la necesidad de un paso adicional para escanear dicho componente. Sin embargo, creo que un solo error procesable sería claramente mucho mejor que el caso actual de "docenas o cientos de errores inaccionables".

Describa las alternativas que ha considerado

• El verdadero estándar de oro en términos de facilidad de uso para el cliente podría ser realizar un escaneo de núcleo de hacha dentro de la instancia de cromo detectada de alguna manera. Pero creemos que esto probablemente sería técnicamente inviable de hacer automáticamente a menos que la instancia de Chromium aceptara comandos del depurador CDP, y sería una gran cantidad de trabajo presentarlo razonablemente.
• Sería bueno investigar / archivar errores contra las violaciones que están constantemente presentes independientemente del contenido de la página. Hicimos una investigación inicial y creemos que esto es probablemente un problema en el lado de Chromium en lugar del lado de WebView2 / MSAA_Proxy, pero no definimos una ubicación exacta. Si quisiéramos hacer un seguimiento de esto, los buenos contactos a los que llegar para obtener más contexto serían las personas marcadas como PROPIETARIOS de la plataforma de accesibilidad de Windows de Chromium. Sin embargo, creemos que presionar sobre estos es una prioridad bastante baja; Los problemas en sí son de tan baja gravedad que creemos que sería difícil obtener tracción sobre ellos, por lo que si terminamos haciendo la regla propuesta arriba que los enmascararía de todos modos, no vale la pena el esfuerzo de tratar de llevarlos a la resolución.`

from axe-windows.

The Chromium rule now triggers exactly once for each Chromium Document. All rules are suppressed for elements within the Chromium Document

from axe-windows.

Released as part of 2.2.0. Closing as complete.

from axe-windows.