Notes of the confcall meetings

2020 June 23rd

Organization

Have wiki page (this one) where we put notes of our meetings.

TODO list:

• move from hackfest notes to separate page which we will try to keep up to date, or at least keep the list of what we are working on.

• create issue entries, that we link from this TODO list.
• for issues recorded on the gnome gitlab, we can use gitlab tags to keep an always-up-to-date list of issues.
• for other issues (e.g. Brltty, Qt), we have to go through the wiki page to get to the issues, and we'd try to note DONE tags in the wiki page when we can

Widening the discussions

• There is a chatroom on matrix on accessibility with people from kde

Next meeting: like 2nd or 3rd week of september

Gtk4: before the end of the year, we want to fix keyboard before that so people can test with orca.

The API will get frozen with the 4.0 release, not before, so applications will probably not want to move before. Porting gnome on gtk4 will be done one app by one app

We can however test gtk4 before that:

• gtk4-demo: various typical interfaces, has a small description and the source code. We want to add a third tab that contains a thorough description of what the user is supposed to be able to read, so that testers know whether they could actually test completely or not (otherwise they can't know that they missed something, since they couldn't read it). Tests with sighted + non-sighted user might still be needed.
• gtk4-widget-factory
• gtk4-icon-browser (for icons)

and test applications as they get ported.

Some RedHat people are doing some a11y tests, they could probably help. The 3.99 release will probably ramp up testing.

Debian experimental currently contains gtk 3.98.2. As this gets updated we can ask Debian users to test gtk4-demo

Testing of latest releases can be done in flatpak. Normally accessibility of flatpak "just works" out of the box: sandbox publishes external files and the a11y bus to the sandbox, so it should work, the code is there. If it doesn't work we shall just debug and fix.

Emmanuele will make the pipeline push the built flatpak image to a stable public URL so the bleeding-edge version can be tested easily.

Emmanuele will try to put at-spi in the CI pipelines

At-spi bus connection

Finding the AT-SPI bus

• There is the legacy AT_SPI_BUS X11 property which tells where the AT-SPI bus is, which we might want to get rid of.
• It is seen useful to be able to run e.g. "orca -l" from an ssh connection or such. Setting DISPLAY and seeing everything else work is really useful.
• On Wayland a protocol could be introduced to get the address of the AT-SPI bus, to get the same behavior.
• Ibus actually has the same kind of issue, see with them to find a common solution

Qt support

• Samuel discussed about it with some Qt people, they will wait for something to settle before working on it.

Authorization

• Not seen as a blocker for gtk 4.0

What is under the mouse? RPC

Mike worked on notification in at-spi in general

Mouse notification: there will probably be work to share with ponytails

We will need granularity within the text of a textview: the mouse moving between words, and the user needs feedback on the words. Getting notification over each character could generate way too much trafic, we need to be smarter. There are several possibilities, the screen readers could request for a piece of text, and get notified when the mouse goes out of the rectangle of that piece. We need to see with Joanmarie to see what we'd need exactly.

Key events/shortcuts

xinput2: Samuel sent some working pieces of code to Mike. Mike made some progress on key events and shortcut registration. Will agree on an API with Joanmarie.

On the Wayland side key events will most probably be in the compositor, Carlos worked on it.

forwarding bug on https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1328

Key shortcuts: no progress yet on the Wayland side. Managing capslock shouldn't be much different from the management of shift/super.

Mike can take some dayjob time to work on this.

a11y stack revamping

generating the code, cleaning up

Generating the AT-SPI interfaces directly from XML: this is not complete yet, because we don't yet have enough information in XML. Emmanuele had to add annotations in the XMLfiles to generate the documentation in addition to the code.

There are bunches of places where the dbus interface can be cleaned up, and notably implement the freedesktop dbus properties interface, so it is able to notify multiple properties at the same time. There are also object manager details as well, to clean signal connection, and gobject plugging would get more optimized.

Some changes would need a dbus namespace bump to keep compatibility with existing code.

For now no remove, only deprecation.

Emmanuele is waiting for some changes in gtk before being able to merge into at-spi

Caching

Caching could be handled generically (problems of stale data etc.)

gdbus codegen can cache things: it pulls all properties in one go, and queries can then be answered locally. The notifications on the bus will then update the cache.

• -> cache invalidation support will be shared

• -> maintenance / bug fixing shared

dropping ATK

Removing atk use from gtk is being merged into gtk4

It adds an interface that widgets will have to implement, an outline of the approach is available on https://gitlab.gnome.org/GNOME/gtk/-/issues/2833

This is heavily based on ARIA. Every single accessible object will have to implement it to expose accessible information directly from gtk and not through atk. This will manage property change etc.

Basically, an AT_context, which kind of works like input methods, and that is what will actually talk over dbus

test backends are to land in the testsuite

We will grow a set of application development rules to make sure that new widgets respect the rules

• -> we can check before merging a new widget in gtk

• -> but also in applications: document how to create a pipeline in the application CI to make the check

Talking dbus directly

on the firefox/chromium/libreoffice side we will probably want to see things above settle down before looking there

On the webkit side, they would be very happy to be able to share the ARIA translation layer with GTK

accessibility checking tools

Samuel still has to write a white paper on gla11y

misc

caret thickness merged to gtk4, will backport to gtk3

caret blink: we can add to the widget development guide that this is needed for a11y -> will remain

automatically test? We can check that the setting exists

new high contrast theme on gtk3 & 4: one regression, add it to the list of blockers.

scrollsubstringto in gtk: Martin Pieuchot cleaned his MR to contain what we need and could implement completely: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1120 Emmanuele will review

2020 October 7

at-spi inside gtk

Merging the new API basics inside gtk is done, with tests (local, not through at-spi). There were some issues with aria because of some mismatch between the widget embedding done by gtk and the aria ssumptions

It would be useful to also do some tests through at-spi, but as a separate test suite, for instance over gtk4-demo, with recorded scenarii, and check that there is no regression there. Hypra has experience with doing it over LibreOffice and Thunderbird and can contribute.

Last month-ish: working on the at-spi implementation. There are some issues with accerciser and other ATs not receiving the datat they expect it. There were some expectations of the happens-to-be behavior of the current atk+atspi-atk implementation, that should perhaps go.

It would be fine to have to fix accerciser accordingly, and also orca, provided that we can fix it early so that it is released when gtk4 starts getting used by actual users.

Currently looking at the xml descriptions of the protocol, to generate most of the code. There would be some interface bumps to fix some corner cases.

We need to keep an eye on the X11 compatibility with Xwayland, notably the at-spi property on the root window which doesn't exist in Xwayland... some toolkits are rather using the dbus session bus, but some might still be using the root property, notably when running multi-user.

Next step would be p2p connection

a11y testing

Samuel wrote a white paper to explain how gla11y tests .ui files and reports 2000 warnings rather than 8000 warnings on LibreOffice https://github.com/hypra/gla11y/blob/master/doc/gla11y.md

colors

In the color palette there are some colors that Matthias didn't really have good names for (green1, green2, green3, etc.). It's still useful to have names so that blind people at least have an idea what color it is. green[123] is not very explicit, possibly more precise could be greenlight[1-3] greendark[1-3] to tell how light and how dark. And not use complex names that only color geeks know about

XInput

Mike made some progress on using XInput for keybindings, with some code snippets from Samuel. Goal: new API for Orca to monitor keys and create key bindings, with two backends (X11/wayland).

Notification is working, keybinding as well to some extent. Will need to revisit a bit how Orca does it (i.e. not let Orca decide on the fly what to eat, and rather make it tell what it wants to eat).

Misc

evince PDF accessibility support ? Will probably be looked at anyway because it's necessary for government grants etc.

https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1120 to be merged, needs a rebase for gtk3

Next meeting? When Emmanuele's work is ready we can test and iterate by mail for a start, and when we feel it useful, organize a meeting.