Neues in ARIA 1.1 #2

Mit aria-current das aktuelle Element anzeigen

Eine Breadcrumb; der letzte Eintrag ist mit current, aktueller Standort, aktuelles Objekt und aktuelle Seite beschriftet.

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:

  • „page“ repräsentiert die aktuelle Seite innerhalb eines Satzes von Webseiten (z.B. in einer Pagination, in der die aktuelle Seite visuell hervorgehoben wird),
  • „step“ repräsentiert den hervorgehobenen Schritt in einem mehrschrittigen Prozess,
  • „location“ repräsentiert die aktuelle Lokation in einer Umgebung oder einem Kontext (z.B. die aktuelle Seite in einer Breadcrumb, der aktuelle Standort auf einer Karte oder eine hervorgehobene Grafik in einem Flow-Chart),
  • „date“ zeigt das aktuelle Datum in einem Satz von Datumsangaben (z.B. in einem Kalender) an und
  • „time“ repräsentiert die aktuelle Zeit in einem Satz von Zeitangaben (z.B. in einem Fahrplan).

zum Beitrag »

Neues in ARIA 1.1 #1

role="presentation" erhält role="none" als Synonym

Eine Waage ist im Gleichgewicht; auf den Waagschalen stehen die Worte none und presentation.

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.

zum Beitrag »

Alternativtext ohne alt-Attribut

Stand der Screenreader-Unterstützung in 2016

Das Gesicht der Mona Lisa mit Sprechblasentext: aria-labelledby > aria-label > alt > title

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:

  • Der „accessible name“ setzt sich aus den Texten zusammen, die mit dem aria-labelledby-Attribut referenziert werden.
  • Ist kein aria-labelledby-Attribut vorhanden, bestimmt ein aria-label-Attribut den Alternativtext.
  • Ist weder ein aria-labelledby- noch ein aria-label-Attribut vorhanden, bestimmt ein alt-Attribut den Alternativtext.
  • Ist weder ein aria-labelledby- noch ein aria-label- noch ein alt-Attribut vorhanden, bestimmt ein title-Attribut den Alternativtext.

zum Beitrag »

DAISY-Bücher

Das Warten auf passende Add-Ons für Word 2016

Ein Buch wird in einen Fleischwolf geworfen aus dem dann Musiknoten zu einem Daisyplayer fliegen.

DAISY steht für Digital Accessible Information System und ist ein Standard für die Aufbereitung von Hörbüchern. Die Möglichkeiten, die DAISY bietet, werden seit 15 Jahren von Blindenhörbüchereien und vereinzelten Verlagen genutzt. Allerdings wird das DAISY-Format selbst nicht weiterentwickelt, weil DAISY in die EPUB-Spezifikation eingeflossen ist.

zum Beitrag »

Schweizer Accessibility Studie 2016

Schlechte Noten für die Digitalisierung

Collage aus dem Logo der Stiftung Zugang für alle, vier Icons der gängigen Browser und ein Foto des Matterhorns

„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“

zum Beitrag »

Lästige Links

Mit ARIA oder CSS doppelte Links vermeiden

Viele doppelte Links die von einer Fliegenklatsche bedroht werden

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>

zum Beitrag »

Links mit ARIA verstecken

Stand der Screenreader-Unterstützung in 2016

Eine Tabtaste umzingelt von vielen doppelten Links

Manchmal müssen (oder sollten) Inhalte vor Screenreadern versteckt werden, die am Bildschirm sichtbar sind. In diesem Beitrag geht es um redundante Links, die mit tabindex=“-1“ zwar im Browser nicht mehr fokussierbar werden, aber dennoch für Screenreader zugänglich bleiben. Die ARIA-Spezifikation sieht zwei Möglichkeiten vor, solche Links auch vor Screenreadern zu verstecken:

  1. Mit aria-hidden=“true“ soll ein Element samt Kindelemente und enthaltener Text vor Screenreadern versteckt werden.
  2. Mit role=“presentation“ (ARIA 1.0) bzw. role=“none“ (ARIA 1.1) soll die Semantik des Elements unterdrückt werden, aber Kindelemente und enthaltener Text für Screenreader zugänglich bleiben.

zum Beitrag »

Landmarks mit ARIA und HTML

Stand der Screenreader-Unterstützung in 2016

Luftaufnahme von Feldern die mit Landmarks beschriftet sind.

Im letzten Herbst habe ich im Beitrag Mehr als nur Semantik über Nutzungsszenarien für die HTML5-Elemente mit einer Rolle eines Landmarks geschrieben. Seinerzeit hatte ich die Beispiele mit Internet Explorer und dem Screenreader JAWS vorgestellt. Obwohl inzwischen die Unterstützung von Landmarks im Internet Explorer kaum zu beanstanden ist, so ist die Unterstützung für Landmarks immer noch uneinheitlich in den verschiedenen Browser-Screenreader-Kombinationen.

zum Beitrag »

Kollaboratives Intranet

Anforderungen an das Autorenwerkzeug

Eine Menschenmenge bewegt sich in Richtung eines Intranet-Schildes; eine Hälfte der Menschenmenge benutzt die Treppe, die andere Hälfte benutzt eine Rolltreppe.

Als ich neulich eingeladen war, die Vorstellung mehrerer Bewerber für die Umsetzung eines kollaborativen Intranets vor dem Hintergrund der Barrierefreiheit mit zu bewerten, war ich über zwei Aspekte überrascht. Zum einen wurde von den Bewerbern zu oft angenommen, dass es nur ein begrenztes Redakteursteam gäbe, und zum anderen wurde zu oft angenommen, dass Menschen mit Behinderungen keine Inhalte zum Intranet beitragen würden. Damit waren die betroffenen Bieter selbstverständlich aus dem Rennen raus. Erst recht konnten die Anbieter nicht in Erwägung gezogen werden, die keine konkreten Informationen zur Barrierefreiheit im Frontend sagen konnten.

zum Beitrag »