- User Since
- Jul 27 2015, 2:36 PM (204 w, 23 h)
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.
Sat, Jun 15
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.
Wed, Jun 12
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
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.
Oct 31 2018
My plan was not to change anything regarding x11/wayland at all. It can be done purely on the accessibility level - faking it completely.
My only concern is that if I implement a (virtual) window for accessibility only for the task switcher, Orca would probably read the window before reading the focus inside it. But that may be fine.
"task switcher" -> "firefox window". I'll try writing it in the near future and let others play with it. In the worst case we can then use Orca scripts, if people find announcing the tab switcher window to be a nuisance.
Oct 30 2018
Nice, this looks good to me. I don't know the code though, so it would be great to hear what people more familiar with it say.
Oct 29 2018
Oct 28 2018
@chempfling let's chat about Qt Quick focus indeed, it's complicated. The problem comes mostly from the fact that initially Qt Quick provided only basic primitives, which were not on the right semantic level for accessibility. We tried some experiments to automatically give every text element an accessible name, but that was not really the way to go as for example buttons should have more properties and would contain the text as child. Therefore the level to implement accessibility became a duty for those building on top of the primitives. Which makes it hard to enforce it. I agree we should try to write rules. There is movement in the human interface guidelines department for KDE, maybe they should be extended. For a long time nobody was pushing to fix these issues, so they have been spreading. On the other hand nowadays things have become much more stable, so making an effort is certainly worth it and appreciated by everyone. Some of the plasmoid code is very old and has simply grown before the standard components were available.