Seit über einer Woche bin ich wieder aus dem Urlaub zurück. Jetlag und Termine haben aber dazu geführt, dass ich nur langsam wieder in den Trott gekommen bin. Letzte Woche war insofern öffentlichkeitswirksam, als eine dpa-Meldung über Barrierefreiheit in verschiedenen Medien erschienen ist und eine Veranstaltung in Düsseldorf unerwartet viele Besucher anlockte.
Über acht Jahre nach Veröffentlichung der Web Content Accessibility Guidelines (WCAG) 2.0 in 2008 ist der erste öffentliche Entwurf (first public working draft) der WCAG 2.1 zur Kommentierung veröffentlicht worden. Der Entwurf enthält knapp 30 neue Erfolgskriterien.
Webseiten berücksichtigen heute zunehmend Accessible Rich Internet Applications (ARIA). Eine Beobachtung der letzten Jahre ist aber der überflüssige Einsatz von ARIA-Attributen. Es beginnt bei redundanten Auszeichnungen wie <button role=“button“>, was im Prinzip harmlos ist, und endet bei <body role=“application“>, was in vielen Situationen dazu führt, dass eine Webseite von Screenreadern nicht mehr gelesen werden kann. Eine weitere Problematik, die in nachfolgenden Beitrag diskutiert wird, ist dass ARIA-Attribute zur Bezeichnung von Elementen vergleichbaren HTML-Techniken überlegen sind.
Bereits in Accessible Rich Internet Applications (ARIA) 1.0 wurde die Rolle „form“ als „landmark role“ definiert. Allerdings war das nicht übertragbar auf das HTML-Element <form>. In ARIA 1.1 werden <form> Elemente auch als Seitenregionen bestimmt werden können.
Grafiken jeder Art benötigen eine Textalternative, die den Zweck der Grafik angibt. Grundsätzlich ist dabei zwischen funktionalen, identifizierenden, beschreibenden und leeren Textalternativen zu unterscheiden:
Accessible Rich Internet Applications (ARIA) 1.1 steht vor der Tür und es gibt einige Änderungen und Neuerungen gegenüber ARIA 1.0. Ein neues globales Attribut ist aria-current, das Hilfsmitteln wie Screenreadern das aktuelle Element in einem Satz von verwandten Elementen anzeigen soll.
Das aria-current-Attribut kann die folgenden Werte annehmen:
Wenn ein HTML-Element die Rolle „presentation“ erhält, wird die Semantik des Elements nicht an den Accessibility-Tree des Betriebssystems übertragen. Gleichwohl sind alle Kindknoten des Elements davon nicht betroffen, d.h. der enthaltene Text und weitere Elemente bleiben weiterhin für Screenreader zugänglich. Da die Rolle „presentation“ offenbar häufig fälschlicherweise so interpretiert wird, dass sowohl das Element als auch seine Inhalte nicht an den Accessibility-Tree übertragen werden, wird in Accessible Rich Internet Applications (ARIA) 1.1 der synonyme Wert „none“ eingeführt.
Nach dem Entwurf der HTML Accessibility API Mappings 1.0 (Stand: 14.12.2016) sollen Browser den Alternativtext bzw. den „accessible name“ einer Grafik anhand der folgenden Attribute berechnen:
„Dass die Barrierefreiheit der Informations- und Kommunikationstechnologien in der Schweiz auf tiefem Niveau stagniert, wie die vorliegende Studie aufzeigt, ist daher ein Grund zur Sorge für die Personen, denen der Zugang verschlossen ist, aber auch für alle anderen, die an der Informationsgesellschaft teilhaben“
Teaser werden unterschiedlich realisiert. Eine häufige Form ist eine verlinkte Überschrift zusammen mit einer verlinkten Grafik. Der Code könnte wie folgt aussehen:
<div class="teaserbox">
<p><a href="seite.html"><img alt=" Superstar Bolt holt Gold über 100 Meter" src="usain-bolt.png"></a></p>
<h2><small>Olympia</small> <a href="seite.html">Superstar Bolt holt Gold über 100 Meter</a></h2>
</div>