Matthias Scharwies: zugängliches Dropdown-Menü funzt net

1 64

zugängliches Dropdown-Menü funzt net

Matthias Scharwies
  • css
  • selfhtml-wiki
  1. 0
    Felix Riesterer
    1. 0
      Matthias Apsel
      1. 0
        Matthias Scharwies
        1. 0
          Matthias Apsel
          1. 0
            Matthias Apsel
            1. 0
              Felix Riesterer
              1. 0
                Matthias Apsel
                1. 0
                  Felix Riesterer
                  1. 0
                    Gunnar Bittersmann
                  2. 0
                    Matthias Apsel
                2. 0
                  Gunnar Bittersmann
        2. 0
          marctrix
          1. 0
            Matthias Scharwies
            1. 0
              marctrix
      2. 0
        Felix Riesterer
        1. 0
          Matthias Apsel
          1. 0
            Felix Riesterer
            1. 0
              Matthias Apsel
              • css
              • usability
              1. 0
                Camping_RIDER
        2. 1

          meine Lösung des Problems

          Camping_RIDER
          1. 0
            Gunnar Bittersmann
            1. 0
              Camping_RIDER
              1. 0
                Gunnar Bittersmann
                1. 1
                  Camping_RIDER
          2. 0
            MudGuard
            1. 0
              Camping_RIDER
  2. 1
    Gunnar Bittersmann
  3. 0
    Felix Riesterer
    1. 1
      Gunnar Bittersmann
      • javascript
      • selfhtml-wiki
      1. 0
        Felix Riesterer
        1. 1
          Gunnar Bittersmann
          • javascript
          1. 1
            Matthias Scharwies
            1. 0
              Gunnar Bittersmann
              1. 4
                1unitedpower
          2. 0
            Felix Riesterer
            1. 0
              Gunnar Bittersmann
              1. 2
                Gunnar Bittersmann
                1. 0
                  Gunnar Bittersmann
                2. 1
                  MudGuard
            2. 0
              Gunnar Bittersmann
              • usability
              • ux
              1. 1

                Doppelmoral? Konzeptproblem?

                Camping_RIDER
                1. 0
                  Gunnar Bittersmann
                  1. 0
                    Gunnar Bittersmann
                    1. 2
                      Mitleser
                      1. 0
                        Gunnar Bittersmann
                        1. 2
                          Mitleser
                          1. 0
                            Gunnar Bittersmann
                            1. 0
                              Mitleser
        2. 1
          Camping_RIDER
          1. 0
            Felix Riesterer
            1. 0
              Camping_RIDER
  4. 0
    Felix Riesterer
    1. 0
      Camping_RIDER
  5. 0

    und mein Versuch einer Lösung

    JürgenB
    1. 0
      Gunnar Bittersmann
      1. 0
        JürgenB
        1. 0
          Gunnar Bittersmann
          1. 0
            JürgenB
      2. 0
        Felix Riesterer
    2. 0
      Camping_RIDER
      1. 0
        JürgenB
  6. 0

    zugängliches Dropdown-Menü -vorläufiges Fazit

    Matthias Scharwies
    1. 0
      Gunnar Bittersmann

problematische Seite

Servus!

Ich habe mal den Artikel CSS/Tutorials/Dropdown-Menüs_mit_CSS_gestalten aufgeräumt. Die Beispiele bauen aufeinander auf, sind jetzt von Anfang an responsiv (Flexbox) und tabbar, bis auf Beispiel 7:

Das Beispiel funktioniert nicht wie gewünscht.

  • Man kann zwar die Submenüs über das tabindex des li-Elements sichtbar machen, die Listeneinträge jedoch nicht mit der Tastatur durchtabben.
  • Wenn man über den Geschwisterselektor a:hover ~ .submenu selektiert, wird das Submenu ein- , sobald der erste Listenpunkt angewählt wird, dann aber doch wieder ausgeblendet.

Habt ihr eine rein CSS-basierte Lösung, wie man so etwas erreichen kann?

Zusätzlich sollten wir auch ein Tutorial anbieten, das ein zugängliches Dropdown-Menü mit Tastatursteuerung, z.B. auch mit Pfeiltasten, in Vanilla-JS erklärt. Wer könnte soi etwas erstellen?

Herzliche Grüße

Matthias Scharwies

--
Es gibt viel zu tun: ToDo-Liste
  1. problematische Seite

    Lieber Matthias,

    ich habe jetzt nicht verstanden, wie diese Dinger auf mobilen Endgeräten zu bedienen sind, da ich dort weder Tab- noch sonstige Tasten nutzen kann - und hovern geht bekanntlich auch nicht. Wo habe ich dieses Detail jetzt übersehen?

    Liebe Grüße,

    Felix Riesterer.

    1. problematische Seite

      Hallo Felix Riesterer,

      ich habe jetzt nicht verstanden, wie diese Dinger auf mobilen Endgeräten zu bedienen sind, da ich dort weder Tab- noch sonstige Tasten nutzen kann - und hovern geht bekanntlich auch nicht. Wo habe ich dieses Detail jetzt übersehen?

      Viele mobile Browser simulieren bei tap ein hover.

      Bis demnächst
      Matthias

      --
      Rosen sind rot.
      1. problematische Seite

        Servus!

        Hallo Felix Riesterer,

        ich habe jetzt nicht verstanden, wie diese Dinger auf mobilen Endgeräten zu bedienen sind, da ich dort weder Tab- noch sonstige Tasten nutzen kann - und hovern geht bekanntlich auch nicht. Wo habe ich dieses Detail jetzt übersehen?

        Viele mobile Browser simulieren bei tap ein hover.

        Ok, füg ich noch ein. Löst aber mein Problem nicht: Wie kann ich den Fokus auf einem li lassen, wenn der Fokus auf ein Kindelement springt.

        Da es kein Elternselektor in CSS gibt, ist das wohl der Punkt, an dem JavaScript nötig wird, oder?

        Und dann kann man gleich neben dem Navigieren mit Tab Pfeiltastensteuerung einbauen.

        Bis demnächst
        Matthias

        Herzliche Grüße

        Matthias Scharwies

        --
        Es gibt viel zu tun: ToDo-Liste
        1. problematische Seite

          Hallo Matthias Scharwies,

          Ok, füg ich noch ein. Löst aber mein Problem nicht: Wie kann ich den Fokus auf einem li lassen, wenn der Fokus auf ein Kindelement springt.

          :focus-within Unterstützung gar nicht soo schlecht.

          Bis demnächst
          Matthias

          --
          Rosen sind rot.
          1. problematische Seite

            Hallo Matthias Apsel,

            Ok, füg ich noch ein. Löst aber mein Problem nicht: Wie kann ich den Fokus auf einem li lassen, wenn der Fokus auf ein Kindelement springt.

            :focus-within Unterstützung gar nicht soo schlecht.

            Ins Beispiel hab ichs eingebaut. Im Text möchte ich jetzt nicht unbedingt umherpfuschen.

            :focus-within enthält :focus.[1] Damit kann :focus irgendwann™️ durch :focus-within ersetzt werden.

            EDIT: Tippfehler beseitigt.

            Bis demnächst
            Matthias

            --
            Rosen sind rot.

            1. Toller Satz, oder? Deshalb hier die Langform The :focus-within CSS pseudo-class represents an element that has received focus or contains an element that has received focus. In other words, it represents an element that is itself matched by the :focus pseudo-class or has a descendant that is matched by :focus. ↩︎

            1. problematische Seite

              Lieber Matthias,

              Damit kann :focus irgendwann™️ durch :focus-inner ersetzt werden.

              hoffentlich nie. Worin soll denn der funktionale Unterschied bestehen? Mir ist im Zweifel die kürzere Form deutlich lieber (und abwärtskompatibel zu älteren UA), wenn sie denn exakt das selbe meint.

              Liebe Grüße,

              Felix Riesterer.

              1. problematische Seite

                Hallo Felix Riesterer,

                Damit kann :focus irgendwann™️ durch :focus-inner ersetzt werden.

                Quatsch, Apsel: Ersetze focus-inner durch focus-within.

                hoffentlich nie. Worin soll denn der funktionale Unterschied bestehen? Mir ist im Zweifel die kürzere Form deutlich lieber (und abwärtskompatibel zu älteren UA), wenn sie denn exakt das selbe meint.

                Sie meint ja nicht exakt dasselbe. :focus ist eine Teilmenge von :focus-within. Bei Focus muss das aktuelle Element den Fokus haben, bei :focus-within das aktuelle oder ein Nachfahre des aktuellen Elements.

                Bis demnächst
                Matthias

                --
                Rosen sind rot.
                1. problematische Seite

                  Lieber Matthias,

                  :focus ist eine Teilmenge von :focus-within.

                  dann wird :focus niemals durch :focus-within erstetzt werden können, da es mit Sicherheit Anwendungsfälle gibt, wo man explizit nicht :focus-within, sondern "nur" :focus haben möchte.

                  Liebe Grüße,

                  Felix Riesterer.

                  1. problematische Seite

                    @@Felix Riesterer

                    dann wird :focus niemals durch :focus-within erstetzt werden können

                    Natürlich nicht. Sonst hätte man ja auch keine neue Pseudoklasse gebraucht, sondern hätte die Funktionsweise der bestehenden ändern können.

                    LLAP 🖖

                    --
                    “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
                  2. problematische Seite

                    Hallo Felix Riesterer,

                    dann wird :focus niemals durch :focus-within erstetzt werden können, da es mit Sicherheit Anwendungsfälle gibt, wo man explizit nicht :focus-within, sondern "nur" :focus haben möchte.

                    Genau. Dieser Thread dreht sich aber um einen ganz bestimmten Anwendungsfall.

                    Bis demnächst
                    Matthias

                    --
                    Rosen sind rot.
                2. problematische Seite

                  @@Matthias Apsel

                  Quatsch, Apsel: Ersetze focus-inner durch focus-within.

                  Ach deshalb hatte ich erst nichts gefunden. Ich wusste doch, ich hatte das erst neulich beim Wickel: Spezielles Inputfeld 1 | Spezielles Inputfeld 2

                  Sie meint ja nicht exakt dasselbe.

                  Eben. Mit :focus statt :focus-within würde das Spezielle Inputfeld nicht funktionieren. Im Sinne von: funktionieren – auch mit Tastatur.

                  In Browsern, die :focus-within nicht unterstützen, funktioniert es aber trotzdem – progressive enhancement at work.

                  LLAP 🖖

                  --
                  “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
        2. problematische Seite

          Hej Matthias,

          Ok, füg ich noch ein. Löst aber mein Problem nicht: Wie kann ich den Fokus auf einem li lassen, wenn der Fokus auf ein Kindelement springt.

          Für aktuelle Browser mit focus-within

          Marc

          1. problematische Seite

            Servus!

            Hej Matthias,

            Ok, füg ich noch ein. Löst aber mein Problem nicht: Wie kann ich den Fokus auf einem li lassen, wenn der Fokus auf ein Kindelement springt.

            Für aktuelle Browser mit focus-within

            Vielen Dank!

            Hat Matthias Apsel am 31.10. vorgeschlagen:

            :focus-within Unterstützung gar nicht soo schlecht.

            Ins Beispiel hab ichs eingebaut. Im Text möchte ich jetzt nicht unbedingt umherpfuschen.

            ist mittlerweile auch im Wiki-Artikel und im Beispiel drin.

            Herzliche Grüße

            Matthias Scharwies

            --
            Es gibt viel zu tun: ToDo-Liste
            1. problematische Seite

              Hej Matthias,

              Ok, füg ich noch ein. Löst aber mein Problem nicht: Wie kann ich den Fokus auf einem li lassen, wenn der Fokus auf ein Kindelement springt.

              Für aktuelle Browser mit focus-within

              Vielen Dank!

              Hat Matthias Apsel am 31.10. vorgeschlagen:

              Ja, sorry. Hatte ich zu spät gesehen.

              Marc

      2. problematische Seite

        Lieber Matthias,

        Viele mobile Browser simulieren bei tap ein hover.

        wenn also der Menüpunkt selbst kein Link ist, dann mag das alles wunderbar sein. Wenn nun aber der Menüpunkt selbst gleichzeitig ein Link ist, dann komme ich nicht an die weiteren Menüpunkte dran.

        Liebe Grüße,

        Felix Riesterer.

        1. problematische Seite

          Hallo Felix Riesterer,

          wenn also der Menüpunkt selbst kein Link ist, dann mag das alles wunderbar sein. Wenn nun aber der Menüpunkt selbst gleichzeitig ein Link ist, dann komme ich nicht an die weiteren Menüpunkte dran.

          Das soll keine Fürsprache werden:

          Mit Trickserei schon. Den Finger auf dem Link lassen, es wird ein Auswahlmenü eingeblendet. Dann auf "zurück" (häufig ↪) drücken um das Auswahlmenü zu schließen. Dann sind alle Links frei zugänglich.

          Bis demnächst
          Matthias

          --
          Rosen sind rot.
          1. problematische Seite

            Lieber Matthias,

            Das soll keine Fürsprache werden:

            Mit Trickserei schon.

            das klingt mir verdächtig nach Würgaround. Passt vielleicht ganz gut zu Halloween...

            Liebe Grüße,

            Felix Riesterer.

            1. problematische Seite

              Hallo Felix Riesterer,

              das klingt mir verdächtig nach Würgaround.

              ist nicht mal das. Was nutzt es mir, wenn ich weiß, wie meine Seite zu bedienen ist, wenn es die Besucher meiner Seite nicht wissen.

              Ich wollte damit nur aufzeigen, dass ich und einige wenige andere das Menu dennoch bedienen können.

              Bis demnächst
              Matthias

              --
              Rosen sind rot.
              1. problematische Seite

                Aloha ;)

                das klingt mir verdächtig nach Würgaround.

                ist nicht mal das.

                Richtig. Es ist mehr ein wichtiger Hinweis falls man mal selbst mit Touch-Gerät Seiten besucht, die ohne weiteres nicht für Touch-Steuerung geeignet gebaut sind und man aber trotzdem an die Inhalte möchte.

                Grüße,

                RIDER

                --
                Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
        2. problematische Seite

          Aloha ;)

          Wenn nun aber der Menüpunkt selbst gleichzeitig ein Link ist…

          …dann bist du an der Stelle, an der Mobilgeräte nicht mehr wirklich in der Lage sind, das gleichwertig zu bedienen wie Geräte mit Maus. Ich sprach da in der Vergangenheit schon mehrfach von einer „verlorengegangenen Interaktionsebene“, die uns Touch-Geräte-/Browser-Hersteller nach wie vor schuldig bleiben und die wir jetzt irgendwie emulieren müssen, um die selbe Vielfalt von Bedienungsmöglichkeiten zu erreichen wie mit Maussteuerung.

          Es handelt sich um ein Problem, das mir damals erst aufgefallen ist, als ich mein Menü fertig hatte (davor hätte ich auch einfach entscheiden können, keine "Portalseiten", sondern ausschließlich Unterseiten einzusetzen).

          Ich habe dann für Geräte mit Touch-Steuerung was eingebaut, was einen Doppel-Touch zum Aufruf der Portalseiten bedingt. Ein Tooltip erscheint und erläutert die Steuerung in einem Satz (und macht darauf aufmerksam, dass sich hinter den Kategorien nicht nur Unterseiten, sondern auch direkt Inhalte verbergen.

          Zum Anschauen: https://eja-aalen.de/angebote/freizeiten[1]

          Zum Testen am Desktop: Chrome bietet in den Entwicklerwerkzeugen die "Device Toolbar" an, die auch Touch-Steuerung emuliert, ob Firefox und Konsorten das auch können weiß ich grad nicht.

          Das war für mich damals der einfachste Weg, mein Menü, das an Geräten ohne Touch-Steuerung komplett ohne Javascript auskommt auch auf Touch-Geräten zugänglich zu machen. Die Bedienbarkeit ohne Javascript (mit Maus) war mir damals wichtig.

          Technisch bediene ich mich dabei einer Krücke, indem ich meine a-Elemente durch neue a-Elemente ohne href ersetze (mit dem href der alten Elemente in einer Eigenschaft des node). Diese bekommen dann eine Boolean-Variable zum "scharfschalten" (rdy, initial false) und eine zur "Blockade" (block, initial false) und verändern beim Klick, wenn sie scharf geschaltet sind, window.location.href.

          Ordentliche Tastatursteuerung gibt mein Menü im Moment leider nicht her, da war ich damals schlampig. Ich schätze die Tastatursteuerung geht beim Austausch der Links flöten, da Links ohne href wahrscheinlich nicht per Tastatur angewählt werden, das hätte ich noch zusätzlich sicherstellen müssen.

          Grüße,

          RIDER


          Für Interessierte der Quellcode mit Erläuterungen:

          
          window.addEventListener("load",function () {
          	
          	var elms = document.querySelectorAll('#kopfzeile ul.nav li.deeper>a');
          		
          	for (var i = 0; i < elms.length; i++) {
          	    
          	  var hr = elms[i].href;
          		var text = elms[i].data;
          		
          		var oldElm = elms[i];
          		
          		var newElm = document.createElement('a');
          		
          		newElm.dblclick = oldElm.href;
          		newElm.appendChild(oldElm.firstChild);
          		
          		oldElm.parentNode.replaceChild(newElm,oldElm);
          		
          		delete oldElm;
          		
          		newElm.rdy = false;
          		
          		newElm.blck = false;
          		
          		newElm.style.cursor = "pointer";
          	    
          	  newElm.addEventListener('mouseup',function(e) { navelmclick(this,e); });
          		newElm.addEventListener('mousedown',function() { navelmmsdwn(this); });
          		
          		newElm.parentNode.addEventListener('touchstart', function() { navlitouch(this.firstChild); });
          		newElm.parentNode.addEventListener('mouseout',function() { navliout(this.firstChild); });
          	}
          	
          });
          
          function navelmclick (elm,e) {
          	if (elm.rdy && e.button = 0) {
          		window.location.href = elm.dblclick;
          	}
          }
          
          function navelmmsdwn (elm) {
          	if (!elm.blck) {	
          		elm.rdy = true;
          	} else {
          		shownote(elm);
          	}
          }
          
          function navliout (elm) {
          	elm.rdy = false;
          	elm.blck = false;
          }
          
          function navlitouch (elm) {
          	if (elm.blck) {
          		elm.blck = false;
          	} else {
          		elm.blck = true;
          	}
          }
          
          function shownote (elm) {
             /* Hinweis zur Touchsteuerung einblenden und nach kurzer Zeit wieder ausblenden */
          }
          

          Im Fall von Maussteuerung passiert folgendes: Der Anwender fährt mit der Maus auf den Link und drückt die Maus, das Mousedown-Event wird ausgelöst und setzt rdy=true, daraufhin feuert automatisch das Click-Event und, da der Link bereits scharfgeschaltet ist, wird die verlinkte Seite aufgerufen.

          Im Fall von Touchsteuerung passiert dasselbe, allerdings feuert bei Touchbedienung auch das Event touchstart - und zwar bevor mousedown ausgelöst wird. Dadurch kann ich bei touchstart block=true setzen und damit das Scharfschalten des Links verhindern. Stattdessen wird bei mousedown nur der Tooltip angezeigt. Der Link erhält dann trotzdem den emulierten hover-Zustand und öffnet das Untermenü wie gewünscht. Beim erneuten Touch wird block=true wieder auf block=false umgeschaltet und damit passiert beim zweiten Touch das selbe wie beim Mausklick.

          --
          Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
          # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[

          1. Disclaimer: Mir gehts hier nur darum, den gefundenen Workaround vorzustellen. Die Seite bekommt bald so oder so eine Groß-Überarbeitung, Kritik am Bestand ist also gerne gesehen, aber auch gleichzeitig recht sinnbefreit. ↩︎

          1. problematische Seite

            @@Camping_RIDER

            Ich sprach da in der Vergangenheit schon mehrfach von einer „verlorengegangenen Interaktionsebene“, die uns Touch-Geräte-/Browser-Hersteller nach wie vor schuldig bleiben und die wir jetzt irgendwie emulieren müssen

            Andersrum wird ein Schuh draus: Designer/Entwickler sollten aufhören, spezielle Interaktionsformen von Desktop-Anwendungen allgemein aufs Web übertragen.

            Ein Tooltip erscheint und erläutert die Steuerung in einem Satz

            Spätestens hier hätte dir dein Fehler auffallen sollen. UI-Elemente hinzufügen, um das UI zu erklären – funktioniert immer. Nicht.

            Zum Anschauen: https://eja-aalen.de/angebote/freizeiten[^1]

            Zickt rum beim Laden.

            Auf dem iPhone erscheint das Menü in Gänze – ohne dass eine Hierarchie erkennbar wäre, was Unterpunkte und was Unterunterpunkte sind.

            Beim Scrollen flackern wie wild Farben auf.

            Ordentliche Tastatursteuerung gibt mein Menü im Moment leider nicht her, da war ich damals schlampig. […] das hätte ich noch zusätzlich sicherstellen müssen.

            Die Vergangenheitsform ist unangebracht.

            Solange das Menü nicht benutzbar ist, solltest du es nicht als Beispiel präsentieren. Es sei denn, als Negativbeispiel.

            LLAP 🖖

            --
            “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
            1. problematische Seite

              Aloha ;)

              Ich sprach da in der Vergangenheit schon mehrfach von einer „verlorengegangenen Interaktionsebene“, die uns Touch-Geräte-/Browser-Hersteller nach wie vor schuldig bleiben und die wir jetzt irgendwie emulieren müssen

              Andersrum wird ein Schuh draus: Designer/Entwickler sollten aufhören, spezielle Interaktionsformen von Desktop-Anwendungen allgemein aufs Web übertragen.

              Nein. Einfach nein. Die Interaktionsform via hover ist schon sehr viel länger „im Web“ (zum Beispiel in den Standards) als Touch-Geräte das Web darstellen.

              Sorry, aber das geht mir schon wieder zu sehr in Richtung spiritistischer Verklärung und Rechtfertigungslehre. Meine Aussage war eigentlich recht simpel: Vor der Verbreitung von Touchgeräten gab es eine Interaktionsebene, die jetzt nicht mehr ohne weiteres zur Verfügung steht.

              Ich glaube nicht, dass man daran viel diskutieren muss.

              Genauso wie man nicht drüber diskutieren muss, dass man die armen Touch-User, die kein hover können, nicht im Regen stehen lassen darf.

              Ich glaube nicht, dass dem viel hinzuzufügen ist?!

              Ein Tooltip erscheint und erläutert die Steuerung in einem Satz

              Spätestens hier hätte dir dein Fehler auffallen sollen. UI-Elemente hinzufügen, um das UI zu erklären – funktioniert immer. Nicht.

              Auf deine konstruktive Erklärung, wie man ein solches Menü auch den nicht-hover-fähigen zugänglich machen kann, bin ich gespannt. Der Schuh, da eine intuitive Behandlung von hover zu erreichen, liegt eigentlich bei den Browserherstellern - die sich aber bis heute diesen Schuh nicht anziehen. Deshalb gibt es da keinen einheitlichen Bedienungsmechanismus, und deshalb brauchts eine Erklärung. Die im Übrigen mehr dazu da ist zu zeigen "da geht noch mehr als nur das Untermenü anzuzeigen"; die Bedienung ist ja bis auf den Doppelklick intuitiv.

              Wenn du mir jetzt sagst: „geht nicht, mach ein anderes Menü“, dann sage ich dir, dass du damit einerseits Recht hast und andererseits das Thema damit um Elefantenbreite verfehlst; ich hatte sehr deutlich beschrieben, dass es mir darum ging, das Dilemma „bestehendes Hover-Menü für Touch-User bedienbar machen“ zu behandeln und nicht die Frage, ob man das Dilemma nicht auch irgendwie durch Refactoring umgehen kann.

              Zum Anschauen: https://eja-aalen.de/angebote/freizeiten[^1]

              Zickt rum beim Laden.

              Das ist keine sehr hilfreiche Fehlerbeschreibung.

              Auf dem iPhone erscheint das Menü in Gänze – ohne dass eine Hierarchie erkennbar wäre, was Unterpunkte und was Unterunterpunkte sind.

              Die nur improvisierte Darstellung auf sehr schmalen Bildschirmen ist einer der Gründe, warum da dringend eine Komplett-Überarbeitung her muss. Das war aber hier nicht der Punkt. Wenn du dein iPhone drehst kannst du im Querformat das sehen, was ich hier zeigen wollte. Falls du daran überhaupt interessiert bist.

              Beim Scrollen flackern wie wild Farben auf.

              Kannst du das genauer beschreiben? Mir ist nicht klar, auf was du mich hinweisen möchtest.

              Ordentliche Tastatursteuerung gibt mein Menü im Moment leider nicht her, da war ich damals schlampig. […] das hätte ich noch zusätzlich sicherstellen müssen.

              Die Vergangenheitsform ist unangebracht.

              Ist sie nicht. Dass eine Neugestaltung ansteht (nicht-Vergangenheitsform) habe ich deutlich geschrieben.

              Solange das Menü nicht benutzbar ist, solltest du es nicht als Beispiel präsentieren. Es sei denn, als Negativbeispiel.

              Ach, hab ich das denn? Ich habe absichtlich dazugeschrieben, dass die verlinkte Seite eben nicht beispielreif ist.

              Ich hätte natürlich auch hergehen können und einfach nur den Quellcode ohne was zum Anschauen hinknallen können. Oder mir noch mehr Zeit um die Ohren schlagen und das auf Codepen nachbauen können. Stattdessen habe ich darauf vertraut, dass Leser meines Beitrages versuchen zu verstehen, was ich Ihnen sagen möchte, ohne selbst jede Eventualität eines Missverständnisses auszumerzen.

              Oder anders formuliert: Ich hatte auf Anwendung des Prinzips der wohlwollenden Interpretation gehofft, um sachlich voranzukommen, und bin auf Strohmann-Argumente gestoßen. Na was das bloß aussagt...

              Grüße,

              RIDER

              --
              Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
              # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
              1. problematische Seite

                @@Camping_RIDER

                Andersrum wird ein Schuh draus: Designer/Entwickler sollten aufhören, spezielle Interaktionsformen von Desktop-Anwendungen allgemein aufs Web übertragen.

                Nein. Einfach nein. Die Interaktionsform via hover ist schon sehr viel länger „im Web“ (zum Beispiel in den Standards)

                Wovon sprichst du? Von Hover-Effekt oder von einem mehrstufigen Aufklappmenü? Ich denke, es geht um letzteres. Und letzteres ist nicht „in den Standards“.

                […] als Touch-Geräte das Web darstellen.

                Das Web entstand zu einer Zeit, als Desktop-Computer mit Maus die Vormachtstellung hatten. Die Zeiten sind längst vorbei. Das Web ist Touch, Gestensteuerung, Sprachsteuerung und und und …

                Meine Aussage war eigentlich recht simpel: Vor der Verbreitung von Touchgeräten gab es eine Interaktionsebene, die jetzt nicht mehr ohne weiteres zur Verfügung steht.

                So isses.

                Dann verstehe ich nicht, warum du mein „Designer/Entwickler sollten aufhören, spezielle Interaktionsformen von Desktop-Anwendungen allgemein aufs Web übertragen“ mit „Nein. Einfach nein“ beantwortest.

                Auf deine konstruktive Erklärung, wie man ein solches Menü auch den nicht-hover-fähigen zugänglich machen kann, bin ich gespannt.

                Hier ist schon der Denkfehler: „ein solches Menü“. Wenn die Interaktionsform mehrstufiges Aufklappmenü fürs Web nicht so gut ist, sollte man eine fürs Web passendere wählen.

                Der Schuh, da eine intuitive Behandlung von hover zu erreichen, liegt eigentlich bei den Browserherstellern - die sich aber bis heute diesen Schuh nicht anziehen.

                Wie auch? Den Schuh müssten sich die Gerätehersteller anziehen und die Finger erkennen, wenn sie einen halben Zentimeter über dem Display schweben.

                Ob das zu nutzerfreundlicher Bedienung führt?

                Deshalb gibt es da keinen einheitlichen Bedienungsmechanismus, und deshalb brauchts eine Erklärung.

                Nein. Es braucht einen Bedienungsmechanismus, der ohne Erklärung verstanden wird.

                Solange das Menü nicht benutzbar ist, solltest du es nicht als Beispiel präsentieren. Es sei denn, als Negativbeispiel.

                Ach, hab ich das denn? Ich habe absichtlich dazugeschrieben, dass die verlinkte Seite eben nicht beispielreif ist.

                Du hast den Titel geändert auf „meine Lösung“, du schriebst „Zum Anschauen“. Hört sich beides nicht nach Negativbeispiel an.

                und bin auf Strohmann-Argumente gestoßen. Na was das bloß aussagt...

                Dass du meine Einwände als Strohmann-Argumente abtust. Nicht mehr und nicht weniger.

                LLAP 🖖

                --
                “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
                1. problematische Seite

                  Aloha ;)

                  Wovon sprichst du? Von Hover-Effekt oder von einem mehrstufigen Aufklappmenü? Ich denke, es geht um letzteres. Und letzteres ist nicht „in den Standards“.

                  Ich sprach in diesem Absatz von ersterem, nicht von letzterem.

                  […] als Touch-Geräte das Web darstellen.

                  Das Web entstand zu einer Zeit, als Desktop-Computer mit Maus die Vormachtstellung hatten. Die Zeiten sind längst vorbei. Das Web ist Touch, Gestensteuerung, Sprachsteuerung und und und …

                  Ja, das ist inzwischen so.

                  Meine Aussage war eigentlich recht simpel: Vor der Verbreitung von Touchgeräten gab es eine Interaktionsebene, die jetzt nicht mehr ohne weiteres zur Verfügung steht.

                  So isses.

                  Dann verstehe ich nicht, warum du mein „Designer/Entwickler sollten aufhören, spezielle Interaktionsformen von Desktop-Anwendungen allgemein aufs Web übertragen“ mit „Nein. Einfach nein“ beantwortest.

                  Weil deine Aussage an dem, was ich bemängelt habe, meilenweit vorbeigeht. Ich habe bemängelt, dass eine bisher gegebene Interaktionsebene (hover) nun durch die Veränderungen im Web kaum mehr nutzbar ist, ohne, dass irgendwo eine Kompensation stattfindet, was ich im ersten Moment als Einschränkung empfinde.

                  Dass mehrstufige Aufklappmenüs dadurch unmöglich werden ist nur eine Folge. Ob man die jetzt braucht oder nicht sei mal dahingestellt.

                  Aber das ist eine akademische Fragestellung, deren Klärung oder-auch-nicht uns nicht konkret weiterbringt.

                  Auf deine konstruktive Erklärung, wie man ein solches Menü auch den nicht-hover-fähigen zugänglich machen kann, bin ich gespannt.

                  Hier ist schon der Denkfehler: „ein solches Menü“. Wenn die Interaktionsform mehrstufiges Aufklappmenü fürs Web nicht so gut ist, sollte man eine fürs Web passendere wählen.

                  Eben. Ist ja auch richtig. Nur gings mir darum grad im Moment gar nicht. Heute / jetzt würde ich einfach eine andere Seitenstruktur wählen und auf die "Portalseiten" oder "Kategorieseiten" schlichtweg verzichten und das Problem löst sich in Wohlgefallen auf. Die Frage war aber, was man tut, wenn man so eine „Altlast“ nun mal da liegen hat und die nicht neu aufziehen kann oder will - unterm Strich also, ob es da eine Art Kompromiss im Kosten-Nutzen-Verhältnis gibt.

                  Dass du nicht der richtige Ansprechpartner für Kompromisse bist weiß ich auch 😉

                  Der Schuh, da eine intuitive Behandlung von hover zu erreichen, liegt eigentlich bei den Browserherstellern - die sich aber bis heute diesen Schuh nicht anziehen.

                  Wie auch? Den Schuh müssten sich die Gerätehersteller anziehen und die Finger erkennen, wenn sie einen halben Zentimeter über dem Display schweben.

                  Ob das zu nutzerfreundlicher Bedienung führt?

                  Möglicherweise? Andere Möglichkeiten sind auch denkbar.

                  Nur werden die nicht kommen. Einfach weil weder Gerätehersteller noch Mobilbrowserhersteller ein Interesse daran haben. Das ist ne Abstimmung mit den Füßen - wenn man eine ausreichende Relevanz/Marktmacht hat braucht man sich nicht drum zu scheren, ob man alle Möglichkeiten des Mediums ausnutzt, weil man sich darauf verlassen kann, dass die Seitenersteller einem schon entgegen kommen werden. Das hat beim Internet Explorer auch jahrelang funktioniert. Aber das ist eine moralische Frage, die mal wieder über die sachliche Ebene rausgeht.

                  Deshalb gibt es da keinen einheitlichen Bedienungsmechanismus, und deshalb brauchts eine Erklärung.

                  Nein. Es braucht einen Bedienungsmechanismus, der ohne Erklärung verstanden wird.

                  Ja, im Optimalfall. Im Kompromissfall ist das ein Dilemma.

                  Solange das Menü nicht benutzbar ist, solltest du es nicht als Beispiel präsentieren. Es sei denn, als Negativbeispiel.

                  Ach, hab ich das denn? Ich habe absichtlich dazugeschrieben, dass die verlinkte Seite eben nicht beispielreif ist.

                  Du hast den Titel geändert auf „meine Lösung“, du schriebst „Zum Anschauen“. Hört sich beides nicht nach Negativbeispiel an.

                  Ja, die Lösung ist der Quellcode-Schnipsel. Anschauen kann man sich dessen Wirkung auf einer Seite, die zusätzlich zur genannten Lösung für das konkret benannte Problem noch einige gröbere Schnitzer aufweist.

                  Man bemerke auch den Unterschied von „meine Lösung“ im Sinne von „wie ich dieses Problem behandelt habe“ zu „die Lösung“ im Sinne eines objektiven Beispielcharakters. Hätte ich die parat, dann würde ich sie ins Wiki schreiben und nicht im Forum zur Diskussion stellen, auch wenn Andere das anders halten.

                  Übrigens bedienst du dich hier schon wieder der Suggestion - wer sagt denn, dass ich es als Negativbeispiel auszeichnen wollte?

                  und bin auf Strohmann-Argumente gestoßen. Na was das bloß aussagt...

                  Dass du meine Einwände als Strohmann-Argumente abtust. Nicht mehr und nicht weniger.

                  Ich freue mich, dass die Einwände in diesem Posting mir weniger wie Strohmänner vorkamen als die im letzten.

                  Grüße,

                  RIDER

                  --
                  Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                  # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
          2. problematische Seite

            Hi,

            …dann bist du an der Stelle, an der Mobilgeräte nicht mehr wirklich in der Lage sind, das gleichwertig zu bedienen wie Geräte mit Maus.

            Warum gibt's eigentlich keine Maus für's Mobilgerät? USB-Anschluß ist doch üblicherweise vorhanden (zum Aufladen ...), und per Blauzahn (hat ja auch fast jedes Smartphone) könnte man die Maus ja auch noch ankoppeln.

            cu,
            Andreas a/k/a MudGuard

            1. problematische Seite

              Aloha ;)

              Warum gibt's eigentlich keine Maus für's Mobilgerät? USB-Anschluß ist doch üblicherweise vorhanden (zum Aufladen ...)

              USB-Sticks kann man am Mobilgerät anschließen (und drauf zugreifen). Maus hab ich noch nie getestet 😂

              Grüße,

              RIDER

              --
              Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
              # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
  2. problematische Seite

    @@Matthias Scharwies

    Habt ihr eine rein CSS-basierte Lösung, wie man so etwas erreichen kann?

    Nein. Und ich glaube auch nicht, dass man nach einer „CSS-only“-Lösung suchen sollte.

    Zusätzlich sollten wir auch ein Tutorial anbieten, das ein zugängliches Dropdown-Menü mit Tastatursteuerung, z.B. auch mit Pfeiltasten, in Vanilla-JS erklärt. Wer könnte soi etwas erstellen?

    Heydon Pickering. Inclusive Components

    LLAP 🖖

    --
    “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
  3. problematische Seite

    Lieber Matthias,

    kannst Du diesen Artikel für Dein Thema gebrauchen? A More Accessible Multi-Level Dropdown Navigation

    Liebe Grüße,

    Felix Riesterer.

    1. problematische Seite

      @@Felix Riesterer

      kannst Du diesen Artikel für Dein Thema gebrauchen? A More Accessible Multi-Level Dropdown Navigation

      Dann aber bitte das jQuery-Zeugs in JavaScript übersetzen.

      “Why write it in plain JavaScript? Because modern browsers support Web API methods very consistently now, and because small interactions should not depend on large libraries.”

      (Heydon Pickering in Collapsible Sections)

      LLAP 🖖

      --
      “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
      1. problematische Seite

        Lieber Gunnar,

        Dann aber bitte das jQuery-Zeugs in JavaScript übersetzen.

        so lange in den Browsern der echte(!) Komfort von jQuery fehlt, gibt es nach wie vor gute Gründe für den Einsatz dieses Frameworks.

        Übersetze mir doch bitte dieses Beispiel in Vanilla-JavaScript und beachte den Aspekt "write less, do more":

        $("#hamburger-navigation ul").parent().prepend(
        	$("<button>open</button>")
        	.attr("aria-label", "open")
        	.attr("title", "open")
        	.click(function (e) {
        		var open, $ul;
        
        		$(e.target).parent().toggleClass("open");
        
        		open = $(e.target).parent().hasClass("open");
        
        		$(e.target)
        		.html(open ? "close" : "open")
        		.attr("aria-label", open ? "close" : "open")
        		.attr("title", open ? "close" : "open");
        	})
        );
        

        Wird es in Vanilla-JS ebenso kurz und iteriert es wirklich über alle gefundenen Elemente in der gleichen Art?

        Liebe Grüße,

        Felix Riesterer.

        1. problematische Seite

          @@Felix Riesterer

          $("#hamburger-navigation ul").parent().prepend(
          	$("<button>open</button>")
          	.attr("aria-label", "open")
          	.attr("title", "open")
          	.click(function (e) {
          		var open, $ul;
          
          		$(e.target).parent().toggleClass("open");
          
          		open = $(e.target).parent().hasClass("open");
          
          		$(e.target)
          		.html(open ? "close" : "open")
          		.attr("aria-label", open ? "close" : "open")
          		.attr("title", open ? "close" : "open");
          	})
          );
          

          Wird es in Vanilla-JS ebenso kurz und iteriert es wirklich über alle gefundenen Elemente in der gleichen Art?

          Ja, das wird es. Und ja, das tut es:

          document.querySelectorAll("#hamburger-navigation ul").forEach(function (ulElement) {
          	const buttonElement = document.createElement("button");
          	buttonElement.innerText = "open";
          	buttonElement.setAttribute("aria-label", "open");
          	buttonElement.setAttribute("title", "open");
          
          	buttonElement.addEventListener("click", function (event) {
          		event.target.parentNode.classList.toggle("open");
          
          		const open = event.target.parentNode.classList.contains("open");
          
          		event.target.innerText = open ? "close" : "open";
          		event.target.setAttribute("aria-label", open ? "close" : "open");
          		event.target.setAttribute("title", open ? "close" : "open");	
          	});
          
          	ulElement.parentNode.insertBefore(buttonElement, ulElement);
          });
          

          Dass meine Zeilen länger sind als bei dir, kommt vor allem daher, dass ich sprechende Variablennamen verwendet habe: event statt e, buttonElement, ulElement.

          Statt event.target lässt sich auch this verwenden. Ich hab das nur 1:1 so aus der Vorlage umgesetzt. Im jQuery auch schon $(this) statt $(e.target).

          Übrigens: Das aria-label-Attribut macht keinen Sinn, wenn da dasselbe steht wie im Elementinhalt. Das title-Attribut macht keinen Sinn, auch wenn da etwas anderes drinstünde.

          Und „iteriert es wirklich über alle gefundenen Elemente in der gleichen Art?“ legt nahe, dass du sowas im Sinn hast:

          <nav id="hamburger-navigation">
          	<div>
          		<ul></ul>
          	</div>
          	<div>
          		<ul></ul>
          	</div>
          </nav>
          

          Das geht. Bei den div-Elementen wird die Klasse open gesetzt bzw. entfernt.

          Hast du aber

          <nav id="hamburger-navigation">
          		<ul></ul>
          		<ul></ul>
          </nav>
          

          dann fliegt dir das Zeug um die Ohren.

          LLAP 🖖

          --
          “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
          1. problematische Seite

            Servus!

            Danke, ich hab's kopiert und versuch's mal in das JS-Tutorial einzubauen. Wird aber etwas dauern.

            Herzliche Grüße

            Matthias Scharwies

            --
            Es gibt viel zu tun: ToDo-Liste
            1. problematische Seite

              @@Matthias Scharwies

              Danke, ich hab's kopiert und versuch's mal in das JS-Tutorial einzubauen.

              Da besteht noch einiges Verbesserungspotential. this anstatt event.target hatte ich ja schon erwähnt, aber auch damit wäre

              event.target.parentNode.classList.toggle("open");
              
              const open = event.target.parentNode.classList.contains("open");
              

              noch unsinnig. Element.classList.toggle() gibt ja schon genau das zurück, was man haben möchte. Die Abfrage mit Element.classList.contains() ist Quatsch.

              const open = this.parentNode.classList.toggle("open");
              

              und gut ist.

              LLAP 🖖

              --
              “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
              1. problematische Seite

                Da besteht noch einiges Verbesserungspotential. this anstatt event.target hatte ich ja schon erwähnt, aber auch damit wäre

                Bitte nicht, this ist das vieldeutigste und unvorhersehbarste Übel, das JavaScript zu bieten hat. Um rauszufinden was this ist, muss man den ganzen Code gedanklich durchspielen. Um rauszufinden was event.target ist, muss man nur gucken wo event definiert wird. Und ein sprechender Bezeichner ist this auch nicht, es sollte it heißen, damit die Leute sich auch angemessen fürchten.

          2. problematische Seite

            Lieber Gunnar,

            vielen Dank für Deine Mühen beim Konvertieren.

            Wenn ich mir allerdings diesen Schreibaufwand anschaue, als Beispiel sei nur der Setter $element.attr("name", "value") im Vergleich zu element.setAttribute("name", "value"), und der Getter $element.attr("name") im Vergleich zu element.getAttribute("name") genannt.

            Das Mantra von jQuery war (neben dem Ausbügeln von Browserunterschieden) "write less do more". Das sehe ich hier ganz deutlich: Mit jQuery schreibt man weniger Code-Fülle, die im Endeffekt zu lesbarerem weil weniger geblähtem Code führt.

            Übrigens: Das aria-label-Attribut macht keinen Sinn, wenn da dasselbe steht wie im Elementinhalt.

            OK, das habe ich nicht gewusst. Und ursprünglich hatte ich einen Link anstelle eines Buttons verwenden wollen. Aber selbst dieser Unterschied ist wohl irrelevant hinslichtlich aria-label.

            Das title-Attribut macht keinen Sinn, auch wenn da etwas anderes drinstünde.

            Mit Verlaub: doch! Wenn jemand mit der Maus über dem Button hovert, dann will der vielleicht wissen, was der bewirkt. Das kann ein Tooltip mit dem Inhalt des title-Attributs vermitteln. In diesem Kontext ist nämlich die Beschriftung des Buttons ausgeblendet. Man "sieht" nur noch ein Plus- oder Minus-Zeichen.

            Und „iteriert es wirklich über alle gefundenen Elemente in der gleichen Art?“ legt nahe, dass du sowas im Sinn hast:

            <nav id="hamburger-navigation">
            	<div>
            		<ul></ul>
            	</div>
            	<div>
            		<ul></ul>
            	</div>
            </nav>
            

            Nö. Ich verschachtele <article><h2/><ul/></article>. Aber Du hast insofern Recht, als document.querySelectorAll alles das findet, was ich brauche. Nur muss ich eben ein extra forEach über die NodeList laufen lassen, anstatt mit $.append() dieses implizit zu tun.

            VanillaJS: Write more do less. Deswegen noch immer jQuery.

            Liebe Grüße,

            Felix Riesterer.

            1. problematische Seite

              @@Felix Riesterer

              Wenn ich mir allerdings diesen Schreibaufwand anschaue, als Beispiel sei nur der Setter $element.attr("name", "value") im Vergleich zu element.setAttribute("name", "value"), und der Getter $element.attr("name") im Vergleich zu element.getAttribute("name") genannt.

              setAttribute/getAttribute sind eben sprechende Namen; attr ist kryptisch.

              Und 8 Zeichen mehr machen für dich Schreibaufwand? Stattdessen willst du lieber dem Nutzer aufbürden, zusätzlich eine 87 kB große Bibliothek zu laden? Ernsthaft?

              Das Mantra von jQuery war (neben dem Ausbügeln von Browserunterschieden) "write less do more". Das sehe ich hier ganz deutlich: Mit jQuery schreibt man weniger Code-Fülle,

              Man schreibt vielleicht weniger, aber …

              die im Endeffekt zu lesbarerem weil weniger geblähtem Code führt.

              … zur Lesbarkeit s.o.

              Weniger aufgebläht? Eben nicht. Die 87 kB musst du in deine Rechnung schon mit einbeziehen.


              Aber falls dir attr heilig sein sollte, kannst sowas in der Art machen:

              Element.prototype.attr = function(name, value)
              {
              	if (arguments.length > 1)
              	{
              		return this.setAttribute(name, value);
              	}
              	else
              	{
              		return this.getAttribute(name);
              	}
              }
              
              
              
              document.body.attr('foo', 'bar');
              
              console.log(document.body.attr('foo')); // bar
              

              Dazu brauchst du kein jQuery.

              LLAP 🖖

              --
              “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
              1. problematische Seite

                @@Gunnar Bittersmann

                setAttribute/getAttribute sind eben sprechende Namen; attr ist kryptisch.

                Wobei die Abkürzung von Attribute zu attr gar nicht mal das Problem ist.

                Bei setAttribute() bzw. getAttribute() ist zu sehen, was die Methode tut – ob man einen Attributwert setzt oder ausliest. Bei attr() ist das nicht der Fall! Man muss erst die Anzahl der Argumente zählen.

                kürzerer Code ≠ besser lesbarer Code


                Aber falls dir attr heilig sein sollte, kannst sowas in der Art machen:

                kannst ≠ solltest

                AFAIK ist es nicht unbedingt die beste Idee, JS-eigene Objekte prototypisch zu erweitern. Zu Risiken und Nebenwirkungen fragen Sie jemanden, der sich damit auskennt.

                LLAP 🖖

                --
                “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
                1. problematische Seite

                  @@Gunnar Bittersmann

                  Bei setAttribute() bzw. getAttribute() ist zu sehen, was die Methode tut – ob man einen Attributwert setzt oder ausliest. Bei attr() ist das nicht der Fall! Man muss erst die Anzahl der Argumente zählen.

                  Es ist sogar noch schlimmer: jQuerys attr() tut verschiedene Dinge und gibt – je nach übergebenen Argumenten – verschiedene Typen zurück: attr('foo', 'bar') ein jQuery-Objekt; attr('foo') einen String (bzw. undefined, wenn es kein foo-Attribut gibt).

                  Das hat zur Folge, dass der Code schnell fehleranfällig wird:

                  $(selector).attr('foo', 'bar').hide(); // OK
                  
                  $(selector).attr('foo').hide(); // TypeError: $(...).attr(...).hide is not a function
                  

                  kürzerer Code ≠ besser lesbarer Code

                  kürzerer Code ≠ besser wartbarer Code

                  LLAP 🖖

                  --
                  “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
                2. problematische Seite

                  Hi,

                  Bei setAttribute() bzw. getAttribute() ist zu sehen, was die Methode tut – ob man einen Attributwert setzt oder ausliest. Bei attr() ist das nicht der Fall! Man muss erst die Anzahl der Argumente zählen.

                  die Anzahl der Parameter reicht nicht - man muß auch wissen, was die Funktion bei welcher Anzahl der Parameter macht.

                  Zwei Parameter könnten ja auch bedeuten, daß der Wert des Attributs mit dem Namen aus dem ersten Parameter gelesen wird, wenn kein solches vorhanden ist, wird der zweite Wert zurückgegeben (sozusagen als Default-Wert).

                  Ein Paramter könnte auch bedeuten, daß das im ersten Parameter genannte Attribut auf null gesetzt oder gelöscht wird.

                  cu,
                  Andreas a/k/a MudGuard

            2. problematische Seite

              @@Felix Riesterer

              Das title-Attribut macht keinen Sinn, auch wenn da etwas anderes drinstünde.

              Mit Verlaub: doch! Wenn jemand mit der Maus über dem Button hovert, dann will der vielleicht wissen, was der bewirkt. Das kann ein Tooltip mit dem Inhalt des title-Attributs vermitteln. In diesem Kontext ist nämlich die Beschriftung des Buttons ausgeblendet. Man "sieht" nur noch ein Plus- oder Minus-Zeichen.

              Bei Anwendungen wie bspw. Photoshop, Illustrator, InDesign usw. weiß ich solche Tooltips durchaus zu schätzen, wenn sie mir die hinter den Icons liegende Funktion erzählen. Nur sind das Desktop-Anwendungen, bei denen man davon ausgehen kann, dass die Nutzer eine Maus schubsen – wenn nicht einen Stift auf dem Grafiktablett.

              Davon ist bei Webanwendungen nicht auszugehen.

              Entweder das UI ist selbsterklärend (yay!)– dann brauchen auch Mausschubser keine Tooltips. Oder das UI ist nicht selbsterklärend (meh!) – dann brauchen auch Nicht-Mausschubser eine Erklärung, und zwar in einer anderen Form, nicht als Tooltips.

              LLAP 🖖

              --
              “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
              1. problematische Seite

                Aloha ;)

                Entweder das UI ist selbsterklärend (yay!)– dann brauchen auch Mausschubser keine Tooltips. Oder das UI ist nicht selbsterklärend (meh!) – dann brauchen auch Nicht-Mausschubser eine Erklärung, und zwar in einer anderen Form, nicht als Tooltips.

                So weit, so richtig. In der Theorie. In der Praxis stellt sich aber die Frage, wann ein UI tatsächlich objektiv selbsterklärend ist. Was mir aufgrund meiner Erfahrung / Prägung / Erziehung / kulturellem Hintergrund als selbsterklärend vorkommt, muss lange nicht für alle Benutzer selbsterklärend sein.

                Meine Devise in der Vergangenheit war dann immer, ein meiner subjektiven Auffassung nach selbsterklärendes UI zu basteln und zusätzlich Erläuterungen zu hinterlegen. Ich habe aber das Gefühl, dass das dann wieder Kritik nach sich zieht, weil ein selbsterklärendes UI ja keine Erklärungen benötigt, und wenn es welche benötigt, ist es nicht selbsterklärend genug.

                Und überhaupt, wenn ich die Erläuterungen, die Missverständnisse für alle Nutzer vermeiden sollen, hinzufügen will, was kann ich dann tun? Bei Mausschubsern habe ich Tooltips zur Verfügung, die genau dafür gedacht sind. Bei Nicht-Mausschubsern fehlt mir eine solche Ebene, weil die Geräte mir das nicht zur Verfügung stellen. Also muss ich die Erläuterungen anders einbauen, und da fällt mir nichts anderes ein, als das in einem weiteren UI-Element zu tun. Nur kommst du dann wieder um die Ecke und erklärst mir

                UI-Elemente hinzufügen, um das UI zu erklären – funktioniert immer. Nicht.

                Das hört sich für mich doch stark nach Doppelmoral an. Und darüber hinaus stelle ich fest, dass da ein offensichtliches, grundsätzliches Konzeptproblem vorliegt. Und während ich das Konzeptproblem nicht anzweifeln will, stelle ich dann doch recht verwundert fest, dass in dieser Argumentation irgendwie immer im nächsten Atemzug die Webentwickler die Bösen sind und nicht die Gerätehersteller, obwohl Letztere Erstere beschränken und nicht umgekehrt.

                Das ist, was ich in dieser Diskussion noch nie verstanden habe.

                Grüße,

                RIDER

                --
                Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
                1. problematische Seite

                  @@Camping_RIDER

                  Was mir aufgrund meiner Erfahrung / Prägung / Erziehung / kulturellem Hintergrund als selbsterklärend vorkommt, muss lange nicht für alle Benutzer selbsterklärend sein.

                  Du sagst es.

                  Meine Devise in der Vergangenheit war dann immer, ein meiner subjektiven Auffassung nach selbsterklärendes UI zu basteln und zusätzlich Erläuterungen zu hinterlegen.

                  Finde den Fehler! Tip: „meiner subjektiven Auffassung nach“

                  Ob sich deine subjektive Auffassung mit der anderer Nutzer deckt, sollte sich durch Nutzertests herausfinden lassen. Und zwar so früh wie möglich – am Prototypen.

                  Wenn die Informationsarchitektur schon nicht gut designt ist, lässt sich das im UI nicht mehr gutmachen.

                  “I remain amazed and perplexed at how often people think they can solve an information architecture problem with interaction design.”
                  Jesse James Garrett

                  Wenn man verständliche Informationsarchitektur hat (d.h. nicht das Datenmodell des Systems dem Nutzer überstülpt, der womöglich ein ganz anderes Modell hat), verständliche Interaktionen, ein verständliches UI, dann sollten keine weiteren Erklärungen nötig sein.

                  stelle ich dann doch recht verwundert fest, dass in dieser Argumentation irgendwie immer im nächsten Atemzug die Webentwickler die Bösen sind und nicht die Gerätehersteller, obwohl Letztere Erstere beschränken und nicht umgekehrt.

                  Och ja, die bösen Gerätehersteller, die einfach nicht die Technik einer Kinect in ein Smartphone integrieren wollen!

                  LLAP 🖖

                  --
                  “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
                  1. problematische Seite

                    @@Gunnar Bittersmann

                    Wenn man verständliche Informationsarchitektur hat […], verständliche Interktionen, ein verständliches UI, dann sollten keine weiteren Erklärungen nötig sein.

                    Kam gerade übern Ticker:
                    “UI is like a joke — if you have to explain it, it’s not that good” 😐😐😐

                    LLAP 🖖

                    --
                    “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
                    1. problematische Seite

                      Kam gerade übern Ticker:
                      “UI is like a joke — if you have to explain it, it’s not that good”

                      Da ist unbestritten etwas Wahres dran. Die durchschwingende Überheblichkeit solcher Statements erzeugt bei mir allerdings sehr verlässlich Würgereiz. Ist auch eine Art UI.

                      1. problematische Seite

                        @@Mitleser

                        Kam gerade übern Ticker:
                        “UI is like a joke — if you have to explain it, it’s not that good”

                        Die durchschwingende Überheblichkeit solcher Statements

                        kann ich nicht erkennen.

                        Überheblich seitens des Designers/Entwicklers ist, Nutzern ein schlecht verständliches UI vorzusetzen – so nach dem Motto: Friss oder stirb.

                        Nicht überheblich ist, Designern/Entwicklern genau das anzukreiden.

                        LLAP 🖖

                        --
                        “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
                        1. problematische Seite

                          Kam gerade übern Ticker:
                          “UI is like a joke — if you have to explain it, it’s not that good”

                          Die durchschwingende Überheblichkeit solcher Statements

                          kann ich nicht erkennen.

                          Das steht Dir frei, ich habe nur meine Einschätzung formuliert. Du die Deine.

                          Überheblich seitens des Designers/Entwicklers ist, Nutzern ein schlecht verständliches UI vorzusetzen – so nach dem Motto: Friss oder stirb.

                          Findest Du? Dann unterscheidet sich unsere Wahrnehmung der Realität sehr stark. Mir fallen spontan mindestens zwölftausend andere Gründe ein, wie ein mieses UI entstehen kann.

                          Nicht überheblich ist, Designern/Entwicklern genau das anzukreiden.

                          Wie so oft im Leben: der Ton macht die Musik.

                          1. problematische Seite

                            @@Mitleser

                            Überheblich seitens des Designers/Entwicklers ist, Nutzern ein schlecht verständliches UI vorzusetzen – so nach dem Motto: Friss oder stirb.

                            Findest Du?

                            Ja.

                            Mir fallen spontan mindestens zwölftausend andere Gründe ein, wie ein mieses UI entstehen kann.

                            Kannst du mir einen davon nennen, der im Widerspruch zur o.g. Aussage stünde?

                            Nicht überheblich ist, Designern/Entwicklern genau das anzukreiden.

                            Wie so oft im Leben: der Ton macht die Musik.

                            Und was genau wäre an “UI is like a joke — if you have to explain it, it’s not that good” schlechter Ton?

                            LLAP 🖖

                            --
                            “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
                            1. problematische Seite

                              Mir fallen spontan mindestens zwölftausend andere Gründe ein, wie ein mieses UI entstehen kann. Kannst du mir einen davon nennen, der im Widerspruch zur o.g. Aussage stünde?

                              Eine gängiges und besonders "effektives" Beispiel: beratungsresistente Kunden.

                              Nicht überheblich ist, Designern/Entwicklern genau das anzukreiden. Wie so oft im Leben: der Ton macht die Musik. Und was genau wäre an “UI is like a joke — if you have to explain it, it’s not that good” schlechter Ton?

                              Naja, der Ton halt ;-) Via Forumspost wäre das ähnlich müßig wie der Versuch, einen Joke erklären ;-)

        2. problematische Seite

          Aloha ;)

          Dann aber bitte das jQuery-Zeugs in JavaScript übersetzen.

          so lange in den Browsern der echte(!) Komfort von jQuery fehlt, gibt es nach wie vor gute Gründe für den Einsatz dieses Frameworks.

          Die Gründe für einen Einsatz von jQuery hin oder her - im Wiki lehren wir nach wie vor ausschließlich Vanilla-JS, wenn ich mich nicht irre. Ich halte das auch für richtig so.

          Grüße,

          RIDER

          --
          Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
          # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
          1. problematische Seite

            Lieber Camping_RIDER,

            Die Gründe für einen Einsatz von jQuery hin oder her - im Wiki lehren wir nach wie vor ausschließlich Vanilla-JS, wenn ich mich nicht irre. Ich halte das auch für richtig so.

            natürlich ist das für das Wiki richtig so. Das wollte ich nicht anzweifeln. Nur das mittlerweile populär werdende jQuery-Bashing zugunsten von VanillaJS hat wie jede Religion so seine Konzeptlücken.

            Liebe Grüße,

            Felix Riesterer.

            1. problematische Seite

              Aloha ;)

              Nur das mittlerweile populär werdende jQuery-Bashing zugunsten von VanillaJS hat wie jede Religion so seine Konzeptlücken.

              Ich würde sogar so weit gehen zu sagen, dass die Konzeptlücken-Eigenschaft dem Wort Bashing bereits inhärent ist 😂

              Grüße,

              RIDER

              --
              Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
              # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
  4. problematische Seite

    Lieber Matthias,

    diese Lösung (siehe Video) scheint eine vernünftige zu sein. Mal sehen, ob ich von ihr Gebrauch machen werde.

    Liebe Grüße,

    Felix Riesterer.

    1. problematische Seite

      Aloha ;)

      diese Lösung (siehe Video) scheint eine vernünftige zu sein.

      Hm. Lustig.

      „By usable I mean being able to use hyperlinks on parental anchors and open them with a double-tap (which is a native act on touch devices)“

      Das ist, was meine Lösung auch tut. Auch für mich war der „double-tap“ eine intuitive Lösung zum Öffnen der „parental anchors“[1]. @Gunnar Bittersmann sah das anders[2].

      Was gilt denn nun - „native act“ oder nicht?

      Grüße,

      RIDER

      --
      Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
      # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[

      1. immer wieder schön, wie prägnant man manche Dinge in anderen Sprachen anfassen kann, wenn sie in der einen nur irgendwie verschwurbelt ausgedrückt werden können. ↩︎

      2. vielleicht hab ich Gunnar hier auch nur falsch verstanden und es ging ihm ausschließlich um das Vorhandensein der Zusatz-Erläuterung, ich glaube aber nicht. ↩︎

  5. problematische Seite

    Hallo,

    ich werfe hier mal meine Version in den Ring:

    https://www.j-berkemeier.de/Buchstabenmixer.html

    Als Speicher für „Menü offen/zu“ habe ich den Checkbox-Hack gewählt. Daher funktioniert auch noch recht viel ohne Javascript. Allerdings fehlen leider die Aria-Label, da mir hier noch der Zugang fehlt.

    Gruß
    Jürgen

    1. problematische Seite

      @@JürgenB

      Als Speicher für „Menü offen/zu“ habe ich den Checkbox-Hack gewählt. Daher funktioniert auch noch recht viel ohne Javascript. Allerdings fehlen leider die Aria-Label, da mir hier noch der Zugang fehlt.

      Anstatt zu versuchen, da mit haufenweise ARIA noch was rauszureißen, sollte man von vornherein auf Hacks verzichten und eine Lösung mit passenden HTML-Elementen suchen. Etwas mehr JavaScript ist nicht immer schädlich.

      LLAP 🖖

      --
      “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
      1. problematische Seite

        Hallo Gunnar,

        ob in meiner Navigation noch Aria-Label fehlen, weiß ich nicht, dazu habe von diesem Thema zu wenig Ahnung.

        Aber was ist so schlecht am Checkbox-Hack? Selbst Heydon Pickering landet dort. Warum ist ein Button mit Javascript besser als eine Checkbox oder ein Radio-Button? Ist mein Menü wegen dieses Hacks unbedienbar? Wenn ja, wo liegen die Schwächen?

        Gruß
        Jürgen

        1. problematische Seite

          @@JürgenB

          Aber was ist so schlecht am Checkbox-Hack? Selbst Heydon Pickering landet dort.

          An welcher Stelle?

          Warum ist ein Button mit Javascript besser als eine Checkbox oder ein Radio-Button?

          Ein Button ist ein Button ist ein Bedienelement, das eine Aktion auslöst.

          Checkboxen und Radio-Buttons sind dazu da, Optionen auszuwählen, üblicherweise in einem Formular.

          Ist mein Menü wegen dieses Hacks unbedienbar? Wenn ja, wo liegen die Schwächen?

          Man müsste Checkboxen/Radio-Buttons dazu bringen, nicht nur so auszusehen wie Bedienelemente, die eine Aktion auslösen, sondern sich auch so zu verhalten. Mit allem Drum und Dran. Nicht machen, Kinder. Gleich das Passende nehmen.

          LLAP 🖖

          --
          “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
          1. problematische Seite

            Hallo Gunnar,

            Aber was ist so schlecht am Checkbox-Hack? Selbst Heydon Pickering landet dort.

            An welcher Stelle?

            in dem von dir verlinkten Artikel im unteren Viertel. Er verlinkt auch ein Beispiel in Codepen.

            Warum ist ein Button mit Javascript besser als eine Checkbox oder ein Radio-Button?

            Ein Button ist ein Button ist ein Bedienelement, das eine Aktion auslöst.

            die Aktion ist „öffnen des Submenüs“.

            Checkboxen und Radio-Buttons sind dazu da, Optionen auszuwählen, üblicherweise in einem Formular.

            und die Optionen sind „Menü auf“ und „Menü zu“

            Ist mein Menü wegen dieses Hacks unbedienbar? Wenn ja, wo liegen die Schwächen?

            Man müsste Checkboxen/Radio-Buttons dazu bringen, nicht nur so auszusehen wie Bedienelemente, die eine Aktion auslösen, sondern sich auch so zu verhalten. Mit allem Drum und Dran. Nicht machen, Kinder. Gleich das Passende nehmen.

            und das ist deiner Meinung nach ein Button mit Javascript als Gedächtnis?

            Gruß
            Jürgen

      2. problematische Seite

        Lieber Gunnar,

        Etwas mehr JavaScript ist nicht immer schädlich.

        es sollte die Dinge erweitern bzw. verbessern, und zwar in Richtung mehr Komfort.

        Hier ist eine Lösung, die ich gerade erarbeite.

        Liebe Grüße,

        Felix Riesterer.

    2. problematische Seite

      Aloha ;)

      Als Speicher für „Menü offen/zu“ habe ich den Checkbox-Hack gewählt.

      Sowas hatte ich auch überlegt, aber das spezifische Problem ist hier, dass in einer mehrstufigen Navigation oft auch die "Kategorien" verlinkt sein sollen, also in deinem Beispiel, dass "Mathematik" eben zusätzlich zum Beinhalten des Untermenüs auch selbst ein Link sein soll. Ohne die Verlinkung der Kategorien ist der Checkbox-Hack da schon eine mögliche CSS-only-Lösung.

      Grüße,

      RIDER

      --
      Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
      # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
      1. problematische Seite

        Hallo,

        … dass in einer mehrstufigen Navigation oft auch die "Kategorien" verlinkt sein sollen, also in deinem Beispiel, dass "Mathematik" eben zusätzlich zum Beinhalten des Untermenüs auch selbst ein Link sein soll.

        genau deswegen waren viele Beispiele, die ich gefunden habe, für mich nicht geeignet, da bei mir die Kategorie eben nicht verlinkt sein soll, sondern nur der Schalter zum öffnen des Untermenüs.

        Gruß
        Jürgen

  6. problematische Seite

    Servus!

    @Matthias Apsel Vielen Dank! Mit :focus-within funktioniert es jetzt so gut, wie es mit CSS halt geht.

    @Felix Riesterer

    ich habe jetzt nicht verstanden, wie diese Dinger auf mobilen Endgeräten zu bedienen sind, da ich dort weder Tab- noch sonstige Tasten nutzen kann - und hovern geht bekanntlich auch nicht.

    Viele mobile Browser simulieren bei tap ein hover.

    wenn also der Menüpunkt selbst kein Link ist, dann mag das alles wunderbar sein. Wenn nun aber der Menüpunkt selbst gleichzeitig ein Link ist, dann komme ich nicht an die weiteren Menüpunkte dran.

    Ja, das und die fehlende Möglichkeit Tabs zu überspringen, sind der Nachteil von CSS-basierten Lösungen. Trotzdem habe ich dieses Tutorial lieber überarbeitet, um hier die Grundlagen zu erklären, anstatt ihn, wie Gunnar in seinem bewährt freundlichen Ton vorschlug vom Netz zu nehmen. Auch bei einer JavaScript-basierten Lösung wird die grundlegende Präsentation ja mit CSS erreicht.

    Trotzdem freut es mich, dass du und Gunnar mal einer Meinung seid! :-)

    Der Artikel verlinkt mehrfach auf das JavaScript-Tutorial, dass seit Dez. 2105 ein ToDo ist. Hier werde ich (jemand anderes findet sich ja wohl nicht mehr) die Problematik versuchen zu lösen. Danke an @Gunnar Bittersmann für den Link, da wird das Problem von Links mit aria-haspopup="true" gut erklärt.

    Apropos jQuery: In Practical ARIA examples hatte auch Heydon jQuery verwendet.

    @JürgenB Das mit den Aria-Attributen scheint auf den ersten Blick wegen der Vielzahl der möglichen Attribute verwirrend zu sein. Ich habe sie als Ersatz für Klassen schätzen gelernt. Die sollten ja nach ihrer Funktionalität benannt werden, und dass ist mit Aria-Attributen imho halt standardisiert worden. Man kann sie über den Attribut-Selektor genauso zum Styling heranziehen.

    Was mir im Tutorial noch fehlt, ist der Hinweis, dass es gerade für mobile Seiten, aber auch am Desktop immer wichtiger wird, eine gute Struktur mit einfachen Menüpunkten anzustreben. Deshalb habe ich das Beispiel zum Flyout-Menü dringelassen, dass diese Problematik imho gut anspricht. Über die Platzierung lässt sich streiten

    Den Exkurs des Ausblendens von Elementen würd ich lieber zum Image-Replacement / bzw. in einen eigenen Artikel packen; da fehlt imho noch ein Verweis auf hidden. @Gunnar Bittersmann In einer JS-basierten Lösung könnte ich die Submenüs ja mit hidden ausblenden - ausgeblendete Elemente sollen / müssen von Screenreadern ja erst gelesen werden, wenn sie eingeblendet werden. Heydon Pickering macht das auch so. (Wichtig ist, dass das hidden erst mit JS hinzugefügt wird).

    Herzliche Grüße

    Matthias Scharwies

    --
    Es gibt viel zu tun: ToDo-Liste
    1. problematische Seite

      @@Matthias Scharwies

      Trotzdem habe ich dieses Tutorial lieber überarbeitet, um hier die Grundlagen zu erklären, anstatt ihn, wie Gunnar in seinem bewährt freundlichen Ton vorschlug vom Netz zu nehmen.

      Ich sagte doch: „bis dahin“ (bis der Artikel überarbeitet wurde).

      „Bewährt freundlich“? Nun ja, schlechte Beispiele schönzureden ist nicht mein Ding.

      In einer JS-basierten Lösung könnte ich die Submenüs ja mit hidden ausblenden […] (Wichtig ist, dass das hidden erst mit JS hinzugefügt wird).

      Und dabei nicht vergessen, das Menü auch erstmal zu stylen, wenn es in seiner Gänze sichtbar ist.

      Daraus wird dann per JS ein Aufklappmenü – als progressive enhancement. Dafür muss es dann wieder andere Regeln im Stylesheet geben.

      LLAP 🖖

      --
      “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory