ILIAS-eLearning
UI: Update Drilldown to Show Filter and Two columns
This PR is a follow up on #6889 after the feedback. It proposes to update the Drilldown Menu to look like shown in the print screens below. There is actually no change to the interface, it just updates the description shown in the factory in this commit here
Further:
- It proposes to introduce a general variable column-standard-width to be used to calculate certain width and defines the Modal width accordingly in this commit here. This way it becomes easier to see when more than one column is needed.
- The implementation still has a few hard coded colors and similar issues, it is additionally based on the current Javascript that is not easy to handle, but I would much appreciate a first feedback to see if this is going in the right direction. If you agree, I would then rework the Javascript into ES6 and give it a simpler structure.
Thank you very much and best, @kergomard
I will fix the failing tests in a next step, as I'm sure there will be more changes to the code there.
Hi @klees and all I now moved the implementation to ES6 and simplified the structure a little, so I think this is ready for a review. I had one problem, maybe somebody knows the solution to:
- I seem to be unable to inject either
jquery(as I understand it, this should actually be possible) noril.Utilities(this I don't know if there is a way to do) through the constructor. - I will give some more thought to the js tests once we have an agreement on the general structure. I hope this is ok.
Best, @kergomard
Just in case somebody looks at this: This had a horrific rebasing accident. Will need to give it one more look tomorrow.
Jour Fixe, 04 MAR 2024: Stephan presented the PR for an updated drilldown. The suggestion is highly appreciated and accepted for trunk. Alexandra suggests to add buttons for submit and delete the search term for better accessibility. Stephan assumes that the PR is accessible but accepts a report in case a WCAG guideline is violated. He would fix the component accordingly.
Hallo,
es geht prinzipiell auch einher mit Erfolgskriterium 3.2.2. (On Input). Da steht sinngemäß, dass User vorher eine Info bekommen müssen, was das nichtstandardkonform agierende Inputfeld tut, auch wenn man kein Submit macht: https://www.w3.org/WAI/WCAG22/Understanding/on-input
Daran anhängig ist "Technique G80": Providing a submit button to initiate a change of context. https://www.w3.org/WAI/WCAG22/Techniques/general/G80 G80 ist explizit beschrieben, weil sie auf jeden Fall die 3.2.2 erfüllt. Andere Methoden brauchen dagegen mehr Arbeit, um WCAG-konform zu sein.
Hallo @atoedt,
das Kriterium lautet:
Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A)
Wobei "change of context" definiert ist als:
major changes in the content of the Web page that, if made without user awareness, can disorient users who are not able to view the entire page simultaneously Changes in context include changes of:
- user agent;
- viewport;
- focus;
- content that changes the meaning of the Web page.
Note: A change of content is not always a change of context. Changes in content, such as an expanding outline, dynamic menu, or a tab control do not necessarily change the context, unless they also change one of the above (e.g., focus). Example: Opening a new window, moving focus to a different component, going to a new page (including anything that would look to a user as if they had moved to a new page) or significantly re-arranging the content of a page are examples of changes of context.
Ich denke, dass die Note hier genau auf unseren Fall zu trifft: Wir haben ein dynamisches Menü. D.h. wenn der Filter nicht nach unten in die Menü-Items springt ("focus"), was er ohnehin nicht tun sollte, ist erstmal entlang dieser Richtlinie keine Forderung abzuleiten, weil wir den Kontext nicht wechseln.
Viele Grüße!
Hi @klees
aus meiner Sicht zeigen oben die beiden Screenshots (oder Mockups) zu "Filter Elements in Administration" eine Kontextänderung im Seiteninhalt, weil gerade in diesem Beispiel durch das Filtern sofort in den Inhalt der Unternavigation "System Settings and Maintenance" gesprungen wird, der ohne Filter explizit angeklickt/ausgewählt werden müsste. So zumindest sieht der Vorschlag dort aus, wenn ich die Funktion richtig verstehe. Das heißt, es gibt eine strukturelle Veränderung im Seiteninhalt, die ein verändertes User-Verhalten nach sich zieht und deshalb meines Erachtens zumindest vorher beschrieben sein müsste.
Technik G80 beschreibt als Beispiel lediglich den Standardprozess für Inputs mittels Submit-Button, wodurch keine zusätzliche besondere Funktionen oder Hinweise mitgeliefert werden müssten, wenn der Button ordentlich beschreibt, was er tut. Das wäre also eine der möglichen Lösungen, die aber hier wohl nicht zur Anwendung kommen soll.
Vielleicht ist hier die ebenfalls zum Erfolgskriterium 3.2.2 (und 3.3.2) gehörende Technik G18 das Mittel der Wahl, also "Describing what will happen before a change to a form control that causes a change of context to occur is made". Wir sollten demnach einen Hinweis mitliefern, was das Filter-Input bereits während einer Eingabe (ohne Benutzung der Enter-Taste oder eines Submit-Buttons) tut, zum Beispiel als Einzeiler über dem Filter-Feld, der gleichzeitig als Label oder Describedby o. ä. fungiert.
Siehe:
- Understanding SC 3.2.2: On Input (Level A)
- Technique G13: Describing what will happen before a change to a form control that causes a change of context to occur is made
- Technik G13 verweist auch noch mal auf 3.3.2:Labels or Instructions (Level A)
Viele Grüße Wolfgang
Hallo @WschS,
ich glaube, dass verstehst du falsch. Durch die Nutzung des Text-Inputs als Filter wird nicht automatisch in den Menübereich gesprungen. Stattdessen werden die Inhalte im Menübereich entsprechend der Eingabe reduziert. In den Menübereich muss ich nach wie vor selbst springen um dort einen Eintrag auszuwählen.
Ich denke, mit einer automatischen Änderung des Fokus ins Menü hinein würde der Filter für niemanden gut funktionieren. Z.B.: Ich tippe ein "B". Springt das Ding jetzt schon in den Menübereich? Was wenn ich noch ein "e" tippen möchte? "Be"... Wird jetzt in den Menübereich geprungen?
Das wirkliche Verhalten ist wie folgt: Durch das Tippen im Filter wird die Menge der verfügbaren Menüpunkte immer auf die eingeschränkt, die die getippte Zeichenkette irgendwo enthalten. D.h., wenn ich mit meinem Suchwort nichts finde, kann ich auch wieder Buchstaben entfernen. Das mache ich solange, bis ich meine, den richtigen Menüpunkt gefunden zu haben. Den klicke/tabbe/whatever ich dann an, so wie ich das beim Menü ohne den Filter drüber machen würde.
Beschreiben sollten wir das aber idT. Auch wenn das Kriterium 3.2.2, siehe Note, nicht anwendbar ist.
Viele Grüße!
Hallo @klees,
das Verhalten hatte ich schon so verstanden, wie du es beschreibst. Aber die Einträge unterhalb des Filterfeldes werden derart verändert, dass sie eine völlig andere Navigationsstruktur ergeben, im Fall der Abbildungen oben zum Beispiel auch schon so, dass die Unterpunkte "Help System" und "System Check" in der Folge direkt anspringbar werden und nicht mehr Teil eines Untermenüs sind. Das ist eine Kontext-Änderung.
Zum einen weiß ich vorher nicht, dass meine Eingaben direkt eine Änderung des Inhalts zur Folge haben, also suche ich nach einer Möglichkeit, die Aktion auszulösen, obwohl sie bereits ausgelöst ist. Navigiere ich im Anschluss weiter durch die Seite, stelle ich fest, dass, obwohl ich auf derselben Seite bin, eine strukturelle Veränderung in der verbliebenden Navigation vorgenommen wurde und muss mich erst wieder neu zurechtfinden. Das ist die Kontextänderung, die ich meine und zu spät und durch Ausprobieren feststellen muss.
Vermutlich werden die meisten Menschen im Laufe der Zeit lernen, wie dieses Filtern funktioniert, aber die Hürde zu Beginn ist vorhanden und ich muss mir unbedingt merken, dass dieser eine Feldtyp in ILIAS-Websites nicht wie ein übliches Input des gesamten Webs funktioniert, während sehende Menschen (bzw. solche mit einem entsprechend großen Viewport) das mit einem Blick erkennen. Ich denke, dass ein BITV-Test auf dieses Objekt fehlschlagen wird, wenn die Funktionsweise des Feldes nicht unmissverständlich kommuniziert wird. Die Frage wäre für mich nicht so sehr, ob, sondern viel mehr, wie wir es kommunizieren, sodass es allen gerecht wird.
Viele Grüße W.
Hallo @WSchS
Es scheint mir dass hier das Konzept des Kontextes etwas "funky" verwendet wird, wo auch immer dies herkommen mag. Aber einfach zur Klärung: An der Struktur ändert sich im engeren Sinne gar nichts: Vor dem Filtern, wie nach dem Filtern haben wir die genau gleiche ungeordnete Liste vor uns. Wir blenden einzig die Inhalte von Knoten ein und aus.
Liebe Grüsse, @kergomard
Hallo @WSchS,
also, einig sind wir uns, dass das Input irgendwie beschrieben werden muss. D.h. die Diskussion ist wohl ab jetzt akademisch. Trotzdem würde mich, anhand der konkreten Guidelines, nochmal interessieren, wie du zu deiner Bewertung kommst. Was in der Definition von Change of Context trifft hier zu? Zumal ja "dynamic menu" in der Note explizit ausgenommen wird?
Viele Grüße!
Hallo @klees,
aufgeführte Ausnahmen müssten immer individuell bewertet werden, also wann ist die Ausnahme gegeben, wann nicht. In solchen Grenzfällen gibt's sicherlich immer Diskussionsbedarf. Dynamische Menüs kann vieles bedeuten, einige davon halte ich für unproblematischer als andere, z. B. wenn sich aufgrund eines Option-Inputs ein komplettes Menü vorhersehbar an die getroffene Auswahl anpasst. Ich spiele die angedachte Variante gedanklich durch und erkenne bei der Strukturänderung durch das Filtern ein voraussichtliches Verständnisproblem durch nichtsehende Menschen. Deshalb meine Ausführungen.
In dem von dir verlinkten Abschnitt gibt es den Hinweis, dass ein "significantly re-arranging the content" ein Beispiel für einen "change of context" ist - unabhängig davon, dass bestimmte dynamische Menüs eine Ausnahme sein könnten. Da sich die sichtbare Verschachtelung der Menüliste strukturell verändert und sich damit (meinem Verständnis nach) die Auswahl und das Auslösen von ursprünglichen Untermenüpunkten verändert, halte ich das für signifikant. Andere mögen das weniger streng sehen. Wenn aber Eingung besteht, dass wir das Filterfeld entsprechend beschreiben, deutet auch diese Notwendigkeit schon auf eine Signifikanz hin. ;)
Liebe Grüße Wolfgang
Hi @WSchS
Da sich die sichtbare Verschachtelung der Menüliste strukturell verändert und sich damit (meinem Verständnis nach) die Auswahl und das Auslösen von ursprünglichen Untermenüpunkten verändert, halte ich das für signifikant. Andere mögen das weniger streng sehen. Wenn aber Eingung besteht, dass wir das Filterfeld entsprechend beschreiben, deutet auch diese Notwendigkeit schon auf eine Signifikanz hin. ;)
Kannst du einen Vorschlag machen, wie sich die vorgeschlagene Component dann besser auszeichnen lassen könnte? Ich bin weitgehend mit @klees einig, aber natürlich offen für Vorschläge das hier so gut wie möglich hinzubekommen. Ich würde hier gerne weiter arbeiten.
lg
Hallo, ein Vorschlag wäre ein klarerer Bezeichner des Feldes als "Filter Administration Menu Entries" und ein Button "Apply" und "Reset" der eindeutig die Aktion auslöst. beste Grüße Alexandra
Hallo @Amstutz ich meine, es muss auf jeden Fall eine Erläuterung zum Eingabefeld, damit klar ist, was eine Eingabe darin tut, vermutlich löst man das mit describedby. Wie @atoedt anmerkt (und wir alle wissen) ;) werden Eingaben üblicherweise mit Button ausgelöst, aber da ihr das so nicht vorhabt, muss die Info, dass es keinen Auslösebutton gibt bzw. eine Eingabe sofort eine Filterung durchführt, konsequent ans Eingabfeld gehängt werden, damit der Screenreader das mitbekommt. Button ist die Standard-Möglichkeit, die WCAG zu erfüllen. Nehmen wir die nicht, müssen wir die Funktion gut kommunizieren. Gruß W.
Thank you very much for the feedback @klees !
I think I got all of the points and I also rebased. I tried to split the changes up a little, I hope this helps (although there is not too much).
I moved ResizeObserver to the constructor to allow for a happy linter and writing tests.
I think this is good for another review.
Thanks again and best, @kergomard
PS: Pictures in examples are broken, but this is a separate issue.