Die 5 häufigsten Fragen in Schulungen zum Thema Barrierefreiheit

Es ist eine spannende Zeit, um im Bereich der digitalen Barrierefreiheit zu arbeiten! Noch vor wenigen Jahren war es oft schwierig, eine offene Stelle als Spezialist für Barrierefreiheit zu finden – insbesondere bei Unternehmen der Privatwirtschaft. In manchen Fällen gab es zwar offene Stellen, doch handelte es sich dabei entweder um Teilzeitstellen, die an eine „normale“ technische Tätigkeit angehängt waren, und/oder um Aufgaben, die der UX-Abteilung zugeordnet wurden. Mittlerweile sehe ich viel mehr eigenständige Stellenangebote im Bereich der digitalen Barrierefreiheit bei Fortune-500-Unternehmen wie Microsoft, Google, Target, JPMorgan Chase, Prudential und vielen anderen.

Ich glaube, dass dieser Wandel bei den Bemühungen um Barrierefreiheit zum einen auf das gestiegene Bewusstsein und zum anderen auf Aufklärung zurückzuführen ist. Natürlich bin ich nicht so naiv zu glauben, dass Rechtsstreitigkeiten dabei keine Rolle gespielt hätten – laut Usable Net gibt es über 40 neue Klagen zum Thema Barrierefreiheit pro Woche, wobei im Jahr 2018 insgesamt über 2.200 Klagen eingereicht wurden –, aber ich möchte hoffen, dass dies nur ein kleiner Teil des Ganzen ist. Auch wenn Rechtsstreitigkeiten zunächst den Weg für digitale Barrierefreiheit ebnen mögen: Sobald mehr Fachleute und Unternehmen aus der Tech-Branche den Wert der Inklusion in ihren Produkten erkennen, besteht die Hoffnung, dass dieser Weg offen bleibt und Veränderungen für alle möglich sind – nicht nur, wenn sie durch Rechtsstreitigkeiten dazu gezwungen werden.

Doch ganz gleich, warum die digitale Barrierefreiheit so rasant zu wachsen scheint – eines ist sicher: Mit der steigenden Zahl an Arbeitsplätzen im Bereich der digitalen Barrierefreiheit wächst auch der Bedarf an Schulungen für diese zukünftigen Fachkräfte. Im Rahmen meiner Tätigkeit bei Deque habe ich das Glück, Teil des Programms für Präsenzschulungen (ILT) zu sein. Das ILT-Programm besteht aus einem Team von Barrierefreiheitsexperten, die technische Fachkräfte in verschiedenen Aspekten der digitalen Barrierefreiheit schulen. Wir decken ein breites Spektrum an Themen ab, darunter Barrierefreiheit im Mobilbereich, im Design und in der Entwicklung.

DequeDas ILT-Team von … war sehr damit beschäftigt, weltweit sowohl Präsenz- als auch virtuelle Schulungen durchzuführen. Allein in den letzten Monaten bin ich über 8.000 Meilen gereist und habe insgesamt 25 Schulungstage geleitet (weitere stehen noch an) … und dabei bin ich bei weitem nicht das beschäftigtste Mitglied unserer Gruppe! Während meiner jüngsten Reisen habe ich eine Liste mit Fragen von Designern und Entwicklern vor Ort zusammengestellt. Unabhängig von der Unternehmensgröße oder der Branche werden Sie vielleicht überrascht sein, dass sich viele dieser Fragen überschneiden. Im Folgenden finden Sie die fünf häufigsten Fragen, die mir gestellt werden, sowie einige Hintergrundinformationen und Ressourcen, um mehr über die einzelnen Themen zu erfahren.

Welche Barrierefreiheitsvorschriften sollte ich beachten?

Zu Beginn jeder Schulung fragen wir die Teilnehmer gerne: „Was fällt Ihnen als Erstes ein, wenn Sie das Wort Barrierefreiheit hören?“ Wir stellen diese Frage, um einen guten Kontakt zum Publikum herzustellen und es von Anfang an einzubeziehen, aber auch, um herauszufinden, wie vertraut die Teilnehmer mit dem Thema Barrierefreiheit sind. Natürlich gibt es eine Vielzahl unterschiedlicher Antworten, aber eine Sache höre ich immer wieder: „Ich bin mir nicht sicher, welche Richtlinien ich befolgen soll.“ Es herrscht große Verwirrung darüber, welche Barrierefreiheitsvorschriften Unternehmen generell befolgen müssen, insbesondere aber in Bezug auf die WCAG. Mit der Veröffentlichung der WCAG 2.1 im vergangenen Jahr ist die Situation für Anfänger noch verwirrender geworden.

Zunächst einmal wollen wir kurz einen Schritt zurückgehen…Was sind die WCAG überhaupt? WCAG ist eine Abkürzung für „Web Content Accessibility Guidelines“ (Richtlinien für barrierefreie Webinhalte) und Version 1.0 wurde bereits 1999 vom World Wide Web Consortium (W3C) veröffentlicht. Der ursprüngliche Schwerpunkt lag ausschließlich auf HTML, und die Richtlinien wurden letztlich geschaffen, um die Barrierefreiheit im aufkommenden Web zu standardisieren. Ende 2008 wurde Version 2.0 der WCAG veröffentlicht. Diese Version war nicht technologiespezifisch und deckte weitaus mehr Aspekte von Behinderungen ab, darunter Blindheit und Sehbehinderungen, Taubheit und Hörverlust, Lernbehinderungen, kognitive Einschränkungen, Bewegungseinschränkungen, Sprachbehinderungen, Lichtempfindlichkeit und vieles mehr.

WCAG 2.0 war ein wichtiger Schritt in der Entwicklung der Barrierefreiheitsstandards. Tatsächlich hat die Internationale Organisation für Normung (ISO) im Oktober 2012 WCAG 2.0 als digitalen Standard für Barrierefreiheit festgelegt, der für viele Länder und Organisationen weltweit zum „Goldstandard“ wurde. Natürlich gibt es auch länderspezifische und branchenspezifische Vorschriften (z. B. US Section 508), die zur Erstellung separate Regelwerke für Barrierefreiheit geschaffen haben. Die vollständige Liste der Vorschriften ist vielfältig und unterliegt ständigen Änderungen; sie kann je nach Kunde unterschiedlich ausfallen, weshalb wir uns bei Schulungen in der Regel auf die grundlegenden WCAG-Regeln konzentrieren.

Ein paar Jahre später, im Jahr 2018, erleben wir eine weitere Weiterentwicklung der WCAG mit der Version 2.1. Aufgrund technologischer Fortschritte und eines tieferen Verständnisses der Nutzerbedürfnisse konzentrierten sich die Änderungen an den WCAG 2.1 auf die Barrierefreiheit bei Mobil- und Tablet-Geräten sowie auf Nutzer mit Sehbehinderungen und kognitiven Beeinträchtigungen. Die WCAG 2.1 gelten als Erweiterung der WCAG 2.0 und nicht als Ersatz dafür. Unsere Kollegin Glenda Sims hat eine hervorragende Artikelserie zu WCAG 2.1 , die ich allen Personen und Organisationen, die sich eingehender mit diesem Thema befassen möchten, wärmstens empfehle.

Wie wir alle wissen, können die WCAG-Richtlinien sehr schnell sehr kompliziert werden … Deshalb versuche ich, mich für Einsteiger auf die umsetzbaren Aspekte der Richtlinien zu konzentrieren, nämlich die P.O.U.R.-Konzepte – Wahrnehmbar, Bedienbar, Verständlich und Robust.

Die erste Kategorie in P.O.U.R. ist Wahrnehmbar. Das bedeutet, dass Nutzer die dargestellten Informationen wahrnehmen können müssen – sie dürfen für keinen ihrer Sinne unsichtbar sein.

• Fragen: Gibt es auf unserer Website oder in unserer App etwas, das eine Person mit einer Behinderung nicht wahrnehmen könnte? Funktioniert dies mit verschiedenen Arten von Hilfsmitteln? Denken Sie dabei unbedingt an alle Arten von Behinderungen – Seh-, Mobilitäts-, Hör-, kognitive und Sprachbeeinträchtigungen, Gleichgewichtsstörungen und Anfallsleiden sowie viele weitere.
• Beispiele: Hinzufügen von Textalternativen zu nicht-dekorativen Bildern, Hinzufügen von Bildunterschriften und Transkripten zu Videos, Sicherstellen, dass die Farbe nicht das einzige Mittel zur Vermittlung von Bedeutung ist.

Die zweite Kategorie ist Bedienbarkeit. Benutzer müssen in der Lage sein, die Benutzeroberfläche zu bedienen – die Benutzeroberfläche darf keine Interaktionen erfordern, die ein Benutzer nicht ausführen kann.

• Fragen: Können Nutzer interaktive Elemente unserer Website/App steuern? Gibt es auf unserer Website irgendwelche Fallstricke?
• Beispiele: Navigation ausschließlich über die Tastatur, Sicherstellen, dass bei Diashows alle Steuerelemente angezeigt werden, Sicherstellen, dass die Nutzer genügend Zeit zum Ausfüllen eines Formulars haben.

Die dritte Kategorie ist Verständlichkeit. Die Nutzer müssen sowohl die Informationen als auch die Bedienung der Benutzeroberfläche verstehen können – der Inhalt oder die Bedienung darf ihr Verständnis nicht übersteigen.

• Fragen: Sind alle Inhalte klar formuliert? Sind alle Interaktionen leicht verständlich? Ist der Aufbau der Seite sinnvoll?
• Beispiele: Verfassen Sie Inhalte auf dem Leselevel der 9. Klasse – verwenden Sie keine komplizierten Wörter, wenn einfache ausreichen, sorgen Sie dafür, dass Ihre Website übersichtlich ist, und stellen Sie sicher, dass etwaige Fehlermeldungen auf Ihrer Website klar verständlich und leicht zu beheben sind.

Die letzte Kategorie ist „Robust“. Das bedeutet, dass Nutzer auch bei technologischem Fortschritt auf die Inhalte zugreifen können müssen – während sich Technologien und Benutzeragenten weiterentwickeln, sollten die Inhalte weiterhin barrierefrei bleiben.

• Fragen: Unterstützt unsere Website nur die neuesten Browser oder Betriebssysteme? Wurde unsere Website nach bewährten Verfahren entwickelt? Funktioniert sie sowohl im Quer- als auch im Hochformat?
• Dafür gibt es keine konkreten Beispiele … testen Sie einfach Ihre Website/App! Setzen Sie dabei unbedingt alle Arten von Tools ein – automatisierte, manuelle, assistive Technologien sowie Nutzertests. Führen Sie nach Ihren ersten Barrierefreiheitstests weitere Tests durch, sobald neue Features oder Funktionen hinzugefügt werden.

Der Grundgedanke von P.O.U.R. besteht nicht darin, sich strikt an feste Regeln zu halten, sondern darin, die vielfältigen Bedürfnisse Ihrer Nutzer zu verstehen und ihnen gerecht zu werden. Sobald Sie sich darauf eingelassen haben, werden die WCAG-Richtlinien eher zu einem Leitfaden als zu einer To-do-Liste.

Was ist ARIA und brauche ich es wirklich?

Nach den WCAG dreht sich die nächsthäufigste Frage immer um ARIA. Je nach dem Kenntnisstand der Zuhörer in Bezug auf Barrierefreiheit und/oder Entwicklung erhalte ich Fragen, die von „Was ist das? Brauche ich das wirklich? Warum kann ich nicht einfach HTML verwenden?“ Um ehrlich zu sein: Als ich den Begriff ARIA zum ersten Mal hörte, nahm ich an, es handele sich lediglich um eine weitere eigenständige Programmiersprache. Bei all den verschiedenen Varianten von JavaScript und CSS, die es da draußen gibt, liegt es nahe, dass ARIA diesem Trend folgen würde. Aber ARIA ist ein bisschen anders.

Zunächst einmal ist ARIA eine Abkürzung für „Accessible Rich Internet Applications“ und heißt offiziell WAI-ARIA (obwohl viele Menschen es bei seinem Kurznamen nennen). Es wurde erstmals im Jahr 2008 von der Web Accessibility Initiative (WAI) – einer Untergruppe des übergeordneten World Wide Web Consortium (W3C), das für die Barrierefreiheit im Internet zuständig ist.

ARIA ist als eine Sammlung von Attributen definiert, die dabei helfen, fehlerhafte Markups zu korrigieren und Lücken im HTML zu schließen, um Nutzern von assistiver Technologie (AT) eine barrierefreiere Erfahrung zu ermöglichen. Durch die korrekte Einbindung von ARIA in Ihren Code wird sichergestellt, dass Nutzer von assistiver Technologie über alle Informationen verfügen, die sie zur Nutzung Ihrer Website oder App benötigen. Oder einfacher ausgedrückt: ARIA ist Hilfs-Code, der die Lücke zwischen der Website/App und dem AT-Nutzer schließt.

ARIA lässt sich wie folgt unterteilen:

• Rollen — definieren, was ein Element ist oder was es tut.
• Eigenschaften — beschreiben Merkmale oder Beziehungen eines Objekts.
• Zustände und Werte — definieren die aktuellen Bedingungen oder Datenwerte, die mit dem Element verbunden sind.

Brauchen Sie ARIA? Nun, wie bei so vielem im Bereich der digitalen Barrierefreiheit kommt es darauf an™. Früher war ARIA die beste Wahl, um Code vollständig barrierefrei zu gestalten, aber mittlerweile haben HTML-Elemente diese Rolle teilweise übernommen. Um es für Anfänger einfach zu halten, wiederholen wir bei den Schulungen von „ Deque “ die erste Regel von ARIA , die vom W3C aufgestellt wurde:

„Wenn Sie ein natives HTML-Element oder -Attribut verwenden können, das bereits über die von Ihnen benötigte Semantik und das gewünschte Verhalten verfügt, anstatt ein Element umzufunktionieren und eine ARIA-Rolle, einen ARIA-Status oder eine ARIA-Eigenschaft hinzuzufügen, um es barrierefrei zu gestalten, dann tun Sie dies.“

Oder wie ich es gerne umformuliere (wobei ich mein Bestes gebe, um wie Brad Pitt im Film „Fight Club“ aus dem Jahr 1999 zu klingen): „Die erste Regel von ARIA lautet: Verwende ARIA nicht.“

Im Zweifelsfall sollten Sie *unterstützte* HTML-Elemente verwenden und anschließend ARIA einsetzen. Um die Browserkompatibilität zu überprüfen, nutze ich häufig Websites wie HTML5 Accessibility, Can I Useoder die W3C-Liste der ARIA in HTML-Attributen , bevor ich mich entscheide, ob ich für ein bestimmtes Muster HTML- oder ARIA-Elemente verwenden kann. Um mehr über ARIA zu erfahren und einige Beispiele zu sehen, schau dir „Much Ado About ARIA“ und so ziemlich alles von Scott O’Hara schreibt oder programmiert.

Wie fügt man am besten alternative Inhalte zu Bildern hinzu?

Die dritthäufigste Frage dreht sich in der Regel um Alternativtext. Ich freue mich riesig, dass sich die Erkenntnis durchgesetzt hat – Bilder brauchen Beschreibungen! Aber so einfach kann es natürlich nicht sein. Je nach Art des Bildes musst du möglicherweise deine Vorgehensweise beim Hinzufügen von Alternativtext anpassen. Der erste Schritt besteht darin, über den Zweck deines Bildes nachzudenken. Soll es den Nutzer informieren? Die „Stimmung“ der Website prägen? Erfüllt es eine bestimmte Funktion? Die „Kategorie“ deines Bildes zu bestimmen, ist nicht immer einfach, aber mithilfe von Entscheidungsbäume für Bild-Alt-Texte kann dabei helfen.

If an image is decorative, you need to hide it from assistive technology devices (ATs). You can use different methods like CSS background images or web fonts. You can also use the <img> tag, but then the decorative image needs to have an empty/null alternative text attribute. This sends a signal to the AT to ignore this image as it is not necessary for understanding the content or action on the page. An empty/null alternative text attribute is not the same as a missing alternative text attribute. If the alternative text is just missing, the AT might read out the file name or surrounding content in an attempt to give the user more information about the image.

Wenn Sie hingegen der Meinung sind, dass ein Bild aussagekräftig ist, sollten Sie unbedingt alternative Informationen zu dem Bild bereitstellen. Es gibt viele verschiedene barrierefreie Muster für Bilder , die du nutzen kannst, um dieses Ziel zu erreichen. Wähle dasjenige (bzw. jene) aus, das (die) in deinem Framework oder CMS am besten funktioniert (funktionieren). Unabhängig davon, für welches Muster du dich entscheidest, achte darauf, dass dein Alt-Text aussagekräftig und beschreibend ist und sich nicht wiederholt. Verwende außerdem keine Formulierungen wie „Bild von“ oder „Grafik von“, um ein Bild zu beschreiben. Ein Screenreader teilt dem Nutzer diese Information bereits mit.

Wenn es darum geht, wie man gute Alternativtexte verfasst, verwende ich oft die Telefon-Analogie. Wenn Sie einen Freund anrufen und nur „Brauner Hund“ sagen und dann auflegen, wäre Ihr Freund wahrscheinlich verwirrt. Wenn Sie einen Freund anrufen und sagen: „Der braune Hund sitzt am Strand“, würde das ein anschaulicheres Bild vermitteln, ohne den Text unnötig zu verkomplizieren oder den Aufwand zu erhöhen. Natürlich muss ein Nutzer eines Screenreaders Ihren alternativen Inhalt anhören, also übertreiben Sie es nicht. Deshalb empfehlen wir, dass Ihr Alt-Text 250 Zeichen nicht überschreitet. Wenn Sie dem Bild mehr Kontext hinzufügen müssen (z. B. bei einem komplexen Diagramm), gibt es andere, aussagekräftigere Muster oder Methoden, mit denen Sie weitere Details einbringen können.

Another kind of informative image is an “actionable” image – which is a tricky one for a lot of people. This is where an image acts as a link or performs a functionality. If your image is actionable you need to provide information about the function of the image instead of describing the image. For example, if you use a magnifying glass as your “submit” button on a search form, that is completely fine. But the alternative text should *not* read <img alt=“magnifying glass”> but something about the action that will happen when you click or press on it <img alt=“Search this website”>.

Warum reicht es nicht aus, ein automatisiertes Barrierefreiheits-Tool einzusetzen?

Menschen, die in der Tech-Branche arbeiten, lieben Tools. Das ist nur logisch. Viele von uns können sich noch daran erinnern, als wir zum ersten Mal einen Computer benutzt haben (ein Gruß an meinen Commodore 64) und denken gerne an die Zeiten der Klapphandys zurück. Ich trage nicht gern Schmuck, deshalb habe ich mir nie eine Apple Watch gekauft … aber ich erinnere mich noch gut daran, als sie auf den Markt kamen und sich die verrückten Schlangen bildeten, um eine zu ergattern.

Wenn mich also Leute bei Schulungen und Konferenzen nach Tools zur Barrierefreiheit fragen, überrascht mich das nicht. Sie wollen ein paar Knöpfe drücken und *zack!* magische Wesen herbeirufen, die sich um alles kümmern, alle Probleme aufspüren und beheben. Natürlich gefällt ihnen meine Antwort nicht, dass automatisierte Tests – unabhängig vom verwendeten Tool – nur zuverlässig 30–40 % aller Barrierefreiheitsprobleme. Und manche Tools sind besser darin, bestimmte Barrierefreiheitsprobleme zu erkennen, während andere vielleicht besser geeignet sind, andere Fehler aufzuspüren – daher muss man wirklich eine ganze Reihe von Tools einsetzen. Hinzu kommt, dass bei vielen der Probleme, die automatische Testtools tatsächlich finden, immer noch ein Mensch erforderlich ist, um die Ergebnisse zu interpretieren und die Probleme zu priorisieren. Ein automatisiertes Testtool könnte dir zum Beispiel mitteilen, dass bei deinem Bild der Alternativtext fehlt, aber es kann dir nicht sagen, welchen Alternativtext du schreiben sollst. Puh … allein der Gedanke daran ist schon anstrengend!

Aber es gibt nicht nur schlechte Nachrichten! Die gute Nachricht ist, dass automatisierte Testtools wirklich beeindruckend sind und mit jeder neuen Version „intelligenter“ werden. Vielleicht wird es schon bald so weit sein, dass diese Tools zuverlässig fast 100 % aller Probleme erkennen und diese sogar für Sie beheben können. Bis es soweit ist, können Sie jedoch UX-/UI-Tests, manuelle Tastaturtests, Touch-Tests für Mobilgeräte sowie Screenreader-Tests (und andere assistive Technologien), Tests zur Lesbarkeit von Inhalten sowie (meiner Meinung nach am wichtigsten) Nutzertests in Ihren Arbeitsablauf integrieren, um die Lücken zu schließen, die automatisierte Tests hinterlassen. Vergessen Sie außerdem nicht, eine Erklärung zur Barrierefreiheit hinzuzufügen und den Nutzern eine barrierefreie Möglichkeit zu bieten, Sie bei Problemen mit Ihrer Website oder App zu kontaktieren – das trägt wesentlich zur allgemeinen Nutzererfahrung und -zufriedenheit bei.

Um Ihnen den Einstieg zu erleichtern, finden Sie hier einige hilfreiche Tools für automatisierte Tests, die wir empfehlen:

• axe für das Web
• axe für iOS
• Axe für Android
• Einblicke in die Barrierefreiheit

Was hat es mit der Barrierefreiheit auf Mobilgeräten auf sich?

Das Thema „Mobilgeräte“ kann für Menschen, die sich noch nicht mit Barrierefreiheit auskennen, sehr verwirrend sein und wird in unseren Schulungen häufig angesprochen. Manche sind überrascht, dass sehbehinderte Menschen Mobilgeräte nutzen, um beispielsweise im Internet zu surfen oder E-Mails abzurufen. Viele hatten keine Ahnung, dass Mobilgeräte über Bildschirmleseprogramme verfügen – von denen viele sogar fest integriert sind. Um ehrlich zu sein, gehörte ich vor nicht allzu langer Zeit selbst zu dieser Gruppe.

Ich erinnere mich noch gut daran, als ich zum ersten Mal live miterlebte, wie jemand einen Bildschirmleser auf dem Handy benutzte. Ich war gerade mit Rachel Olivero auf dem Weg zum Mittagessen bei einer Tech-Konferenz, als mir auffiel, dass Rachel einen Ohrstöpsel im linken Ohr trug und ihr Handy in der Hand hielt. Sie tippte wie wild auf einen schwarzen Bildschirm. Da ich wusste, dass Rachel blind ist, blieb ich stehen und fragte sie, ob sie Hilfe beim Einschalten ihres Handys brauche. Sie lachte und sagte, mit ihrem Handy sei alles in Ordnung, sie habe lediglich den Bildschirmvorhang auf ihrem iOS-Gerät aktiviert, der ihr mehr Privatsphäre vor neugierigen Blicken verschaffte.

Laut der jüngsten Screenreader-Umfrage von WebAIMnutzen 88 % der Befragten mobile Screenreader auf ihren Mobilgeräten, und diese Zahl ist in den letzten Jahren deutlich gestiegen. Von den Befragten bevorzugten 75,6 % iOS-Geräte (z. B. iPad, iPhone) mit dem Screenreader VoiceOver, gefolgt von Android-Geräten mit 22,0 %, auf denen der Screenreader TalkBack zum Einsatz kommt. Nicht nur die Zahl der mobilen Nutzer steigt, sondern 54 % der Befragten gaben an, dass sie mobile und Desktop-Bildschirmleseprogramme etwa gleich oft nutzen, was mobile Geräte nicht nur zu einer Neuheit, sondern zu einem unverzichtbaren Bestandteil des Alltags macht. Zusätzlich zum Anstieg der Nutzerzahlen konzentrieren sich viele der neuen WCAG 2.1-Richtlinien auf Probleme im mobilen Bereich , sodass der mobile Bereich ein wichtiger Aspekt ist, den es in Sachen Barrierefreiheit richtig umzusetzen gilt.

Aber wie fängt man mit der Barrierefreiheit auf Mobilgeräten an? Am einfachsten ist es, einfach Ihr Smartphone zur Hand zu nehmen und den Bildschirmleser zu aktivieren! Im Gegensatz zu den meisten Bildschirmlesern für Desktop-Computer sind mobile Bildschirmleser in der Regel bereits auf Ihrem Gerät vorinstalliert und lassen sich recht intuitiv bedienen, sobald Sie ein paar Wisch- und Tippgesten gelernt haben.

Verwendung von VoiceOver unter iOS

VoiceOver aktivieren

• Sie können VoiceOver aktivieren, indem Sie zu „Einstellungen“ > „Allgemein“ > „Barrierefreiheit“ navigieren und dort „VoiceOver“ auf „Ein“ schalten.
• Alternativ kannst du den Bildschirmleser auch über Siri aktivieren. Gehe zu „Einstellungen“ > „Siri & Suche“ > aktiviere die Option „Auf ‚Hey Siri‘ hören“. Sage dann: „Hey, Siri. Schalte VoiceOver ein.“

Kurze Demo mit VoiceOver

• Berühren Sie den Bildschirm Ihres iPhones mit einem Finger, um den Fokus auf den Hauptbildschirm der App zu setzen, und streichen Sie von links nach rechts. VoiceOver nennt den Namen der App, auf die der Fokus liegt.
• Sobald Sie sich in einer App befinden, die Sie öffnen möchten, tippen Sie mit einem Finger zweimal auf eine beliebige Stelle auf dem Bildschirm, um die App zu starten.

VoiceOver deaktivieren

• Sie können VoiceOver deaktivieren, indem Sie zu „Einstellungen“ > „Allgemein“ > „Barrierefreiheit“ navigieren und dort „VoiceOver“ auf „Aus“ schalten.
• Oder du kannst den Bildschirmleser mit Siri ausschalten. Sag einfach: „Hey, Siri. Schalte VoiceOver aus.“

iOS VoiceOver-Ressourcen

• Anleitungen zu VoiceOver-Tastenkombinationen und Gesten – https://dequeuniversity.com/screenreaders/voiceover-ios-shortcuts
• Vollständige Liste der Befehle – http://tinyurl.com/commands-voiceover-ios

Verwendung von TalkBack unter Android

TalkBack aktivieren

• Sie können TalkBack aktivieren, indem Sie zu „Einstellungen“ > „Barrierefreiheit“ > „TalkBack“ navigieren und den Schalter auf „Ein“ stellen. Hinweis: Bei einigen Android-Geräten müssen Sie zunächst die TalkBack-App installieren.

Kurze Demo mit Talkback

• Rufen Sie eine barrierefreie Website auf, wie beispielsweise die W3C-Hauptwebsite , und nutzen Sie dazu entweder den Chrome- oder den Firefox-Webbrowser.
• Wischen Sie mit einem Finger von oben nach unten, um in TalkBack durch die Elemente zu blättern, nach denen Sie suchen möchten. Wählen Sie in dieser Demo „Überschriften“ aus.
• Streichen Sie mit einem Finger von links nach rechts, um die Seitenüberschriften der Reihe nach vom oberen bis zum unteren Rand der Seite anzuhören. Möglicherweise bemerken Sie, dass der Ton höher wird, je weiter Sie auf der Seite nach unten navigieren. Dies hilft dem Nutzer von assistiver Technologie dabei, ein Gefühl dafür zu bekommen, wie lang die Seite ist.
• Doppelklicken Sie auf eine beliebige aktivierbare Überschrift, um zu einer neuen Seite zu gelangen.

TalkBack deaktivieren

• Sie können TalkBack deaktivieren, indem Sie zu „Einstellungen“ > „Barrierefreiheit“ > „TalkBack“ navigieren.
• Tippen Sie einmal auf „TalkBack“, um die Funktion auszuwählen, und tippen Sie anschließend zweimal darauf, um den Schalter auf „AUS“ zu stellen.

TalkBack-Ressourcen

• TalkBack-Tastenkombinationen und Anleitung zu Gesten – https://dequeuniversity.com/screenreaders/talkback-shortcuts
• Vollständige Liste der Befehle – http://tinyurl.com/commands-talkback

Sobald Sie sich mit der Nutzung von Bildschirmleseprogrammen auf Mobilgeräten besser auskennen, probieren Sie doch einmal einige Ihrer Lieblingswebsites oder -Apps aus – Sie werden schnell den Unterschied zwischen barrierefreien und nicht barrierefreien Angeboten erkennen. Sobald Sie das beherrschen, können Sie zum Testen von Bildschirmleseprogrammen auf Mobilgeräten übergehen. Auf Deque finden Sie einige Tools, die Ihnen dabei ebenfalls helfen können (siehe oben)! Natürlich macht Sie die gelegentliche Nutzung Ihres mobilen Screenreaders noch nicht zum Experten. Aber hoffentlich tragen einige dieser Demos und Tests dazu bei, mehr Einfühlungsvermögen und Verständnis dafür zu entwickeln, dass digitale Barrierefreiheit nicht nur ein nettes Extra ist oder etwas, das man tut, wenn man Zeit oder Budget dafür hat – sondern etwas, das für viele Ihrer Nutzer unverzichtbar ist.

Zusammenfassung

Wie ihr an diesen fünf ILT-Fragen und -Antworten erkennen könnt, gibt es zum Thema digitale Barrierefreiheit viel zu wissen … und das ist nur die Spitze des Eisbergs! Ich hoffe, dieser Artikel hat euch geholfen, einige grundlegende Fragen zur digitalen Barrierefreiheit zu klären, und euch dazu angeregt, mehr darüber zu erfahren. Ich lade euch herzlich ein, unten oder auf Twitter einen Kommentar mit euren eigenen Fragen zu hinterlassen. Natürlich kenne ich selbst nicht alle Antworten, aber es gibt so viele tolle Leute in der Barrierefreiheits-Community, dass ich mir sicher bin, dass wir auf jede gestellte Frage eine Antwort (oder zwei, oder drei) finden können.

Abschließend möchte ich euch noch ein paar aufmunternde Worte mit auf den Weg geben. Ich verstehe, dass das Thema digitale Barrierefreiheit manchmal überwältigend sein kann, aber es ist wichtig, die Hoffnung nicht aufzugeben und weiterhin Fragen zu stellen.

„Alleine können wir so wenig erreichen, gemeinsam können wir so viel erreichen.“ – Helen Keller