Barrierefreiheit

Dieser Abschnitt ist der Grund, warum sich die Veröffentlichung der Seite lohnt. Jeder Punkt ist real, wir kennen ihn, und keiner wird hier als behoben dargestellt.

Die Website ist in dreißig Sprachen veröffentlicht und wurde nicht in allen davon mit einem Screenreader getestet. Tests wurden auf Englisch durchgeführt. Aussprache und Lesereihenfolge in Sprachen mit Schreibrichtung von rechts nach links sowie in Schriften, für die unsere Anzeigeschriftarten keine Zeichen enthalten und die Plattformschrift einspringt, wurden mit assistiven Technologien nicht überprüft.

Unsere beiden Schriftarten decken nur das lateinische Alphabet ab. Kyrillisch, Devanagari, Georgisch, Thai, Arabisch, Hebräisch, Bengalisch, Äthiopisch und CJK verwenden die Schriften der jeweiligen Plattform. Das ist im Allgemeinen gut für die Lesbarkeit. Es bedeutet jedoch, dass wir die typografischen Details, die wir im Englischen steuern — Gewicht, Abstände und die Größe, ab der kleiner Text nicht mehr klein genug ist — in diesen Sprachversionen nicht kontrollieren.

Einige interaktive Elemente sind neu und weniger umfassend getestet. Die Vergleichsmatrix und die Hilfesuche filtern Zeilen direkt an Ort und Stelle, was dem richtigen Muster entspricht. Die Ansage einer geänderten Trefferzahl an einen Screenreader wurde jedoch implementiert und noch nicht mit Nutzern getestet.

Für die App gilt dieselbe Zielsetzung, sie wird jedoch seltener geprüft als die Website. Sie unterstützt die eigene Textgrößenanpassung und den Screenreader der Plattform, die beide den größten Teil der Arbeit übernehmen. Wir führen derzeit jedoch für jede Veröffentlichung kein formelles Barrierefreiheits-Audit durch.

Weder für die Website noch für die App wurde ein formelles Audit durch Dritte durchgeführt. Das sagen wir lieber offen, als eine Zertifizierung anzudeuten, die wir nicht besitzen.

Die Telvio-App nutzt die Barrierefreiheitsfunktionen des Betriebssystems, auf dem sie ausgeführt wird: VoiceOver und Dynamic Type unter iOS sowie TalkBack und die Schriftgrößenanpassung unter Android. Damit wird das meiste abgedeckt, was bei einer App mit Wähltastatur, Guthaben und einer Tarifliste wichtig ist.

Eine Designentscheidung sollte eher als Eigenschaft der Barrierefreiheit denn als Funktion erwähnt werden. Da die App kein Konto erfordert, gibt es kein Anmeldeformular, kein einzugebendes Passwort, keinen E-Mail-Bestätigungsschritt und keinen Code, der aus einer Nachricht abgerufen werden muss — die gesamte Interaktionsklasse, an der Menschen mit assistiven Technologien oder generell Menschen, denen Formulare schwerfallen, am häufigsten scheitern, ist schlicht nicht vorhanden. Installieren, wählen, sprechen.

Die entsprechende Einschränkung steht auf derselben Seite wie alle anderen Informationen: Die App kann keine Notdienste anrufen. Das ist unter Notrufe beschrieben. Wenn jemand diese App für eine angehörige Person einrichtet — ein häufiges Muster, insbesondere bei älteren Menschen, die ihre Familie im Ausland anrufen — ist das der wichtigste Punkt, den Sie dabei erklären sollten.

Senden Sie eine E-Mail an [email protected] mit dem Betreff Accessibility. Hilfreiche Angaben sind: die Seite oder der Bildschirm, was Sie tun wollten, welche assistive Technologie Sie einschließlich ihrer Version verwendet haben und was stattdessen passiert ist. Nichts davon ist zwingend erforderlich — ein Satz wie “Ich kann die Tariftabelle mit einem Screenreader nicht nutzen” ist ein vollkommen ausreichender Bericht, und wir erhalten ihn lieber als gar keinen.

Wir bemühen uns, innerhalb von fünf Werktagen mit einer Einschätzung und, sofern wir einen Fehler bestätigen, einem groben Zeitrahmen zu antworten. Dinge, die jemanden daran hindern, eine Aufgabe abzuschließen, werden vor anderen Arbeiten behoben. Dinge, die eine Aufgabe erschweren, werden ehrlich eingeplant, statt vage versprochen zu werden.

Wenn Sie sich in der Europäischen Union befinden und der Meinung sind, dass eine Verpflichtung zur Barrierefreiheit nicht erfüllt wird, können Sie dies auch der zuständigen nationalen Durchsetzungsstelle melden. Wir möchten lieber, dass Sie sich zuerst an uns wenden, und wir antworten Ihnen in jedem Fall.

Zwei Dinge sollten wir erläutern, weil sie den Unterschied zwischen einer Erklärung und gelebter Praxis ausmachen.

Der Kontrast wird anhand der Darstellung geprüft, nicht anhand des Quellcodes. Ein aus einem Stylesheet ausgelesener Farbwert zeigt, wie ein Element aussehen sollte, nicht wie es tatsächlich aussieht — etwa ein halbtransparentes Element über einem dunklen Streifen, eine moderne Farbfunktion, die ein regulärer Ausdruck nicht versteht, oder ein fixierter Header über einem Hero-Bild. Die Prüfung rendert den tatsächlichen Hintergrund jedes Elements, indem sie bis zum ersten opaken Vorfahren nach oben geht und die Farbe direkt im Browser auflöst, und berechnet anschließend das Verhältnis. Dabei wurde festgestellt, dass der Fließtext auf dieser Website ein Verhältnis von 4.49:1 hatte, also unter AA lag und isoliert betrachtet völlig normal aussah.

Die Seite wird so geprüft, wie sie dargestellt wird, nicht so, wie sie geschrieben ist. Eine separate Prüfung lädt jede Seite in einem echten Browser und ermittelt, ob Text im sichtbaren Bereich eine Deckkraft von null hat, ob das Dokument seitlich scrollbar ist und ob etwas in seiner eigenen Hintergrundfarbe dargestellt wird. Der letzte Punkt klingt absurd, bis er tatsächlich veröffentlicht wird: Eine einzelne gruppierte CSS-Regel setzte einmal die Farbe und den Hintergrund eines Labels auf denselben Wert. Das führte zu einem Kontrastverhältnis von 1:1, das im Markup, im DOM und in einem Screenshot der Quelle unsichtbar war.