Dialog-Komponenten: Native HTML verwenden oder selbst entwickeln?

Als Autor einer Bibliothek namens AgnosticUI bin ich ständig auf der Suche nach neuen Komponenten. Und vor kurzem beschloss ich, mich damit zu beschäftigen und mit der Arbeit an einer neuen Dialog-Komponente (auch bekannt als Modal) zu beginnen. Das ist etwas, das viele Entwickler gerne in ihrem Werkzeugkasten haben möchten, und mein Ziel war es, die bestmögliche zu erstellen, mit einem besonders starken Fokus auf Inklusivität und Zugänglichkeit.

Mein erster Gedanke war, dass ich auf Abhängigkeiten verzichten und den sauren Apfel beißen und meine eigene Dialog-Komponente bauen würde. Wie Sie vielleicht wissen, gibt es ein neues <dialog>-Element, das die Runde macht, und ich dachte, es wäre richtig, es als Ausgangspunkt zu verwenden, insbesondere in den Bereichen Inklusivität und Zugänglichkeit.

Aber nach einiger Recherche entschied ich mich stattdessen, a11y-dialog von Kitty Giraudel zu nutzen. Ich habe sogar Adapter geschrieben, damit es nahtlos mit Vue 3, Svelte und Angular integriert. Kitty bietet auch schon lange einen Adapter für React an.

Warum habe ich diesen Weg gewählt? Lassen Sie mich Sie durch meinen Denkprozess führen.

Erste Frage: Sollte ich überhaupt das native <dialog>-Element verwenden?

Das native <dialog>-Element wird aktiv verbessert und wird wahrscheinlich der Weg für die Zukunft sein. Aber es gibt derzeit noch einige Probleme, die Kitty sehr gut dargelegt hat

1. Das Klicken auf das Backdrop-Overlay schließt das Dialogfeld nicht standardmäßig
2. Die alertdialog ARIA-Rolle, die für Alerts verwendet wird, funktioniert einfach nicht mit dem nativen <dialog>-Element. Wir sollen diese Rolle verwenden, wenn ein Dialog eine Antwort des Benutzers erfordert und nicht durch Klicken auf das Backdrop oder durch Drücken von ESC geschlossen werden darf.
3. Das <dialog>-Element kommt mit einem ::backdrop Pseudo-Element, aber es ist nur verfügbar, wenn ein Dialog programmatisch mit dialog.showModal() geöffnet wird.

Und wie Kitty auch anmerkt, gibt es allgemeine Probleme mit den Standardstilen des Elements, wie zum Beispiel, dass sie dem Browser überlassen werden und JavaScript erfordern. Es ist also irgendwie nicht zu 100 % HTML.

Hier ist ein Pen, der diese Punkte demonstriert

Nun, einige dieser Probleme betreffen Sie oder Ihr Projekt möglicherweise nicht speziell, und Sie können vielleicht sogar Lösungen dafür finden. Wenn Sie den nativen Dialog immer noch nutzen möchten, sollten Sie sich den wunderbaren Beitrag von Adam Argyle über das Erstellen einer Dialogkomponente mit nativem Dialog ansehen.

Okay, lassen Sie uns besprechen, was tatsächlich die Anforderungen an eine zugängliche Dialogkomponente sind…

Was ich suche

Ich weiß, dass es viele Ideen darüber gibt, was eine Dialogkomponente tun sollte oder nicht tun sollte. Aber was mich persönlich für AgnosticUI angeht, konzentrierte ich mich auf das, was meiner Meinung nach eine zugängliche Dialogerfahrung ausmacht.

1. Das Dialogfeld sollte sich schließen, wenn außerhalb des Dialogfelds (auf dem Backdrop) geklickt wird oder wenn die ESC-Taste gedrückt wird.
2. Es sollte den Fokus einsperren, um zu verhindern, dass man mit der Tastatur aus der Komponente heraus tabbt.
3. Es sollte das Weiter-Tabben mit TAB und das Zurück-Tabben mit SHIFT+TAB ermöglichen.
4. Es sollte den Fokus zurück auf das zuvor fokussierte Element zurückgeben, wenn es geschlossen wird.
5. Es sollte die aria-*-Attribute und Toggles korrekt anwenden.
6. Es sollte Portals bereitstellen (nur wenn wir es innerhalb eines JavaScript-Frameworks verwenden).
7. Es sollte die alertdialog ARIA-Rolle für Alertszenarien unterstützen.
8. Es sollte verhindern, dass der darunterliegende Körper scrollt, falls erforderlich.
9. Es wäre großartig, wenn unsere Implementierung die gängigen Fallstricke vermeiden könnte, die mit dem nativen <dialog>-Element einhergehen.
10. Es sollte idealerweise eine Möglichkeit bieten, benutzerdefinierte Stile anzuwenden und gleichzeitig die Benutzerpräferenzabfrage prefers-reduced-motion als weitere Zugänglichkeitsmaßnahme zu berücksichtigen.

Ich bin nicht der Einzige mit einer Wunschliste. Sie könnten sich Scott O'Haras Artikel zu diesem Thema ansehen, sowie Kittys vollständigen Beitrag zur Erstellung eines zugänglichen Dialogs von Grund auf hier für detailliertere Informationen.

Es sollte inzwischen klar sein, warum ich das native <dialog>-Element aus meiner Komponentenbibliothek gestrichen habe. Ich glaube natürlich an die Arbeit, die in das Element gesteckt wird, aber meine aktuellen Bedürfnisse überwiegen die Kosten bei weitem. Deshalb habe ich Kittys a11y-dialog als Ausgangspunkt gewählt.

Prüfung der Dialog-Zugänglichkeit

Bevor Sie einer bestimmten Dialog-Implementierung vertrauen, sollten Sie sicherstellen, dass sie Ihren Anforderungen entspricht. Da meine Anforderungen stark auf Zugänglichkeit ausgerichtet sind, bedeutete dies, a11y-dialog zu prüfen.

Zugänglichkeitsprüfungen sind ein eigenständiger Beruf. Und auch wenn es nicht mein alltäglicher Schwerpunkt ist, weiß ich, dass es einige Dinge gibt, die es wert sind, getan zu werden, wie zum Beispiel:

• die oben aufgeführte Funktionalität manuell zu überprüfen, natürlich in verschiedenen Browsern,
• Zugänglichkeitswerkzeuge wie Lighthouse, IBM Equal Access Accessibility Checker, Deque’s AXE und WAVE zu verwenden, um Einblicke zu gewinnen und Probleme aufzudecken,
• mit echten Screenreadern zu testen, wie JAWS, NVDA und VoiceOver, und
• die Komponente mit echten Menschen zu testen.

Das ist, wie Sie sich vorstellen können (oder aus Erfahrung wissen), ziemlich viel Arbeit. Es ist verlockend, den Weg des geringsten Widerstands zu wählen und zu versuchen, Dinge zu automatisieren, aber in einer Studie von Deque Systems können automatisierte Werkzeuge nur etwa 57 % der Zugänglichkeitsprobleme erkennen. Es gibt keinen Ersatz für gute alte harte Arbeit.

Die Prüfumgebung

Die Dialogkomponente kann an vielen Orten getestet werden, darunter Storybook, CodePen, CodeSandbox oder was auch immer. Für diesen speziellen Test ziehe ich es jedoch vor, eine Skelettseite zu erstellen und lokal zu testen. Auf diese Weise vermeide ich es, die Prüfer selbst zu validieren, sozusagen. Die Verwendung eines Storybook-spezifischen Add-ons für die Zugänglichkeitsprüfung ist in Ordnung, wenn Sie Storybook bereits für Ihre eigenen Komponenten verwenden, aber es fügt eine weitere Komplexitätsebene hinzu, wenn Sie die Zugänglichkeit einer externen Komponente testen.

Eine Skelettseite kann den Dialog mit manuellen Überprüfungen, vorhandenen Zugänglichkeitswerkzeugen und Screenreadern überprüfen. Wenn Sie mitmachen, möchten Sie diese Seite über einen lokalen Server ausführen. Dafür gibt es viele Möglichkeiten; eine davon ist die Verwendung eines Tools namens serve, und npm bietet sogar einen schönen Einzeiler-Befehl npx serve <VERZEICHNIS>, um Dinge zu starten.

Lassen Sie uns gemeinsam eine Beispielprüfung durchführen!

Ich bin hier offensichtlich von a11y-dialog überzeugt, also lassen Sie es uns auf die Probe stellen und es mit einigen der empfohlenen Ansätze, die wir behandelt haben, verifizieren.

Auch hier fange ich nur mit einem HTML an. Sie können dasselbe verwenden, das ich benutze (komplett mit integrierten Stilen und Skripten).

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>A11y Dialog Test</title>
    <style>
      .dialog-container {
        display: flex;
        position: fixed;
        top: 0;
        left: 0;
        bottom: 0;
        right: 0;
        z-index: 2;
      }
      
      .dialog-container[aria-hidden='true'] {
        display: none;
      }
      
      .dialog-overlay {
        position: fixed;
        top: 0;
        left: 0;
        bottom: 0;
        right: 0;
        background-color: rgb(43 46 56 / 0.9);
        animation: fade-in 200ms both;
      }
      
      .dialog-content {
        background-color: rgb(255, 255, 255);
        margin: auto;
        z-index: 2;
        position: relative;
        animation: fade-in 400ms 200ms both, slide-up 400ms 200ms both;
        padding: 1em;
        max-width: 90%;
        width: 600px;
        border-radius: 2px;
      }
      
      @media screen and (min-width: 700px) {
        .dialog-content {
          padding: 2em;
        }
      }
      
      @keyframes fade-in {
        from {
          opacity: 0;
        }
      }
      
      @keyframes slide-up {
        from {
          transform: translateY(10%);
        }
      }

      /* Note, for brevity we haven't implemented prefers-reduced-motion */
      
      .dialog h1 {
        margin: 0;
        font-size: 1.25em;
      }
      
      .dialog-close {
        position: absolute;
        top: 0.5em;
        right: 0.5em;
        border: 0;
        padding: 0;
        background-color: transparent;
        font-weight: bold;
        font-size: 1.25em;
        width: 1.2em;
        height: 1.2em;
        text-align: center;
        cursor: pointer;
        transition: 0.15s;
      }
      
      @media screen and (min-width: 700px) {
        .dialog-close {
          top: 1em;
          right: 1em;
        }
      }
      
      * {
        box-sizing: border-box;
      }
      
      body {
        font: 125% / 1.5 -apple-system, BlinkMacSystemFont, Segoe UI, Helvetica, Arial, sans-serif;
        padding: 2em 0;
      }
      
      h1 {
        font-size: 1.6em;
        line-height: 1.1;
        font-family: 'ESPI Slab', sans-serif;
        margin-bottom: 0;
      }
      
      main {
        max-width: 700px;
        margin: 0 auto;
        padding: 0 1em;
      }
    </style>
    <script defer src="https://cdn.jsdelivr.net/npm/a11y-dialog@7/dist/a11y-dialog.min.js"></script>
  </head>

  <body>
    <main>
      <div class="dialog-container" id="my-dialog" aria-hidden="true" aria-labelledby="my-dialog-title" role="dialog">
        <div class="dialog-overlay" data-a11y-dialog-hide></div>
        <div class="dialog-content" role="document">
          <button data-a11y-dialog-hide class="dialog-close" aria-label="Close this dialog window">
            ×
          </button>
          <a href="https://www.yahoo.com/" target="_blank">Rando Yahoo Link</a>
  
          <h1 id="my-dialog-title">My Title</h1>
          <p id="my-dialog-description">
            Some description of what's inside this dialog…
          </p>
        </div>
      </div>
      <button type="button" data-a11y-dialog-show="my-dialog">
        Open the dialog
      </button>
    </main>
    <script>
      // We need to ensure our deferred A11yDialog has
      // had a chance to do its thing ;-)
      window.addEventListener('DOMContentLoaded', (event) => {
        const dialogEl = document.getElementById('my-dialog')
        const dialog = new A11yDialog(dialogEl)
      });
    </script>
  </body>

</html>

Ich weiß, wir ignorieren eine Reihe von Best Practices (was, Stile im <head>?!), und haben das gesamte HTML, CSS und JavaScript in einer Datei kombiniert. Ich gehe nicht auf die Details des Codes ein, da der Fokus hier auf der Prüfung der Zugänglichkeit liegt, aber Sie sollten wissen, dass dieser Test eine Internetverbindung erfordert, da wir a11y-dialog von einem CDN importieren.

Zuerst die manuellen Checks

Ich habe diese Einzelseiten lokal bereitgestellt und hier sind meine Ergebnisse der manuellen Überprüfung

Als Nächstes verwenden wir einige Zugänglichkeitswerkzeuge

Ich habe Lighthouse verwendet, um die Komponente sowohl auf einem Desktop-Computer als auch auf einem Mobilgerät zu testen, und zwar in zwei verschiedenen Szenarien, bei denen der Dialog standardmäßig geöffnet und standardmäßig geschlossen ist.

Ich habe festgestellt, dass die Werkzeuge manchmal keine dynamisch angezeigten oder versteckten DOM-Elemente berücksichtigen, daher stellt dieser Test sicher, dass ich für beide Szenarien eine vollständige Abdeckung erhalte.

Ich habe auch mit IBM Equal Access Accessibility Checker getestet. Im Allgemeinen gibt Ihnen dieses Tool eine rote Violationsmeldung aus, wenn etwas Unzumässiges falsch ist. Es wird Sie auch bitten, bestimmte Punkte manuell zu überprüfen. Wie hier zu sehen ist, gibt es ein paar Punkte zur manuellen Überprüfung, aber keine roten Violations.

Weiter zu Screenreadern

Zwischen meinen manuellen Checks und den Tooling-Checks fühle ich mich bereits relativ sicher, dass a11y-dialog eine zugängliche Option für mein Dialog-Programm meiner Wahl ist. Wir sollten jedoch unsere Sorgfaltspflicht erfüllen und einen Screenreader konsultieren.

VoiceOver ist der praktischste Screenreader für mich, da ich derzeit an einem Mac arbeite. Aber JAWS und NVDA sind ebenfalls wichtige Namen, die man sich ansehen sollte. Ähnlich wie beim Prüfen der UI-Konsistenz über Browser hinweg ist es wahrscheinlich eine gute Idee, wenn möglich mehr als einen Screenreader zu testen.

So habe ich den Screenreader-Teil der Prüfung mit VoiceOver durchgeführt. Grundsätzlich habe ich die zu testenden Aktionen aufgeführt und jede davon wie ein Skript bestätigt.

Testen mit Menschen

Wenn Sie denken, dass wir jetzt mit dem Testen mit echten Menschen weitermachen, muss ich leider sagen, dass ich niemanden finden konnte. Hätte ich das getan, hätte ich ihnen eine ähnliche Reihe von Schritten zur Verfügung gestellt, die sie durchlaufen sollten, während ich zuschaue, Notizen mache und ein paar Fragen zur allgemeinen Erfahrung stelle.

Wie Sie sehen können, erfordert eine zufriedenstellende Prüfung viel Zeit und Überlegung.

Gut, aber ich möchte eine Dialogkomponente eines Frameworks verwenden

Das ist cool! Viele Frameworks haben ihre eigenen Dialogkomponenten-Lösungen, also gibt es viel zur Auswahl. Ich habe keine erstaunliche Tabellenkalkulation aller Frameworks und Bibliotheken, die da draußen sind, und werde Ihnen die Arbeit ersparen, sie alle zu bewerten.

Stattdessen sind hier einige Ressourcen, die gute Ausgangspunkte und Überlegungen für die Verwendung einer Dialogkomponente in einigen der am weitesten verbreiteten Frameworks sein könnten.

Haftungsausschluss: Ich habe diese nicht persönlich getestet. Das sind alles Dinge, die ich bei meiner Recherche gefunden habe.

Angular Dialog-Optionen

Im Jahr 2020 veröffentlichte Deque einen Artikel, der Angular-Komponentenbibliotheken prüfte, und die TL;DR-Version war, dass Material (und seine Angular/CDK Bibliothek) und ngx-bootstrap beide eine anständige Dialog-Zugänglichkeit zu bieten scheinen.

React Dialog-Optionen

Reakit bietet eine Dialogkomponente an, die angeblich mit den WAI-ARIA Dialogrichtlinien konform ist, und chakra-ui achtet anscheinend auf seine Zugänglichkeit. Natürlich ist Material auch für React verfügbar, also lohnt sich das auch. Ich habe auch Gutes über reach/dialog und Adobes @react-aria/dialog gehört.

Vue Dialog-Optionen

Ich bin ein Fan von Vuetensils, der naked (auch headless) Komponentenbibliothek von Austin Gil, die zufällig eine Dialogkomponente hat. Es gibt auch Vuetify, eine beliebte Material-Implementierung mit einer eigenen Dialogkomponente. Ich bin auch auf PrimeVue gestoßen, war aber überrascht, dass seine Dialogkomponente es nicht schaffte, den Fokus auf das ursprüngliche Element zurückzugeben.

Svelte Dialog-Optionen

Sie könnten sich svelte-headlessui ansehen. Material hat einen Port in svelterial, der ebenfalls einen Blick wert ist. Es scheint, dass viele aktuelle SvelteKit-Benutzer ihre eigenen Komponentensätze bevorzugen, da das Idiom von SvelteKits Paketierung es super einfach macht, dies zu tun. Wenn das auf Sie zutrifft, empfehle ich Ihnen definitiv, svelte-a11y-dialog als bequemes Mittel zur Erstellung benutzerdefinierter Dialoge, Schubladen, Bottom Sheets usw. in Betracht zu ziehen.

Ich möchte auch darauf hinweisen, dass meine AgnosticUI-Bibliothek die zuvor erwähnten Adapter-Implementierungen von a11y-dialog für React, Vue, Svelte und Angular umschließt.

Bootstrap, natürlich

Bootstrap ist immer noch etwas, das viele Leute benutzen, und es ist nicht überraschend, dass es eine Dialogkomponente anbietet. Es erfordert, dass Sie einige Schritte befolgen, um das Modal zugänglich zu machen.

Wenn Sie andere inklusive und zugängliche bibliotheksbasierte Dialogkomponenten haben, die in Betracht gezogen werden sollten, würde ich sie gerne in den Kommentaren erfahren!

Aber ich erstelle ein benutzerdefiniertes Designsystem

Wenn Sie ein Designsystem erstellen oder einen anderen selbstgebauten Dialogansatz in Betracht ziehen, können Sie sehen, wie viele Dinge getestet und berücksichtigt werden müssen… und das nur für eine Komponente! Es ist natürlich machbar, es selbst zu entwickeln, aber ich würde sagen, es ist auch extrem fehleranfällig. Sie könnten sich fragen, ob sich der Aufwand lohnt, wenn es bereits bewährte Optionen gibt, aus denen Sie wählen können.

Ich überlasse Ihnen nur etwas, das Scott O’Hara – Mitherausgeber der ARIA in HTML und HTML AAM Spezifikationen und darüber hinaus super hilfsbereit bei allen Dingen rund um Zugänglichkeit – feststellt

Sie könnten die Arbeit investieren, um diese Erweiterungen hinzuzufügen, oder Sie könnten ein robustes Plugin wie a11y-dialog verwenden und sicherstellen, dass Ihre Dialoge eine ziemlich konsistente Erfahrung über alle Browser hinweg haben werden.

Zurück zu meinem Ziel…

Ich brauche, dass der Dialog Implementierungen für React, Vue, Svelte und Angular unterstützt.

Ich erwähnte bereits, dass a11y-dialog bereits Ports für Vue und React hat. Aber der Vue-Port wurde noch nicht für Vue 3 aktualisiert. Nun, ich war ziemlich glücklich, die Zeit, die ich für die Erstellung einer wahrscheinlich fehlerhaften, selbstgebauten Dialogkomponente aufgewendet hätte, stattdessen auf die Aktualisierung des Vue-Ports verwendet zu haben. Ich habe auch einen Svelte-Port und einen für Angular hinzugefügt. Diese sind beide sehr neu und ich würde sie zum Zeitpunkt der Abfassung als experimentelle Beta-Software betrachten. Feedback ist natürlich willkommen!

Es kann auch andere Komponenten unterstützen!

Ich denke, es ist erwähnenswert, dass ein Dialog das gleiche zugrunde liegende Konzept zum Aus- und Einblenden verwendet, das auch für eine Schubladenkomponente (auch Off-Canvas genannt) verwendet werden kann. Wenn wir zum Beispiel das CSS, das wir in unserer Dialog-Barrierefreiheitsprüfung verwendet haben, ausleihen und ein paar zusätzliche Klassen hinzufügen, kann a11y-dialog in eine funktionierende und effektive Schubladenkomponente umgewandelt werden.

.drawer-start { right: initial; }
.drawer-end { left: initial; }
.drawer-top { bottom: initial; }
.drawer-bottom { top: initial; }

.drawer-content {
  margin: initial;
  max-width: initial;
  width: 25rem;
  border-radius: initial;
}

.drawer-top .drawer-content,
.drawer-bottom .drawer-content {
  width: 100%;
}

Diese Klassen werden additiv verwendet und erweitern im Wesentlichen die Basis-Dialogkomponente. Das ist genau das, was ich getan habe, als ich meine eigene Schubladenkomponente zu AgnosticUI hinzugefügt habe. Zeitersparnis und Wiederverwendung von Code FTW!

Zusammenfassung

Hoffentlich habe ich Ihnen einen guten Einblick in den Denkprozess gegeben, der in die Erstellung und Wartung einer Komponentenbibliothek einfließt. Hätte ich meine eigene Dialogkomponente für die Bibliothek selbst entwickeln können? Absolut! Aber ich bezweifle, dass dies bessere Ergebnisse erzielt hätte als das, was eine Ressource wie Kitty's a11y-dialog bietet, und der Aufwand ist gewaltig. Es hat etwas Cooles, sich seine eigene Lösung auszudenken – und es mag gute Situationen geben, in denen Sie das tun möchten –, aber wahrscheinlich nicht auf Kosten der Opferung von etwas wie Barrierefreiheit.

Wie auch immer, so bin ich zu meiner Entscheidung gekommen. Ich habe unterwegs viel über das native HTML-<dialog>-Element und dessen Barrierefreiheit gelernt, und ich hoffe, meine Reise hat Ihnen auch einige dieser Erkenntnisse vermittelt.