Ok next i want to polish the default start menu. Its another very importaint component to interact with an desktop.

Here i have a little naming confusion first. its the startmenu named "kicker" or "kickoff" and what is the difference?

maybe @hein can give me another tipp where is the right place here?

Here i have a little naming confusion first. its the startmenu named "kicker" or "kickoff" and what is the difference?

Plasma ships 3 different start menus.

Kickoff
Kicker
Dashboard (Not sure if this is the name)

They are just different menus. Kickoff and Kicker are both visually different. People who use Kickoff generally like it because it has more room, links, categories to accommodate for items. Kicker is more streamlined, it resembles older start menus that went directly to the point of finding your apps and launch them.

Ah ok, so each „alternative“ when i rigt click on the start button -> alternatives is an own menu? Or do they share the code with just different views?

Where can i find the ui for those? ( maybe someone can give me a tip like for the desktop icons). Because my biggest issue is finding the right codepaths since its very mutch code. But with experience this knowledge will increase ;)

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.

• Application Launcher (Kickoff) is the KDE default menu with the tabbed interface.
• Application Menu (Kicker) is the Windows 95 styled menu.
• Application Dashboard (KickerDash) reuses the Kicker source code, but uses DashboardRepresentation.qml as the entry point instead of main.qml. KickerDash's metadata.desktop file is in the kdeplasma-addons repo. Effectively, everything is in the plasma-desktop repo though as that one .desktop file is the only thing outside it.

• https://github.com/KDE/plasma-desktop/tree/master/applets/kickoff/package/contents/ui
• https://github.com/KDE/plasma-desktop/tree/master/applets/kicker/package/contents/ui
• https://github.com/KDE/plasma-desktop/blob/master/applets/kicker/package/contents/ui/DashboardRepresentation.qml
• https://github.com/KDE/kdeplasma-addons/tree/master/applets/kickerdash
• Apps and Docs https://github.com/KDE/plasma-desktop/blob/master/applets/kicker/package/contents/ui/DashboardTabBar.qml#L43

In T9878#164684, @Zren wrote:

• Application Launcher (Kickoff) is the KDE default menu with the tabbed interface.
• Application Menu (Kicker) is the Windows 95 styled menu.
• Application Dashboard (KickerDash) reuses the Kicker source code, but uses DashboardRepresentation.qml as the entry point instead of main.qml. KickerDash's metadata.desktop file is in the kdeplasma-addons repo. Effectively, everything is in the plasma-desktop repo though as that one .desktop file is the only thing outside it.
  
  ----
• https://github.com/KDE/plasma-desktop/tree/master/applets/kickoff/package/contents/ui
• https://github.com/KDE/plasma-desktop/tree/master/applets/kicker/package/contents/ui
• https://github.com/KDE/plasma-desktop/blob/master/applets/kicker/package/contents/ui/DashboardRepresentation.qml
• https://github.com/KDE/kdeplasma-addons/tree/master/applets/kickerdash
• Apps and Docs https://github.com/KDE/plasma-desktop/blob/master/applets/kicker/package/contents/ui/DashboardTabBar.qml#L43

Woe :), thanks for that _detailed_ information. Its all clear now. This is enough information to fix this up. Thanks!
This information also helps me to fix T7037.

You guys are so great and ready to help, its so fun to work for this with so great people.... Thanks! that said!

I wonder why "Row" is used to implement the tab bar at top on the screen in dash menu (instead of the TabBar Widget). everything is custom implemented but i don't see a reason for this?
Maybe it should be considered to replace the custom implementation with the default TabBar/ TabButton classes (what would not require the fix then i think).
the current implementation also loses the focus after switching the tab. but to do this i need more experience with that.

Anyway first concentrate the issue:
this fixes the missing "Apps & Docs" and "widgets" a11y labels of the tabbar. I give it the role what it use to be "PageTab". Orca announces this correctly.

memo for myself:
/usr/share/plasma/plasmoids/org.kde.plasma.kicker/contents/ui/DashboardTabBar.qml

Row {
    id: tabBar

    property int activeTab: 0
    property int hoveredTab: -1

    Accessible.name: (activeTab == 0) ? i18n("Apps & Docs")  :  i18n("Widgets")
    Accessible.role: Accessible.PageTab
    
    signal containsMouseChanged(int index, bool containsMouse)

i will send the patch tomorrow.

Add Accessibility information to Tabbar in in Dash:
https://phabricator.kde.org/D16383

I currently try to fix ""Application Starter" (default) is missing a11y Labels"
as i figured that the missing labels are the more small problem.

The bigger issue is the focus chain. orca is not able to read the items because those are not able to get the focus. those are just "highlighted" but not focused. the only widget what is able to be receive the focus is the search box.

i read strange things about focus scopes and all kind of magic, but didn't know what to do here currently. i assume some parts of kickoff needs to be restructured for doing that.

why it is so hard to make a proper focus handling for plasmoids? i found similar issues in the Dashboard "Tabbar"

as this seems to be a big issue also for other widgets maybe can do a short talk about that gladhorn?
maybe a we should write down a "best practice" or something i can follow to fix that stuff? how can i make a sub item focus able?

maybe it goes to far here but:
why do plasmoids not just behave like any other window with widgets (having an focus chain, what could be cycled with Tab/ ctrl + tab)? Or are they and the focus handling is just overwritten in most cases i see here (example: open volume, printer, network; press tab; nothing is focused at all)? Anyone an idea about that?
seems to be a bad behave to implement that basic things over and over in different ways instead of following an default guideline what could be overwritten. i assume 60 percent of a11y issues are just caused by that.
it feels somehow that i just stroke on the surface but the real issue is more deep.

I tried some of the examples in your post and the focus chain situation is really bad, many items are simply inaccessible via keyboard navigation.
There definitely should be some guidelines to make sure your plasmoid is navigable via keyboard.

On the plasma side something like Full Keyboard Access in OSX is needed to access those items, as I can't find any such option in keyboard shortcuts (some of the categories there are really bad too, I have no idea what "KDE daemon" is).

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

BTW guys, I am on business travel at the moment that's why I'm not super looped in or helpful.

this is blocked by T10065

https://phabricator.kde.org/D7780