[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