Installation Progress - der beste Weg?
Fortschrittsanzeigen bei der Installation von Software kennt jeder. Sie sind eine schöne visuelle Lösung, um die Benutzer:innen über den aktuellen Stand eines Prozesses zu informieren. Und in unserem Falle ein sehr gutes Beispiel dafür warum HTML manchmal komplizierter ist, als man denkt.
Progressbars vertreiben uns die Zeit und informieren darüber:
- wie lange ein Prozess insgesamt dauern wird
- wie der aktuelle Status ist
- wie lange es noch dauern wird bis der Prozess zu Ende ist
- und sollten stoppen, wenn es zu einem Fehler kommt
In unserem Beispiel geht es um Teile der Joomla!-Installation. Die Benutzer:innen sollen darüber informiert werden, welche Schritte gerade abgearbeitet werden. Wird die Installation unterbrochen, meldet das System was schief gelaufen ist. Diese Information ist für die spätere Fehlerbehebung besonders wichtig.
Lösung Teil 1: Bootstrap
Den Fortschrittsbalken visuell auf dem Bildschirm - mit Hilfe des Bootsstrap 5 Frameworks - anzuzeigen ist gar kein Problem. Bootstrap setzt hier nicht auf das native progress-Element, sondern verwendet stattdessen ein div-Element mit entsprechenden Aria-Attributen.
Der eigentliche Installations-Prozess - mit seinen einzelnen Schritten - wird unterhalb der Progressbar, als Liste dargestellt. Wobei die Listenelemente nach und nach eingeblendet und nach mit einem grünen Haken versehen werden.
Aber wo ist nun das Problem?
Falsche Annahme:
Menschen, die sich unsere Installation auditiv erschließen, sollen exakt die selben Informationen erhalten wie sehende Menschen.
Während die Installation läuft kann ich, als sehende Person, auf den Fortschrittsbalken, den Text darunter oder aus dem Fenster schauen.
Screenreadernutzer können das nicht. Nicht Hinhören ist schwierig. Zudem kann nur der Status der Progressbar oder der darunter stehende Text in der Liste erfasst werden. Der Fokus liegt immer nur auf einem Element. Im Sinne der Zugänglichkeit kann das nicht richtig sein, dachten wir.... und haben angefangen das ganze zu Verschlimmbessern.
Wir haben den vollständigen Inhalt der Statusmeldungen mit dem Fortschrittsbalken ausgegeben. Das hat dazu geführt, dass die Screenreader sich verschluckt haben. Der Installationsprozess war einfach zu kurz, als dass die Statusmeldungen hätten richtig ausgesprochen werden können.
Also haben wir unsere Meldungen textlich gekürzt , Step 1 , Step 2, Step 3 ... und eine Zeitverzögerung in unserem Script eingebaut.
Den darunter stehenden Text haben wir diese Kürzungen vorangestellt damit die Zuordnungen nachvollzogen werden können. So nach dem Motto Step 1 ist die Datenbank usw. Aria-describedby stellt die Beziehung zur Überschrift her.
<h2 id="loadinglabel">Installation:</h2>
<div class="progress">
<div id="progress-bar" aria-describedby="loadinglabel" class="progress-bar progress-bar-striped progress-bar-animated" role="progressbar" aria-valuenow="0" aria-valuemin="0" aria-valuemax="100" style="width: 0%;"></div>
<p id="progress-status" role="status"> Step 1 </p>
</div>SCRIPT:
....
for (let i = 0; i < messages.length; i++) {
setTimeout(function () {
document.getElementById('progress-status').innerText = "Step" + (i + 1) + " of " + messages.length;
progress.setAttribute('aria-valuenow', Math.round(100/messages.length * (i + 1 )));
progress.style.width= Math.round(100/messages.length * (i + 1 )) + '%';
if(i == messages.length -1)
{document.getElementById('progress-status').innerText= 'Installation finished ' ;}
}, 3000 * i)}
...http://der-auftritt.de/tests/bootstrapsteps.html
Screenreadertests:
Das Ergebnis war schon mal gar nicht so schlecht.
Narrator and NVDA Firefox
Ignorieren die Ausgabe der Progressbar und verhalten sich folgendermaßen:
- Step 1 of 5
- Step 2 of 5
- Step 3 of 5
- Step 4 of 5
- Installation finished
Jaws auf Chrome und Firefox
Scheint die Ausgabe der Progresbar nur alle 10 Sekunden auszugeben, ansonsten verhält er sich wie oben beschrieben.
- Step 1 of 5 20
- Step 2 of 5
- Step 3 of 5 60
- Step 4 of 5
- Installation finished
Lösung Teil 2 : natives progress-Element
Solange natives HTML Lösungen anbietet sind diese dem Einsatz von ARIA vorzuziehen. Native Technologien sind weit aus robuster. Die Browserunterstützung des Progress-Elements ist mittlerweile ganz gut. Auch die Gestaltung lässt sich mit Hilfe von Vendor-Prefixes im CSS gut anpassen. Das Progess-Element und die Status-Meldung wurden in ein label gepackt und so sinnvoll gruppiert.
Nach Gesprächen mit Screenreader-Nutzer:innen kristallisierte sich für mich eine sehr große Überraschung heraus. Den meisten war es völlig egal, was bei der Installation gerade geschieht.
Die Information, dass
- die Installation läuft,
- abgeschlossen ist
- oder gerade einen Fehler rausschmeißt
reicht ihnen völlig.
Aus diesen Grunde haben wir die Status-Meldungen textlich angepasst und auf diese wesentlichen Informationen reduziert.
Testcase https://der-auftritt.de/tests/final.htm
Screenreadertests:
NVDA und Narrator
Erzeugt eine beep bei jeden Schrritt und spricht:
- Installation running
- Installation running
- Installation running
- Installation running
- Installation finished
Jaws
meldet sich nur alle 10 Sekunden zu Wort
- Installation running
- Installation finished
Fazit: Weniger ist mehr
Es scheint fast egal welche technische Variante wir verwenden, viel wichtiger sind die inhaltlichen Aussagen, die getroffen werden.
Status und Fehlermeldungen müssen kurz aber dennoch aussagekräftig sein.
Sowohl der native Testcase https://der-auftritt.de/tests/final.htm als auch die textlich angepasste Bootstap-Variante https://der-auftritt.de/tests/bootstrap.html scheinen Ihren Dienst zu tun. Ich persönlich würde die native Variante bevorzugen, weil mir der Code deutlich sauberer erscheint und ich annehme, dass die Performace deutlich besser ist.
Notizen:
Gelernt habe ich, dass man im NVDA die Progressbar mit U aktivieren muss, Jaws den Status der Progressbar nur alle 10 Sekunden ausgibt. Aria-label echt gefährlich ist und manchmal sogar beißt. Aria-describedby immer besser ist. Und wie immer: Weniger mehr ist!