Tue, Jul 2
Wed, Jun 19
And the patch is in, so starting with Qt 5.12.5 you'll be able to uses it as role. To be honest, I'm not a big fan of the linux/at-spi api here, other platforms send a notification as far as I can tell. Forcing the "notification" role on something seems pretty arbitrary to me. But we decided to play along and make Orca work, so for now that's how it's going to be.
https://codereview.qt-project.org/c/qt/qtbase/+/264761 will hopefully make it into Qt 5.12.4 or 5.12.5.
Jun 15 2019
I'd like to add that the work has started independent of this goal. So @chempfling has already been active for a year, making many improvements, so that basic usage of the desktop is now possible for blind people. Making this an official goal would be really nice, I'd hope to get even more people on board that way.
Jun 12 2019
May 14 2019
Apr 29 2019
Yes and no. We want the Qt roles to be meaningful across desktops and mobile, so they should be as sensible as possible. But of course we can add things that are adding new semantics. https://codereview.qt-project.org/#/c/259401/ Is now going to be in Qt 5.12.4, so from there on "Desktop Frame" and "Terminal" will work.
Let me know if you think there are other roles that should be added to Qt in general. We now assert that all roles that are present in Qt are somehow mapped to AT-SPI.
Apr 24 2019
Hi, I very much think we should meet :) The Plasma sprint is a good option, since we can then influence the right people. Do you think it would be possible to travel to Valencia for you Chrys?
Apr 21 2019
You can build Qt and run Kate with the patched Qt version. Sadly the change to Qt needs more work and I haven't gotten around to it for a long time :(
It seems like adding icon needs a patch to Qt. I can do that, what is the preferred role though?
https://codereview.qt-project.org/#/c/259401 adds the "terminal" role to Qt.
Very nice :) We should probably change the "role" of the task switcher items. I think Joanie suggested "Icon"?
The initial implementation was written, but lacked testing by actual users. I guess setting the terminal role should be rather simple (just setting the property in the right place). I haven't looked at this in ages, let me know if you want help :)
Dec 17 2018
I also find the text rather confusing (thank you for working on this!).
What is AccessX? And why should I care as a user? I need the feature...
Nov 26 2018
Yes, we've been sloppy with that kind of thing in Qt Quick accessibility, I assume this will need some work in Qt.
Is this task about the desktop part or the android app?
Nov 25 2018
Nov 23 2018
Nov 20 2018
I don't see any spam. It makes a lot of sense to have many small well-defined tasks in my opinion.
Argh, somehow I thought moving it to the done column in the board would close it. Thanks for the reminder :)
Yes, thanks :) Should be in Qt 5.12.0.
Nov 19 2018
@gladhorn More food for thought by the way: in this patch (and the master) the search field is focused while searching and while navigating the search results - it still accepts input even though you've technically navigated away from it. Should this functionality be kept (regardless of if the search field remains visibly focused or not), or should we prevent the user from typing into the search field while the focus is on the search results?
I think it's a good idea to let the user type to search from wherever they may be in Kickoff, but to draw the focus away from the search field (like Kicker).
There are a lot of good changes in here, like those keyboard navigation improvements! And I appreciate all the work that clearly went into this. However, the problem with huge patches like this is that if we like some but not all of it, you end up needing to re-work a lot of the patch. That's generally why we prefer "atomic" changes with one change per patch/commit. It makes that kind of thing way saner.
And I'm afraid I don't think we can do #1. @chempfling and @gladhorn have been working hard to push on accessibility, and one thing I've learned in the past week weeks is how important focus is. Making sure that the active element both has and looks like it has focus is critical to making sure the UI is accessible for screen readers. As such, we need to keep it visually focused by default when it opens.
Nov 18 2018
https://download.kde.org/stable/libqaccessibilityclient/ has version 0.3.0 now.
@davidedmundson any progress on this? Where would we in general do this? I think adding a keyboard shortcut to cycle the focus through panels might be a good idea.
Tarballs are created, waiting for sysadmin for 0.3.0 to be pushed out.
Nov 17 2018
This is kinda blocked on getting the patch into Qt, that's a more general solution instead of hacking around it in Kate.
Thanks, good mail :) Let's see what comes out of this.
Nov 16 2018
Nov 12 2018
https://codereview.qt-project.org/#/c/245319/ presumably fixes the keys not being sent.
Nov 10 2018
Nov 7 2018
Yes, I hope so :) it would be great to have anyone else report success, but I think it's done.
Nov 5 2018
I just tested again, it doesn't read what I'm typing as long as the input is focused, so I guess this was a false alarm.
This is in I'm unsure why "arc land" didn't close it.
Changed it to be more pleasant by using client as role and set the focus on the top level, so that the geometry is also more sensible.
Yes, it looks like this will work.
After the change in KWin only this is needed
Use qpa api instead of actually requesting the window to be activated.
Nov 4 2018
It looks like I need either forceActiveFocus or to remove the window manager bypass hint. Or find some other way to get the focus on the window...
OK, I seem to have reached something surprisingly simple: D16638 and D16664 give me a tab box that works with Orca.
The requestActivate is needed to get the focus into the window, the window manager hint has to go (are there side-effects?) and after that pressing alt-tab announces a window containing labels for all other windows. The role should be adjusted, but compared to everything else that should be rather trivial.
Removed Qt.X11BypassWindowManagerHint which makes everything work
Updated to remove more legacy code.
Ouch, I overlooked that, good catch.
I think this looks good :) Feel free to push.
Nov 3 2018
I have been a fool :) I just found that KWin actually does create accessible interfaces for the window switcher since it uses QML and we added accessibility information in some form... What is missing is only pretending that the task switcher window is the active window and maybe sending focus events. That should make this task quite a bit smaller (and I get to throw away my proof of concept code and start over).
Nov 2 2018
Yes, I'd love it if we do give KWin focus - it would make things just work for accessibility, so in that sense it's the right solution. I just had the feeling that it would be close to impossible to convince the KWin maintainers to go that way.
I already have a proof of concept that informs of the Windows that are open - I just need to figure out how to best send updates and do a proper model for memory management of the stuff I wrote, currently I wouldn't be surprised if it crashes and leaks, I just wanted to see that it's doable at all...
Nov 1 2018
I now have a very hackish proof of concept. It shows KWin as application on the accessibility dbus session. It has one child (a virtual main window) with children for the "clients" as KWin calls the windows. There are no updates sent yet, so Orca will not read anything. In addition I'm leaking memory, so this needs a day of cleanup. But I think in principle it will work.