Zugängliche_Dialog-Box - Problem im Safari

[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)