Hello, I hope you don't mind my cc-ing debian-accessibility. For best impact, this discussion should really be kept public.
Arpit Jain, le dim. 27 sept. 2026 04:27:47 +0000, a ecrit: > If convenient, could you please point me towards any existing Debian, Orca, > AT-SPI or related automated accessibility testing infrastructure, test suites > or work in this direction which you consider particularly relevant? Debian itself does not write automatic tests, it runs the upstream testsuites on package building, and on reverse-dependencies uploads, notably for: - at-spi2-core - dogtail - espeak-ng - liblouis mentioning it, I now realize that orca now has a testsuite, but we were missing the pytest-mock dependency to get it run, fixing it. > I would also value your view on which parts of accessibility testing can > realistically be automated in CI and which necessarily require testing by > actual users with disabilities. That's a vast question. The testsuites above are mostly about the accessibility tools themselves working. For general software accessibility, it's a completely different question, which reminds me the question "can websites accessibility be automatically tested?", for which it is rather a "no" than a "yes". That being said, some testing can be achieved. Some years ago I led the development of gla11y: https://github.com/hypra/gla11y which allows to automatically check the labelling of dialog boxes made with glade, I wrote a white paper that explains the principles: https://inria.hal.science/hal-02957129 It is notably used by libreoffice in its testsuite: https://blog.documentfoundation.org/blog/2018/05/07/welcome-gla11y-the-user-interface-accessibility-checker/ https://wiki.documentfoundation.org/Development/Accessibility and a few MATE tools use it too. Oh, I now notice that liferea uses it too :) We had also worked at hypra on writing testing scripts, I don't know the current status of it. But just like for web accessibility, this is only a piece of testing, even if already quite useful. dogtail can be used to automate testing, but it requires updating the scripts on software interface changes, it's hard to maintain. I had an idea of automatically testing some properties such as the tab order and reachability of elements, but haven't yet found time to work on it. Ideally, such testing should be integrated in upstream testsuites, to catch regressions during development. > I would like, over time, to encourage collaboration across > distributions and upstream projects rather than having each project > solve the same accessibility problems independently. So it would be about inventing tools and then promoting them to upstream software. Distributions will then naturally run them along the rest of the testsuites, ideally they won't actually have to care beyond making sure to run the complete testsuite. With regards, Samuel
