SUMMARY In the digital clock widget with calendar integrated I can't click on days shown for previous or next month without click the arrows around "today" to switch the visible month. This adds an extra click for example when i want to check my events for Tuesday July 1st which is in 2 days. STEPS TO REPRODUCE 1. Open digital clock widget with calendar events integrated 2. Try to click on a day in the next month (which is in the same week as current week) OBSERVED RESULT The mouse click does nothing. The days are "greyed" showing they are outside of the current month but should still be clickable in this view. EXPECTED RESULT Any day visible in the widget should be clickable SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora KDE (Kinoite) KDE Plasma Version: 6.4.1 KDE Frameworks Version: 6.15.0 Qt Version: 6.9.1 ADDITIONAL INFORMATION
This was caused by https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5614
I'm afraid this was an intentional change for accessibility made in Plasma 6.4.1. You see, if the days for other months have super light text but remain clickable, they don't achieve WCAG AA for text readability. However if we disable clickability for those days, then they aren't considered at all for WCAG purposes, so we pass. And passing this is important for https://invent.kde.org/plasma/plasma-desktop/-/issues/149#note_1237256
The change may be intentional, the bug remains. It acts unexpectedly and is a regression. There's lots of other solutions to explore. As for the original change I don't think it's enough to begin with. >Must have a contrast ratio of at least 7:1, except for the following: >Incidental > Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or >that are part of a picture that contains significant other visual content, have no contrast requirement. It's not an "inactive user interface component" just because it's not clickable. WCAG would apply to someone reading this comment in bugzilla which isn't clickable.
(In reply to David Edmundson from comment #3) > The change may be intentional, the bug remains. It acts unexpectedly and is > a regression. There's lots of other solutions to explore. > > As for the original change I don't think it's enough to begin with. > > >Must have a contrast ratio of at least 7:1, except for the following: > >Incidental > > Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or >that are part of a picture that contains significant other visual content, have no contrast requirement. > > It's not an "inactive user interface component" just because it's not > clickable. WCAG would apply to someone reading this comment in bugzilla > which isn't clickable. It is; see https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html under "Inactive User Interface Components".
Some calendars use alternating background colours to identify months. Using black text on a darker background, or a lighter background for the current month, could solve the contrast issue without functionality loss.
Closing again because the current UI is intentional and implemented the way it is for legal reasons. There are of course other potential legal solutions (like using different background colors for days outside of the current month) as long as those preserve adequate contrast if they're interactive. However, we currently don't use background colors here at all; it just inherits the background of the popup. So that would be a larger UI redesign. …Which is fine. I'm open to a UI redesign to make this even better. But that's somewhat outside the scope of a bug report.
So there is a design flaw that, together with reading a law to the letter, leads to functionality loss. Where should the flawed design be reported, if not here?
A new bug report to request a different design (e.g. background-based differentiation for days outside the current month) would be appropriate. I'm not against that, if we can make it look good.