SUMMARY This is more of a generic, meta issue that affects the entire KDE ecosystem than a specific bug. I find the current focus indicator to be very hard to discover during keyboard navigation. Very often I try to press Tab to cycle through the UI elements and the focus indicator plays hide-and-seek. The rectangle is thin and low contrast, and the design is also very unpredictable to users and inconsistent: sometimes it's a rectangular line frame, sometimes it's rectangular background color and then sometimes it's underline. The existing UI elements also distracts the focus indicator as they use the same theme color. STEPS TO REPRODUCE Take the System Settings for example: 1. Go to Window Management -> Window Behavior 2. Focus on the tab bar: It's underline, current tab selection follows left/right arrow key 3. Focus on the left list menu: It's background color, current page selection doesn't follow up/down arrow, requires Space to activate 4. Focus on the System Settings menu button: It's a rectangular line frame 5. Focus on the "Help" and then press Tab to cycle forward: Now your focus indicator is gone This is a tiny fraction of all the inconsistency issues. SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 ADDITIONAL INFORMATION Windows does a better job at this with WinUI, by using a thick line frame as the consistent focus indicator across WinUI applications. The color is fixed(black/white) instead of following theme color to distinguish from UI elements, and the design is always line frame so it's very hard to ignore. A similar design is also seen in Android with TalkBack enabled, as the selection indicator also always uses a line frame.
Can you attach a screenshot of exactly the focus indicator that you're having trouble distinguishing? I ask because we have a few.
Created attachment 162242 [details] Focus indicator design issues in KDE software
Issues mentioned in the pdf file are commonly seen across all KDE software. System Settings is frequently mentioned here because it has the most variations of UI elements, and it's also easily accessible in any distributions with KDE Plasma installed. I think the issue should go to HIG (Human Interface Guidelines). The fix I recommend would be to streamline the focus indicator design and make sure it stands out among other UI elements. This won't fix the messes that third-party applications have (especially those with custom skins and designs, and they're equally terrible on Windows), but at least within KDE ecosystem it's a significant improvement in terms of accessibility.
Thanks. The good news is that your PDF doc illustrates the problem well. The bad news is that it isn't one problem, it's about 500 separate problems, plus a few conceptual issues and design issues. To really fix this, we would need to: - Decide once and for all what we want color to mean in our UIs; should we only use color to mean selection, or use something else to mean selection and make it visually distinct from the color of unselected items? - Come up with a style for "this is the default button in the dialog" that isn't so colorful, or at least can't trick you into thinking that it's selected - Come up with a consistent style to communicate selection that can work for all the different kinds of UI components we have, so that we're always communicating selection in the same way - Generally change our hover styling to be less visually obvious compared to selection - Implement all decided-upon changes in all places that need changes, which would include Breeze, Kirigami, qqc2-desktop-style, plasma-framework, many repos throughout Plasma, and each individual app's repo. We're talking about a *huge* task. As such unfortunately this isn't really something trackable in the context of a bug report. What's needed is to start a formal project and start tackling the individual sub-components of this task, starting with a discussion on the overall design language around selection. So basically, you're 100% right about the problem, but the problem is too broad to be a specific bug report. We could use this bug report as a meta-task, and track the individual work items as sub-tasks of it using the "blocked by" relationship. I'll also CC Carl Schwan, who leads KDE's Accessibility goal.