Bug 475093

Summary:	Focus indicator is inconsistent and hard to distinguish from the rest of the UI elements with keyboard navigation
Product:	[I don't know] kde	Reporter:	unblended_icing552
Component:	general	Assignee:	Unassigned bugs mailing-list <unassigned-bugs>
Status:	CONFIRMED ---
Severity:	normal	CC:	carl, nate, unblended_icing552
Priority:	NOR	Keywords:	accessibility, usability
Version:	unspecified
Target Milestone:	---
Platform:	openSUSE
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	Focus indicator design issues in KDE software

Description unblended_icing552 2023-10-01 12:59:36 UTC

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.

Comment 1 Nate Graham 2023-10-11 19:52:07 UTC

Can you attach a screenshot of exactly the focus indicator that you're having trouble distinguishing? I ask because we have a few.

Comment 2 unblended_icing552 2023-10-12 07:54:03 UTC

Created attachment 162242 [details]
Focus indicator design issues in KDE software

Comment 3 unblended_icing552 2023-10-12 08:08:09 UTC

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.

Comment 4 Nate Graham 2023-10-12 22:13:13 UTC

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.