$wcfUserMenuLinkActive fehlt

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

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

Quote from Black Rider

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