$wcfUserMenuLinkActive fehlt

  • Affected Version
    WoltLab Suite 5.5
    Affected App
    WoltLab Suite Core

    Auch wenn es per se kein Fehler ist, irgendwie schon für mich. :D


    Zwar kann man beim neuen Benutzermenü im Stileditor die Hintergrundfarbe des aktiven Menüpunkts angeben, nicht aber die Textfarbe, was dann $wcfUserMenuLinkActive ergeben würde. Also jedes Mal, wenn man dort eine Farbe angibt, die dunkel ist, müsste man hier manuell nacharbeiten. Das sehe ich nicht als sinnvoll an und ist auch inkonsistent zu Buttons und anderen Drop-downs.


    Ist mir eben beim Versuch, meine Stile zu aktualisieren, aufgefallen. Daher hoffe ich, dass das noch in 5.5 kommt und nicht erst später.

  • Die Anpassung mit dem Editor ist sowieso nicht besonders schön. Es fehlen viele Detailanpassungen wie zum Beispiel Box Shadows. Wenn man die nicht haben will darf man erstmal suchen.


    Da gibt es sehr viel wo man manuell rumfummeln muss. :|

    • Official Post

    Hallo,


    ich hatte bei der Umsetzung darüber nachgedacht, mich aber letztlich dagegen entschieden. Ich sehe im Wesentlichen nur zwei Anwendungsfälle für eine gesonderte Farbe:

    1. Harter Farbwechsel beim Hover.
      Typische Beispiele sind der Wechsel von einer dunklen Hintergrundfarbe zu einer hellen Hintergrundfarbe und umgekehrt. Das ist aber irgendwo auf einer Stufe mit Comic Sans, insofern habe ich dies nicht als validen Anwendungsfall betrachtet.
    2. Mangelnder Kontrast der Schriftfarbe beim Hover.
      Dies tritt üblicherweise auf, wenn der Kontrast der Schrift- und Hintergrundfarbe bereits hart an der Grenze liegt. Bei einer Abweichung der Hintergrundfarbe ins Helle bzw. Dunkle ergibt sich dadurch dann ein endgültig schlechter Kontrast. Aber auch hier ist der schlechte Kontrast eher ein Symptom und nicht die Ursache selbst, denn ein Hover sollte dezent ausfallen.

    Seit einigen Versionen achten wir viel stärker als früher auf Barrierefreiheit und sind darum bemüht, die Software bereits im Standard so gut wie möglich zu gestalten (historische Probleme wie die Linkfarbe mal außen vor). Bei Neuentwicklungen steht auch immer der Gedanke im Raum, Funktionen so umzusetzen, dass eine Barrierefreiheit selbst bei einer Anpassung gegeben ist, weil diese in „engere“ Bahnen gelenkt werden.


    Ich kann natürlich nicht ausschließen, dass ich etwas übersehen habe bzw. einen Aspekt nicht ausreichend gewürdigt habe, insofern bin ich offen für entsprechende Argumente :)

  • Das ist aber irgendwo auf einer Stufe mit Comic Sans, insofern habe ich dies nicht als validen Anwendungsfall betrachtet.

    Huh? Das wäre mir neu. Das ist durchaus ein valider Anwendungsfall und ist aus designtechnischer Sicht absolut vertretbar. Und genau das war auch mein Anwendungsfall.

    • Official Post

    Ich bin ungeachtet dessen weiterhin skeptisch, was einen starken Farbwechsel beim Hover angeht. Ich sehe es tagtäglich, wie teilweise selbst auf sehr großen Seiten vollkommen unnötig auf Barrierefreiheit gepfiffen wird. Ein typisches Beispiel ist hellgraue Schrift auf Weiß: Das mag zwar „aus designtechnisch Sicht absolut vertretbar [sein].“, ist im Hinblick auf die Barrierefreiheit aber ein absolutes No-Go (Kontrast i.d.R. unter 3:1, wobei es bei kleiner Schrift sogar 4,5:1 oder besser sein sollte!).


    Allerdings muss ich einräumen, dass ich beim Herumspielen mit ein wahllosen Auswahl an Farbwerten darauf gestoßen war, dass teilweise ein Wechsel der Schriftfarbe von dunkel zu hell notwendig ist, obwohl die Hintergrundfarbe nur leicht wechselt. Insbesondere Rot- und Grüntöne sind sehr anfällig dafür (Stichwort „perceived luminance”).


    Add support for hover color in the user menu · WoltLab/WCF@1757bb3
    See https://www.woltlab.com/community/thread/296209-wcfusermenulinkactive-fehlt/
    github.com

  • Ich sehe einen Wechsel von heller Hintergrundfarbe zu dunkler und dementsprechend von dunkler Textfarbe zu heller nicht als Problem in der Barrierefreiheit. Zumindest ist mir das auch noch nie untergekommen und sofern vorher wie nachher alles sauber lesbar ist, finde ich das in Ordnung. Wenn du hier andere Informationen hast, freue ich mich gern über einen entsprechenden Link, um das nachzulesen. Denn natürlich bin ich gewillt, bei meinen Designs auch die Barrierefreiheit zu beachten und tue das bereits.

    • Official Post

    Wenn du hier andere Informationen hast, freue ich mich gern über einen entsprechenden Link, um das nachzulesen. Denn natürlich bin ich gewillt, bei meinen Designs auch die Barrierefreiheit zu beachten und tue das bereits.

    Es ist etwas komplizierter und hat etwas mit „Unruhe“ zu tun. Beispielsweise war das alte mobile Hauptmenü recht hübsch anzusehen und insbesondere der „Slide“-Effekt beim Wechsel zwischen den Menüebenen würde ich als „chic“ bezeichnen. Aus Sicht der Barrierefreiheit ist dies aber problematisch, denn so etwas wird schnell als unangenehm wahrgenommen, weshalb beispielsweise iOS seit Ewigkeiten eine Option zur Reduktion von Bewegungen hat.


    Animationen sind dabei das prominenteste Beispiel für Unruhe, dies kann aber auch durch zu harte Farbwechsel entstehen, insbesondere bei großflächigen Farbänderungen. Je stärker der Kontrast zwischen den beiden Farbwerten, desto unangenehmer kann dies empfunden werden. Ein Wechsel von Hellblau zu Dunkelblau ist etwa vollkommen akzeptabel, aber beispielsweise eine Invertierung von Farben kann schon eher problematisch sein.


    Ich bin vor einer ganzen Weile auf den Blog von https://adrianroselli.com/ gestoßen, der hat viele lesenswerte Artikel zum Thema Accessibility. Wenn man die Querverweise einrechnet, hat man dort genug Lesestoff für einen ganzen Sommer :D

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!