A sample text widget
Etiam pulvinar consectetur dolor sed malesuada. Ut convallis
euismod dolor nec pretium. Nunc ut tristique massa.
Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan.
Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem,
suscipit in posuere in, interdum non magna.
|
Hi, I’ve been asked to make a new release of libqaccessibilityclient, which seemed like a good idea. So here we go: https://download.kde.org/stable/libqaccessibilityclient/ – version 0.3.0 is now available. I’d like to say thanks to the KDE sysadmins for being super fast.
Now if I wasn’t involved with the accessibility project, I’d have no clue what this is about… so What is libqaccessibilityclient?
It’s a small library that can help understand/use the accessibility information available on DBus. It could be used to write assistive applications such as screen readers. Right now my main purpose for it is to understand what’s going on, so I use it as debugging helper. There are now two small helper applications, one has been there before and shows a complete tree of accessibility objects, so the representation of applications as screen readers see them. The second one is new, it just dumps the same tree on the command line. I used this to find out KWin’s state, since doing anything while pressing alt-tab is hard. I could run it on the command line with a sleep and then see what KWin reported while I pressed alt-tab.
By the way, we’ve been organizing our work on a phabricator board here, feel free to comment and help out with some of the tasks, especially when it comes to Plasma keyboard handling.
Chrys took up the role of coordinator, fixer and new master of KDE accessibility, which I think is just fantastic. We have been working on what he decided to be most important, mostly chrys fixing issues to make things work with Plasma and screen readers. After getting Orca to read desktop icons he spent quite some time to improve the various start menus.
With so much fresh energy around I started poking at KWin, which was a bit scary, to be honest. It was fun to read code I hadn’t looked at before. In the end, after I spent a while working on a huge work-around, it turned out that we could enable the task switcher to work with relatively little code added. The main issue was that KWin does really not want to give focus to the task switcher. My first attempt was to write sub-classes of QAccessibleInterface for everything in KWin. That started to work, but during some debugging I realized that KWin was actually creating the regular representations for its UI, it was just not properly announcing them to Orca. Thus I threw away my almost complete prototype. At least I verified that it’s possible to create an entire Qt UI for screen readers only, disconnected from the actual UI. Thanks to QAccessible::installFactory it is nowadays pretty easy to instantiate custom representations (subclasses of QAccessibleInterface). Once that was done, I started over and made the task switcher think it’s an active window without letting X11 or Wayland know. That way we get the right dbus messages sent to Orca, when alt-tabbing through the windows. Thanks David, Martin, Roman and Vlad for your input 🙂
More work is needed on Plasma when it comes to keyboard usability – getting the focus onto the panel and the various notification areas. I’m sure some great ideas are already being worked on, but I can see this easily as a blocker going forward. Configuring the network, checking the battery status and other tasks are really important after all.
I wrote the basics for Kate to work with screen readers in 2014 and it seems like there are some improvements needed when working with Orca, luckily we got some help from Joanie (who maintains Orca) to figure out what goes wrong when navigating by lines. Now it’s just to verify the findings and get the issues sorted out.
If you have a bit of time and want to help, we need someone with good English skills to help clean up the wiki. Good written instructions are really helpful when getting blind users to try Plasma for the first time. We’d also be happy if more people joined in testing and improving things. Join the KDE Accessibility mailing list to join the fun.
It’s been rather quiet when it comes to accessibility in KDE land for a while. But I’m very happy to see some movement and fresh energy, moving in a good direction.
If you’re curious about making our software available to more users, improving it for everyone (for example keyboard usability), now is the time to join. We are talking on the accessibility mailing list. It’s still to early to say what the exact plan will look like, but there will be progress. Thanks to the last Randa meeting, we reached the point where a few things in Plasma do work with a screen reader, enough to let a few brave souls experiment with it. Now we’ll have to structure what needs improvements, I could imaging defining some workflows. Once we have broken down the big goal of making Plasma a joy to use with a screen reader, we’ll have to make sure of a few things for each sub goal:
- Keyboard navigation needs to work – being blind, using a mouse is often pointless, since you won’t see the pointer. It’s very important that we can do everything with the keyboard. This is of course good for everyone, we all win.
- The screen reader needs to know what to present to the user – we need to make sure that buttons that only show an icon have an alternative description for example. Some work has been done in this direction, but without user testing, it won’t be polished or even complete.
- Performance fixes in the accessibility stack – this needs some investigation, some of the implementation in Qt may not be in agreement with what Orca expects.
I think we really need someone to take on the role of coordinator and help move this forward, listening to users what’s most important and getting developers to spend a little time fixing things. This is really something anyone can help with, and I think we already have some people interested on the list.
The accessibility BoF at Akademy this year consisted mainly of Alex Merry and me looking at what needs to be done to get Orca working with Plasma Next. While things are far from perfect and sighted assistance is probably still required, there is slow but steady improvement.
Assuming you have a recent release of Plasma Next (5.3 and up), testing is quite easy. It boils down to installing Orca (in some distributions gnome-orca) and clicking a checkbox in System Settings:
- make sure Orca is installed and sound from speech dispatcher works
- when installing Orca, speech-dispatcher should come along. Test it with “spd-say hello” in a terminal. Make sure to have some text to speech synthesizer installed (Arch for example doesn’t seem to give you one by default…), get espeak since it’s easy and fast.
- enter System Settings, find “Desktop Behavior” -> “Accessibility” and the last tab will be “Screen Reader”. Currently it only contains a check box to activate the screen reader. It seems like things are not working out of the box as much as I’d like them to (help investigating why not much appreciated), so logging out of the session will be required.
- restart your desktop session.
 
You will be greated by Orca speaking Gnome and Qt 5 based applications (including Plasma). For Qt 4 based applications, get qt-at-spi and have QT_ACCESSIBILITY=1 in your environment (or even better, port them to Qt 5).
For Plasma itself, make sure to use the traditional menu, and check that the menu has a keyboard shortcut associated (alt-f1).
When pressing that shortcut, the menu should open and be read when navigating the menu with the arrow keys. The lock-screen mostly works, but many other things need a bit of polish when it comes to being able to control them with the keyboard only and have them read properly.
I hope this is enough to get someone started to poke at things. Especially for Qt Quick based applications, it’s often very easy to fix accessibility bugs, by adding the Accessible attached property to give some context.
Consider helping triaging, organizing testing and fixing pressing issues when it comes to accessibility. I think KDE can become usable for a new audience in one or two releases. I would love to see this happen and I’m quite exited about it, but I know I won’t find the time to get it done by myself.
In just a few days we’ll have an open source conference in Oslo. I’m happy that we’ll have a Qt and KDE track, so I’d like to invite everyone to join for the weekend May 8-10 at the University of Oslo.
If you’re involved with KDE or Qt and would like a promo code, just send me a message.
Just head over to osdc.no and join! There will be a panel discussion on Friday.
The program for the weekend can be found here: Saturday and Sunday
I got involved in organizing a local conference in Oslo: Open Source Developers’ Conference Nordic. I’m very much looking forward to an open source event here!
And it looks like we will have a Qt track! I’d be happy to add more Qt and KDE talks, so sign up. Of course everyone involved in free and open software is invited to join. And a big thanks goes to the local Perl Mongers to get the whole show started.
Here is the invitation to join the event:
OSDC Nordic is an upcoming open-source friendly community-oriented
event, held May 8th - 10th in Oslo.
Open Source Developers' Conference exists to enable the many Nordic
open source communities to come together and share their enthusiasm.
Read more about the event on
http://osdc.no/cfp.html
We want you and your friends to come together to learn, hack and share
their enthusiasm!
Participate by presenting a talk, hosting a workshop, involving your
community, by volunteering, or simply by participating in this awesome
and unique event. Register on http://goo.gl/forms/fgUhby8aU9
Feel free to contact us with any questions on organizers@osdc.no
And finally. To build a great community event we need everybody care by sharing.
Help us spread the word!
KDE’s yearly conference Akademy is currently on. It’s great to see so many familiar and new faces.
Anyone interested in the Qt Project, KDE Accessibility and other fun topics find me and talk to me.
I will give two talks:
- Qt Quick and input: is about how to handle mouse and keyboard in Qt Quick applications. It’s actually a talk that I gave in similar form at Qt Dev days and I recommend everyone who writes applications with QML to join and learn some of the more tricky aspects of Qt Quick.
- The second talk will be about KDE Accessibility. I’m excited to talk about how we can make KDE a great choice for many more users. I will explain how blind users “see” the desktop and what’s missing. If just a few people show interest, we can include and welcome a new group of curious users.
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.
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.
I’ll be talking about accessibility for KDE on Sunday afternoon, please join me and help getting your application into the hands of ever more users.
At the same time I’ll be happy to talk about the Qt Project. And I’m looking forward to meeting so many old and new friends.
Quite often the question comes up how to build a KDE application.
Now we have great tools such as kdesrc-build and buildtool and long wiki pages on techbase…
But many of these aim at building not just one application but the world. Or at least kdelibs and everything on top of it. To start development, it’s often easier to build just the application you care about. Lately for a quick patch, that’s what I’ve been using. So if you’re not yet hacking on the internals but just want to build let’s say Parley, here you go:
http://techbase.kde.org/Development/Tutorials/Building_An_Existing_Application
I bet there is much to add and improve, so please help make techbase nicer for new contributors, we all started at some point, right 😉 I wonder if this approach should be more  mentioned as the default way of building an application – it just takes a couple of minutes and you’re good to start hacking.
This post was triggered by some great Parley patches I received from Christian Muschick, who also happened to ask how to best build the application without messing up his system.
|
|