1. Accessibility repositories are now merged

    Translations: es - Tags: accessibility, gnome

    Over the past week I worked on merging the atk and at-spi2-atk repositories into at-spi2-core. A quick reminder of what they do:

    • at-spi2-core: Has the XML definitions of the DBus interfaces for accessibility — what lets a random widget identify itself as having a Button role, or what lets a random text field to expose its current text contents to a screen reader. Also has the "registry daemon", which is the daemon that multiplexes applications to screen readers or other accessibility technologies. Also has the libatspi library, which is a hand-written binding to the DBus interfaces, and which is used by...

    • at-spi2-atk: Translates the ATK API into calls to libatspi, to effectively make ATK talk DBus to the registry daemon. This is because...

    • atk: is mostly just a bunch of GObject-based interfaces that programs can implement to make themselves accessible. GTK3, LibreOffice, and Mozilla use it. They haven't yet done like GTK4 or Qt5, which use the DBus interfaces directly and thus avoid a lot of wrappers and conversions.

    Why merge the repositories?

    at-spi2-core's DBus interfaces, the way the registry daemon works, atk's interfaces and their glue in at-spi2-atk via libatspi... all of these are tightly coupled. You can't make a change in the libatspi API without changing at-spi2-atk, and a change in the DBus interfaces really has to ripple down to everything, but keeping things as separate repositories makes it hard to keep them in sync.

    I am still in the process of learning how the accessibility code works, and my strategy to learn a code base, besides reading code while taking notes, is to do a little exploratory refactoring.

    However, when I did a little refactoring of bit of at-spi2-core's code, the tests that would let me see if that refactoring is correct were in another repository! This is old code, written before unit tests in C were doable in a convenient fashion, so it would take a lot more refactoring to get it to a unit-testable state. I need end-to-end tests instead...

    ... and it is at-spi2-atk that has the end-to-end tests for all the accessibility middleware, not at-spi2-core, which is the module I was working on. At-spi2-atk is the repository that has tests like this:

    • Create a mock accessible application ("my_app").
    • Create a mock accessibility technology ("my_screen_reader").
    • See if the things transferred from the first one to the second one make sense, thus testing the middleware.

    By merging the three repositories, and adding a code coverage report for the test suite, we can add a test, change some code, look at the coverage report, and see if the test really exercised the code that we changed.

    Changes for distributions

    Please see the announcement on discourse.gnome.org.

    That coverage report is not accessible!

    Indeed, it is pretty terrible. Lcov's genhtml tool creates a giant <pre>, with things like the execution count for each line just delimited with a <span>. Example of lcov's HTML.

    (Librsvg's coverage report is pretty terrible as well; grcov's HTML output is a bunch of color-coded <div>. Example of grcov's HTML.)

    Does anyone know code coverage tools that generate accessible output?

Page 1 of 92 (next)