Plasma Next Accessibility

Hello,

it’s been a looong time since I wrote in this blog, lately things usually end up in the Qt blog. I hope everyone is reading up on accessibility and other fun things Qt there ;) My contributions to KDE were code-wise mostly small things (such as helping a little with porting Kate’s accessibility implementation to Qt 5) and I’m happy that Parley found new maintainers (thanks Amarvir and Inge!).

I’ve been wondering for quite some time though how the state of Plasma Next is when it comes to accessibility. In this case accessibility is mostly how the applications and desktop shell expose semantics to the accessibility framework via an API (on Linux the beast is called AT-SPI, a DBus API). The goal is that assistive technology such as a screen readers (Orca), the screen magnifier, or Simon can pick up what’s going on and assist the user. This allows for example blind people to use the software. The big thing here is that while Qt never had good support for QGraphicsView accessibility, we plowed away at making things work well with Qt Quick. This afternoon I finally got around to looking at the next iteration of the KDE desktop for real. In fact I’m writing this in a running Plasma Next session on top of the frameworks 5 libraries. It feels a bit like the porting from KDE 3 to 4, except that most things seem to just work so far.

I ended up running the neon5 packages on top of Kubuntu. I don’t manage to keep up with the speed of KF5 development and whenever I want to run anything I’d be building and the day is usually over when I figured out the dependencies and such. Instead I now ignored all warnings (big red signs saying: “don’t do this at home kids”) and installed the daily build packages (for some reason the weekly one didn’t work at all on my laptop). After that I built and installed the things I was interested in over the system packages to be able to debug them. This is a horrible way of messing up one’s installation, but since the neon packages install nicely into /opt, I decided to go for it. I ended up wanting to debug a few things, so now I have my own build of qtbase+declarative+plasma-frameworks+plasma-workspace+plasma-desktop.

The first issue I ran into is that Gnome changed their interpretation of a settings value which is reflected on DBus in the a11y service… the property IsScreenReaderEnabled will now return false, even when a screen reader is running. I’ll have to find a better way of starting Qt’s accessibility on Linux, hopefully for Qt 5.4. There is no real standard to these things since so far it was a Gnome-only thing.

For now the work-around is to simply run this one-liner before trying anything else:
gsettings set org.gnome.desktop.a11y.applications screen-reader-enabled true

With that in place I could restart plasmashell and see that … there was not much to see.
Before running a screen reader, it makes sense in this case to use one of the explore and debugging tools first to see what is exposed about the desktop.
I ran “Randamizer” which is an example that comes with libkdeaccessibilityclient, the alternative is “Accerciser”. Both tools now showed me plasmashell (yay!) and I could navigate to see the hierarchy of accessible elements. Which turns out to be completely empty (meh). I was not quite sure if this was due to bugs or simply really no information was provided, luckily (that’s easier to fix) it turned out to be the second one.

Screenshot of Randamizer
I started writing a few patches for the above mentioned plasma repositories and now I have at least a few things showing up, I can see the clock is there and even see the time displayed. I can also see the desktop element as such and some panels. The patches need cleaning up, but I’m happy that getting the basics to work will be relatively easy.
Now I don’t think I’ll manage to go though all of KDE and Plasma to fix simple issues, even though I’ll try to get the basics covered in the next few days. Consider this is a call for help, please join KDE’s accessibility mailing list (IRC is also good) and help out.
The most basic work is to look at the Qt Quick items used in Plasma and add some simple information to them. For example for the Button.qml in plasma-frameworks the patch will add these lines:

Accessible.role: Accessible.Button
Accessible.name: text
Accessible.description: tooltip
Accessible.checkable: checkable
Accessible.checked: checked

They are just a few bindings, but with QML it is impossible to automatically detect the meaning of a an item – is it just decorative or part of a control? Where is the actual control? Which Rectangle has which significance?
This is why it’s important for authors of Qt Quick UIs to use standard controls where possible. Qt Quick Controls shipped with Qt are accessible, the Plasma ones will soon be, I hope :) When writing custom controls, the properties as shown above need to be added.
For more information on what properties are available and should be set, check the documentation for the Accessible attached property.

1 comment to Plasma Next Accessibility

  • [...] Plasma Next Accessibility I’ve been wondering for quite some time though how the state of Plasma Next is when it comes to accessibility. In this case accessibility is mostly how the applications and desktop shell expose semantics to the accessibility framework via an API (on Linux the beast is called AT-SPI, a DBus API). The goal is that assistive technology such as a screen readers (Orca), the screen magnifier, or Simon can pick up what’s going on and assist the user. This allows for example blind people to use the software. The big thing here is that while Qt never had good support for QGraphicsView accessibility, we plowed away at making things work well with Qt Quick. This afternoon I finally got around to looking at the next iteration of the KDE desktop for real. In fact I’m writing this in a running Plasma Next session on top of the frameworks 5 libraries. It feels a bit like the porting from KDE 3 to 4, except that most things seem to just work so far. [...]