Ein Blick von Christian Kozalla auf das <dialog> HTML-Element und wie man es verwendet, um ein gut aussehendes und zugängliches Modal zu erstellen.
Mich reizt das <dialog> Element, da es eines dieser Elemente ist, bei denen man "viel geschenkt bekommt" (noch mehr als das beliebte <details> Element) und es ist so einfach, Modal-Zugänglichkeit falsch zu machen (z. B. Fokus-Trapping), dass es großartig scheint, so etwas von einem nativen Element bereitgestellt zu bekommen. ::backdrop ist besonders cool.
Aber ist es zu gut, um wahr zu sein? Solide Unterstützung ist noch nicht da, Safari unterstützt es nicht.Christian erwähnt das Polyfill von Google, das definitiv hilft, grundlegende Funktionalität in Browsern ohne Unterstützung zu bringen.
Das Hauptproblem ist das eigentliche Testen auf einem Screenreader. Scott O’Hara hat einen Artikel, „Having an open dialog,“ der noch diesen Monat (Oktober 2021) aktualisiert wurde, in dem er letztendlich sagt: „[...] das dialog Element und sein Polyfill sind nicht für den Einsatz in der Produktion geeignet.“ Ich bezweifle Scotts Tests nicht, aber da die meisten Leute einfach eigene Modal-Erlebnisse entwickeln, ohne auf Zugänglichkeit zu achten, frage ich mich, ob das Web besser dran wäre, wenn mehr Leute einfach <dialog> (und das Polyfill) trotzdem verwenden würden. Höhere Nutzung würde wahrscheinlich mehr Browser-Aufmerksamkeit und Verbesserungen auslösen.
Buchstäblich heute wird das Dialog-Element in Safari TP 134 unterstützt: https://webkit.org/blog/12033/release-notes-for-safari-technology-preview-134/
Ich frage mich, wie lange bis zur stabilen Version? Ich habe heute auf Monterey aktualisiert, also im schlimmsten Fall ist es wie... das nächste Betriebssystem danach? Ich bin begeistert, ich würde gerne denken, dass wir das in Zukunft wirklich nutzen können
Ja, ich dachte, das kann kein Zufall sein...
Sehr gut, Fortschritte zu sehen
Ich stimme vollkommen zu, je mehr Nutzung, desto mehr würde es auch Browsern anzeigen, dass wir es wollen.
Auch das Hinzufügen der fehlenden Zugänglichkeit durch ein wenig zusätzliche JS kann diesen fehlenden Teil lösen, obwohl es schön gewesen wäre, wenn dies Teil des Dialogs direkt gewesen wäre.
Das wäre nicht der Fall. Allerdings würde es wissentlich Benutzer ausschließen.
Scott bietet Beispiele, wie es richtig gemacht wird. Das Vorschlagen eines nachweislich unzugänglichen Musters anstelle der Weiterleitung von Entwicklern zu einem zugänglichen Muster ist eine Einladung zu WCAG (und rechtlichen) Risiken.
Die Geschichte legt nahe, dass dies nicht der Fall ist.
Zum Beispiel zögert Chrome weiterhin bei Empfehlungen von Experten, wo der Standardfokus beim Öffnen eines Dialogs liegen sollte, selbst wenn andere Browser mitmachen. Chromes drei (3) Jahre lange Verzögerungstaktik und sein übermäßiger Einfluss auf WHATWG HTML sind bereits eine Zugänglichkeitsbarriere.
Ganz zu schweigen davon, dass die Barrierefreiheits-Experten von Microsoft eingreifen mussten, um sicherzustellen, dass die Standard-Fokusumrandungen in Chrome im Jahr 2019 die WCAG-Checks bestanden. Ganz zu schweigen davon, dass kein Browser Links, die sich in neuen Fenstern öffnen, als Teil der Zugänglichkeits-Schicht freigegeben hat seit WCAG 1.0 dies 1999 gefordert hat. Und so weiter.
Ein verantwortungsvollerer Ansatz für Entwickler wäre die Verwendung der zugänglichen Muster. Diejenigen, die an Standards arbeiten, können diese Fälle nutzen, um zu demonstrieren, dass Browser hinterherhinken, und Druck ausüben. Ohne Benutzer auszuschließen.
Ich widerspreche dieser Ansicht entschieden. Bewusst unzugänglichen Code zu veröffentlichen, beraubt Menschen des Zugangs. Was ist, wenn dieses Modal Ihnen hilft, Lebensmittel einzukaufen, einen Arzttermin zu bekommen oder die Zustimmung zu erteilen?
Das Problem bleibt Ableismus auf Browser-Ebene, wo bekannte Zugänglichkeitsbedenken zugunsten von glänzenden neuen Dingen zurückgestellt werden.
Sie werden sowieso das Gleiche mit einem Div bauen müssen. Ich lasse meine einfach ein Dialog mit dialog[open=”true”] {…} (und mehr) verwenden. Wenn die Unterstützung zunimmt, fangen Sie an, proprietären Code für nativen Code fallen zu lassen. Die Leute denken auch, dass selbst ein Modal eine so große Aufgabe ist, dass Sie dafür ein Plugin kaufen müssen. Es ist im Grunde nur ein Block CSS und zyklisches Tabbing. Keine große Sache!
Leider funktionieren die wirklich guten Dinge von
<dialog>, nämlich z-index-Handling, Fokusmanagement und Backdrop-Unterstützung, nur über die imperative.showModalAPI. Dasopen-Attribut tut dasselbe wie die normale.show-Methode und rendert den Dialog als normales,<div>-ähnliches Element.Deshalb ist es praktisch nutzlos in deklarativen Frameworks,
<dialog open modal />wäre schön...Wie die meisten anderen coolen nativen HTML-Elemente ist dies extrem... mangelhaft.
Backdrop erbt keine CSS-Variablen (z. B. Farben).
Sie müssen Abstände und Ränder über Resets entfernen (warum auch immer).
Öffnen/Schließen erfolgt über display block/none, daher ist es unmöglich, das Erscheinen über Übergänge zu animieren. Sie müssen alles manuell ändern, um Übergänge zu ermöglichen.
Backdrop wird nicht versteckt, sondern beim Ausblenden entfernt, so dass selbst wenn Sie den Dialog umschreiben, um Übergänge zu ermöglichen, der Backdrop nicht mit ihnen funktioniert. Sie müssen JS und Animationen verwenden oder einen Hack verwenden und dem Dialog einen riesigen box-shadow geben.
Dies sind nur die Dinge, die ich in 2 Stunden gefunden habe. Wer entwirft so etwas? Wenn dies eine Komponente wäre, würde ich sie mit einer Liste von Fehlerbehebungen zurückschicken! Jesus.