Eine Handreichung der Arbeitsgruppe 03 Mobile Anwendungen
Herausgeber: Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik (Externer Link)
Version: 1.5
Sie können diese Handreichung auch als PDF herunterladen(Öffnet PDF-Dokument)
Vorwort (3 min)
Einleitung (7 min)
Vielfalt der Bedürfnisse von Nutzenden und Interaktionsmöglichkeiten (4 min)
Prüfverfahren im Vergleich (4 min)
Best Practices (6 min)
Anhang A - Annotierte Linkliste (5 min)
Anhang B - Mitgliedsliste der AG03 Mobile Anwendungen (2 min)
Mobile Anwendungen (kurz mobile Apps) werden zunehmend als Ergänzung oder sogar Ersatz für Webangebote eingesetzt. In manchen Fällen kommt man gar nicht umhin, eine mobile App zu benutzen, wenn man ein Online-Angebot wahrnehmen möchte. Zum Beispiel ist bei Banken inzwischen eine Zwei-Faktor-Authentifizierung Pflicht, und als zweiter Faktor kommt oft eine mobile App zum Einsatz. Der Gesetzgeber hat in der EU-Richtlinie 2016/2102 vom 26.10.2016 alle öffentlichen Stellen dazu verpflichtet, mobile Apps und ihre integrierten Inhalte barrierefrei zu gestalten.
Diese Handreichung soll eine erste Einführung und Orientierung über das Thema barrierefreie mobile Apps geben. Sie richtet sich an Designende, Entwickelnde und Testende von mobilen Apps, aber ebenso an das Management, Qualitätsbeauftragte und Beauftragte für Barrierefreiheit an öffentlichen Stellen und anderen Organisationen.
Diese Handreichung informiert über die vielfältigen Bedürfnisse von Nutzenden, insbesondere von Nutzenden mit körperlichen, kognitiven oder anderweitigen Einschränkungen. Darüber hinaus erläutert sie die unterschiedlichen Arten von mobilen Anwendungen wie native Apps und Webapps. Sie gibt zudem eine Einführung in die gängigen Screenreader auf mobilen Plattformen. Sie enthält auch eine Gegenüberstellung von drei in Deutschland verfügbaren Prüfverfahren für die Barrierefreiheit von mobilen Apps.
Diese Handreichung ersetzt jedoch keine vollständige Beratung im Entwicklungsprozess.
Für jeden Abschnitt ist eine ungefähre Lesezeit angegeben, damit Sie Ihren Zeitaufwand abschätzen können. Jeder Abschnitt beginnt mit der Formulierung von Lernzielen. Damit können Sie schnell feststellen, ob er für Sie relevant ist oder nicht. Gegebenenfalls gibt es in den Abschnitten eine kommentierte Linkliste, die Ihnen beim weiteren Studium des jeweiligen Themas helfen kann. Links, die auf englischsprachige Ressourcen verweisen, sind mit „(en)“ gekennzeichnet.
An dieser Handreichung haben verschiedene Beitragende mitgearbeitet. Sie finden die Autorenschaft jeweils am Ende eines Abschnitts.
Hinweis: Wir versuchen, in unseren Formulierungen alle Geschlechter zu berücksichtigen. Aus Gründen der Barrierefreiheit richten wir uns am Duden aus.
European Commission (2016). Directive on making public sector websites and apps more accessible (EU) 2016/2102 (2016). http://data.europa.eu/eli/dir/2016/2102/oj. Deutsche Übersetzung: https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016L2102&from=EN.
Lernziele für diesen Abschnitt:
Die Prinzipien der Web Content Accessibility Guidelines (WCAG) kennen lernen
Die Bedeutung der DIN EN 301 549 für gesetzliche Vorschriften kennen lernen
Web Accessibility Directive (WAD) in Grundzügen verstehen
European Accessibility Act (EAA) in Grundzügen verstehen
Behindertengleichstellungsgesetz (BGG) und Barrierefreie Informationstechnik-Verordnung (BITV) kennen
In dieser Einleitung werden die wichtigsten Standards und Gesetze zur Barrierefreiheit in Europa und Deutschland erklärt. Zuerst geht es um Standards (WCAG und DIN EN 301 549), dann um die Gesetze, die diese Standards gesetzlich vorschreiben (WAD, EAA, BGG und BITV).
Die Web Content Accessibility Guidelines (WCAG) teilen sich in vier Grundprinzipien auf:
Wahrnehmbarkeit
Bedienbarkeit
Verständlichkeit
Robustheit
Jedes Prinzip hat einen Schwerpunkt und fasst somit Kriterien zusammen, die diesem Punkt zuzuordnen sind. So befasst sich das Prinzip Wahrnehmbarkeit z.B. mit der Beschriftung von Grafiken oder der Zugänglichkeit von Videos (Untertitel / Audiodeskription). Im Prinzip Bedienbarkeit geht es um die Bedienung per Tastatur oder anderen Eingabegeräten. So soll sichergestellt werden, dass alle Eingabegeräte genutzt werden können, um die jeweilige Webseite oder mobile Anwendung zu bedienen. Im Prinzip Verständlichkeit geht es darum, den Inhalt gut nachvollziehen zu können. Hier wird z.B. darauf geachtet, dass Links eine sinnvolle Beschriftung haben, die gut beschreibt, was der Link tut. Ein anderer wichtiger Punkt in diesem Prinzip ist der konsistente Aufbau der Seite, so soll z.B. die Navigation immer gleich funktionieren. Auch Formulare sollen korrekt beschriftet sein und bei Fehlern den Nutzenden lesbare und nachvollziehbare Hinweise liefern. Beim Prinzip Robustheit geht es darum, dass die einzelnen Bedienelemente wie z.B. Buttons, Auswahllisten von Assistiven Technologien wie z.B. Screenreadern richtig dargestellt und von den Nutzenden bedient werden können.
Die Barrierefreiheit in Europa ist maßgeblich in der europäischen Norm DIN EN 301 549 definiert. Die Norm besteht aus diversen Kapiteln und Anhängen, die die Barrierefreiheit für verschiedene Objekte (Webseiten, mobile Anwendungen, Software, Selbstbedienungsterminals) beschreibt. Welche Kapitel und Kriterien für welches Objekt zutreffen, ist in der Tabelle A.1 (für Webseiten) und A.2 (für mobile Anwendungen) beschrieben. Für die anderen Objekte gibt es keine explizite Kriterienliste; es muss im konkreten Fall selbst ermittelt werden, welche Kriterien anwendbar sind und welche nicht.
Die WCAG-Kriterien sind in der DIN EN 301 549 in Kapitel 9 (Web) aufgeführt. Die WCAG-Kriterien werden in der DIN EN 301 549 auch auf Dokumente (Kap. 10) und Software (Kap. 11) übertragen. Somit bilden die WCAG das Grundgerüst der Barrierefreiheitsanforderungen in der DIN EN 301 549, die aber um weitere Kriterien (auch für Webseiten) in den Kapiteln 5-8 und 12-13 ergänzt werden. Um also ein Objekt barrierefrei im Sinne der DIN EN 301 549 zu machen, ist es notwendig, alle anwendbaren Kriterien aus DIN EN 301 549 zu überprüfen. Eine reine WCAG-Prüfung ist nicht ausreichend.
Die Web Accessibility Directive (WAD) wurde 2016 von der Europäischen Kommission offiziell mit dem folgenden Titel veröffentlicht: “European Commission - Directive on making public sector websites and apps more accessible (EU) 2016/2102”. Die WAD bezieht sich auf Websites und mobile Apps öffentlicher Stellen. Für Websites und mobile Apps muss eine Erklärung zur Barrierefreiheit angefertigt und ein Feedback-Mechanismus bereitgestellt werden, um Barrieren zu melden. Die WAD definiert keine technischen Kritieren zur Barrierefreiheit, sondern verweist stattdessen auf “anzuwendende Standards”, die separat per Durchführungsbeschluss festgelegt werden können. Ein solcher Durchführungsbeschluss wurde 2018 offziell mit dem folgenden Titel veröffentlicht: “Commission Implementing Decision (EU) 2018/2048 of 20 December 2018 on the harmonised standard for websites and mobile applications drafted in support of Directive (EU) 2016/2102 of the European Parliament and of the Council”. Er bestimmt, dass zur Konformität mit der WAD die Erfüllung der Kriterien aus Tabelle A.1 (für Webseiten) bzw. Tabelle A.2 (für mobile Apps) der DIN EN 301 549 v2.1.2 genügt.
Die EU-Richtlinie war bis zum 23.09.2018 von den Mitgliedsstaaten in nationales Recht umzusetzen. In Deutschland ist dies für den Bund durch das Behindertengleichstellungsgesetz (BGG) und die Barrierefreie Informationstechnik-Verordnung (BITV) geschehen. Die BITV ergänzt die Bestimmungen der WAD um zusätzliche Anwendungsbereiche und Kriterien:
Barrierefreiheit ist auch für elektronisch unterstützte Verwaltungsabläufe und für “grafische Programmoberflächen” vorgeschrieben.
Für Websites sind Erläuterungen in Leichter Sprache und in Gebärdensprache zur Verfügung zu stellen.
Für Portalseiten und bestimmte interaktive Webseiten soll ein “höchstmögliches Maß an Barrierefreiheit” angestrebt werden.
Die Länder haben für ihren Zuständigkeitsbereich entsprechende Regelungen getroffen.
Um die Barrierefreiheit für Produkte und Dienstleistungen der Privatwirtschaft zu verbessern, hat die Europäische Kommission 2019 das European Accessibility Act veröffentlicht, offiziell: “Directive (EU) 2019/882 of the European Parliament and of the Council of 17 April 2019 on the accessibility requirements for products and services”. Diese Richtlinie muss noch in deutsches Recht umgesetzt werden. Sie betrifft bestimmte Produkte und Dienstleistungen, die ab dem 28.06.2025 auch barrierefrei gestaltet werden müssen, insb. Internet-Shops, E-Books, Computer, Smartphones, Fernsehgeräte, Fernsehsendungen, Video-Player, Banken, Bankautomaten, Fahrkartenautomaten und sonstige öffentliche Terminals.
Bundesministerium der Justiz und für Verbraucherschutz (2018). Behindertengleichstellungsgesetz des Bundes. http://www.gesetze-im-internet.de/bgg/index.html
Bundesministerium der Justiz und für Verbraucherschutz (2019). Barrierefreie Informationstechnik-Verordnung (BITV). http://www.gesetze-im-internet.de/bitv_2_0/index.html
European Commission (2016). Directive on making public sector websites and apps more accessible (EU) 2016/2102 (2016). http://data.europa.eu/eli/dir/2016/2102/oj. Deutsche Übersetzung: https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016L2102&from=EN.
European Commission (2018). Commission Implementing Decision (EU) 2018/2048 of 20 December 2018 on the harmonised standard for websites and mobile applications drafted in support of Directive (EU) 2016/2102 of the European Parliament and of the Council, Pub. L. No. 32018D2048, 327 OJ L (2018). http://data.europa.eu/eli/dec_impl/2018/2048/oj/eng. Deutsche Übersetzung: http://data.europa.eu/eli/dec_impl/2018/2048/oj.
European Commission (2019). Directive (EU) 2019/882 of the European Parliament and of the Council of 17 April 2019 on the accessibility requirements for products and services, (2019). http://data.europa.eu/eli/dir/2019/882/oj. Deutsche Übersetzung: https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32019L0882&from=DE.
Lernziele für diesen Abschnitt:
Bedürfnisse von Nutzenden für Barrierefreiheit (eng. “User Accessibility Needs”, UAN) kennen lernen
Einen groben Einblick in die Bandbreite der Bedürfnisse von Nutzenden geben
Barrieren und Assistive Technologien veranschaulichen
Verschiedene Nutzende haben unterschiedliche Bedürfnisse und nutzen unterschiedliche Interaktionsmöglichkeiten im Umgang mit mobilen Apps. Durch die für mobile Apps typischen Merkmale für Eingabe (Touch, Sprache) und Ausgabe (kleiner Bildschirm, Vibration, Sprache) ergeben sich teilweise Unterschiede zu den Bedürfnissen und Interaktionsmöglichkeiten mit Desktop-Anwendungen.
Im europäischen Standard DIN EN 301 549 (Kap. 4) werden 10 generelle Bedürfnisse von Nutzenden für Barrierefreiheit (eng. “User Accessibility Needs”, UAN) definiert, welche als Bewertungsgrundlage für Barrierefreiheit herangezogen werden können. Hinweis: Im Durchführungsbeschluss (EU) 2018/1524 der europäischen Kommission sind diese 10 “User Accessibility Needs” in Abschnitt 1.3 auf 9 reduziert dargestellt - “Nutzung mit eingeschränkter Reichweite” fehlt hier.
Zur Illustration der Vielfalt der Bedürfnisse von Nutzenden für Barrierefreiheit bedient sich diese Handreichung der Accessibility Personas (en) des Government Digital Service (GDS) des Vereinigten Königreichs. Die Übersetzung der Personas ins Deutsche und die Zuordnung von “User Accessibility Needs” zu den Personas wurde von den Beitragende dieser Handreichung vorgenommen.
Hinweis: Eine Persona ist ein Modell aus dem Bereich der Mensch-Computer-Interaktion. Die Persona stellt einen Prototyp für eine Gruppe von Nutzenden dar, mit konkret ausgeprägten Eigenschaften und einem konkreten Nutzungsverhalten. Wikipedia. Persona (Mensch-Computer-Interaktion)
| Persona | Bedürfnisse von Nutzenden für Barrierefreiheit (UAN) nach DIN EN 301 549 Kap. 4 |
|---|---|
| Anne: sehbehinderte Screenreader-Nutzende | 4.2.1 Nutzung ohne Sehvermögen |
| Christoph: bewegungseingeschränkter Nutzender mit rheumatoider Arthritis | 4.2.7 Nutzung mit eingeschränkter Handhabung oder Kraft |
| Claudia: sehbehinderte Nutzende, die Vergrößerungstools und eine Bildschirmlupe benutzt | 4.2.2 Nutzung mit eingeschränktem Sehvermögen |
| Paul: Nutzender mit Asperger | 4.2.9 Verringerung von Anfallsauslösern bei Photosensibilität; 4.2.10 Nutzung mit kognitiven Einschränkungen |
| Heinz: älterer Nutzender mit mehreren Einschränkungen | 4.2.2 Nutzung mit eingeschränktem Sehvermögen; 4.2.5 Nutzung mit eingeschränktem Hörvermögen |
| Sarah: eine Nutzende, die gehörlos ist | 4.2.4 Nutzung ohne Hörvermögen |
| Simone: eine Nutzende mit Lese-Rechtschreibstörung | 4.2.10 Nutzung mit kognitiven Einschränkungen |
| Nicht durch Personas abgedeckt | 4.2.3 Nutzung ohne Farbwahrnehmung; 4.2.6 Nutzung ohne Sprachvermögen; 4.2.8 Nutzung mit eingeschränkter Reichweite |
Internetquellen:
ETSI (2021). EN 301 549 v3.2.1. Accessibility requirements for ICT products and services. Englisches PDF-Dokument des europäischen Barrierefreiheitsstandards. Kap. 4 definiert die 10 “User Accessibility Needs”.
Europäische Kommission (2018). Durchführungsbeschluss (EU) 2018/1524 der Kommission vom 11. Oktober 2018 zur Festlegung einer Überwachungsmethodik und der Modalitäten für die Berichterstattung der Mitgliedstaaten gemäß der Richtlinie (EU) 2016/2102 des Europäischen Parlaments und des Rates über den barrierefreien Zugang zu den Websites und mobilen Anwendungen öffentlicher Stellen. Deutsche Übersetzung des Durchführungsbeschlusses zur Überwachung. In Abschnitt 1.3 werden die “User Accessibility Needs” (UAN) in deutsch beschrieben, allerdings auf 9 reduziert. “Usable with limited reach” fehlt hier.
Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik. Glossar, Eintrag “User Accessibility Needs”. Definition von “User Accessibility Needs” in deutscher Sprache.
„Ich konnte meiner Schwester zum Geburtstag nicht das kaufen, was sie wollte, weil keines der Felder auf der Webseite gelabelt war.“
Anne ist 24 und lebt in Frankfurt und hat vor kurzen ihre Ausbildung
abgeschlossen. Sie arbeitet in der Verwaltung eines Krankenhauses.
Auf Grund einer genetischen Veränderung hat sie in ihrer Jugend einen Großteil
ihres Sehvermögens eingebüßt und benutzt nun einen Screenreader, um am Rechner
zu arbeiten, einzukaufen und Behördengänge zu erledigen.
Sie hat jemand, der sie an 3 Tagen in der Woche im Büro bei der Bearbeitung der Papierakten unterstützt. Es werden ansonsten vor allem Google Drive und Google Docs Dokumente verwendet. Anne arbeitet aber lieber mit Word Dokumenten, da diese besser vom Screenreader unterstützt werden.
Anne benutzt seit 8 Jahren JAWS, ein Screenreader, der Text in Sprache umwandelt
und so blinden und sehbehinderten Menschen hilft, Webinhalte zu lesen. Bei der
Arbeit hat sie JAWS auf einem Notebook, zu Hause arbeitet sie mit einem Windows
PC. Vor JAWS verwendete sie ZoomText, ein Tool zum Vergrößern des
Bildschirminhalts. Das wurde aber mit fortschreitendem Sehverlust immer
schwieriger.
Mobil benutzt Anne ein iPhone 6, das sie sich selber eingerichtet hat. Mit Apps
wie VoiceOver und SpeakScreen findet sie sich gut damit zurecht.
Eigentlich würde sie gerne ein MacBook benutzen, um viele der Features auch dort benutzen zu können, müsste aber sehr lange dafür sparen.
Anne möchte einfach jede erdenkliche Webseite einfach benutzen können.
Außerdem möchte sie in ihrer Arbeit und im Privatleben unabhängiger werden.
Wenn auf einer Webseite etwas vom Screenreader nicht oder nicht richtig
vorgelesen werden kann, was sie für ihre Arbeit benötigt, muss Anne erst
jemanden anrufen oder um Hilfe fragen, was sie sehr stört.
Ihr Screenreader kann Formulare und Formularfelder nicht richtig wiedergeben,
wenn diese nicht mit Labeln sauber beschriftet sind. Manchmal kann sie erraten,
was in die Felder muss, aber bei der Arbeit oder finanziellen Transaktionen
macht sie das nicht, weil es zu riskant ist.
Wenn sie beim Online shoppen ist, kann sie sich manchmal die Dinge nicht richtig
vorstellen, da keine Bildbeschreibungen vorhanden sind, die der Screenreader
anständig ausgeben kann.
Statt Maus oder Trackpad benutzt Anne lediglich eine Tastatur und ist echt
genervt, wenn sie erst durch eine ganze Liste von Einträgen mit der Tabtaste
springen muss, um zum eigentlichen Inhalt zu kommen.
Ohne Überschriften ist es für sie sehr schwierig, die Inhalte einer Seite schnell
zu erfassen und einen Überblick zu gewinnen.
Befolgen der Best Practices für Formulare, z.B.:
Labeln von Feldern
Fieldset und Legend Elemente benutzen
neue Informationen so einblenden, dass Screenreader sie wahrnehmen und vorlesen können
Fehlermeldungen
Warnungen
Bestätigungen
Fortschrittsanzeigen, usw.
Tastaturbedienung sicherstellen und ohne Maus arbeiten
Überschriften einsetzen, um Inhalte zu strukturieren
Sprechende Linktexte verwenden
Bilder und Grafiken mit Textalternativen versehen und Bildbeschreibungen im Text einsetzen
Ohne Maus und mit Screenreader testen
Grundsätzlich auf Barrierefreiheit testen
Mit Blinden und sehbehinderten Usern testen
Quelle: Government Digital Service (2019). Accessibility Personas. Ashleigh. Freigegeben unter Open Government License.
„Ich versuche einer Sprachsteuerung meine Sprachbefehle anzutrainieren. Bis das richtig funktioniert, benutze ich eine Tastatur, weil das weniger schmerzhaft ist als eine Maus zu nehmen.“
Christoph ist 53 und lebt zusammen mit seiner Frau Helene in Hamburg. Sie sind
gerade das erste Mal Großeltern geworden.
Er ist Buchhalter in einem großen Lebensmittelkonzern, in dem er seit 22 Jahren
arbeitet.
Vor 10 Jahren fing es mit der rheumatoiden Arthritis an und wurde stetig
stärker. Sein Arbeitgeber hilft ihm bei der passenden Einrichtung seines
Arbeitsplatzes und evaluiert jährlich die Ausstattung gemeinsam mit ihm.
Am Arbeitsplatz arbeitet er mit einem Desktop Computer, einer Tastatur mit
Handballenauflage und einem Trackball. Um die Bedienung zu erleichtern hat er
sich Tastaturshortcuts eingerichtet, die er lieber verwendet als den Trackball,
da dort nach kurzer Zeit die Schmerzen in der Hand stark zunehmen.
Vor kurzen hat er sich eine Spracherkennungssoftware installiert und denkt, dass
ihm das weiterhelfen kann. Dafür wird Christoph jetzt einiges an Zeit
investieren, um die Spracherkennung entsprechend zu trainieren.
Ein Smartphone hat Christoph nicht, nur ein einfaches Handy zum Telefonieren. Er
denkt, dass er mit einem Smartphone sowieso nichts anfangen kann, da er es nicht
richtig bedienen kann.
Christoph möchte mehr Software, die genauso einfach auch nur mit der Tastatur
bedient werden kann. Er versucht schon eine Weile einen Kalender mit Bildern
seines Enkels zu erstellen, hat aber noch keine Seite gefunden, auf der er das
ohne Mausbenutzung hätte machen können.
Wenn er mit dem Training der Spracherkennungssoftware vorangekommen ist, möchte
er überall im Web damit surfen und Inhalte bedienen können.
Es ärgert Christoph, wenn er einzelne Bereiche von Webseiten nicht mit der
Tastatur bedienen oder erreichen kann, wie zum Beispiel einige Videoplayer oder
einzelne Menüs.
Er benötigt manchmal etwas länger, um Formulare auszufüllen und hasst es, wenn
diese plötzlich ohne Vorwarnung mit einem Timeout abgebrochen werden.
Eine Menge Zeit geht für ihn verloren, wenn er durch lange Menüstrukturen tabben muss, um zum eigentlichen Inhalt zu kommen. Es wäre schön für ihn, wen er generell weniger mit Tab springen müsste und Bereiche direkt anspringen könnte.
Auch Popups stellen Christoph manchmal vor Probleme, wenn diese auftauchen, der Fokus aber irgendwo im Hintergrund bleibt und er das Popup nicht bedienen und schließen kann.
Sicherstellen, dass alle Bereiche und Elemente einer Seite für Nutzender ohne Maus oder Trackpad nur mit einer Tastatur erreicht und bedient werden können.
Die Navigation der gesamten Seite mit der Tastatur ermöglichen.
Zeitlimits entweder ausschalten oder großzügig behandeln sowie rechtzeitig vor Ablauf eines Limits Warnungen einblenden. Ermöglichen, dass der aktuelle Stand gespeichert oder das Limit verlängert werden kann.
Tabreihenfolge, Tastaturzugänglichkeit sowie ausreichenden Tastaturfokus ausführlich testen und umsetzen.
Hilfen beim Ausfüllen von Formularen anbieten, z.B. Adressvervollständigung nach Eingabe einer Postleitzahl.
Sicherstellen, dass auch Spracherkennungssoftware mit der Seite und für Eingaben auf der Seite funktioniert.
Quelle: Government Digital Service (2019). Accessibility Personas. Chris. Freigegeben unter Open Government License.
„Mit meiner Bildschirmvergrößerung kann ich endlich wieder Webseiten benutzen. Es wäre schön, wenn mehr Seiten einfacher aufgebaut wären.“
Claudia ist 54 und lebt mit ihrem Mann und ihrer 12-jährigen Tochter in
Stuttgart, die beiden anderen Kinder sind älter und studieren.
Sie ist auf Grund ihrer Diabetes und einer Augenerkrankung, Glaukom oder grüner
Star, stark sehbehindert.
Claudia arbeitet Teilzeit bei der Stadtverwaltung, wo sie früher viel unterwegs war, um Menschen vor Ort zu unterstützen. Seit ihre Sehkraft jedoch immer mehr nachgelassen hat, traut sie sich das nicht mehr zu. Jetzt arbeitet sie im Büro und hofft nach Abschluss einer Weiterbildung darauf, bald neue Sozialarbeiter ausbilden und unterstützen zu können.
Der Arbeitsplatz von Claudia umfasst einen sehr großen Bildschirm und eine mit Großschrift und gutem Kontrast sichtbare Tastatur sowie die Software ZoomText, die den Bildschirminhalt stark vergrößern kann. Zu Hause hat sie eine ähnliche Ausstattung.
Vor kurzem hat sie sich einen Kindle Fire zum Lesen gekauft. Eigentlich benutzt
sie aber lieber eine Vergrößerung und Audiobooks, um Bücher zu lesen.
Zur Kommunikation benutzt Claudia das Telefon und verwendet auf ihrem Smartphone
die Text-to-Speech Software, um Nachrichten zu verwenden. Textnachrichten
eingeben lässt sie ganz bleiben.
Claudia würde gerne einfach bei Firmen anrufen können und Dinge mündlich erledigen. Es ist leichter und schneller für sie, als Mails zu schreiben. Außerdem würde sie viel lieber übersichtliche und weniger vollgemüllte Webseiten im Internet vorfinden. Sie möchte das Wesentliche für ihre jeweilige Aufgabe schnell finden und damit dann weitermachen können.
Gelegentlich passiert es ihr bei der Benutzung von ZoomText, dass sie nebeneinander angeordnete Formularfelder übersieht und nicht horizontal scrollt. Dann kann sie nicht alle Felder ausfüllen oder übersieht Hilfetexte, wenn sie nebeneinander anstatt übereinander angeordnet sind.
Wenn mehrseitige Formulare oder Seiten nicht konsistent aufgebaut sind, verliert sie die Orientierung auf der Seite und muss mit der starken Vergrößerung sehr viel herumsuchen, um die Inhalte zu finden, die vorher in einem ähnlichen Bereich dargestellt waren.
Vor allem hasst sie Pop-Up Fenster, die außerhalb des sichtbaren Bereichs auftauchen. Ein Ton zeigt zwar an, dass da etwas neu aufgetaucht ist, aber sie muss erst viel Fläche absuchen, um das Fenster zu finden und zu schließen.
Auf dem Tablet ihres Mannes, das sie manchmal zum Surfen benutzt, könnte sie viel besser Inhalte sehen, wenn die Kontraste stark genug wären.
Best Practices für Formulare anwenden, z.B. Felder untereinander anordnen, Labels den Feldern zuordnen und genügend Abstand zwischen den Feldern lassen.
Das Layout konsistent und vorhersagbar gestalten, so dass die Seiten immer möglichst ähnlich strukturiert sind. Gleiche Bedienelemente auf den Seiten sind immer an der gleichen Stelle positioniert und funktionieren gleich.
Verwendete Farbkontraste sind mindestens mit einem Verhältnis von 4,5:1 von Text zum Hintergrund dargestellt und passen von den Farbkombinationen zueinander.
Für die Zoomfähigkeit wird responsive Design verwendet und Inhalte werden nicht als PDFs publiziert, da diese im Regelfall nicht angepasst werden können und das Zoomen zu Schwierigkeiten führen kann.
Rücksprache halten mit Nutzendern, die Zoomsoftware verwenden bzw. selber mit Zoom testen.
Quelle: Government Digital Service (2019). Accessibility Personas. Claudia. Freigegeben unter Open Government License.
„Webseiten sind so mit Ablenkungen überhäuft, dass ich Ewigkeiten brauche, um etwas zu erledigen. Ich habe das Gefühl alle Links anklicken und alles lesen zu müssen, damit mir nichts entgeht.“
Paul ist 24 und lebt mit seinen Eltern in München. Er ist auf Jobsuche, nachdem er sein Chemiestudium abgeschlossen hat. Er hat Asperger, eine Variante aus dem Autismus Spektrum, die stark beeinflusst, wie er seine Umgebung wahrnimmt und mit anderen Personen interagiert. Zudem wurde bei ihm vor kurzem eine Angststörung diagnostiziert.
Er wird sich über Selbsthilfegruppen und organisierte Gesellschaften über Möglichkeiten bei der Arbeitssuche informieren, wenn er sich bereit dafür fühlt.
Mit Technik kennt Paul sich gut aus und kann normalerweise selbst herausfinden,
wie etwas funktioniert. Am liebsten benutzt er Apps, die einfacher aufgebaut
sind als Webseiten.
Vor kurzem haben seine Eltern ihm zum Geburtstag ein Laptop geschenkt, mit dem
er gerne spielt und auch auf Jobsuche geht.
Mit persönlicher Kommunikation hat Paul Probleme, aber in den Spiel Communities chattet er gerne online. Social Media hat er aufgegeben, nachdem ihn die meisten Meldungen und Kommentare zu sehr ängstigten.
Paul wünscht sich auf Webseiten schneller zum Ziel zu kommen und Informationen
schneller und leichter finden zu können. Sehr oft gibt es zu viel zum Lesen,
dass er nicht ignorieren kann.
Für Kontakte möchte er statt dem Telefon am liebsten Web Chats benutzen, da er
so noch über das nachdenken kann, was er sagen möchte und nicht sofort antworten
muss.
Es gibt zu viele Ablenkungen. Paul wird sehr leicht abgelenkt und muss dann
alles lesen und auf alle angebotenen Links klicken. Weniger Text und Ablenkungen
würden ihm helfen.
Von hellen, blinkenden Farbfeldern, wie Werbebannern oder automatisch startende
Videos lenken ihn auch immer wieder ab. Leuchtende, helle Farben verursachen ihm
Stress.
Angebote, die nicht für Paul geeignet erscheinen, oder zu viel Wissen voraussetzen, setzen ihn unter Druck. Ebenso, wenn es keine Kontaktmöglichkeit per Chat oder E-Mail gibt bzw. diese schwierig zu finden sind. Er kann kein Telefon für Gespräche benutzen.
Vermeiden von grellen Farben, Farbwechseln oder blinken und automatisch startende Videos.
Benutzen von Untertiteln in Videos und strukturierte Texte mit Überschriften und Listen.
Die wichtigsten Informationen zu Beginn der Seite.
Ausreichende Bearbeitungszeiten in Formularen oder Speichermöglichkeiten für mögliche Time-Outs.
Einbeziehung von Usern aus dem Autismus Spektrum.
Quelle: Government Digital Service (2019). Accessibility Personas. Pawel. Freigegeben unter Open Government License.
„Ich mag es nicht Call Center anrufen zu müssen. Es ist zu laut und ich verstehe nichts.“
Heinz ist 82 und lebt mit seiner Frau in Köln. Er hat Arthritis und wird immer schwerhöriger. Er hat Grauen Star, eine Eintrübung der Linse im Auge und künstliche Hüftgelenke auf beiden Seiten.
Wenn er in geschäftigen Umgebungen ist, hat er Hörprobleme durch die Hintergrundgeräusche, und am Computer kann er die Maus nur schwer benutzen.
Zu Hause hat Heinz ein Festnetztelefon mit eingebauter Audio-Induktionsschleife, extra Verstärker und großen Tasten. Sein Handy ist ein Klapphandy mit großen Tasten, die er bedienen kann, aber er benutzt es nicht zum Nachrichten schreiben und liest auch keine Nachrichten auf seinem Handy.
Außerdem besitzt er ein Tablet, mit dem er und seine Frau sich über Videochat mit ihren Kindern und Enkeln unterhalten und auch manchmal zum Mail schreiben benutzen.
Die Hörgeräte, die Heinz in beiden Ohren trägt, enttäuschen ihn, da er die Umgebung nur lauter und nicht klarer hören kann. Er findet sie aber sehr nützlich, wenn er sie mit einer Audio-Induktionsschleife verbinden kann, wie sie zum Beispiel der Bahnhof in seinem Ort anbietet.
Heinz würde gerne bei Webseiten deutlichere Farben haben, um Dinge unterscheiden zu können. Zudem würden ihm direkte Rufnummern helfen, um über Telefon Kontakt aufnehmen zu können.
Wenn er bei Behörden offizielle Gespräche führen muss, hat er es schwer sein Gegenüber zu verstehen, wenn es keine Audioschleife gibt, oder zu viele Hintergrundgeräusche im das Verstehen erschweren. Ebenso, wenn er bei Telefonanrufen durch undeutliche Sprache nicht alles hören kann.
Durch den Grauen Star hat er Schwierigkeiten große, gleichförmige Textblöcke richtig zu lesen. Er weiß nicht, was er an seinem Computer umstellen müsste, um das zu verändern und gibt daher schnell auf.
Angebote zur Offline Kontaktaufnahme anbieten und zum Beispiel Audioschleifen oder geräuscharme Umgebungen bereitstellen.
Informationen in leichter Sprache oder leicht verständlich formulieren und auf den Webseiten durch Überschriften oder Listen strukturieren. Die wichtigsten Punkte zu Beginn der Seite darstellen.
Zu kleinen Text vermeiden, gute Kontraste verwenden und Formulare verständlich und aufgeräumt präsentieren, z.B. durch Anordnung der Felder untereinander mit der Beschreibung jeweils direkt darüber und genügend Abstand zwischen den Zeilen.
Fragen sie ältere Menschen, was diese von ihren Webangeboten halten und wie sie damit umgehen können.
Quelle: Government Digital Service (2019). Accessibility Personas. Ron. Freigegeben unter Open Government License.
„Ich beherrsche die Deutsche Gebärdensprache (DGS) und kann von den Lippen ablesen, wenn jemand deutlich spricht, aber viele Leute tun das nicht und schauen mich komisch an, wenn ich gebärde.“
Sarah ist 22 und gerade im dualen Studium zur Verwaltungsinformatikerin. Sie lebt meistens zu Hause bei ihren Eltern, wenn sie nicht unterwegs ist. Sie ist gehörlos, kann Geräusche in ihrer Umgebung oder Sprache nicht wahrnehmen. Die Gebärdensprache beherrscht sie flüssig und würde gerne mehr Leute kennen, mit denen sie so kommunizieren kann.
Neue Situationen oder Menschen kennenzulernen erfordert viel Mut und Konzentration von ihr. Sie muss sehr auf ihre Umgebung achten und bei Unbekannten intensiv auf Gesicht und Gestik achten, um etwas zu verstehen. Das macht auch ihr Studium außergewöhnlich anspruchsvoll für sie.
Mit ihrem Android Tablet chattet Sarah gerne mit Freunden, die auch die Gebärdensprache beherrschen über Videochat. Au ihrem Notebook geht das nicht immer so gut, da sie nicht immer eine gute Internetleitung hat und die Übertragung dann manchmal stockt oder asynchron ist.
Mit ihrem iPhone schreibt sie Nachrichten, zum Videochat benutzt sie es aber nicht gerne, da das Display zu klein ist, um andere gut sehen zu können.
Am liebsten hätte Sarah, dass mehr Leute Gebärdensprache beherrschen. Ihr hörender Bruder kann es ziemlich gut und sich gut mit ihr unterhalten, ihre Eltern könne die Grundlagen, aber nicht viel mehr
Auf YouTube oder bei Instagram Videos hätte Sarah gerne immer Untertitel, die auch vernünftig wiedergeben, was gerade gesagt wird, oder bei Musik auch die Liedtexte einblenden.
Vor allem ärgert sich Sarah über Inhalte, die Sound abspielen und sie die darin enthaltenen Informationen nicht bekommen kann. Auch bei Liedern oder Musikvideos hätte sie gerne die Texte und nicht nur eine Anzeige „Musik spielt“. Unterschiedliche Farben bei Dialogen fände sie auch hilfreich, um unterscheiden zu können, wer gerade spricht.
Wenn es Transkriptionen zu Videos gibt ist das auch in Ordnung, aber lange Texte sind für sie sehr schwierig zu lesen und aufzunehmen. Am besten versteht sie Gebärdensprache.
Ohne automatische Textkorrektur würde Sarah auch manchmal verzweifeln, da sie einige Schwierigkeiten mit der Schriftsprache hat.
Am meisten regt sie sich auf, wenn es gar keine Alternative für Gehörlose gibt
und zum Beispiel ihre Mutter für sie Anrufe übernehmen muss, weil keine Mail
oder Chatkommunikation angeboten wird.
Auch bei Türklingeln mit Gegensprechanlage kommt sie nicht weiter, sondern kann
immer nur sagen, dass sie nichts hört, bis dann vielleicht die Tür aufgeht, oder
sie jemand anderem folgen kann.
Ohne eine Möglichkeit bei der Eingabe ihrer Handynummer darauf hinzuweisen, dass sie Textnachrichten bekommen möchte und keine Anrufe, können ihr viele Anrufe entgehen.
Informationen und Angebote in Gebärdensprache erläutern und bei großer Nachfrage eine Übersetzung in Gebärdensprache anbieten. Ganz allgemein mehrere Kontaktmöglichkeiten anbieten und den Kontaktsuchenden die Wahl lassen, über welches Medium sie kommunizieren möchten und können. Nachfragen, was gewünscht wird und diese Wünsche berücksichtigen und umsetzen.
Texte strukturieren und mittels Überschriften in übersichtliche Blöcke aufteilen.
Videos mit Untertiteln versehen und diese auch auf Verständlichkeit und Genauigkeit überprüfen lassen. Transkripte für reinen Audioinhalt gut sichtbar bereitstellen und bei wichtigen Inhalten auch eine Erklärung in Gebärdensprache.
Quelle: Government Digital Service (2019). Accessibility Personas. Saleem. Freigegeben unter Open Government License.
„Ich kann nicht gut schreiben und beim Formulare ausfüllen brauche ich ewig. In meinem Job muss das aber funktionieren und die Software, die ich verwende, hilft mir sehr.“
Mit ihrem Mann und ihren beiden Söhnen lebt Simone in Hannover. Sie arbeitet als Office Managerin in einer Webentwicklungsagentur in Laatzen bei Hannover. Sie geht mit ihrem Mann gerne spazieren an der Leine.
Die Dyslexie wurde bei ihr vor 2 Jahren offiziell diagnostiziert. Simone hat kein Problem damit, wenn die Menschen in ihrem Umfeld davon Wissen, sie spricht aber trotzdem nicht so gerne darüber.
Am Computer benutzt Simone eine spezielle Dyslexie Software, die ihr die Texte und Webseiten vorliest und ihr beim Schreiben Unterstützung bietet. Mit der Software kann sie gut Texte schreiben, fragt aber bei wichtigen Mails lieber vorsichtshalber nochmal einen Kollegen, um Korrektur lesen zu lassen. Durch zusätzliche Farbhervorhebungen kann sie sich längere Schreiben strukturieren und wichtige Stellen markieren.
Mit ihrem Smartphone telefoniert sie viel und für Social Media und Audiobooks benutzt sie ein Tablet, mit dem sie auch manchmal Online einkauft.
Auch wenn ihre Familie und die Kollegen ihr immer gerne helfen, möchte Simone gerne selbstständiger und selbstsicherer werden. Neue Sachen zu lernen fallen ihr schwer, und sie möchte auch nicht immer um Hilfe bitten müssen.
Als Hobby häkelt sie recht viel und gut und würde liebend gerne einige ihrer Sachen auch online verkaufen. Allerdings weiß sie nicht, wie sie das anfangen soll.
Durch die Schwierigkeiten beim Schreiben benötigt Simone sehr lange beim Ausfüllen von Formularen und muss immer wieder ihren Mann oder einen Sohn fragen, ob alles richtig ist. Ihre Rechtschreibung ist sehr schlecht ohne Software, die sie korrigiert und Vorschläge macht könnte sie nicht arbeiten oder im Internet etwas suchen.
Inhalte, die zu komplex, zu umfangreich oder durcheinander sind, kann sie nicht entziffern und verstehen. Auch flackernde Werbebanner oder bewegende Tickerzeilen lenken sie sehr stark ab.
Texte strukturieren durch Überschriften, Absätze oder Listen. Keine langen Textblöcke ohne Orientierungsmöglichkeiten verfassen. Vermeiden von komplizierten und langen Satzkonstruktionen.
Möglichkeiten geben, um Text- oder Hintergrundfarben von Usern wechseln zu lassen und zum Beispiel Kursivschriften vermeiden.
Bei Formularen deutliche Warnung vor Timeout und eine Möglichkeit zum Zwischenspeichern anbieten.
Menschen mit Dyslexie oder anderen Sprach- und Schreibverständnisproblemen rechtzeitig in Tests einbeziehen.
Quelle: Government Digital Service (2019). Accessibility Personas. Simone. Freigegeben unter Open Government License.
Lernziele für diesen Abschnitt:
Den Unterschied zwischen verschiedenen Ansätzen zur Entwicklung von mobilen Apps verdeutlichen
Mögliche Probleme bei der Anwendung verschiedener Entwicklungsansätze aufzeigen
Auf spezifische Richtlinien für die Entwicklung von mobilen Apps verweisen
Es gibt verschiedene Arten von Apps: Native Apps, plattformübergreifende Apps und Web Apps. Hinsichtlich der Entwicklung und der sich ergebenden Barrierefreiheit gibt es wichtige Unterschiede. Bei der Entwicklung einer App steht am Anfang die Entscheidung, was für eine App erstellt werden soll. Grundlage hierfür ist auch, ob z.B. Code wiederverwendet werden soll. Hierfür eignen sich besonders native Apps oder Web Apps. Beide Arten von Apps lassen sich unter mehreren Betriebssystemen ohne oder nur mit geringen Anpassungen benutzen.
Eine native App wird in der Programmiersprache des jeweiligen Systems entwickelt und nutzt direkt die Programmierschnittstelle der jeweiligen Plattform. Bei Apples iOS ist dies z.B. die Programmiersprache Swift, bei Android die Programmiersprachen Java und Kotlin.
Für die Entwicklung von barrierefreien Apps kann durch die enge Verzahnung mit der Plattform die dort angebotenen und dokumentierten Funktionen direkt genutzt werden. Native Apps haben daher den Vorteil, dass der Entwickler den maximalen Einfluss auf die Barrierefreiheit der App hat, da die einzige Abhängigkeit hier zu den Schnittstellen des Betriebssystems besteht. Wir gehen aktuell davon aus, dass dadurch auch die maximal mögliche Barrierefreiheit erreicht werden kann.
Die jeweiligen Richtlinien zur barrierefreien Entwicklung von nativen Apps zeigen auf, wie die Möglichkeiten der Plattform genutzt werden können, beispielsweise für Apple iOS (en). Die Android-Guidelines (en) umfassen sogar Hilfestellungen für die barrierefreie Gestaltung, die barrierefreie Entwicklung sowie zum Testen während der Entwicklung.
Eine Alternative zu den nativen Apps stellen plattformübergreifende oder cross-platform Apps dar. Dabei wird die App zunächst auf der Basis eines speziellen Frameworks entwickelt, statt für eine bestimmte Plattform. Vereinfacht gesagt ist eine solche mit einem entsprechenden Framework entwickelte App erstmal plattformunabhängig. Das Framework erlaubt oftmals die Nutzung von vorgefertigten Bausteinen und Funktionen. Erst im letzten Schritt wird die auf diese Weise entwickelte App automatisiert an die Zielplattform „angepasst“.
Damit die App auf der Zielplattform funktioniert, wird eine Runtime (Laufzeitumgebung) benötigt. Diese führt den Code aus und stellt die Verbindung zum Betriebssystem her. Für die Barrierefreiheit bedeutet dies, dass im Fall der plattformübergreifenden Apps zwei Komponenten für die Barrierefreiheit verantwortlich sind. Zum Einen die App selbst, in der alle angebotenen Barrierefreiheitsfunktionen korrekt konfiguriert werden müssen. Zum Anderen die Laufzeitumgebung, die alle in der App konfigurierten Barrierefreiheitsfunktionen korrekt an die jeweiligen Schnittstellen des Betriebssystems weiterreichen muss. Für die Entwicklung einer App stehen also nur die Barrierefreiheitsfunktionen zur Verfügung, die sowohl vom eingesetzten Framework inklusive der Laufzeitumgebung, als auch vom jeweiligen Betriebssystem unterstützt werden.
Zur optimalen Umsetzung der Barrierefreiheit muss unter Umständen auf die Dokumentation des jeweiligen Frameworks zurückgegriffen werden, da die in der Dokumentation des Betriebssystems beschriebenen Funktionen im Framework eventuell nicht zur Verfügung stehen. Beispiele für solche Frameworks sind (ohne Anspruch auf Vollständigkeit) Qt (en), Xamarin (en) oder Flutter (en).
Bei der Nutzung von Frameworks sollte immer die aktuelle Version verwendet werden Grund hierfür ist, dass neue oder verbesserte Funktionen der Barrierefreiheit von den Herstellern als neue Funktionalität (englisch: Feature) und nicht als Fehlerbehebung (englisch: Bug) angesehen werden. In der Konsequenz werden diese nur in neuen Versionen umgesetzt. Eine entsprechende Aktualisierung in älteren Versionen findet häufig nicht statt. Auch kann der erreichbare Grad der Barrierefreiheit einer App davon abhängen, wie gut das verwendete Framework diese jeweiligen Funktionen implementiert hat.
Da sich die Barrierefreiheitsfunktionen der beiden großen Betriebssysteme Android und iOS unterscheiden, sollte beim Einsatz von Frameworks im Vorfeld der Entwicklung geprüft werden, ob und welche Beschränkungen bei einem Einsatz bestehen.
Diese Apps basieren auf HTML-Seiten, die meist in einem gekapselten Browser dargestellt werden, der als Solches für die Nutzenden nicht zu erkennen ist. In Web Apps können alle HTML-Strukturelemente verwendet werden. Da die Darstellung mit Hilfe des Browsers erfolgt, ist auch die Zugänglichkeit identisch zu “normalen” Web-Seiten. Entwickler müssen für die Barrierefreiheit darauf achten, die Anforderungen der WCAG umzusetzen. Bei der Barrierefreiheit von Web Apps gibt es keinen Unterschied, ob diese im Browser auf dem Desktop oder als Web App auf dem mobilen Endgeärt dargestellt wird. Allerdings sollte bei der Gestaltung beachtet werden, dass sich das Aussehen und das Bedienverhalten nicht an einer Web-Seite, sondern an den Gestaltungsrichtlinien der jeweiligen Plattform und an den Bediengewohnheiten der Nutzenden orientiert. Dies ist für eine gute und effiziente Bedienung der Web App entscheidend und sollte explizit im Entwicklungsprozess aufgegriffen werden.
Eine besondere Form der Apps stellen die sogenannten hybriden Apps dar. Diese sind in der Regel eine Mischung aus der nativen oder plattformübergreifenden App, in der z.B. Inhalte als HTML dargestellt werden. Ein Beispiel hierfür sind Apps von Nachrichtenplattformen, in denen die einzelnen Artikel aus dem jeweiligen Web-Angebot eingebettet werden.
Lernziel für diesen Abschnitt:
Den Einstieg in die Nutzung von mobilen Screenreadern erleichtern
Aktuell gibt es am Markt zwei große Plattformen für mobile Betriebssysteme. Die eine Seite stellt Apple dar. Das Unternehmen produziert sowohl Hardware und entwickelt gleichzeitig Software. Dabei ist zu beachten, dass es das Betriebssystem iOS für die iPhones und iPadOS für die iPads gibt. Die andere Seite umfasst das Betriebssystem Android, welches hauptsächlich von Google weiterentwickelt wird. Gleichzeitig stellt Google eigene Geräte her. Neben Google gibt es zahlreiche andere Hersteller, die Mobilgeräte mit Android herstellen. In beiden Betriebssystemen ist ein Screenreader implementiert.
Bei Apple gibt es die Unterscheidung von zwei Bedienungshilfen, zum einen den Screenreader VoiceOver, welcher alle Bildschirmelemente vorliest und die Bedienung für Menschen ohne Sehvermögen möglich macht.
Die zweite Bedienungshilfe ist Zoom. Hier geht es darum, den Bildschirminhalt zu vergrößern und Kontraste anzupassen. Die Zielgruppe hier sind Nutzende mit Seheinschränkungen.
Bei Android sind die Bedienungshilfen in den Tools für die Barrierefreiheit zusammengefasst. Sie umfassen sowohl den Screenreader Talkback für blinde Menschen (eine Vorlesemöglichkeit), eine Zoomfunktion für seheingeschränkte Menschen sowie verschiedene Verbesserungsmöglichkeiten für motorisch eingeschränkte und höreingeschränkte Menschen.
Zu beachten ist, dass die Hardwarehersteller teilweise Anpassungen an Android vornehmen. Dies kann dazu führen, dass die Zugänglichkeit sowohl der Hardware als auch der Apps variiert. Für einen Test unter Android empfiehlt es sich, möglichst Geräte zu nutzen, die als Betriebssystem eine aktuelle Android-Version verwenden und auf Anpassungen verzichten. Solche Geräte werden direkt von Google, wie auch von anderen Herstellern angeboten.
Die Bedienung eines Touchscreens unterscheidet sich für Menschen ohne Sehvermögen essentiell von der Art, wie Sehende mit der Technik interagieren. Statt direkt auf ein Element zu tippen und dadurch eine Aktion auszulösen, wird bei aktiviertem Screenreader durch ein doppeltes Tippen auf eine beliebige Stelle des Bildschirms das aktuell fokussierte Element aktiviert. Durch die Wischgeste nach rechts wird der Fokus auf das nächste Element, durch ein Wischen nach links auf das vorherige Element gelegt.
Bei einem Wechsel des Fokus (z. B. durch die Wischgeste oder Bewegen des Fingers über den Bildschirm) wird das neu fokussierte Element vorgelesen.
Um blinden Menschen die Bedienung des Touchscreens zu ermöglichen, wird die Bedienung des Displays verändert. So muss bei aktiviertem Screenreader jedes Element doppelt angetippt werden, bevor es aktiviert werden kann.
Darüber hinaus gibt es zahlreiche weitere Gesten, welche die Navigation auf dem Bildschirm und innerhalb von Apps erleichtern und ermöglichen. Diese können Sie den nachfolgenden Referenzen entnehmen.
Apple. iPhone mit VoiceOver-Gesten bedienen. Die wichtigsten Gesten für VoiceOver werden erklärt, nach Funktionsgruppen geordnet.
Google. Touch-Gesten in TalkBack. Die verschiedenen Arten von Gesten für TalkBack werden in Tabellen aufgeführt.
Apple hat die beiden Screenreader unter dem Begriff “Bedienungshilfen” zusammengefasst. Diese sind aktuell im Menü “Einstellungen” zu finden.
Wenn man das Menü “Einstellungen > Bedienungshilfen” öffnet, kann man sowohl VoiceOver als auch Zoom aktivieren. Wählt man VoiceOver aus, so wird man direkt von Apple darauf hingewiesen, dass sich die Bedienung des Telefons grundlegend ändert.
Es können diverse Einstellungen für VoiceOver vorgenommen werden, die im Detail von Apple auf den entsprechenden Seiten beschrieben werden.
Um nun zu erfahren, wie barrierefrei die App mit VoiceOver ist, sollte der Screenreader, wie oben beschrieben, aktiviert werden. Anschließend kann die entsprechende App gestartet werden.
Die App kann dann über die Wischgeste „ein Finger nach links oder rechts“ erkundet werden. Damit bewegt man sich nun von Element zu Element.
VoiceOver sollte jedes Element sinnvoll sprechen. Es sollte nicht nur die Art, sondern auch die Funktion des Bedienelements deutlich werden. Es sollte z.B. „Schließen“ anstatt „Schalter“ oder einer anderen kryptischen Bezeichnung gesagt werden. Auch sollte man bei diesem Test darauf achten, dass VoiceOver auch den Elementtyp, also Schalter, Überschrift, Auswahlliste, usw., spricht. Zudem sollten sich alle Elemente entsprechend bedienen lassen.
Google hat in Android die verschiedenen Bedienungshilfen unter den „Tools für die Barrierefreiheit“ zusammengefasst. Diese lassen sich auf jedem Android-Gerät aus dem PlayStore heraus installieren, sofern diese noch nicht installiert sind, oder Hersteller-eigene Bedienungshilfen installiert sind. Es empfiehlt sich, auf jedem Android-Gerät mit den „Tools für die Barrierefreiheit“ zu arbeiten.
In den Einstellungen findet man die verschiedenen Funktionen meist unter dem Punkt Bedienungungs- oder Eingabehilfen. Im entsprechenden Menüpunkt lassen sich hier nun die verschiedenen Funktionen aktivieren, so auch der Screenreader Talkback. Wird Talkback aktiviert, so wird man auch hier darauf hingewiesen, dass sich die Bedienung des Telefons grundlegend ändert.
Es können diverse Einstellungen für Talkback vorgenommen werden, die im Detail von Google beschrieben werden:
Google. Android mit TalkBack verwenden. https://support.google.com/accessibility/android/answer/6283677?hl=de. Der Screenreader Talkback ist in Android eingebaut und kann zum Blackbox-Testen auf Barrierefreiheit verwendet werden.
Google. Touch-Gesten in TalkBack. Die verschiedenen Arten von Gesten für TalkBack werden in Tabellen aufgeführt.
Um nun zu erfahren, wie barrierefrei die App mit Talkback ist, sollte der Screenreader, wie oben beschrieben, aktiviert werden. Anschließend kann die entsprechende App gestartet werden.
Die App kann dann, wie mit VoiceOver, über die Wischgeste „ein Finger nach links oder rechts“ erkundet werden. Damit bewegt man sich nun von Element zu Element.
Dabei sollte Talkback nun jedes Element sinnvoll sprechen. Es sollte nicht nur die Art, sondern auch die Funktion des Bedienelements deutlich werden. Es sollte z.B. „Schließen“ anstatt „Schalter“ oder einer anderen kryptischen Bezeichnung gesagt werden. Auch sollte man bei diesem Test darauf achten, dass Talkback den Elementtyp, wie etwa Schalter, Überschrift, Auswahlliste, usw., ansagt.
Alle der Logik nach bedienbaren Elemente sollten sich entsprechend bedienen lassen.
Mit diesen Möglichkeiten bekommt man nun einen ersten, teilweise guten, Eindruck über die Bedienbarkeit der Apps unter iOS/iPadOS und Android. Werden schon bei diesem Ersteindruck Mängel festgestellt, so sollte man die Feedbackmöglichkeiten der Apps/des jeweiligen Stores nutzen und die Probleme den Entwickelnden melden. Auch bei späteren eingehenden Tests sollte diese Möglichkeit stets genutzt werden. Damit erhalten auch die Entwickelnde ein wichtiges Feedback bezüglich der Nutzbarkeit der App durch Menschen mit unterschiedlichen Bedürfnissen.
Bei der Prüfung von mobilen Apps auf Barrierefreiheit muss man zwischen Whitebox- und Blackbox-Tests unterscheiden. Bei Whitebox-Tests haben Testende Zugang zum Programmcode und können diesen genau inspizieren. Damit kann man eine umfassende Barrierefreiheit sicherstellen. Beim Blackbox-Test haben Testende keinen Zugang zum Programmcode und können die App nur als „Nutzende“ testen. Bei Blackbox-Tests kann man keine 100-prozentige Barrierefreiheit garantieren, weil einige Kriterien ohne Programmcode nicht genau überprüft werden können.
Wenn man den Code einer App hat, kann man grundsätzlich über die Entwicklungsumgebungen von Google (Android Studio) and Apple (Xcode) Whitebox-Tests durchführen. Dazu muss man die einzelnen Kriterien aus Tabelle A.2 des DIN EN 301 549 auf Basis des Programmcodes überprüfen. Für einige der Kriterien sind auch automatische Überprüfungen in die Entwicklungsumgebungen eingebaut.
Apple. Testing for Accessibility on OS X (en). Sie können den Accessibility Inspector in Xcode verwenden, um eine iOS-App mit einem Whitebox-Test auf Barrierefreiheit zu testen.
Google. Test your app’s accessibility (en). Dieses Dokument erklärt mehrere Möglichkeiten, Android Apps auf Barrierefreiheit zu testen, u.a. mit Whitebox-Tests („Analysis tools“): Lint (integriert in Android Studio), Espresso (Test-Framework), Roboelectric (Test-Bibliothek).
Wenn man den Code einer App nicht hat, bleibt nur die Möglichkeit eines Blackbox-Tests. Viele (wenn auch nicht alle) der Kriterien aus DIN EN 301 549 Tabelle A.2 kann man durch eine Sichtprüfung der App überprüfen. Wer auch noch die Informationen aus der Accessibility API des Betriebssystems überprüfen möchte, kann dies mit Hilfe der Screenreader Talkback (Android) und VoiceOver (iOS) tun. Auf Android gibt es außerdem Werkzeuge, mit denen man auch ähnliche Überprüfungen durchführen kann. Auf iOS ist das allerdings nicht möglich, weil es aus Sicherheitsgründen dem Betriebssystem (inkl. Screenreader VoiceOver) vorbehalten ist, die Accessibility API auszulesen.
Google. Android mit TalkBack verwenden. Der Screenreader Talkback ist in Android eingebaut und kann zum Blackbox-Testen auf Barrierefreiheit verwendet werden.
Google. Test your app’s accessibility (en). Dieses Dokument erklärt mehrere Möglichkeiten, Android Apps auf Barrierefreiheit zu testen, u.a. durch Blackbox-Tests mit: Talkback, Switch Access.
Google. Accessibility Scanner. Kostenlose App zur automatischen Überprüfung (Blackbox) von Android-Apps auf Barrierefreiheit. Es wird aber nur ein kleiner Teil der Kriterien aus DIN EN 301 549 überprüft.
Apple. Aktivieren und Einüben von VoiceOver auf dem iPhone. Der Screenreader VoiceOver ist in iOS eingebaut und kann zum Blackbox-Testen auf Barrierefreiheit verwendet werden.
Hinweis: Die folgende Masterthesis gibt einen Überblick über Werkzeuge zum Testen von Apps auf Android:
Gersbacher, Pirmin (2021). Analyse von automatisierten Testverfahren für die Barrierefreiheitsprüfung von Apps im Hinblick auf den Europäischen Standard EN 301 549. Hochschule der Medien Stuttgart. https://hdms.bsz-bw.de/frontdoor/index/index/start/0/rows/10/sortfield/score/sortorder/desc/searchtype/simple/query/gersbacher/docId/6628
Lernziel für diesen Abschnitt:
Informationen über Prüfverfahren vermitteln, damit man eine für die Situation passende Auswahl treffen kann
Inhalt:
Öffentlich dokumentierte Verfahren
BITi-Softwaretest für Mobile Apps (öffentlich dokumentiert) (5 min)
BIK BITV Test für mobile Apps (öffentlich dokumentiert) (10 min)
Proprietäre Verfahren
BITV Audit (proprietär) (10 min)
Barriere-Check Pro (proprietär) (5 min)
Lernziel für diesen Abschnitt:
Informationen über das Prüfverfahren BITi vermitteln
Der BIT inklusiv (BITi) Softwaretest für Mobile Apps eignet sich zur Überprüfung der digitalen Barrierefreiheit von Applikationen auf den beiden bekannten Betriebssystemplattformen iOS und Android, die für den mobilen Einsatz entwickelt wurden.
Die Überprüfung der BITV-Konformität basiert auf den Anforderungen des DIN EN 301 549 Kapitel 11 in der Version 3.2.1.
Der BITi-Test ist anwendbar für Software, die eine Benutzeroberfläche bereitstellt. Die Anforderungen des BITi-Softwaretests gelten nicht für Webseiten und nicht für Software, die in eine Webseite integriert ist.
Der Prüfbericht enthält eine Dokumentation vorhandener Probleme hinsichtlich der digitalen Barrierefreiheit. Die Anwendung gilt als BITV-konform, wenn alle Prüfschritte „erfüllt“ oder nur als „leichte Einschränkung“ bewertet wurden.
Bei der Bewertung werden 5 Stufen unterschieden:
Erfüllt bzw. nicht anwendbar
Leichte Einschränkung (eher erfüllt)
Einschränkung (teilweise erfüllt)
Barriere (eher nicht erfüllt)
Blockade (nicht erfüllt)
Hier finden Sie alle Prüfschritte in der Übersicht.
Die genannten BIT-inklusiv-Prüfstellen haben sich auf den folgenden Qualitätskodex geeinigt:
Die Gestaltung und das Format des BIT-inklusiv-Prüfberichts kann von der Prüfstelle frei gewählt werden.
Ein BIT-inklusiv-Prüfbericht enthält jedoch immer folgende Angaben:
Nennung und Verweis auf das BIT-inklusiv-Prüfverfahren
Nennung der beteiligten Prüfenden
Zeitraum der Prüfung
Nennung des Prüfgegenstandes inklusive Versionsnummer und Beschreibung der Use-Cases
Gesamtbewertung in Textform (Zusammenfassung)
Auflistung aller Prüfschritte mit Bewertung
Nennung der Prüfumgebung, z. B. Betriebssystem, verwendete assistive Technologien
Wenn Sie Fragen zu diesem Prüfverfahren haben, wenden Sie sich bitte an:
Deutscher Verein der Blinden und Sehbehinderten in Studium und Beruf e.V. (DVBS)
Frauenbergstraße 8, 35039 Marburg
Email: kontakt@bit-inklusiv.de
Der BIK BITV-Test für mobile Apps trägt den speziellen Anforderungen von mobilen Apps an die Barrierefreiheit Rechnung und berücksichtigt daher auch Merkmale, die speziell mobile Endgeräte mitbringen.
Dem Test liegen die Kriterien des DIN EN 301 549 Tabelle A.1 zugrunde, der die W3C Web Content Accessibility Guidelines (WCAG) 2.1 A-AA enthält.
Prüfende Personen sind mit den Grundlagen der HTML-Programmierung und mit geltenden Konzepten des barrierefreien Webdesigns vertraut. Sie kennen das Verfahren des BITV- bzw. WCAG-Tests und können die Prüfschritte des Tests sicher anwenden. Der BITV-Prüfverbund hält ein festgelegtes Verfahren zur Qualifizierung von Prüfenden vor. Nur bei erfolgreichem Abschluss der Qualifizierung werden Prüfende in den Prüfverbund aufgenommen.
Das Prüfverfahren richtet sich danach, ob das Testergebnis des BITV-Tests nur für interne Zwecke benötigt wird, oder ob das Testergebnis in Form eines Prüfberichts veröffentlicht werden soll.
Wird das Ergebnis nur für interne Zwecke benötigt, so kann eine Dialogauswahl vorgegeben werden oder es wird mit der Prüfstelle besprochen, welche Dialoge getestet werden sollen. Die Dialogauswahl kann repräsentativ sein, muss es aber nicht.
Soll das Ergebnis als Prüfbericht veröffentlicht werden, wählt die Prüfstelle repräsentative Dialoge aus. Die Dialogauswahl ist der auftraggebenden Organisation nicht bekannt.
Wenn die Konformität mit den gesetzlichen Vorgaben erreicht werden soll, werden in der Regel zwei Tests benötigt:
Ein BITV-Test, sinnvollerweise mit repräsentativer Dialogauswahl. Dieser ermittelt den Stand der Barrierefreiheit, der ausführliche Prüfbericht unterstützt bei der Optimierung.
Es folgt ein weiterer, vollständiger Re-Test (mit leicht veränderter Dialogauswahl). Dieser bestätigt im Idealfall die Konformität einer optimierten mobilen App.
Um Konformität zu erreichen, darf kein Prüfschritt schlechter als “eher erfüllt” bewertet worden sein. Sollte dieses Ziel bereits im ersten Test erreicht sein, entfällt der Re-Test im zweiten Schritt.
Bei komplexeren Projekten oder Anwendungen können gegebenenfalls mehrere Re-Tests sinnvoll sein.
Wenn die verbleibenden Mängel eines Re-Tests geringfügig sind, kann die Prüfstelle in Absprache mit der Qualitätssicherung die Möglichkeit anbieten, dass die auftraggebende Organisation nachbessert. Es werden dann nur noch die Nachbesserungen geprüft und kein vollständiger Re-Test durchgeführt.
Abschließend erfolgt eine Qualitätssicherung durch eine zweite Person.
Bei jedem einzelnen Prüfschritt wird die tatsächliche Relevanz des Prüfschritts für die App geprüft. Sollte ein Prüfschritt nicht nötig sein, weil zum Beispiel das zu prüfende Element nicht in der App auftritt, so ist der Prüfschritt nicht anwendbar.
Jeder einzelne Prüfschritt erläutert, warum Barrierefreiheit des zu prüfenden Elements wichtig ist, bzw. welche Auswirkung eine unzureichende Barrierefreiheit hat. Die Ergebnisse eines Tests basieren auf Einschätzungen der testenden Person und hängen nicht allein von der Einhaltung formaler Regeln ab. Um die Nachvollziehbarkeit von Ergebnissen zu gewährleisten, beinhaltet jeder Prüfschritt eine detaillierte Beschreibung der Vorgehensweise der Prüfung und Kriterien für die Bewertung. Hinweise und Abgrenzungen des Prüfschritts zu anderen Prüfschritten helfen auch ungeübteren Personen bei der Selbstbewertung (siehe BITV-Selbstbewertung) einer mobilen Anwendung.
Sofern anwendbar, haben Prüfschritt ein fünfstufiges Bewertungsschema (erfüllt / eher erfüllt / teilweise erfüllt / eher nicht erfüllt / nicht erfüllt). Eine übergeordnete BITV-Anforderung gilt nur dann als erfüllt, wenn das Testergebnis aller zu ihr gehörenden Prüfschritte, als “erfüllt” oder “eher erfüllt” bewertet wurden. Alle Bewertungen, die schlechter sind (also “teilweise erfüllt” bis “nicht erfüllt”) werden als Nicht-Erfüllung dieser Anforderung gewertet.
Wenn im Rahmen eines BITV-Tests die abschließende Prüfung ergeben hat, dass alle Dialoge der Dialogauswahl konform mit der BITV sind, so kann die App das BIK-Prüfzeichen „BIK BITV-konform“ tragen sind.
Neben dem beauftragten BITV-Test gibt es die Möglichkeit einer BITV-Selbstbewertung. Diese Option richtet sich an Personen, die eine barrierefreien Anwendung entwickeln und sich an den Vorgaben des BITV-Tests orientieren wollen. Bei der Selbstbewertung ist ein wichtiger Unterschied gegenüber dem BITV-Test, dass aus der erreichten Bewertung keine qualitative Beurteilung der mobilen App ermittelt wird.
Internetquellen:
GitHub: BIK-BITV / BIK-App-Test (en). Dokumentation der Prüfschritte des BIK BITV-Tests für mobile Apps.
Wenn Sie Fragen zu diesem Prüfverfahren haben, wenden Sie sich bitte an:
Detlev Fischer, DIAS GmbH
Email: fischer@dias.de
Das BITV-Audit ist ein Evaluationsverfahren für die Barrierefreiheit von digitalen Produkten, das von der T-Systems MMS GmbH angeboten wird.
Für die Prüfung der Barrierefreiheit von digitalen Produkten (bspw. informationsorientierte Webseiten, Webanwendungen, Software, mobile Anwendungen und Nicht-Web-Dokumente wie PDFs) setzt die T-Systems MMS GmbH ein einheitliches Evaluationsverfahren ein, das sowohl als vereinfachtes als auch als eingehendes Audit durchgeführt werden kann.
Das BITV-Audit basiert auf Anforderungen aus den folgenden Standards:
Barrierefreie Informationstechnik-Verordnung (BITV 2.0), 2019.
DIN EN 301 549:2020. Barrierefreiheitsanforderungen für IKT-Produkte und -Dienstleistungen (deutscher Text der EN 301 549:2018 v2.1.2).
W3C (2018). Web Content Accessibility Guidelines (WCAG 2.1).
DIN EN ISO 9241-171:2008. Leitlinien für die Zugänglichkeit von Software.
DIN ISO 14289-1:2016. Verbesserung der Barrierefreiheit für das Dateiformat von elektronischen Dokumenten (PDF/UA).
Das Prüfverfahren deckt damit europäische und deutsche Rechtsnormen sowie internationale Richtlinien ab.
Die Barrierefreiheit testende Person bestimmt zu Evaluationsbeginn, um welche Art Anwendung es sich handelt, bspw. Software, Web oder mobile Anwendung. Darauf basierend werden die zu prüfenden Konformitätskriterien ausgewählt.
Die Evaluation besteht aus zwei Teilen, um eine möglichst umfassende Aussage über den Status der Barrierefreiheit zu treffen: der Benutzbarkeitsprüfung und der Konformitätsprüfung.
Bei der Benutzbarkeitsprüfung handelt sich um eine empirische Expertenevaluation, bei dem die Zugänglichkeit der Anwendung aus Sicht von Nutzenden mit Beeinträchtigungen betrachtet wird. Für die Evaluation wird nach fünf Gruppen von Nutzenden unterschieden, die auf den in der DIN EN 301 549 genannten zehn Aussagen über die funktionelle Leistungsfähigkeit basieren. Im Folgenden sind diese Gruppen von Nutzenden und die für das jeweilige Prüfvorgehen eingesetzten Assistiven Technologien dargestellt.
Sehbeeinträchtigte Nutzende (Nutzung mit eingeschränktem Sehvermögen, Nutzung ohne Farbwahrnehmung): die Prüfung erfolgt unter der Verwendung einer Bildschirmlupe (ZoomText, SuperNova) sowie mit nativen Funktionen des Browsers (Zoom), Browsererweiterungen für die Kontrastprüfung (WCAG - Color Contrast Checker) bzw. des jeweiligen Betriebssystems (z. B. Kontrastanpassung);
blinde Nutzende (Nutzung ohne Sehvermögen): die Prüfung erfolgt unter Verwendung eines Screenreaders (JAWS, VoiceOver, NVDA, TalkBack);
motorisch beeinträchtigte Nutzende (Nutzung mit eingeschränkten manuellen Fähigkeiten oder Stärke, Nutzung mit eingeschränkter Reichweite): die Prüfung erfolgt unter Verwendung der Tastatur sowie einer Sprachsteuerung (NaturallySpeaking);
hörgeschädigte Nutzende (Nutzung ohne Hörvermögen, Nutzung mit eingeschränktem Hörvermögen, Nutzung ohne Sprechvermögen); und
kognitiv beeinträchtigte Nutzende (Minimale Auslöser für fotosensitive Anfälle, Nutzung mit kognitiver Beeinträchtigung).
Die eingesetzten Hilfsmittel, Browser und Media-Player werden projekt- und plattformspezifisch ausgewählt.
Bei der Konformitätsprüfung werden die in der Zugänglichkeitsprüfung festgestellten Probleme den Konformitätskriterien zugeordnet. Außerdem wird überprüft, ob weitere noch nicht betrachtete Kriterien verletzt wurden.
Jedes so festgestellte Problem wird mit Konformitätskriterium, Screenshot, Vorkommen, Ursache, Auswirkung, Gewichtung, betroffenen Personengruppen, sowie Handlungsempfehlung dokumentiert. Die Gewichtung eines Problems erfolgt nach Schwere der Auswirkung auf die jeweils betroffene Personengruppe als Zugänglichkeitsblockade, Zugänglichkeitshürde oder leichte Zugänglichkeitseinschränkung.
Für die Qualität der Evaluationsergebnisse sind die Qualifikation der Prüfenden, die Einhaltung des Evaluationsverfahrens sowie die Aufbereitung der Evaluationsberichte maßgebend.
Die Qualitätssicherung von Evaluationsberichten erfolgt im Vier-Augen-Prinzip. Im Team-Review stellt die testende Person die Ergebnisse der Evaluation in einem Walkthrough mindestens einer anderen testenden Person vor. Dabei werden Problemursachen, -Gewichtungen und ggf. Handlungsempfehlungen diskutiert. Evaluationsabschließend führt die Teamleitung ein formales Abnahme-Review des Evaluationsberichts durch.
Neben den Problembeschreibungen enthält jeder Prüfbericht eine Management Zusammenfassung mit der Gesamtbewertung der geprüften Anwendung. Die Konformitätsaussage gibt an, inwiefern die Konformität zur BITV 2.0 (konform, teilweise konform, nicht konform) besteht. Die Benutzbarkeitsaussage gibt an, wie gut die geprüfte Anwendung für die betrachteten Personengruppen zugänglich ist. Dieses Gesamtergebnis wird ergänzt um die Liste der verletzten Prüfkriterien je Personengruppe mit deren Gewichtung. Die Zusammenfassung richtet sich vor allem an das Management, die Projektleitung sowie die institutionellen Sozialpartner. Dementsprechend sind die grundlegenden Informationen zum Prüfgegenstand und zum Ergebnis enthalten, die benötigt werden, um anschließenden Maßnahmen zu planen, bspw. die Erstellung der Erklärung zur Barrierefreiheit oder die Behebung bestehender Probleme.
Das Test and Integration Center Dresden der T-Systems MMS GmbH ist ein durch die DAkkS nach DIN EN ISO/IEC 17025:2018 akkreditiertes Prüflaboratorium für multimediale, web-basierte Anwendungen und Billing-Systeme sowie Gebrauchstauglichkeit, Effizienz und Barrierefreiheit von Software-Produkten. Die Akkreditierung gilt für die in der Urkunde aufgeführten Prüfverfahren. (Registriernummer der Urkunde: D-PL-12109-01-00).
Die Einhaltung des Evaluationsverfahrens wird jährlich durch die Akkreditierung nachgewiesen.
Wenn Sie Fragen zu diesem Prüfverfahren haben, wenden Sie sich bitte an:
Kompetenzzentrum für digitale Barrierefreiheit & Software-Ergonomie, T-Systems Multimedia Solutions GmbH
Email: usercenteredtest@t-systems-mms.com
Der Barriere-Check Pro ist ein von der auf digitale Barrierefreiheit spezialisierten Agentur anatom5 entwickeltes Verfahren zur Überprüfung von Barrierefreiheit unterschiedlicher digitaler Produkte. Es handelt sich aktuell nicht um einen Konformitätstest mit dem Ziel einer Zertifizierung.
Ursprünglich wurde der Barriere-Check Pro als erweitertes Testverfahren für Webseiten und Web-basierte Anwendungen entwickelt. Seit einigen Jahren wird der Test auch als Blackbox-Test für native Apps angeboten. Darüber hinaus gibt es den Barriere-Check Pro auch als vereinfachtes Verfahren (Grobprüfung) mit reduziertem Scope. Das Evaluationsverfahren folgt vom Grundsatz her immer dem gleichen Aufbau.
Die Prüfberichte des Barriere-Check Pro sind grundsätzlich nicht zur Veröffentlichung freigegeben. Es handelt sich explizit nicht um ein Zertifizierungsverfahren. In der Regel wird der Barriere-Check Pro für interne Zwecke und/oder als Vorbereitung auf eine Zertifizierung durch einen BIK BITV Test eingesetzt. Das Verfahren orientiert sich an den relevanten Prüfschritten der EN 301549 und an der Prüfschrittbeschreibung des BIK BITV Tests bzw. des BITi-Tests, um im Falle einer späteren Zertifizierung möglichst geringe Abweichungen in der grundsätzlichen Bewertung zu erreichen.
Im Aufbau unterscheidet sich der Barriere-Check Pro vor allem in der konzeptionellen Herangehensweise. Da es bei jedem Internetauftritt, bei jeder Webanwendung und bei jeder App Funktionselemente und Seitenbereiche gibt, die auf allen Seiten identisch sind, gibt es im Barriere-Check Pro für diese Elemente und Seitenbereiche eine Sammelbewertung als Einstieg. Alle Aspekte, die in dieser Sammelbewertung bereits bemängelt wurden, werden im Rahmen der weiteren Überprüfung nicht wiederholt. Ebenso werden keine Prüfschritte aufgelistet, die erfüllt, eher erfüllt oder nicht anwendbar, also BITV-konform sind. Dadurch wird die Dokumentation insgesamt deutlich übersichtlicher. Im weiteren Verlauf der Evaluation werden dann nur noch Seitenbereiche bewertet, die in der Sammelbewertung nicht enthalten waren. Durch diese Vorgehensweise werden redundante Informationen vermieden.
In Deutschland hat sich das fünfstufige Bewertungsschema (erfüllt / eher erfüllt / teilweise erfüllt / eher nicht erfüllt / nicht erfüllt) etabliert. Dieses Schema wird sowohl vom BIK BITV Test, als auch vom BITi-Test verwendet. Beide Verfahren sind öffentlich dokumentiert. Vor diesem Hintergrund verwendet auch der Barriere-Check Pro dieses Schema. So sind Erkenntnisse aus dem Barriere-Check Pro auch für das Ziel einer Zertifizierung verwendbar. Neben diesem Bewertungsschema, welches die Anforderungen europäischer und deutscher Rechtsnormen abdeckt, berücksichtigt der Barriere-Check Pro im Einzelfall auch Normen, wie die DIN 1450 (Leserlichkeit von Schrift) oder die ISO 9241 (Richtlinien der Mensch-Computer-Interaktion) – allerdings nur als Hinweis ohne negative Bewertung im Sinne der BITV.
Jedes festgestellte Problem wird nach dem oben beschriebenen Schema dem entsprechenden Konformitätskriterium zugeordnet und mit dem Erfüllungsgrad ausgezeichnet. Zu jedem Konformitätskriterium gibt es eine kurze Erläuterung, warum und für welche Zielgruppen der Prüfschritt relevant ist. Zur Dokumentation werden Screenshots und konkrete Handlungsempfehlungen sowie die genaue Position des Problems mitgeliefert. Die Gesamtergebnisse werden als sogenannte Management Summary für einen schnellen Überblick zusammengefasst. Die Dokumentation enthält das Datum des Tests sowie die genaue Anzahl der Seiten/Ansichten, die als repräsentative Seitenauswahl für den Test herangezogen wurden. Darüber hinaus enthält die Dokumentation Informationen zu den zugrundegelegten Konformitätskriterien und zum fünfstufigen Bewertungsschema. Wenn relevant werden auch Informationen zur Prüfumgebung, also zum Beispiel Betriebssystem, Browser und Browsereinstellungen, Screenreader-Version oder auch benutzerdefinierte Einstellungen benannt.
Bei Webseiten und webbasierten Anwendungen wird darüber hinaus noch geprüft, ob eine Erklärung zur Barrierefreiheit vorhanden ist. Weiterhin wird auf die jeweils geltenden Landesverordnungen verwiesen, da gegebenenfalls zusätzliche Anforderungen erfüllt werden müssen – beispielsweise Informationen in Leichter Sprache und in Gebärdensprache. Für beides wird geprüft, ob Informationen vorhanden sind. Eine fachliche Prüfung der Informationen in Leichter Sprache und in Gebärdensprache findet nicht statt. Wenn anwendbar, werden pro Test auch ca. fünf PDF-Dokumente stichprobenartig heruntergeladen und einem schnellen PDF/UA Test und einer groben Sichtprüfung unterzogen. Auf diese Weise kann auch im Rahmen des Barriere-Check Pro Auskunft darüber gegeben werden, ob die Barrierefreiheit von Dokumenten schon berücksichtigt wurde.
Die Prüfergebnisse werden als änderungsgeschützte, semantisch strukturierte Word-Dokumente geliefert. Sämtliche Abbildungen sind mit Alternativtexten versehen. Alle Informationen sind maschinenlesbar, ausreichend kontrastreich und barrierefrei zugänglich – also keine PDF-Dokumente oder komplexen Excel-Tabellen.
Für Fragen zum Prüfverfahren steht Ihnen Jörg Morsbach von der anatom5 GmbH zur Verfügung. Neben dem Barriere-Check Pro bietet er als offizieller Prüfer im BIK BITV-Test Prüfverbund auch den BIK BITV-Test an. Email: info@anatom5.de
Die folgende Tabelle soll dabei helfen, die drei vorgestellten Prüfverfahren miteinander zu vergleichen. Sie beschreibt das ursprünglich vorgesehene Vorgehen der Verfahren; diese können ggf. adaptiert werden. Keines der Testverfahren erlaubt es, dass eine Einzelperson mit Einschränkungen den Test komplett allein durchführt.
Die Tabelle darf keinesfalls als Empfehlung des Ausschusses für ein bestimmtes Prüfverfahren verstanden werden.
Bitte beachten Sie: Ein „nein“ bedeutet nicht das Fehlen eines Features. Ebenso lässt die Anzahl der „ja“ oder „nein“-Einträge keine Rückschlüsse auf die Qualität eines Prüfverfahrens zu.
| Kriterien | BITi | BIK BITV | BITV Audit | Barriere-Check Pro |
|---|---|---|---|---|
| Testdurchführung teilweise durch Betroffene möglich | ja | ja | Ja. Der Test ist auf mehrere Tester, auch Tester mit Beeinträchtigungen skalierbar. Der Betroffene muss aber Experte der Barrierefreiheit sein, er ist nicht durch sein Fähigkeitsspektrum per se qualifiziert. | Teilweise. Eine Beeinträchtigung ist kein Hinderungsgrund, aber auch keine Qualifizierung. |
| Selbsttest möglich | ja | Ja, es existieren hier aber Einschränkungen, da Schritte und Bewertungen auf Einschätzungen beruhen. | Nein. Unter anderem haben Prüfende eine spezielle Ausbildung durchlaufen, um verschiedenen Rollen einnehmen zu können. | Nein. Der Barriere-Check Pro ist ein Expertentest, der eine spezielle Ausbildung und Erfahrung erfordert. |
| Testverfahren offengelegt / transparent | Ja, alle Prüfschritte einsehbar und detailliert beschrieben. | Ja, alle Prüfschritte einsehbar und detailliert beschrieben. | Nein. Nicht alle internen Prozesse einsehbar. | Nein |
| Rollenbasiertes Testen (UANs / Persona) | nein | nein | ja, in der Benutzbarkeitsprüfung | teilweise |
| Kriterien DIN EN 301 549 | ja | ja | ja | ja |
| Testverfahren prozessorientiert oder dialogorientiert | prozessorientiert | dialogorientiert; Testen von Prozessen möglich | prozessorientiert | dialog- und/oder prozessorientiert |
| Ausbildung zum zertifizierten Tester (extern) möglich | ja, aber IAAP bevorzugt | ja | Nein. Ausbildung nur innerhalb T-Systems. | Nein |
| Wird weiterentwickelt | ja | ja, anlassbezogen | ja, Re-Akkreditierung alle 1,5 Jahre | ja, ständige Aktualisierung anhand Standards und Best Practices |
Testdurchführung teilweise durch Betroffene möglich: Können einzelne Schritte des Tests von Personen der verschiedenen UAN-Gruppen durchgeführt werden? Hier wird nicht abgebildet, ob der ganze Test von einer solchen Person durchführbar ist oder ob, eine Beteiligung notwendig ist.
Selbsttest möglich: Sind alle Prüfwerkzeuge und Prüfschritte öffentlich zugänglich?
Testverfahren offengelegt / transparent: Sind die einzelnen Schritte des Verfahrens für Dritte transparent?
Rollenbasiertes Testen (UANs / Persona): Nehmen Prüfende eine bestimmte Rolle einer Person einer UAN ein?
Kriterien DIN EN 301 549: Liegen dem Testverfahren die Kriterien der DIN EN 301 549 oder andere zu Grunde? Wenn ja, welche?
Testverfahren prozessorientiert oder dialogorientiert: Werden einzelne repräsentative Dialoge evaluiert, oder wird bei der Evaluation ein Prozess durchlaufen?
Ausbildung zum zertifizierten Tester (extern) möglich: Können externe Personen sich als zertifizierte Testende ausbilden lassen?
Wird weiterentwickelt: Gibt es Änderungen an dem Verfahren und in welchem Zyklus?
Lernziel für diesen Abschnitt:
Verständnis für eine notwendige Ansichtenauswahl entwickeln
Generell gilt es, das Thema digitale Barrierefreiheit auch bei Apps von Anfang an zu berücksichtigen. Das heißt, diese Frage fängt beim Produktkonzept an und zieht sich über alle Stufen in einem Software Development Life Cycle.
In dem hier dargestellten Best Practice Ansatz soll eine Orientierung geschaffen werden, mit welchen Fragestellungen sich Interessierte beschäftigen sollten, wenn über eine Evaluation bzw. Test einer App nachgedacht wird. Damit eine möglichste breite Abdeckung beim Testen stattfindet, sollen zwei Dinge berücksichtigt werden:
Das Testergebnis wird umso aussagekräftiger, je mehr Betroffenengruppen auch bei der Prüfung als Tester / Probanden involviert werden. Details dazu finden Sie in der Darstellung: Vielfalt der Bedürfnisse von Nutzenden und Interaktionsmöglichkeiten. Mit den Informationen können Sie entsprechende Testgruppen definieren.
Eine sorgfältige Planung der zu prüfenden Ansichten in der App ist ein weiterer möglicher Garant für eine gute Testabdeckung.
In dieser Handreichung sollen Sie Informationen und Impulse finden, die Sie in einer Testdefinition für Apps unterstützt. Diese Empfehlung enthält keine vollständige Testabdeckung, dazu sei an der Stelle auf entsprechende Fachpublikationen zur Softwareevaluation verwiesen. Ebenso ist diese Handreichung kein Ersatz für die Struktur einer eingehenden Prüfung nach EU-Durchführungsbeschluss (EU) 2018/1524.
Dieser Best Practise Ansatz empfiehlt, mit der Prüfung einer App am Ursprung anzufangen. D.h. die Prüfung fängt in dem entsprechenden App-Store an, und zwar an der Stelle, an der die entsprechende App heruntergeladen / installiert werden kann. Damit kann diese Handreichung Abstand von eventuellen Diskussionen erreichen bei Apps, die nicht in öffentlichen App-Stores zu finden sind.
In einem App Store sind üblicherweise wichtige Informationen zu finden: Name der App inkl. Kurzbeschreibung und der Herausgeber sind benannt. Wann erfolgte die Aktualisierung der App im App Store? Hier sind auch Informationen und Hinweise zur Datensicherheit hinterlegt.
Bevor ein Test gestartet wird, sollte geklärt sein, welche Nutzungsszenarien in der App abgebildet worden sind. Es sollte geklärt sein, ob ein Nutzerkonto eine zwingende Voraussetzung darstellt. Bei einigen Nutzerkontoinformationen sind eventuell Testdatasets erforderlich (z.B. eine korrekte prüfbare Adresse, evtl. Versichertendaten, eine Bankverbindung, ein valides Geburtsdatum, Daten aus Schlüsseltabellen und viele weitere mögliche Testdaten). Eine nicht uninteressante Frage ist die Nutzung in strukturschwachen Räumen. Funktioniert diese App auch offline?
Eine Auswahl an Ansichten stellt die folgende Aufstellung dar, die zugleich auch ein notwendiges Minimum beschreibt (ohne Anspruch auf Vollständigkeit): Die Startansicht, die sich bei der erstmaligen Nutzung einer App öffnet:
Hier geht es im Test um initiale Eingaben zur Nutzung der App
Die Startansicht, die sich bei der weiteren Nutzung der App öffnet:
Sind auf der Startansicht wiederkehrend andere Informationen zu erreichen, sollte hier versucht werden, eine repräsentative Auswahl zu testen
Wenn die Erklärung zur Barrierefreiheit vorhanden ist:
Hier finden Nutzende Orientierung über eventuell vorhandene Probleme der Barrierefreiheit in der App
Wenn eine Ansicht zur Kontaktaufnahme vorhanden ist:
In der Ansicht zu allen möglichen Eingabefeldern navigieren, damit sichergestellt werden kann, dass auch mit externer Tastatur alle Eingabefelder erreichbar sind
Wenn eine Ansicht zu Supportinformationen vorhanden ist:
Ein möglicher Testschwerpunkt sind Kontaktmöglichkeiten des Supports wie Emailversand, Chat, Chatbot. Genauso aber auch eventuell vorhandene Dokumentationen wie Links zu Webadressen oder eingebettete Dokumente wie PDFs. PDFs bzw. eingebettete Dokumente sollten als relevante Information für Nutzende auch barrierefrei sein.
Wenn eine Ansicht zu Datenschutzinformationen vorhanden ist, diese prüfen. Eine sinnvolle Prüfung bei Datenschutz / Kontaktinformation / Supportinformation kann an der Stelle auch der Verständlichkeit der Informationen dienen, d. h. sind die Texte in einfacher / bürgernaher Sprache oder sogar in Leichter Sprache abgebildet.
Nach den dargestellten Vorbereitungen kann jetzt eine Evaluation / ein Test der mobilen App gestartet werden. Durch Ihre Vorarbeiten und den dabei erhobenen Nutzungsszenarien können Sie jetzt die App testen. Ein Hinweis an der Stelle: Bitte beachten Sie bei Ihren Testdurchführungen, dass Sie alle Nutzungsbedürfnisse berücksichtigen. Nicht immer sind die Testanforderungen (insbesondere bei der Nutzung von assistiven Technologien) deckungsgleich. Wird z. B. mit der Persona eines blinden Nutzers getestet, werden andere technologische Anforderungen bedient, als wenn Sie mit der Persona eines physisch Eingeschränkten testen. Hinweis: Haben Sie technologische Bausteine zur Suche in der App, testen Sie diese bitte auch mit unterschiedlichen Suchmethoden, damit sich ändernde Suchergebnisse in den Test kommen. Eventuell verhält sich ein Suchergebnis, das über mehr als eine Seite geht, anders in der Bedienung als ein einseitiges Suchergebnis.
Dieses Dokument beschreibt keine vollständige Evaluation nach Durchführungsbeschluss.
Überwachungsstellen testen im Rahmen der eingehenden Übverwachung Apps nach EN 301 549 und Stand der Technik.
Eine Prüfung von herunterladbaren Dokumenten ist hier nicht berücksichtigt.
Nachfolgend werden alle in der Handreichung enthaltenen Links zu externen Quellen aufgelistet, in alphabetischer Reihenfolge.
Apple. Aktivieren und Einüben von VoiceOver auf dem iPhone. Der Screenreader VoiceOver ist in iOS eingebaut und kann zum Blackbox-Testen auf Barrierefreiheit verwendet werden.
Apple. iPhone mit VoiceOver-Gesten bedienen. https://support.apple.com/de-de/guide/iphone/iph3e2e2329/ios. Die wichtigsten Gesten für VoiceOver werden erklärt, nach Funktionsgruppen geordnet.
Apple. Testing for Accessibility on OS X (en). https://developer.apple.com/library/archive/documentation/Accessibility/Conceptual/AccessibilityMacOSX/OSXAXTestingApps.html. Sie können den Accessibility Inspector in Xcode verwenden, um eine iOS-App mit einem Whitebox-Test auf Barrierefreiheit zu testen.
Bundesministerium der Justiz und für Verbraucherschutz (2018). Behindertengleichstellungsgesetz des Bundes. http://www.gesetze-im-internet.de/bgg/index.html
Bundesministerium der Justiz und für Verbraucherschutz (2019). Barrierefreie Informationstechnik-Verordnung (BITV 2.0). http://www.gesetze-im-internet.de/bitv_2_0/index.html
DIN (2008). DIN EN ISO 9241-171:2008, Ergonomie der Mensch-System-Interaktion - Teil 171: Leitlinien für die Zugänglichkeit von Software; Deutsche Fassung EN ISO 9241-171:2008. Beuth Verlag GmbH. https://doi.org/10.31030/1426650
DIN (2016). DIN ISO 14289-1:2016, Dokumentenmanagementanwendungen - Verbesserung der Barrierefreiheit für das Dateiformat von elektronischen Dokumenten - Teil 1: Anwendung der ISO_32000-1 (PDF/UA-1) (ISO 14289-1:2014). Beuth Verlag GmbH. https://doi.org/10.31030/2588241
DIN (2020). DIN EN 301 549. Barrierefreiheitsanforderungen für IKT-Produkte und -Dienstleistungen; Englische Fassung EN 301 549 V2.1.2 (2018-08); Text Deutsch. Beuth-Verlag. https://www.beuth.de/de/norm/din-en-301549/318391440
ETSI (2021). EN 301 549 v3.2.1. Accessibility requirements for ICT products and services. Englisches PDF-Dokument des europäischen Barrierefreiheitsstandards. Kap. 4 definiert die 10 “User Accessibility Needs”.
Europäische Kommission (2018). Durchführungsbeschluss (EU) 2018/1524 der Kommission vom 11. Oktober 2018 zur Festlegung einer Überwachungsmethodik und der Modalitäten für die Berichterstattung der Mitgliedstaaten gemäß der Richtlinie (EU) 2016/2102 des Europäischen Parlaments und des Rates über den barrierefreien Zugang zu den Websites und mobilen Anwendungen öffentlicher Stellen. https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32018D1524&from=EN. Deutsche Übersetzung des Durchführungsbeschlusses zur Überwachung. In Abschnitt 1.3 werden die “User Accessibility Needs” (UAN) in deutsch beschrieben, allerdings auf 9 reduziert. “Usable with limited reach” fehlt hier.
European Commission (2016). Directive on making public sector websites and apps more accessible (EU) 2016/2102 (2016). http://data.europa.eu/eli/dir/2016/2102/oj. Deutsche Übersetzung: https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016L2102&from=EN.
European Commission (2018). Commission Implementing Decision (EU) 2018/2048 of 20 December 2018 on the harmonised standard for websites and mobile applications drafted in support of Directive (EU) 2016/2102 of the European Parliament and of the Council, Pub. L. No. 32018D2048, 327 OJ L (2018). http://data.europa.eu/eli/dec_impl/2018/2048/oj/eng. Deutsche Übersetzung: http://data.europa.eu/eli/dec_impl/2018/2048/oj.
European Commission (2019). Directive (EU) 2019/882 of the European Parliament and of the Council of 17 April 2019 on the accessibility requirements for products and services, (2019). http://data.europa.eu/eli/dir/2019/882/oj. Deutsche Übersetzung: https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32019L0882&from=DE.
Gersbacher, Pirmin (2021). Analyse von automatisierten Testverfahren für die Barrierefreiheitsprüfung von Apps im Hinblick auf den Europäischen Standard EN 301 549. Hochschule der Medien Stuttgart. https://hdms.bsz-bw.de/frontdoor/index/index/start/0/rows/10/sortfield/score/sortorder/desc/searchtype/simple/query/gersbacher/docId/6628
Google. Accessibility Scanner. https://play.google.com/store/apps/details?id=com.google.android.apps.accessibility.auditor. Kostenlose App zur automatischen Überprüfung (Blackbox) von Android-Apps auf Barrierefreiheit. Es wird aber nur ein kleiner Teil der Kriterien aus DIN EN 301 549 überprüft.
Google. Android mit TalkBack verwenden. https://support.google.com/accessibility/android/answer/6283677?hl=de. Der Screenreader Talkback ist in Android eingebaut und kann zum Blackbox-Testen auf Barrierefreiheit verwendet werden.
Google. Test your app’s accessibility (en). https://developer.android.com/guide/topics/ui/accessibility/testing. Dieses Dokument erklärt mehrere Möglichkeiten, Android Apps auf Barrierefreiheit zu testen, u.a. mit Whitebox-Tests („Analysis tools“): Lint (integriert in Android Studio), Espresso (Test-Framework), Roboelectric (Test-Bibliothek).
Google. Touch-Gesten in TalkBack. Die verschiedenen Arten von Gesten für TalkBack werden in Tabellen aufgeführt.
Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik. Glossar, Eintrag “User Accessibility Needs”. https://www.bfit-bund.de/DE/Footer/Glossar/Functions/glossar.html?cms_lv2=1145404. Definition von “User Accessibility Needs” in deutscher Sprache.
UK Central Digital & Data Office (2017). Understanding disabilities and impairments: User profiles. https://www.gov.uk/government/publications/understanding-disabilities-and-impairments-user-profiles. GOV.UK. Eine Sammlung von Personas mit Einschränkungen: Ashleigh, Christopher, Claudia, Pawel, Ron, Saleem, Simone.
Andrew Kirkpatrick, Joshue O Connor, Alastair Campbell, & Michael Cooper (2018). Web Content Accessibility Guidelines (WCAG) 2.1. https://www.w3.org/TR/WCAG21/
Die AG03 Mobile Anwendungen hat Stand 2022-01-17 die folgenden Mitglieder:
Dirk Barkhorn, ITZBund - Informationstechnikzentrum Bund
Brigitte Bornemann
Michael Düren, Stiftung Pfennigparade
Detlef Girke, BITV-Consult
Dirk Haas, Deutsche Rentenversicherung
Stephan Heinke, Überwachungsstelle für digitale Barrierefreiheit Berlin (SenInnDS)
Barbara Koldin, Microsoft Deutschland GmbH
Thomas Langkabel Microsoft Deutschland GmbH
Erdmuthe Meyer zu Bexten, Landesbeauftragte für barrierefreie IT
Tim Neumann, In der Gemeinde leben gGmbH (PIKSL)
Ralf Niemietz, IT.NRW
Alexander Pfingstl, Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik
Jessica Probe, Dataport AöR
Oliver Riedel, Fraunhofer-Institut für Arbeitswirtschaft und Organisation IAO
Rebecca Romppel Zentralstelle für barrierefreie Informationstechnik, Bremen
Thorsten Schröder, NOW-IT GmbH
Benjamin Tannert, Hochschule Bremen
Julia Walter, BSK e.V.
Jörg Willomitzer, Fraunhofer-Institut für Angewandte und Integrierte Sicherheit (AISEC)
Gottfried Zimmermann, Kompetenzzentrum Digitale Barrierefreiheit, Hochschule der Medien, Stuttgart
Die Handreichung “Barrierefreie mobile Anwendungen” wird unter der Lizenz CC-BY-SA 4.0 veröffentlicht. Sie können Sie bearbeiten und unter Namensnennung und mit gleicher Lizenz weiterverbreiten. Wenn Sie Teile davon verändern, müssen Sie das entsprechend kennzeichnen.
Diese Handreichung hat die Version 1.5 und wurde am 28.05.2026 erstellt.
Die Deutsche Rentenversicherung Knappschaft-Bahn-See ist eine rechtsfähige Körperschaft des öffentlichen Rechts mit Selbstverwaltung und besitzt Dienstherrnfähigkeit (§ 29 SGB IV in Verbindung mit § 143 Abs. 1 SGB VI).
Dieses Impressum gilt für dieses Dokument der Arbeitsgruppen des Ausschusses für barrierefreie Informationstechnik nach § 5 BITV 2.0. Die Arbeitsgruppen werden von der Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik organisiert.
Deutsche Rentenversicherung Knappschaft-Bahn-See
Pieperstraße 14 - 28
44789 Bochum
Tel. 0234 304 - 0
Fax 0234 304 - 66050
E-Mail an die Zentrale der KBS: zentrale@kbs.de
Umsatzsteuer-Identifikationsnummer: DE 124089627
Dieses Dokument wird herausgegeben von der Deutschen Rentenversicherung Knappschaft-Bahn-See, vertreten durch die Geschäftsführung, Dr. Rainer Wilhelm.
Bundesministerium für Arbeit und Soziales
Wilhelmstraße 49
10117 Berlin
Die Inhalte dieser Handreichung werden mit größtmöglicher Sorgfalt verfasst. Unser Anspruch ist es, richtige, vollständige und aktuelle Inhalte bereitzustellen. Wir übernehmen dennoch keine Gewähr für versehentlich gemachte falsche Angaben.
Diese Handreichung enthält Verknüpfungen zu Webauftritten Dritter (“externe Links”). Wir haben bei der erstmaligen Verknüpfung zu externen Links die fremden Inhalte daraufhin überprüft, ob etwaige Rechtsverstöße bestehen. Zu diesem Zeitpunkt haben wir keine Rechtsverstöße vorgefunden. Wir haben jedoch weder Einfluss auf die aktuelle und zukünftige Gestaltung der verknüpften Seiten noch auf deren Inhalte oder Angebote. Sollten uns Rechtsverstöße bekannt werden, löschen wir die betreffenden externen Links unverzüglich. Bitte weisen Sie uns gegebenenfalls darauf hin.