Ein unwiderstehliches HTML-Element im Detail von Ire Aderinokun, diesmal über das <abbr title="">-Element für Abkürzungen. Man kann es irgendwie einfach benutzen (JUI) und es funktioniert gut, aber wenn man hofft, einen Tooltip dafür zu erstellen (der auch auf Touchscreens funktioniert), dann ist es viel komplizierter.
Das Endergebnis ist, das semantische HTML unangetastet zu lassen und mit etwa 50 Zeilen JavaScript progressiv zu verbessern, das interaktive Wrapper-Elemente und Event-Handler hinzufügt.
Ich finde, das ist genau die Art von Ding, die zu einer Web-Komponente gemacht werden könnte und sollte, die weit verbreitet genutzt werden kann. Vielleicht eine <a11y-abbr>-Komponente oder so. Können Web-Komponenten andere native HTML-Elemente erweitern? Wenn nicht, fällt es wohl auf das zurück, was im Wesentlichen ein <span> ist, also vielleicht ist das nicht ideal.
Ich wage es zu sagen, das ist auch die Art von Sache, bei der React glänzen kann. Zum Beispiel benutze ich Reach Router, und standardmäßig erhalten Links (<Link>s, die zu <a>s werden), wenn sie die aktuelle Seite sind, das richtige aria-current-Attribut. Das ist gute Barrierefreiheit, die man kostenlos bekommt, weil die Bibliothek gut genug war, dieses Detail richtig zu machen. So sehr, wie Bibliotheken wie React für problematische Barrierefreiheit kritisiert werden, gibt es viel Potenzial für Verbesserungen der Barrierefreiheit durch Abstraktion. Ähnlich wie Brad Frost die besten Praktiken für Barrierefreiheit in React-Komponenten erzwingt.
Hauptsächlich benutze ich es, um ein Inhaltsverzeichnis für die Seite zu enthalten. Ich lege das Inhaltsverzeichnis in eine mehrstufige ungeordnete Liste. Vor den Details habe ich einen Link, der sagt "überspringe Inhaltsverzeichnis", der auf die erste Abschnitts-ID danach verlinkt. Das liegt daran, dass einige Screenreader den Inhalt eines Details-Knotens vorlesen, unabhängig davon, ob er geöffnet ist oder nicht. Wenn das Detail also viel Inhalt hat, ist es praktisch, eine Möglichkeit für Screenreader zu geben, es zu überspringen.
Ich habe früher ein Polyfill verwendet, aber das brach manchmal bei einem Browser-Update – also kümmere ich mich jetzt nicht mehr darum, wenn der Browser Details nicht unterstützt, ist es einfach immer offen.
Ich fand es nützlich, dem Summary-Element einen gelben Hintergrund zu geben, und wenn das Detail standardmäßig geschlossen ist, schreibe ich in Klammern (klicken Sie mich zum Erweitern) – erstaunlich, wie viele Leute das nicht wissen, es sei denn, das steht im Summary.
Was Tooltips angeht, ehrlich gesagt, glaube ich, dass Details das falsche Werkzeug für den Job ist, das meiner Meinung nach mit reinem JS und CSS in einem Div behandelt werden muss.
Es wäre schön, wenn es ein echtes Tooltip-Element gäbe.
Ich frage mich, ob dies ein Fall ist, in dem die cursorbasierte Behandlung des title-Attributs so allgegenwärtig ist, dass ein Konsens über die Behandlung von Tooltip-ähnlichem Verhalten auch auf Touch-Geräten erzielt und von mobilen Browsern implementiert werden sollte. Andererseits sind mobile Browser jetzt schon so lange im Umlauf, dass eine solch drastische Änderung problematisch sein und bestehende Websites kaputt machen könnte.
Schwierige Entscheidung, das. Es ist einfach schade, dass ein ~50 Zeilen langes Polyfill notwendig ist, um Tooltips auf dem Handy zu behandeln.
Das erinnert mich auch an einen Gedanken, den ich hatte und darüber gebloggt habe, bei dem wir den Browsern eine prominentere Rolle bei der standardmäßigen Formatierung/Behandlung von Inhalten erlauben, um schnellere Ladezeiten und bessere Erfahrungen zu ermöglichen. Wenn dieses ~50 Zeilen lange Polyfill oder eine ähnliche Erfahrung auf einem großen Teil des Webs verwendet würde, wäre es vielleicht etwas, das auf einer niedrigeren Ebene unterstützt werden muss.