- User Since
- Jul 27 2015, 2:36 PM (172 w, 1 d)
Mon, Nov 12
https://codereview.qt-project.org/#/c/245319/ presumably fixes the keys not being sent.
Sat, Nov 10
Wed, Nov 7
Yes, I hope so :) it would be great to have anyone else report success, but I think it's done.
Mon, Nov 5
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.
Sun, Nov 4
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.
Sat, Nov 3
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).
Fri, Nov 2
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...
Thu, Nov 1
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.
Wed, Oct 31
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.
Tue, Oct 30
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.
Mon, Oct 29
Sun, Oct 28
@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.
My current thinking is:
KWin shows up as accessible application with no children.
Create an accessible window inside that application. This window has no relation to any other object but will probably make things less confusing for screen readers. It can also become the active window for screen reader purposes when interacting with KWin.
Sat, Oct 27
Next to the window switching, there is also desktop switching (virtual desktops) which I consider secondary (but it may be fixed with the same change).
The common way is to use Alt-Tab to switch windows. Currently Orca does not react to alt-tab while alt is held, but once a new window gains focus, it is read.
So for me this would mostly about enabling the reading of window titles while alt is pressed.
My understanding is that there is luckily a centralized component in KWin which deals with this. kwin/tabbox seems like the relevant files.
Mon, Oct 22
Fri, Oct 19
I guess we can go with this for now, let's be pragmatic. Qt doesn't have icon or desktop_icon at the moment. I can add, if Joanie suggests doing that on the Orca mailing list.
Thu, Oct 18
I think the menus live in git://anongit.kde.org/plasma-desktop - there is all kinds of desktop related stuff - kicker and kickoff are subdirectories in that repository.
We have some information on https://community.kde.org/Infrastructure/Phabricator - there are two options, uploading the file to https://phabricator.kde.org/differential/ or using a command line tool. Please add "gladhorn" and "hein" as reviewers so we can get it in quickly :)
Oh wow, this is super awesome! Yay!!!!
The next step is to get your patch in of course. Do you want to put it up for review on phabricator?
Wed, Oct 17
@chempfling is that enough to get you started? I'm a bit short on time, so if you make progress alone that's perfect, but as soon as you are stuck in any way you can ask @hein and me for help. Please ask away. You can probably even modify the installed file to test changes directly and then just restart plasma-shell - to make quick iterations possible. Just be careful not to lose the changes when they work :)
OK, let's work on that! @hein will help as well.
Mon, Oct 15
With kicker you mean the default start menu?
I don't even see how to keyboard focus the desktop. Do you manage that somehow?
I think this is one of the most important tasks for screen reader users. I assume we'll have to contact the KWin developers. Ideally after doing a bit of research how other window managers solve this.
https://codereview.qt-project.org/#/c/205728/ made it in :)
Oct 14 2018
Sep 29 2018
Aug 24 2018
OK, let's do it :)
Aug 20 2018
Having a clean solution to this would indeed be great.
Yes please :)
Aug 17 2018
This looks generally nice, I like it. Since we're short on people maintaining this stuff, I'd like more of the code to be shared though.
Looks nice, but I think it would be nice to have captions for the icons. The same is true for the normal OSD, there it shows some caption on hover at least.