Das <progress>-Element  

Die Darstellung einer Fortschrittsentwicklung verhält sich wie eine Live-Region

Fortschrittsbalken

Das <progress>-Element ist nützlich, um den Fortschritt eines Prozesses darzustellen. Das Element wird üblicherweise als Fortschrittsbalken dargestellt. Das Element ist nach der ARIA-Spezifikation zwar eine Dokumentenstruktur, aber es verhält sich ebenso wie eine Statuszeile. Die sich verändernden Werte des Fortschrittsbalkens sollen in regelmäßigen Abständen von Browsern an Assistenztechnologien weitergeleitet werden.

Vor Kurzem hat Angie Radtke auf Twitter dazu aufgerufen, bei der Verbesserung der Barrierefreiheit von Fortschrittsbalken in Joomla zu unterstützen.

Das war Grund genug, das Verhalten des <progress>-Elements mit verschiedenen Browsern und Screenreadern anzuschauen. Das Ergebnis in verschiedenen Browser-Screenreader-Kombinationen war unterschiedlich. Die Testseite ist am Ende dieses Beitrags verlinkt.

Das <progress>-Element hat die Rolle „progressbar“, erbt nach der ARIA-Spezifikation aber auch die Eigenschaften einer Live-Region (role=“status“). Obwohl das Element in der HTML-Spezifikation als Formularelement kategorisiert wird, ist eine Interaktion der NutzerInnen mit dem Element nicht vorgesehen.

Eine Live-Region ist ein Bereich einer Webseite mit (meist) sich verändernden Inhalten. Normalerweise teilt der Browser Assistenztechnologien mit, welche Änderungen in der Live-Region stattgefunden haben. Bei einem <progress>-Element soll der veränderte Wert des value-Attributs Assistenztechnologien übermittelt werden.

Ein Fortschrittsbalken kann mit ARIA durch die korrekte Zuweisung von Rollen und sonstigen ARIA-Attributen zusammengebaut werden, aber ARIA ist für ein Fortschrittsbalken eigentlich überhaupt nicht notwendig. HTML bietet alles, was für die Barrierefreiheit eines Fortschrittsbalkens notwendig ist. Browser unterstützen die Barrierefreiheit, indem Sie Rolle und andere Attribute korrekt an Assistenztechnologien weiterleiten.

Was braucht ein <progress>-Element?

Es sind zwei Attribute für das <progress>-Element definiert. Der Wert eines <progress>-Elements wird durch das value-Attribut bestimmt. Das value-Attribut muss ein Wert zwischen 0 und 1 sein oder, wenn das max-Attribut gesetzt ist, ein Wert zwischen 0 und dem Wert des max-Attributs. Der Zustand eines <progress>-Elements ist unbestimmt (indeterminate), wenn das value-Attribut fehlt.

Die Anzeige einer Fortschrittsentwicklung benötigt außerdem einen „accessible name“, vorzugsweise bestimmt durch eine Beschriftung, die mit dem <label>-Element mit dem <progress>-Element verknüft wird:

<h2>Fortschritt einer Aufgabe</h2>
<p><label>Skripte werden verarbeitet: <progress id="foo" value="0" max="100"><span>0</span>%</progress></label></p>

Die HTML-Spezifikation empfiehlt, den Wert der Anzeige auch als Text innerhalb des <progress>-Elements zu berücksichtigen, damit alte Browser, die das <progress>-Element nicht unterstützen, die Fortschrittsentwicklung anzeigen können.

Das value-Attribut des <progress>-Elements muss dynamisch geändert werden:

<script>
var progressBar = document.getElementById(‚foo‘);
function updateProgress(newValue) {
progressBar.value = newValue;
progressBar.getElementsByTagName(’span‘)[0].textContent = newValue;
}
</script>

Die Methode muss durch Code auf der Webseite aufgerufen werden während die Aufgabe fortschreitet.

Browser unterstützen das value-Attribut. Firefox und Safari wandeln den Wert in eine Prozentzahl um, so dass Screenreader immer eine Fortschrittsentwicklung von 0% bis 100% erfahren. Chrome liefert nur den Wert (value-Attribut) an Assistenztechnologien, so dass bei einer Skala, die vom Standard 0 bis 1 abweicht, die Wartezeit in einem Screenreader nicht festgestellt werden kann.

Die groben Ergebnisse sind:

  • Der Screenreader JAWS funktioniert mit Chrome und Firefox.
  • Der Screenreader NVDA funktioniert mit Firefox, aber nicht mit Chrome.
  • VoiceOver/Safaria behandelt eine Fortschrittsanzeige nicht als Live-Region.

Ersatztext für den Wert

Weil nicht alle Browser einen Prozentwert ausgeben, wird bei langen Wartezeiten ein menschenlesbarer Ersatztext für den Wert des <progress>-Elements empfohlen. Dafür wird ARIA (vielleicht doch) erforderlich:

<p><label for=“foo“>Installation</label>
<progress id=“foo“ value=“3″ aria-valuetext=“fast fertig 15%“ max=“20″>3 von 20 (15%)</progress></p>

Das Ergebnis in verschiedenen Screenreader-Browser-Kombinationen ist unterschiedlich. JAWS hat keine Probleme mit dem aria-valuetext-Attribut und ersetzt den Wert. NVDA mit Firefox steigt hingegen aus und gibt die Fortschrittsentwicklung nicht mehr aus.

Für alle lesbare Statusinformationen

Das <progress>-Element sollte nur eingesetzt werden, wenn sich Nutzerinnen auf eine längere Wartezeit einstellen müssen. Wenn in diesem Prozess verschiedene Schritte durchlaufen werden, kann auch diese Information besser für die UX sein. Das aria-valuetext-Attribut könnte dafür genutzt werden, aber es wird nur (bedingt) von Assistenztechnologien unterstützt. Statt dessen ist ein sichtbarer Text besser geeignet:

<p><label>Installation <progress value=“0.2″>20%</progress></label></p>
<p>Schritt 3: <span role=“status“>Anwendung wird konfiguriert</span></p>

Die Statusinformation wird in einer Live-Region (role=“status“ gesteckt, damit Browser diese Texte bei Änderung an Assistenztechnologien weiterleiten.

Im Ergebnis besteht das kleine Beispiel aus zwei Live-Regionen:

  • Der Wert des <progress>-Elements wird in Abständen von ca. 5 Sekunden an Assistenztechnologien weitergeleitet.
  • Der Inhalt des Elements mit role=“status“ wird an Assistenztechnologien weitergeleitet, wenn der Inhalt geändert wird.

Demoseite

Auf einer Demoseite können vier Beispiele angeschaut werden:

  • <progress> mit einem value-Attribut,
  • <progress> mit einem max- und einem value-Attribut,
  • <progress> mit einem aria-valuetext- und einem value-Attribut und
  • <progress> mit einer zusätzlichen Statusinformation.

Wie bereits angedeutet, sind die Ergebnisse durchwachsen. Die Umsetzung eines <progress>-Elements sollte in jedem Fall durch eine zweite Live-Region mit menschenlesbarem Text ergänzt werden.

Um die Beispiele zu testen, muss ein Screenreader aktiviert werden.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert