- User Since
- Jul 27 2015, 2:36 PM (195 w, 3 d)
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?
Sun, Apr 21
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.
@chempfling what do you think? Would it be possible to label the buttons inside the tab bar instead?
I don't think there's any ongoing progress, @mart any plans about this?
Hmm, deviating too much from what sighted users see is always a problem because it will not be maintained when the other code changes. The flexibility of plasma is hard here in many ways - we cannot make assumptions what kind of panels there will be etc.
On the other hand I'd really try to get the defaults to work first. So assuming there is one panel, making sure that can be navigated with the keyboard and we can get the relevant information conveyed to blind users would be my starting point.