Testing OS-specific accessibility APIs in WPT - can it be done??

Logistics

Date & Time: Wednesday 5th June at 15:00 CEST (local time)
URL: https://meet.jit.si/WEH2024-Testing-Accessibility
Notes: https://github.com/Igalia/webengineshackfest/wiki/2024-Testing-OS-specific-accessibility-APIs-in-WPT
Slides: https://notes.igalia.com/p/pgqfgU8DV#/

Facilitator(s)

@spectranaut (Igalia) @alice (Igalia)

Summary

Assistive Technologies (such as screen readers) interact with applications like browsers through OS-specific accessibility APIs. Part of the work of the ARIA working group is mapping ARIA and HTML features to the platform specific accessibility APIs, which you can see in the Core-AAM and HTML-AAM standards. Browsers implement these standards.. but we don't have automated tests in WPT for them.. and why not??

There are a few reasons why this hasn't been done, yet. To add automated accessibility test we would need to:

Introduce tests that have OS-specific results
Introduce tests that need to be run on Browser/Operating System pairs (instead of only Browsers)
Introduce tests will need to find the accessibility API for each browsers, ideally via a process ID but potentially through the browser name (limiting parallelizability).
Introduce tests will need to query the accessibility API of each browser, which is somewhat complicated and entirely operating system dependent.

Igalians have been prototyping an extension to testdriver.js to run these tests. In this scenario, the code to run the tests lays alongside the webdriver APIs. In this breakout group, we will discuss current design, short comings of this approach and problem solve solutions.

Type

Onsite

Other comments

No response

Igalia / webengineshackfest