[kde] [Bug 475093] Focus indicator is inconsistent and hard to distinguish from the rest of the UI elements with keyboard navigation
Nate Graham
bugzilla_noreply at kde.org
Thu Oct 12 23:13:13 BST 2023
https://bugs.kde.org/show_bug.cgi?id=475093
Nate Graham <nate at kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[Accessibility] Current |Focus indicator is
|focus indicator is hard to |inconsistent and hard to
|distinguish from the rest |distinguish from the rest
|of the UI elements with |of the UI elements with
|keyboard navigation |keyboard navigation
Resolution|WAITINGFORINFO |---
Status|NEEDSINFO |CONFIRMED
Ever confirmed|0 |1
CC| |carl at carlschwan.eu
Keywords| |accessibility, usability
--- Comment #4 from Nate Graham <nate at kde.org> ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the Unassigned-bugs
mailing list