Contrib.social

Update and adjust the Klaro styling

Open on Drupal.org →
Created on 31 October 2024, 13 days ago

Problem/Motivation

The current styling used in Klaro has two problems:

  1. First it has a several accessibility related issues:
    • In the consent box the color contrast of the green customize link text isn't meeting the minimum color contrast requirement of 4.5:1 against the dark background (ref SC 1.4.3). When the modal is expanded by clicking the customize link, the greyish description, the green privacy policy link, the greyish Powered by Klaro sub line, as well as the Always required label are also not meeting the minimum color contrast requirement of 4.5:1.
    • In regards of non-text contrast the grey of the decline button isn't meeting the necessary 3:1 against the darker background, that way the interface component, the button, is not clearly distinguishable (ref SC1.4.11). On the expanded modal it applies to the decline button there as well. In addition to that the knobs for the app toggles are not recognizable at all for the disabled state and are also far from good with 1.6:1 for the enabled state. The intermediate state for the "enable or disable all services" toggle is also visually unclear. In addition to that there is a visual inconsistency, if all services are enabled, required services are using a different green for the background and the knob, than the non-required services. And it has to be noted that the background of the consent box is not necessarily distinguishable and meeting the color contrast of 3:1 if the background is the dark footer in olivero for example. and strictly speaking the light grey outline and drop shadow of the toggle button has also a too low color contrast against light or white backgrounds. (but that i don't consider that pressing since the lock inside is still visible that way)
    • The visibility of the focus outline is also not meeting SC2.4.13 which is a AAA criterion but which should be an at least AA criterion since based on SC2.4.7 a color contrast for a focus outline of 1.1:1 is meeting the requirement of focus "visible". ;) The rule of thumb is that focus outlines should have at least a width of 2px and a color contrast of at least 3:1. In the context of Klaro the focus outline for the toggle button has a thick focus outline but for the focus color browser default styles are being used, that means in safari on macos the 3:1 are not met with safaris light blue focus colors. in contrast edge is meeting the success criterion with its dark/black default focus style. In the consent box the customize link has a green outline that meets the contrast with 3.3:1 while the now blue focus outline fails for the decline and accept button with a color contrast of 1.5:1. The focus outline color should be consistent ideally (it would be confusing and distracting if the color of a mouse cursor would be changing in different contexts). On the expanded modal the blue outlines for the close button, the services, the decline and accept selected buttons have a too low color contrast, same for the greyish focus outline for the powered by klaro sub line.
    • Some of the elements on the expanded modal are not meeting SC2.5.8 for the minimum target size of 24x24px (testable with for example https://github.com/stevefaulkner/targetsize/blob/main/bookmarklet.md). The close button, the link for the privacy policy, the toggle button labels (there only relevant for the ones that are not required), and the powered by Klaro link are not meeting the minimum target size of 24x24px
  2. The default design Klaro is shipping with is not in line with the designs used in Oliver, Claro, and/or Gin. And from my perspective it would make sense to have one design that is working consistently across Olivero, Claro, and Gin, which is adding another level of complexity unfortunately probably.

Steps to reproduce

Proposed resolution

Since the entire appearance of Klaro is themeable by CSS it would be a good thing to adjust the visual appearance to Olivero, Claro and Gin (and make it visually in line with Drupal CMS in consequence). As a positive side effect those visual changes would also fix most or all of the accessibility related issues listed above. I've added the Needs design tag and @jurgenhaas already contacted @ckrina in that regard (but she is out of office for the next three weeks)

Remaining tasks

User interface changes

API changes

Data model changes

🐛 Bug report
Status

Active

Version

3.0

Component

User interface

Created by

🇩🇪Germany rkoller Nürnberg, Germany

Live updates comments and jobs are added and updated live.
  • Accessibility

    It affects the ability of people with disabilities or special needs (such as blindness or color-blindness) to use Drupal.

  • Usability

    Makes Drupal easier to use. Preferred over UX, D7UX, etc.

Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @rkoller
  • Comment 13 days ago →
    🇩🇪Germany jan kellermann

    Thank you for the extensive feedback!

    We are working with the upstream CSS from klaro. Maybe the better way is to open an issue on Github?

    But of course we can add more CSS to our module. Maybe we can add an own Drupal Style and let the site builder choose between different styles (e.g. Klaro Vanilla and Claro Drupal")?

  • Comment 11 days ago →
    🇬🇧United Kingdom Emma Horrell

    I agree with Ralf that Drupal CMS offers an opportunity to align the styles of Olivero, Claro and Gin to ensure a consistent user experience of Drupal CMS. This became apparent to me in the context of the privacy recipe where the widget had a different style to the admin UI. Perhaps this can be considered at an appropriate time in the schedule of work for the Starshot demo design system.

  • Comment 10 days ago →
    🇦🇺Australia pameeela

    Does the Klaro block need to appear in Gin? Or can we show it only in Olivero? Anyone viewing the admin theme will also be viewing Olivero and would have to log in via Olivero initially anyway.

    (Presumably, anyone viewing the admin theme is working on the site so consent is not an issue, but I'm not sure of the legalities of all of that.)

  • Merge request !31Change to Klaro! light style. Override some color in favor of Oliviero. → (Merged) created by jan kellermann
  • Comment 10 days ago →
    🇩🇪Germany jan kellermann

    I just added some options and color as "low hanging fruits".

    Further MRs are appreciated.

    State unchanged.

  • Comment 8 days ago →
    🇦🇹Austria Grienauer Vienna

    thank you @rkoller for the great overview!
    this is a tough problem I guess…

    "do we need to support the gin backend theme in Klaro?"

    If there is no possibility, that a user is on a gin backend site, without to be first on a Oliviero page, then I see here no problem… e.g. if the login page comes form Oliviero. <- deleted that after I had some time to think more about that.

    yes, I think so, because we can not be clear, that e.g. NO youtube video or other third party services are loaded on the drupal admin page and the content blocker is displayed/blocking the content from loading or a user is triggering/opening the consent window.

    but please prove me wrong and let's have a discussion.

    thx @jan. you are really quick and responsive in answering/fixing/discussing things!

  • Comment 8 days ago →
    🇩🇪Germany jan kellermann

    @grienauer Thank you for your comment! For the gin login page you need a consent in the moment - but I hope #3475773 🐛 Setting localstorage without consent on login page Postponed: needs info will be fixed soon ;-)

    In general: There are other consent options for logged-in users. For websites with registration, you can add a checkbox to the registration form to indicate that the backend stores data in the browser or uses social media. And do employees have to consent if the data processor is their company itself and the browser is on their working laptop?

    So I dont think that you need klaro in the backend in most cases, this can be solved with the editorial team in a different way.

    You can set the permission to access the UI for anoymous users only. Or we can add an option “dont show an admin pages” (please open ticket).

    There is also ticket #3484938, with which the notice box can only be used if it is needed.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024