Notes of the confcall meetings
2020 June 23rd
Have wiki page (this one) where we put notes of our meetings.
- 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-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
- Samuel discussed about it with some Qt people, they will wait for something to settle before working on it.
- 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.
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 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
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
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