Frage zum Wiki-Artikel „zugängliche_Dialog-Box“

[Knut]

Hallo zusammen,

das Beispiel wirft einen Fehler, weil lastFocus nicht definiert ist und DIV 2 mal definiert wird. Vorschlag: VOR function toggleDialog() einfügen:

var div = Object, lastFocus = Object;

Das DIV wird unten 2 mal angelegt. Beide VAR raus nehmen. Dann nach

if (!dialog.hasAttribute('open')) {...

Einfügen:

// save focus

lastFocus=document.activeElement;

Gruß, Knut

[Matthias Scharwies]

Hallo Knut!

das Beispiel wirft einen Fehler, weil lastFocus nicht definiert ist und DIV 2 mal definiert wird. Vorschlag:

Vielen Dank für die Meldung und für den Verbesserungsvorschlag!

VOR function toggleDialog() einfügen:

var div = Object, lastFocus = Object;

Das DIV wird unten 2 mal angelegt. Beide VAR raus nehmen. Dann nach

if (!dialog.hasAttribute('open')) {...

Einfügen:

// save focus

lastFocus=document.activeElement;

Gruß, Knut

Herzliche Grüße

Matthias Scharwies

[JürgenB]

Hallo Matthias,

hinter allen Beispielen steckt die gleiche Beispiel-Datei, ist das so gewollt? Sollte man nicht die Datei nicht nur über das Letzte Beispiel aufrufen können?

Gruß
Jürgen

[Matthias Scharwies]

Servus!

Hallo Matthias,

hinter allen Beispielen steckt die gleiche Beispiel-Datei, ist das so gewollt? Sollte man nicht die Datei nicht nur über das Letzte Beispiel aufrufen können?

Hatte ich lange so gemacht - irgendwann hatte jemand mal beim "Beispiel 1: HTML-Markup" die Funktion vermisst. Wie's hier ist, weiß ich gar nicht.

Ich habe leider keine Zeit, bzw. Geduld, mich zeitnah zu drum zu kümmern. Könntest Du ......? (bitte, bitte, bitte?)

(Ich hatte immer gehofft, dass Mozilla zwecks dialog-Element mal in die Hufe kommt und das Tutorial dann gar nicht mehr wichtig ist.)

Herzliche Grüße

Matthias Scharwies

[JürgenB]

Hallo Matthias,

ich habe das mal repariert. Vielleicht schaut noch mal jemand drüber.

Gruß
Jürgen

[Matthias Scharwies]

Servus!

Hallo Matthias,

ich habe das mal repariert. Vielleicht schaut noch mal jemand drüber.

Vielen, vielen Dank!

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Jürgen,

willst Du da nochmal verbessernd ran? Oder sollte man sich nicht etwas grundsätzlich besseres überlegen?

Derzeit funktioniert die ESC-Taste nicht, weil Du toggleDialog ohne Parameter aufrufst. Daraufhin geht die Zuweisung von eventTarget an lastFocus kaputt.

Die ESC Steuerung ist darüber hinaus ein Memory Leak, weil sie jedesmal einen neuen keydown-Handler installiert. Das ist ein Funktionsliteral, deswegen entsteht jedesmal ein neues Funktionsobjekt und eine neue Registrierung. Der ESC-Handler muss eine function außerhalb von toggleDialog sein, sonst bleibt er nicht konstant.

Die lastFocus-Steuerung ist ebenfalls dysfunktional. Wenn toggleDialog zum Schließen gerufen wird, dann wird lastFocus als erstes mal überschrieben. Und selbst wenn nicht - der lastFocus Wert, der beim Öffnen gespeichert wurde, ist beim Schließen eh nicht mehr verfügbar, weil keine Closure da ist, die ihn festhält.

Das geht so alles nicht. Ich bastele mal eine Alternative...

Rolf

[JürgenB]

Hallo Rolf,

gut, dass du drauf geschaut hast. Ich war froh, den groben Fehler mit lastFocus erst mal gefunden zu haben. Dann bin ich am backdrop hängen geblieben und habe leider nicht weiter getestet.

Gruß
Jürgen

[JürgenB]

Hallo Rolf,

ich habe noch einen Reparaturversuch gewagt. Wenn du noch mal …

Gruß
Jürgen

[Rolf B]

Hallo JürgenB,

okay, scheint nun zu funktionieren. Aber bist Du damit in dieser Form glücklich?

Rolf

[JürgenB]

Nein ☹️

Gruß
Jürgen

[Rolf B]

Hallo Jürgen,

magst Du Dir mal das hier anschauen:

https://jsfiddle.net/Rolf_b/qhtoedy8/

Ignoriere zuerst einmal die Initialisierung von DialogHandler in Zeile 4-103.

Alles, was man braucht, ist ein DialogHandler.register Aufruf für den Dialog. Das gelingt mit dialog-Elementen, und für mich, zum Testen unter Chrome, auch x-dialog Elemente.

Im Firefox verhalten sich dialog und x-dialog leicht unterschiedlich. Das liegt daran, dass dieser Lump das dialog-Element zwar nur dom.dialog_element.enabled Schalter unterstützt, aber trotzdem Browser-CSS dafür mitbringt und es styled.

Wenn Du meinst, dass dieser Ansatz hilfreich sein kann, bau ich weiter daran.

Der Handler ist auch für Browser nützlich, die das dialog-Element unterstützen (auch wenn das mit Spatzen auf Kanonen geschossen ist) - man kann einen Close-Button registrieren.

Rolf

[JürgenB]

Hallo Rolf,

ich habe einige Zeit gebraucht, um zu verstehen, was du da machst. Ich habe mich völlig in den vielen Abfragen verirrt.

Braucht man die alle? Hier soll doch keine idiotensichere Biblithek gebaut werden, sondern nur gezeigt werden, wie man so einen Dialog zugänglich und Browserübergreifend hin bekommt. Wer versucht, das Dialog-Script auf beliebige oder nicht vorhandene Elemente anzuwenden, bekommt die Fehlermeldung vom Browser. Ich finde, ein Test, ob dialog nativ unterstützt wird, sollte reichen.

Da würde ich eher eine Veknüpfung von Open-Button und Dialog einbauen, z.B. ober das fpr-Attribut:

<button for="okDialog">Ist dasOK?</button>
<dialog id="okDialog"> ...

Gruß
Jürgen

[JürgenB]

Hallo,

ich war gestern auch schon angefangen, das Script zu verbessern. Meine Minimalversion sieht jetzt so aus:

http://test.berkemeier.eu/selfwiki/Dialog/dialog.html

Gruß
Jürgen

[Rolf B]

Hallo JürgenB,

ich habe einige Zeit gebraucht, um zu verstehen, was du da machst. Ich habe mich völlig in den vielen Abfragen verirrt.

Sorry - ich hab's vermutlich mal wieder übertrieben. Das kann man sicherlich abstrippen. Die Frage war nur - was hältst Du von der Idee, mit einem solchen Wrapper ranzugehen, der das Handling von dialog-Elementen kapselt und automatisch erkennt, ob der Browser native Dialoge hat oder nicht.

Wie fängt man eigentlich ab, dass der User mit Tab aus dem Dialog rausrennt und "Dialog öffnen" nochmal auswählt? Man hat dann nämlich zwei Backdrops und wird einen davon nicht mehr los 😉

Aber wenn das alles einfach wäre, hätte Google keine 866 Zeilen daraus gemacht 😏

Rolf

[JürgenB]

Hallo Rolf,

… Die Frage war nur - was hältst Du von der Idee, mit einem solchen Wrapper ranzugehen, der das Handling von dialog-Elementen kapselt und automatisch erkennt, ob der Browser native Dialoge hat oder nicht.

Das finde ich gut. In meinem Entwurf und auch in der Wiki-Version ist das im Ansatz (Eventhandler für DOMContentLoaded) ja auch schon drin.

Wie fängt man eigentlich ab, dass der User mit Tab aus dem Dialog rausrennt und "Dialog öffnen" nochmal auswählt? Man hat dann nämlich zwei Backdrops und wird einen davon nicht mehr los 😉

In meinem Entwurf prüfe ich, ob der Dialog (nicht) offen ist. Gerade geupdatet.

Wenn man allerdings den Focus fangen möchte, wie es im Nativen Dialog der Fall ist, wird es „schwierig“.

Gruß
Jürgen

[Marc]

Hej zusammen,

leider ist ein zugänglicher Dialog nicht so einfach und auch auf die Browser-Hersteller kann man sich nicht verlassen (die Umsetzung von type="date" oder browsergenerierte Fehlermeldungen in Formularen sind beispielsweise bis heute nicht barrierefrei).

Unter anderem darf man aus dem Dialog mit der Tastatur nicht herauskommen…

Beispiel

• Demo "Barrierefreier Dialog"
• Github-Repo "Barrierefreier Dialog"

edit:

Wobei das "richtige" Fenster für Dialoge (per alert aufrufbar) ist meines Wissens vollständig barrierefrei, wenn man es sich einfach machen möchte.

Marc (marctrix)

[JürgenB]

Hallo Marc;

Beispiel

• Demo "Barrierefreier Dialog"
• Github-Repo "Barrierefreier Dialog"

fast 500 Zeilen Javascript, also nichts für ein Tutorial, und leider funktioniert die Demo im FF nicht. 😟

Gruß
Jürgen

[Marc]

Hej JürgenB,

Beispiel

• Demo "Barrierefreier Dialog"
• Github-Repo "Barrierefreier Dialog"

fast 500 Zeilen Javascript, also nichts für ein Tutorial,

Mir ging es darum, dass unser Wiki-Beispiel nicht zugänglich ist.

Vielleicht einfach das "zugänglich" entfernen.

und leider funktioniert die Demo im FF nicht.

Bei mir gehts FF 86 unter Big Sur…

Marc (marctrix)

[JürgenB]

Hallo Marc,

Rolf und ich beschäftigen uns mit dem Artikel. Was meinst du, ist das so zugänglich(er)? Leider funktioniert die Focusfalle beim nativen Dialog (Chrome) nicht.

Gruß
Jürgen

[JürgenB]

Hallo,

ich habe mich noch etwas mit dem Thema beschäftigt und in meinen einfachen Entwurf auch die Tastaturbedienbarkeit und einen einfachen Focus-Trap eingebaut. „Leider“ habe ich in allen mir zur Verfügung stehenden Browsern getestet.

Beim Safari komme ich nicht weiter. Bei Mausklicks funktioniert es so, wie vorgesehen, bei Tastaturbedienung aber nicht. Der Focus wird nach dem Öffnen des Dialogfensters nur manchmal auf den Close-Button gesetzt, aber eben nicht immer. Der Focus-Befehl wird am gewünschten Element ausgeführt, es kommt keine Fehler Meldung, der Focus bleibt aber am Open-Button. Kann sich bitte das mal jemand ansehen?

Hier der Link zur aktuellen Version.

Gruß
Jürgen

[Marc]

Hej JürgenB,

Beim Safari komme ich nicht weiter. Bei Mausklicks funktioniert es so, wie vorgesehen, bei Tastaturbedienung aber nicht.

Hier der Link zur aktuellen Version.

Bei mir klappt es (MacOS BigSur 11.2.2)

Marc (marctrix)

[JürgenB]

Hallo Marc,

Beim Safari komme ich nicht weiter. Bei Mausklicks funktioniert es so, wie vorgesehen, bei Tastaturbedienung aber nicht.

Hier der Link zur aktuellen Version.

Bei mir klappt es (MacOS BigSur 11.2.2)

das ist irgendwie verrückt. Vielleicht ist mein MacBook Air von 2015 zu langsam? Ich habe mal versuchsweise den Fokus auf den Closebutton mit setTimeout gesetzt (noch nicht online), dann klappt es auch bei mir zuverlässig. 😕

Was hältst du von der Zugänglichkeit?

Gruß
Jürgen

[Marc]

Hej JürgenB,

Beim Safari komme ich nicht weiter. Bei Mausklicks funktioniert es so, wie vorgesehen, bei Tastaturbedienung aber nicht.

Hier der Link zur aktuellen Version.

Bei mir klappt es (MacOS BigSur 11.2.2)

das ist irgendwie verrückt.

Nein, ich bin es wohl. ich habe nicht genau genug gelesen. Bei mir bleibt der Focus auch auf dem "Öffnen"-Button.

Das ist aber in Ordnung, so lange man mit dem nächsten Tab im Dialog landet (das ist bei mir der Fall).

Auch mit dem Screenreader landet man mit jeder vorwärts führenden Geste (zur nächsten Überschrift, zum nächsten Element) im Dialog.

Was hältst du von der Zugänglichkeit?

Was mich etwas irritiert: warum zuerst auf den "Schließen"-Button - in meine Logik wäre das das letzte anzuspringende Element, wenn man durch alle Inhalte des Dialogs durch ist. Eigentlich braucht man den ja nicht. In der Regel sollte der Dialog verschwinden, sobald man ein enthaltenes Form abschickt o.ä.

Wenn der Dialog nur einen Hinweis enthält, soll man den ja auch lesen, bevor man den Dialog wieder schließt. Also insofern würde ich den "Schließen"-Button ans Ende des Dialogs setzen.

Aber das ist jetzt auch nichts, womit man durch den Test fallen würde.

Ansonsten fühlt es sich für mich mit Safari und VoiceOver gut an!

Zumindest was den Fokus-Aspekt angeht. Ansonsten gibt es natürlich noch Arbeit. So passen die Inhalte beispielsweise nicht auf schmale Bildschirme (320px) und der Schließen-Button wäre, wenn er wie üblich als "x" dargestellt würde auch nicht mehr im Viewport (egal ob oben links oder oben rechts) - man kann nicht mal mit dem Scrollbalken an den zum linken Rand der Box scrollen.

Ich bin jetzt aber nicht alle 92-Prüfschritte des BITV-Tests durchgegangen…

Wollte eigentlich mal ein Video machen, bin aber noch gar nicht mit der Arbeit fertig und kann das daher jetzt nicht bis in jedes Detail testen - das ist auch der Grund, warum ich eigentlich gegen solche Lösungen bin. Ich nehme lieber Lösungen, die ich im netz finde und melde gefundene Bugs, damit alle was davon haben. Mit der Zeit haben solche Lösungen dann so viel Feedback und Tests hinter sich, dass man das mit vertretbaren Aufwand nicht annähernd so gut machen kann.

Hier geht es ja darum möglichst kompakt etwas beizubringen. Man kann nicht in jedem Tutorial alle 92 Prüfschritte berücksichtigen und erklären, womit man welchen Prüfschritt erfüllt - sonst wird das kein Tutorial, sondern ein Buch.

Daher noch mal mein Vorschlag: bezeichne es einfach nicht als barrierefreien Dialog, mach das Tutorial einfach, konzentriere dich auf das, was du beibringen möchtest. Der a11y-Dialog hat sicher nicht umsonst 500 Zeilen…

Marc (marctrix)

[JürgenB]

Hallo Marc

danke für's Feetback.

Nein, ich bin es wohl. ich habe nicht genau genug gelesen. Bei mir bleibt der Focus auch auf dem "Öffnen"-Button.

Wenn da keiner mehr eine Idee hat, werde ich den Fokus über setTimeout verzögert setzen, so geht es.

Das ist aber in Ordnung, so lange man mit dem nächsten Tab im Dialog landet (das ist bei mir der Fall).

Das ist so, weil der Dialog hinter dem Open-Button steht.

Auch mit dem Screenreader landet man mit jeder vorwärts führenden Geste (zur nächsten Überschrift, zum nächsten Element) im Dialog.

Was hältst du von der Zugänglichkeit?

Was mich etwas irritiert: warum zuerst auf den "Schließen"-Button - in meine Logik wäre das das letzte anzuspringende Element, wenn man durch alle Inhalte des Dialogs durch ist. Eigentlich braucht man den ja nicht. In der Regel sollte der Dialog verschwinden, sobald man ein enthaltenes Form abschickt o.ä.

Wenn der Dialog nur einen Hinweis enthält, soll man den ja auch lesen, bevor man den Dialog wieder schließt. Also insofern würde ich den "Schließen"-Button ans Ende des Dialogs setzen.

Meine jetzige Version setzt den Fokus auf das erste fokussierbare Element. Ich habe den Close-Button mal ans Ende gesetzt

Aber das ist jetzt auch nichts, womit man durch den Test fallen würde.

Ansonsten fühlt es sich für mich mit Safari und VoiceOver gut an!

😀

Zumindest was den Fokus-Aspekt angeht. Ansonsten gibt es natürlich noch Arbeit. So passen die Inhalte beispielsweise nicht auf schmale Bildschirme (320px) und der Schließen-Button wäre, wenn er wie üblich als "x" dargestellt würde auch nicht mehr im Viewport (egal ob oben links oder oben rechts) - man kann nicht mal mit dem Scrollbalken an den zum linken Rand der Box scrollen.

Das war einfoch noch nicht drin. Ein width: min(30em,80vw); sollte das Problem lösen.

Ich bin jetzt aber nicht alle 92-Prüfschritte des BITV-Tests durchgegangen…

Wollte eigentlich mal ein Video machen, bin aber noch gar nicht mit der Arbeit fertig und kann das daher jetzt nicht bis in jedes Detail testen - das ist auch der Grund, warum ich eigentlich gegen solche Lösungen bin. Ich nehme lieber Lösungen, die ich im netz finde und melde gefundene Bugs, damit alle was davon haben. Mit der Zeit haben solche Lösungen dann so viel Feedback und Tests hinter sich, dass man das mit vertretbaren Aufwand nicht annähernd so gut machen kann.

Hier geht es ja darum möglichst kompakt etwas beizubringen. Man kann nicht in jedem Tutorial alle 92 Prüfschritte berücksichtigen und erklären, womit man welchen Prüfschritt erfüllt - sonst wird das kein Tutorial, sondern ein Buch.

Daher noch mal mein Vorschlag: bezeichne es einfach nicht als barrierefreien Dialog, mach das Tutorial einfach, konzentriere dich auf das, was du beibringen möchtest. Der a11y-Dialog hat sicher nicht umsonst 500 Zeilen…

Ich glaube, so weit sind wir von einer zugänglichen Lösung nicht entfernt.

✔︎ Leveraging the native <dialog> element if desired

Ich nutze es, wenn vom Browser unterstützt.

✔︎ Closing dialog on overlay click and ESC
✔︎ Toggling aria-* attributes
✔︎ Trapping and restoring focus

Haben wir auch drin.

✔︎ Firing events
✔︎ DOM and JS APIs

Fehlt und geht für das Tutorial zu weit. Es soll kein vollständiger Polyfill sein.

✔︎ Fast and tiny

Kein Problem.

Aber ich hänge nicht am „barrierefreien“ im Titel.

Gruß
Jürgen

[Marc]

Hej JürgenB,

danke für's Feetback.

Gern

Nein, ich bin es wohl. ich habe nicht genau genug gelesen. Bei mir bleibt der Focus auch auf dem "Öffnen"-Button.

Wenn da keiner mehr eine Idee hat, werde ich den Fokus über setTimeout verzögert setzen, so geht es.

Ich glaube, so weit sind wir von einer zugänglichen Lösung nicht entfernt.

✔︎ Leveraging the native <dialog> element if desired

Ich nutze es, wenn vom Browser unterstützt.

✔︎ Closing dialog on overlay click and ESC
✔︎ Toggling aria-* attributes
✔︎ Trapping and restoring focus

Haben wir auch drin.

✔︎ Firing events
✔︎ DOM and JS APIs

Fehlt und geht für das Tutorial zu weit. Es soll kein vollständiger Polyfill sein.

✔︎ Fast and tiny

Kein Problem.

Aber ich hänge nicht am „barrierefreien“ im Titel.

WOW - dann bist du aber schon nah dran. Gut gemacht. Ich will ihn dir auch nicht ausreden natürlich. Es war nur ein Vorschlag, dich ggfs auf etwas anderes zu konzentrieren im Tutorial und das kurz zu halten.

Was. Ihr noch fehlt ist ein Hinweis darauf, was passiert, wenn man auf den Button drückt, bevor man ihn drückt.

Getestet habe ich übrigens Dialog 2, habe ich vergessen zu erwähnen.

Marc (marctrix)

[JürgenB]

Hallo Marc,

Was. Ihr noch fehlt ist ein Hinweis darauf, was passiert, wenn man auf den Button drückt, bevor man ihn drückt.

was meinst du damit?

Gruß
Jürgen

[Marc]

Hej JürgenB,

Was. Ihr noch fehlt ist ein Hinweis darauf, was passiert, wenn man auf den Button drückt, bevor man ihn drückt.

was meinst du damit?

Ja, war schon spät, ist hier im Beispiel irrelevant. Irgendwie fand ich es noch nicht eindeutig, dass man weiß, was passiert, wenn man den Button drückt, bevor man ihn drückt. Ist aber eher eine redaktionelle Sache, als eine technische.

Marc (marctrix)

[JürgenB]

Hallo,

ich habe an meiner Version noch weiter gebastelt. „Eigentlich“ sollte es jetzt funktionieren. Könnt ihr das bitte mal testen? Unter Linux und Android konnte ich mangels Gerät nicht testen, hier wäre es besonders wichtig.

@Rolf B Kannst du dir den Quelltext auch mal ansehen, ob das so Tutorialtauglich ist. Wahrscheinlich müssen da noch mehr Kommentare rein.

Wie sollen wir weitermachen? Willst du die Ideen in deine Version übernehmen?

Hier gehts zur aktuellen Version.

Gruß
Jürgen

[Der Martin]

Hallo Jürgen,

Hier gehts zur aktuellen Version.

die zweite Box hat ein input-Feld und lässt daher vermuten, dass sie eine Benutzereingabe abfragen möchte. Dafür würden ihr aber die üblichen Buttons für [OK] und [Cancel] gut tun - wobei das Drücken der Enter-Taste natürlich mit [OK] korrelieren sollte.

Ansonsten gefällt mir die Lösung schon sehr gut, sie fühlt sich "richtig" an.
Firefox 86 und Pale Moon 29.1 unter Linux Mint 18.2, MATE-Desktop.

Live long and pros healthy,
 Martin

[JürgenB]

Hallo Martin,

Hier gehts zur aktuellen Version.

die zweite Box hat ein input-Feld und lässt daher vermuten, dass sie eine Benutzereingabe abfragen möchte. Dafür würden ihr aber die üblichen Buttons für [OK] und [Cancel] gut tun - wobei das Drücken der Enter-Taste natürlich mit [OK] korrelieren sollte.

das Input-Feld hat die Aufgabe, ein weiteres fokussierbares Element in den Dialog zu legen, damit das Setzen des Fokus beim Öffnen und die Fokusfalle getestet werden können.

Ansonsten gefällt mir die Lösung schon sehr gut, sie fühlt sich "richtig" an.
Firefox 86 und Pale Moon 29.1 unter Linux Mint 18.2, MATE-Desktop.

Danke fürs Testen.

Gruß
Jürgen

[Rolf B]

Hallo Jürgen,

ich war jetzt ein paar Tage nicht mehr am Thema dran. Und ich wollte Dir auch nicht mit einem Parallelentwurf hineingrätschen. Wir machen hier ja keinen "wer kann's besser" Wettbewerb.

Aber es gilt hier, denke ich, eine Grundsatzentscheidung zu treffen. Tutorial hin oder her, etwas Architektur sollte auch vermittelt werden. Und da bin ich mit deinem Ansatz unzufrieden. Du trennst nämlich nicht - so wie die nativen Dialoge - zwischen Dialog-Anzeige und dem Dialog-Trigger. Du hast eine Logik designed, die das Öffnen eines Dialogs über data-for an genau einen Button koppelt. Einen Dialog ohne data-for Button behandelst Du nicht einmal. Das ist kein Pattern, das man als Vorlage geben sollte. Meine ich - andere mögen das anders sehen.

Meine Lösung, die ich im Fiddle angefangen hatte, sah vor, in Browsern ohne native Dialogunterstützung einen Polyfill zu bieten, der am Dialog-Element die dokumentierten Funktionen show, showModal und close bereitstellt und auf ESC reagiert, und für alle Browser die Unterstützung des Close-Buttons hinzuzufügen (die ESC Taste wird nativ eh unterstützt. Das Öffnen des Dialogs war außen vor, ganz bewusst, es mag ja ganz andere Gründe geben, einen Dialog anzuzeigen, als einen extra dafür bereitgestellten Button. Zum Beispiel ein Submit-Button, der einen Dialog zur Bestätigung aufpoppt.

Die Frage ist also: Entfernt man sich für ein Tutorial vom dokumentierten Dialog-API oder nicht?

Rolf

[JürgenB]

Hallo Rolf,

ich habe mich eigentlich nur um das Funktionieren gekümmert, und da speziell um die Fokus-Behandlung, also Fokus beim Öffnen, Schließen und Fokusfalle. Ansonsten kann der Quelltext meine Wurzeln in der C/Fortranwelt nicht überdecken.

Im Tutorial muss als ersten festgelegt werden, ob wir einen vollständigen Polyfill anbieten, oder nur ein Script, mit dem Dialoge über einen Button geöffnet und einen weiteren geschossen werden.

Aber unabhängig davon ist eine moderne Architektur schon gut, aber da musst du dann dran. Da lerne ich lieber bei dir, helfe aber natürlich beim Testen. Meine Version kann da als Ideenlieferant dienen.

Gruß
Jürgen

[Rolf B]

Hallo JürgenB,

um auf deine Äußerung in Gerrits Thread zurückzukommen: Wie sinnvoll ist es, den Polyfill vom Thema "zugänglich" zu trennen? D.h. einfach ein funktionierendes <dialog> Element vorauszusetzen und zu zeigen, wie man einen on-demand Polyfill hinzufügt?

Rolf

[JürgenB]

Hallo Rolf,

um auf deine Äußerung in Gerrits Thread zurückzukommen: Wie sinnvoll ist es, den Polyfill vom Thema "zugänglich" zu trennen? D.h. einfach ein funktionierendes <dialog> Element vorauszusetzen und zu zeigen, wie man einen on-demand Polyfill hinzufügt?

leider verhält sich das native dialog-Element beim Focus-Trap nicht so, wie ich es gelesen habe und auch erwarte. Beim Verlassen des Dialogs landet der Fokus zwar nicht im Dokument, aber außerhalb des Browserfensters. Hier muss man überlegen, was man möchte. Und ich habe jetzt nicht geprüft, ob das aria-hidden gesetzt wird.

Ein echter Polyfill für dialog ist zu kompliziert. Man muss sich ja nicht nur um den Fokus und den Hintergrund kümmern. Man muss ja auch auf die close und open-Events reagieren. Ein dialog kann ja auch per Javascript geöffnet und geschlossen werden. Da landet man sofort bei Custom-Events und MutationsObserver. Obwohl, das könnte auch eine interessante Anwendung dafür sein. Aber hier auf eine schon vorhandene Lösung zurückzugreifen wäre auch OK,

Einen einfachen Polyfill, der auf Öffnen und Schließen durch die button reagiert, den Fokus vernünftig behandelt und den Backdrop anlegt, sollte aber fürs Wiki reichen. Und an diesem kann man auch zeigen, wie Scripte on-demand nachgeladen werden können. Denn leider arbeiten viele Polyfills so, dass sie immer geladen werden, und erst dann entscheiden, ob sie überhaupt gebraucht werden.

Gruß
Jürgen

[Rolf B]

Hallo JürgenB,

ich würde auf einen fertigen Polyfill aus reputabler Quelle verweisen, wie den hier. Der verwendet übrigens eine register-Methode, so wie ich. Und ich hab da nicht abgeguckt 😂

if (!window.HTMLDialogElement) {
   // dialog-polyfill.css hinzufügen
   // dialog-polyfill.js hinzufügen (manuell, AMD)
   // ODER dialog-polyfill.esm.js hinzufügen (ES6-import)
}

Und dann kann man sich - unbehindert durch Fragen zum Polyfill an sich - um Dinge kümmern wie Focus-restore oder Button-Steuerung. Beim Google-Polyfill schreiben sie zu dem Thema:

Focus
The WAI-ARIA doc suggests returning focus to the previously focused element after a modal dialog is closed. However, this is not part of the dialog spec itself. See this snippet to add this, even to the native dialog.

Nicht jedes Rad ist so eckig, dass man es neu erfinden muss 😉

Im Firefox klappt die Fokussierung eines Dialog-Buttons übrigens prima, der Fokus wird vom Firefox angezeigt.

In Chrome wird der Button durchaus fokussiert, der richtige Button reagiert auf ENTER, aber er zeigt es, solange keine :focus CSS Regel existiert, einfach nicht an! Man muss einmal Tab drücken, dann erst erscheint der Fokus-Rand am Button. Da hilft auch kein setTimeout, sehr merkwürdig. Das ätzende ist, dass man einen fokussierten Button per CSS nicht so stylen kann wie Chrome das ab Werk tut.

Buttons in einem Dialog kann man übrigens viel einfacher handeln als mit einer click-Handler Registrierung: Man setzt ein <form method="dialog"> in den Dialog. Klickt man einen Button, wird sein value zum returnValue des Dialogs. Brrr - wieso sagt einem das keiner?

Nachdem ich das entdeckt habe, habe ich mein eigenes Buttonhandling gleich wieder rausgeschmissen.

Guck mal hierhin: http://dialog-test.borchmann.one/dialog-test.html. Einfach nur mal als alternative Möglichkeit.

Guck erstmal nur in die dialog-test.html, das ist das, was ein Anwender programmieren und designen würde. Das Öffnen der Dialoge und das Handhaben des Rückgabewertes ist dort implementiert - stupide, für eine Testshell.

Spezialitäten meines DialogHandlers:

• show/showModal geben ein Promise zurück. Man muss keinen close-Eventhandler registrieren, man hängt sich einfach mit .then an show()/showModal() an.
• wer ganz modern ist, baut eine async function und verwendet await, statt mit .then einen Callback zu registrieren. Boah ey 😂. Ist aber nur Syntaxzucker für Promises und .then().
• ich unterstütze ein paar data-Attribute am Dialog:
  • data-default: Der value des Buttons, der zu Beginn fokussiert sein soll.
  • data-cancel: Der returnValue, der bei ESC gesetzt werden soll

Buttons im Dialog unterstütze ich nur über ein <form method="dialog">. Der Google-Polyfill für Dialoge unterstützt das. Fertig.

Danach kannst Du dialog-handler.js anschauen, das ist mein Code. Er lädt bei Bedarf den Dialog-Polyfill von Google nach. DER ist riesig, macht eine Menge, aber das ist eine Blackbox.

Es sind ECMAScript-Module, deswegen läuft nichts mit IE - es ist die Frage, ob man das für das Wiki haben sollte.

Alles in allem auch nur noch 80 Zeilen, mit Leerzeilen drin und dem dynamischen Laden des Google-Polyfills. Was hältst Du von diesem Ansatz?

Rolf

[JürgenB]

Hallo Rolf,

das sieht schon richtig gut aus. Du hast zwar für die modernen Methoden den IE geopfert, aber dafür haben wir nicht nur einen funktionierenden Dialog, sondern auch noch ein Beispiele für Promise, für class, für import/export und für Script und css on demand.

Die Fukusbehandlung gefällt mir noch nicht.

Safari: Bei Shift-Tab bleibt der Fokus im Dialog, aber bei Tab läuft er vom Dialog durch die fokussierbaren Bereiche des Browsers und kehrt dann in den Dialog zurück. So kommt auf ESC auch nicht immer eine Reaktion.

MacOS FF: ESC funktioniert, Rückwärts-Tab auch, aber bei Vorwärts-Tab ist der Fokus beim Verlasen ganz weg.

Gruß
Jürgen

[Rolf B]

Hallo JürgenB,

Du hast zwar für die modernen Methoden den IE geopfert

das ist nicht zwingend notwendig. Man kann auf die Modularisierung verzichten oder ein allgemeines UMD-Pattern als Modulkapsel verwenden. Diese Patterns sind auch IE geeignet. Es ist nur dumm, dass es kein Pattern zu geben scheint, dass alle Varianten unterstützt:

• globale Variable
• AMD-Kompatibel (define/require)
• ES6-Kompatibel (exports)

Denn bisher finde ich bei Libraries immer zwei Versionen: eine für ES6, und eine für AMD und globale Variablen.

Es gibt wohl auch Tools, die aus gemeinsamem .js Quellcode die ES6 und die AMD-Version generieren. Aber das wird für's Wiki zu komplex.

Die Fukusbehandlung gefällt mir noch nicht.

Mir auch nicht, aber da habe ich bisher die Kontrolle dem Google-Polyfill überlassen. Da muss man wohl nochmal drüber brüten. Deine Lösung ist ja eigentlich zu restriktiv, man kann nicht aus der Seite hinaus in die Browser-Controls tabben.

Rolf

[JürgenB]

Hallo Rolf,

ich finde die Vorteile überwiegen. Im Tutorial sind Beispiele für Promise, class, import/export und css/js on demand. Da darf man den IE ruhig verprellen. Evtl. sollte man eine Meldung einbauen.

Die Fukusbehandlung gefällt mir noch nicht.

Mir auch nicht, aber da habe ich bisher die Kontrolle dem Google-Polyfill überlassen. Da muss man wohl nochmal drüber brüten. Deine Lösung ist ja eigentlich zu restriktiv, man kann nicht aus der Seite hinaus in die Browser-Controls tabben.

Ich habe irgendwo gelesen, dass der Fokus ein modales Fenster nicht verlassen kann, außer mit F5/cmd-r etc.

Gruß
Jürgen

[Rolf B]

Hallo JürgenB,

Ich habe irgendwo gelesen, dass der Fokus ein modales Fenster nicht verlassen kann, außer mit F5/cmd-r etc.

Die eingebauten Dialoge von Chrome tun das nicht. Ich tabbe aus einem modalen Dialog geradewegs in den Browserrahmen hinein. Das Google Polyfill überwacht lediglich das Tabbing, wenn ich den Code richtig lese, und ruft .blur() auf, wenn der Fokus den Dialog verlässt. Ich sehe aber in der Spec nichts, was das Verhalten von Tab im Dialog vorschreibt. Oder ich verstehe das Geschwurbel der Spec mal wieder nicht 😕

Ich habe jetzt in der Spec auch noch gelesen, dass ein Dialog das autofocus-Attribut beachtet, wenn showModal verwendet wird. Aber es steht nur dort dabei! Chrome beachtet das autofocus-Attribut aber auch, wenn show statt showModal verwendet wird. Heißt für mich eigentlich: Mein data-default Konzept ist falsch, ich muss autofocus verwenden. Und für den Default-Button eines Forms bin ich auf die HTML-Standards angewiesen: Der Default-Button ist der in Tree-Order erste im Form. Wenn man möchte, dass der dritte Button der Default-Button ist, muss man tricksen und überrascht den User, weil man keine Möglichkeit hat, das - analog zu Windows - visuell anzuzeigen. Windows kann den Default-Button hervorheben und den Fokus dennoch auf das erste Eingabefeld setzen.

Ein Stackoverflow-Artikel meint, dass man auf diese Weise den Default-Button manipulieren könne. Klappt für die Tastatur perfekt, aber wie ist die Bedienbarkeit mit Assistenztechnik? Keine Ahnung ob das zulässig ist.

<form method="dialog">
...
<button hidden value="ok"></button>
<button value="cancel">Abbrechen</button>
<button value="ok">Ok</button>
</form>

Rolf