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.

In D16479#351097, @graesslin wrote:

In D16479#350266, @gladhorn wrote:

In D16479#350247, @graesslin wrote:

So far I always said no to such changes as it doesn't really offer advantages for done code and just clutters the commit history.

I do think there is a bit advantage: When refactoring and a base classes' function gets renamed, any overriding virtuals will stop compiling, so this kind of change makes the code more future-proof.

I fully understand the advantage of override. I do add it to new code. I'm questioning the advantage of adding it to old and done code. Nobody has touched these classes for years and there won't be any reason to do so for years. And even if one would touch it, it's as simple as doing the change to add override then.

My point against such a change is that we either need to do this for all of KWin or not at all. And for all of KWin I think it's a bad idea as it introduces a commit breaking any git blame. Would you +1 such a change in Qt changing all overriding methods to override?

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.

In D16479#350247, @graesslin wrote:

So far I always said no to such changes as it doesn't really offer advantages for done code and just clutters the commit history.

@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?

@davidedmundson do you have plans about this? @chempfling did you play with the network settings? Is there even any way to open the plasmoid at this point in time? I'll put this back to todo for now.

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.

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.

Congratulations :)

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.

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 applets 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?

@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.

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 :)

https://codereview.qt-project.org/#/c/205728/ - @gladhorn needs to get this sorted out...

OK, let's do it :)

Having a clean solution to this would indeed be great.

Yes please :)

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.

In D14514#301328, @broulik wrote:

Why are they not in the Plasma theme, though?

Remove more cruft

seems like this is not wanted

The alternative would be to deprecate this and add a new function. I think this is nonetheless sensible.

In D14353#299282, @zzag wrote:

I suggest to describe in the summary why data members are ordered from largest to smallest.

I think the qml code should not do logic fiddling with the EDID :) but needs investigation.

Messed up merge :(

Add note about the edid pointer becoming invalid

initializer order fixed

Move two more members to the right spot

arc messup, it squashed another patch into this one

arc mangled two patches again :(

Updated commit message and rebased.

Sort edids in test rows. I still think this is completely pointless and a waste of time.

Good catch, I'll have to look into it, right now I get an empty string for both.

Removed xfail, it was fixed by the string parsing fix

Moved Q_REQUIRED_RESULT to the front

It's been there for ages, it's mentioned in the changelog at least... but actually it seems more common to put the attribute before the function, I'll update with that.

I'll check, if it's not public API, I'll make it. Thanks for the pointer.

Yes, my laptop screen uses all 13 bytes, that's how I noticed (the model had one character cut off and I happened to debug and see that it was there, so I did the math :)).