Beschreibung des Prüfverfahrens (App)

1. BITV-Test (App) und WCAG2ICT-Test (App)

BIK bietet zwei Testmöglichkeiten: den BIK BITV-Test (App) und den BIK WCAG2ICT-Test (App).

• Mit dem BIK BITV-Test (App) werden die Barrierefreiheitsanforderungen überprüft, die die Barrierefreie-Informationstechnik-Verordnung (BITV) 2.0 in § 3 ‚Anzuwendende Standards‘ definiert, nämlich die Anforderungen der EN 301 549 V3.2.1 (2021-03) (PDF, 2,17 MB), im Folgenden kurz "EN". Die EN enthält für mobile Apps im Abschnitt 11 Software eine Untermenge von Anforderungen der WCAG 2.1. Darüber hinaus enthält sie weitere Anforderungen aus den Kapiteln 5, 6, 7 und 12, auf die in der Tabelle A2 des Annex A der EN verwiesen wird.

• Der BIK WCAG2ICT-Test (App) prüft eine Untermenge der Anforderungen des BIK BITV-Tests (App). Es werden die Anforderungen der Web Content Accessibility Guidelines (WCAG) 2.1 auf Konformitätsstufe AA überprüft. Die Basis sind die Anforderungen des Dokuments WCAG2ICT (W3C Working Group Note vom 5. September 2013), welches jedoch nur die Anforderungen der WCAG 2.0 enthält. Eine aktualisierte Version der Working Group Note ist in Bearbeitung. In dieser sind auch die zusätzlichen Erfolgskriterien der Version 2.1 der WCAG enthalten. Auch wenn das aktualisierte WCAG2ICT Dokument noch nicht veröffentlicht ist, enthält der BIK WCAG2ICT-Test (App) bereits diese zusätzlichen Anforderungen.

Die BITV 2.0 definiert weitere Anforderungen:

• Erläuterungen in Leichter Sprache und Gebärdensprache sind auf Websites öffentlicher Stellen verpflichtend, nicht in Apps (siehe § 4 BITV 2.0).

• Erklärung zur Barrierefreiheit: § 7 BITV 2.0 definiert, dass mobile Anwendungen öffentlicher Stellen eine ‚Erklärung zur Barrierefreiheit‘ einbinden müssen. Ein BITV App-Test kann die Grundlage für die Erklärung zur Barrierefreiheit der App liefern, da die Angaben auf der Basis einer tatsächlichen Bewertung zu erstellen sind (laut § 7 Absatz 5 BITV 2.0). Die inhaltliche Prüfung der Erklärung zur Barrierefreiheit ist aber nicht Teil des BITV- bzw. WCAG2ICT App-Tests. Sofern die Erklärung zur Barrierefreiheit in der App selbst angeboten wird, wird sie lediglich auf Barrierefreiheit überprüft, wenn sie Teil der Auswahl von Ansichten ist.

• Barrierefreie PDF-Dokumente: Zu Apps gehören ggf. auch PDF-Dokumente. Auch diese müssen barrierefrei zur Verfügung gestellt werden. Die BITV 2.0 definiert in § 3 Absatz 3: "Soweit Nutzeranforderungen oder Teile von Angeboten, Diensten oder Anwendungen nicht von harmonisierten Normen abgedeckt sind, sind sie nach dem Stand der Technik barrierefrei zu gestalten." Das bedeutet, dass für die barrierefreie Gestaltung von PDF-Dateien neben dem Abschnitt 10 (Non-web documents) der EN auch die ISO-Norm 14289-1:2012-07 (PDF/UA) berücksichtigt werden muss. Der BITV-/WCAG2ICT App-Test prüft jedoch mobile Apps in den Betriebssystemen iOS oder Android, PDF-Dokumente werden nicht geprüft, da dies ein unterschiedliches Verfahren erfordert. Gegebenenfalls muss hier eine zusätzliche Dokument-Prüfung beauftragt werden.

Ausführliche Informationen, auf was sich die Ergebnisse des BIK BITV-/WCAG-Tests beziehen, finden sich im Artikel: Die BITV 2.0 – Was prüft der BITV-Test, was prüft er nicht? (Link folgt)

1.1 Hintergrund des Prüfverfahrens

Das hier beschriebene Prüfverfahren ist angelehnt an den Leitfaden zur Prüfung von Webauftritten des W3C, die Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0.

1.2 Ansatz des BIK BITV-Test (App) Prüfverfahrens #

Die Prüfschritte im aktuellen BIK BITV-Tests (App) werden nach dem fünfstufigen Bewertungsschema (erfüllt / eher erfüllt / teilweise erfüllt / eher nicht erfüllt / nicht erfüllt) bewertet. Eine Anforderung kann jedoch nur dann mit "konform" bewertet werden, wenn untergeordnete Prüfschritte mit "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. Anforderungen wie 1.3.1 Informationen und Beziehungen, die mehrere Prüfschritte enthalten, sind demnach nur dann erfüllt, wenn alle untergeordneten Prüfschritte mit "erfüllt" oder "eher erfüllt" bewertet wurden.

1.3 Hintergrund des Bewertungsschemas

Die BITV 2.0 verweist direkt auf die geltende EN 301 549, deren Abschnitt 9 die Erfolgskriterien der WCAG 2.1 einschließlich ihrer Konformitätsbedingungen (9.6 WCAG conformance requirements, PDF) reproduziert. Der BIK BITV-Test (Web) folgt deshalb dem Konformitätsansatz der WCAG. Dieser wurde auch auf den App-Test übertragen.

Im PDF-Prüfbericht ist sowohl die abgestufte Bewertung wie auch die Konformitätsauswertung zu sehen, im HTML-Prüfbericht ist wahlweise eine Ansicht mit abgestuften Bewertungen oder die Konformitätsauswertung möglich. Das hat für Entwickler*innen und Redakteur*innen, die die Testergebnisse nutzen, den Vorteil, dass sie aus den abgestuften Bewertungen besser Prioritäten für Verbesserungen des Angebots ableiten können als aus einem erfüllt / nicht-erfüllt-Ergebnis.

1.4 Geltungsbereich der Prüfung #

Die volle Konformität einer Ansicht kann nur erreicht werden, wenn alle anwendbaren BITV-Anforderungen der EN 301 549 erfüllt sind. Entsprechend werden in der Auswertung die einzelnen Anforderungen als erfüllt / nicht erfüllt aufgelistet. Grundsätzlich lässt sich im jetzigen Konformitätsmodell der WCAG Konformität nur für einzelne Ansichten feststellen, nicht für ganze Apps oder ausgewählte Elemente oder Prozesse in diesen Apps. Sind sämtliche Ansichten einer App, oder alle Ansichten einer unabhängig vorgenommenen und repräsentativen Auswahl voll konform, gilt die App als BITV-konform.

Manche Apps mit geringerem Funktionsumfang lassen sich vollständig prüfen. Bei anderen ist die Prüfung sämtlicher Ansichten nicht realistisch. Im BIK BITV-Test (App) besteht deshalb der Anspruch, in einer dann zu treffenden Auswahl alle wichtigen Ansichten und dynamischen Zustände der App abzubilden. Prozesse müssen gemäß der in der EN referenzierten WCAG-Konformitätsanforderung „Komplette Prozesse" ganz erfasst sein. Das zugrundeliegende Testverfahren ermöglicht damit eine Einschätzung der Barrierefreiheit der gesamten App. Das Prüfzeichen "BIK-konform (geprüfte Ansichten)" weist jedoch darauf hin, dass sich der Konformitätsanspruch nur auf die tatsächlich geprüften Ansichten erstreckt. Für den Rest der App gilt nur eine Konformitätsvermutung.

Es ist auch wichtig zu verstehen, dass die Konformität einer App nur für den Zeitpunkt des Tests bestätigt werden kann. Aktualisierungen und Änderungen der App können bedeuten, dass eine einmal bestätigte Konformität möglicherweise dann nicht mehr gegeben sein kann.

2. Technische Voraussetzungen #

Um einheitliche technische Prüfvoraussetzungen sicherzustellen, werden Apps auf performanten möglichst aktuellen Mobilgeräten mit der aktuellen Version des mobilen Betriebssystems (die Plattformen sind iOS bzw. iPadOS und Android) geprüft. Ein zentraler Bestandteil bei der Prüfung ist dabei der Einsatz des Screenreaders der jeweiligen Plattform. Die prüfende Person hat in der Regel keinen Zugang zum Quelltext der App und muss deswegen Aspekte wie zum Beispiel die richtige Benennung von Bedienelementen oder die programmatische Ausgabe von Rollen, Zuständen, Statusmeldungen über die Nutzung der App mit Screenreader ermitteln.

Unter iOS bzw. iPadOS kommt der Screenreader VoiceOver in der aktuellsten Version zum Einsatz. Android-Testgeräte sind bevorzugt Google Pixel Geräte mit unverändertem Android (ohne zusätzliche Hersteller-Skins) mit dem Screenreader TalkBack. In manchen Android-Tests kommen auch Geräte von Herstellern zum Einsatz, die ein angepasstes Interface, eine sogenannte Android Skin, haben, etwa dann, wenn der Einsatzzweck die Verwendung einer möglichst weit verbreiteten Geräteklasse verlangt. Dabei werden Geräte bzw. Skins gewählt, die für gute Zugänglichkeit bekannt sind, bei Tests auf Tablets etwa der Android-Marktführer Samsung mit der Skin One UI.

Tastaturbedienbarkeit ist eine zentrale normative Anforderung auch für mobile Apps, selbst wenn sie vorrangig über die Touchbedienung genutzt werden. Zur Prüfung der Tastaturbedienbarkeit von Apps werden Geräte mit Bluetooth-Tastaturen oder über Kabel bzw. direktes Andocken von Tablet-Tastaturen wie Apples Magic Keyboard geprüft. Der Screenreader ist während der Prüfung der Tastaturbedienbarkeit abgeschaltet.

3. Rahmenbedingungen der Prüfung #

Die meisten Anforderungen der BITV an Apps können nicht automatisch geprüft werden. Basis der Prüfung ist die Prüfung durch Expert*innen, die im Umgang mit Mobilgeräten und dem Einsatz der mobilen Screenreader vertraut sind. Dieser Abschnitt beschreibt die Rahmenbedingungen der Prüfung und die erforderliche Qualifikation der Prüfenden.

3.1. Zusammenarbeit von Prüfer*innen und Qualitätssicherung #

Jeder BIK BITV-Test (App) erfährt eine umfassende externe Qualitätssicherung (QS). Der Prüfende und die beauftragte Qualitätssicherung sollen in der Regel unterschiedlichen Prüfstellen angehören, um eine unabhängige Validierung der Ergebnisse sicherzustellen. Der Konformitätstest wird von einer Prüferin oder einem Prüfer durchgeführt. Die externe QS bürgt für einen zweiten unabhängigen Blick. Sie validiert die Prüfergebnisse, gibt Rückmeldungen zu Bewertungen und Anmerkungen oder ergänzt auch Übersehenes. Die Prüfergebnisse müssen von Prüfenden entsprechend ergänzt und angepasst werden. Der Test kann nur abgeschlossen werden, wenn die QS die Umsetzung der Hinweise überprüft und den Test daraufhin freigegeben hat.

3.2. Qualifikation der Prüfer*innen #

Die Qualifikation der Prüfenden ist eine wichtige Voraussetzung für die richtige Anwendung des BITV- bzw. WCAG-Tests. Prüfende sind mit den Anforderungen der Barrierefreiheit im Detail vertraut, kennen den Umgang mit mobilen Screenreadern, und wissen, was eine barrierefreie App ausmacht. Anwärter für den BIK BITV-Test (App) sind bereits für den BIK BITV-Test (Web) qualifiziert. Sie haben sich mit dem BIK App-Test-Prüfverfahren intensiv vertraut gemacht und können die Prüfschritte sicher anwenden. Als Eingangsvoraussetzung überprüft die BIK Testentwicklung die Qualifikation neuer App-Prüfender anhand der Analyse von Prüfberichten mehrerer App-Prüfungen, die Anwärter*innen vor der Zulassung für das BIK App-Test-Prüfverfahren durchgeführt haben.

3.3 App-Prüfungen im Team-Test #

Eine Variante der App-Prüfung ist die Prüfung im Team durch sehbehinderte Prüfer*innen und sehende Assistenz bzw. einer zweiten prüfenden Person. Das BIK Prüfverfahren erlaubt das Anlegen eines Co-Prüfers oder einer Co-Prüferin, der oder die einen gleichberechtigten Zugang zum Prüfgegenstand hat. Bewertungen und Anmerkungen werden aus der gemeinsamen Prüfung heraus erarbeitet. Diese Prüfung findet häufig entfernt statt, das bedeutet, die prüfenden Personen sitzen an verschiedenen Orten. Während der Prüfung teilt in der Regel die sehbehinderte / bzw. blinde Prüfer*in den Bildschirm. Die Assistenz kann das Verhalten anhand der Erläuterungen der Prüfer*in und auch über die Verfolgung des visuellen Fokus auf der Ansicht und ggf. der Ausgabe des Screenreaders nachvollziehen. Visuelle Aspekte wie Kontraste, Bewegungen, Vergrößerbarkeit usw. prüft die sehende Assistenz. Auch im Fall der Team-Prüfung gibt es eine externe QS, die die Prüfergebnisse validiert und Rückmeldungen an das Prüf-Team liefert.

3.4. Einheitlicher Bewertungsansatz, Abstimmung von Bewertungen #

Damit Testergebnisse vergleichbar und wiederholbar sind, müssen die Prüfenden ihre Bewertungsspielräume in möglichst ähnlicher Weise nutzen. Um einen möglichst einheitlichen Bewertungsansatz im BIK Prüfverbund zu gewährleisten, gibt es verschiedene Mechanismen:

1. Die ausführlichen Rückmeldungen der Qualitätssicherung (QS) von durchgeführten Tests an die Prüfenden: Das wichtigste Instrument zur Sicherstellung eines möglichst einheitlichen Bewertungsansatzes ist der stete Austausch zwischen Prüfenden und Qualitätssicherung bei jedem durchgeführten Test. In Tests tauchen immer wieder Bewertungsfragen auf, die sowohl zwischen Prüfer*in und QS als auch darüber hinaus im Prüfverbund diskutiert und abgestimmt werden.

2. Diskussionen auf der Mailingliste: Die Prüfenden nutzen die BIK-Mailingliste, um Fragen, die sich bei der Bewertung von Apps ergeben, mit anderen BIK Prüfenden und der BIK-Testentwicklung zu diskutieren.

3. Issues und Pull Requests auf GitHub: Offene Fragen bezüglich Bewertungen und Prüfschritten können seit März 2020 öffentlich im BIK BITV-Test Repository auf GitHub mithilfe von Issues diskutiert werden. Das Anlegen solcher Issues steht allen interessierten Personen offen. Änderungsbedarfe bezüglich der Prüfschritte oder der Bewertung (etwa durch Änderungen bei Screenreadern oder der Tastatur-Unterstützung) führen gegebnenfalls zu Änderungen an den Prüfschritten über GitHub Pull Requests. Zum Ende eines Quartals wird ein neues Release der Prüfschritte veröffentlicht. Über ein Änderungsprotokoll, das auf GitHub einsehbar ist, sind die Änderungen transparent dokumentiert.

4. Workshops über Fragen der Prüfung und Bewertung: Es finden regelmäßig Online-Workshops statt, in denen BIK-Prüfende aktuelle Fragen bezüglich Prüfung und Bewertung diskutieren.

3.5. Ablauf der Qualitätssicherung #

Für jeden BITV-Test (App) wird eine gründliche Qualitätssicherung (QS) durchgeführt. Die QS muss dafür in gleicher Weise Zugang zum Prüfgegenstand haben wie die prüfende Person. Die QS prüft anhand der Ansichten sowohl die Plausibilität der Anmerkungen und Bewertungen im Prüfreport, als auch ob diese im Sinne der Prüfschrittbeschreibungen korrekt sind und der bisherigen Bewertungspraxis entsprechen. Prüfende sind angehalten, schon während des Tests offene Fragen der Bewertung der App-Ansichten mithilfe des Prüfwerkzeugs für die zuständige QS zu dokumentieren. Damit wird sichergestellt, dass diese berücksichtigt und geklärt werden. Die QS gibt detaillierte Rückmeldungen an die Prüfenden und die Prüfergebnisse werden dann auf Basis dieser Rückmeldungen ergänzt bzw. korrigiert.

4. Definition des Prüfgegenstands #

Die Festlegung des Prüfgegenstandes erfolgt in Rücksprache mit der auftraggebenden Organisation. Bei einem BITV-Test (App) ist der Prüfgegenstand in der Regel die gesamte App. Es wird geklärt, welche Ansichten und Bereiche ggf. nicht der zu prüfenden App zuzurechnen sind. Dazu können Einbindungen von Webinhalten über Webviews gehören, sofern diese deutlich abgrenzbar sind und nicht Kernprozesse der App betreffen. Bei einem BITV-Test (App) dessen Ergebnis veröffentlicht werden und damit als Konformitätsnachweis dienen soll, muss in jedem Fall nachvollziehbar sein, auf welchen Prüfgegenstand sich Prüfbericht und gegebenenfalls Prüfzeichens beziehen.

Hinweis: Die Definition des Prüfgegenstandes ist etwas anderes als die Auswahl von Ansichten. Die repräsentative Auswahl von Ansichten (siehe Abschnitt 6) wird für den definierten Prüfgegenstand vorgenommen. Die auftraggebende Organisation kann nur bei der Festlegung des Prüfgegenstandes, nicht aber bei einer repräsentativen Auswahl der zu prüfenden Ansichten mitreden. Wird eine nicht repräsentative Auswahl geprüft oder legt der Kunde eine Auswahl bestimmter Ansichten fest, sind die Ergebnisse des Tests nur intern zu nutzen. Sie dürfen dann nicht veröffentlicht oder für Konformitätsaussagen in einer Erklärung der Barrierefreiheit genutzt werden.

4.1. Was gehört zum Prüfgegenstand? #

Oft ist der Prüfgegenstand mit der Angabe der Adresse der App im jeweiligen Store – Apple App Store (iOS), Google Play Store (Android) – hinreichend klar festgelegt. In anderen Fällen werden Entwicklungsversionen über Apple TestFlight oder Android APK-Dateien geprüft. In der Regel führen Tests dieser Versionen zu keinem Ergebnis, das veröffentlicht werden kann, sondern zu Prüfberichten, die von Entwicklungsteams intern genutzt werden, es sei denn, der so vorab bereitgestellte Prüfgegenstand und die dann später veröffentlichte Version im App Store sind identisch.

Welche Ansichten in der Ansichten-Auswahl erfasst werden, ist je nach Zweck der App recht unterschiedlich. Oft gehören zum Prüfgegenstand:

• Ansicht nach Erstinstallation
• Einmalig zu durchlaufende Einführungen
• Startansicht (bei wiederholtem Launch)
• Startansicht nach Anlegen eines Nutzerprofils
• Registrierungs- und Login-Prozess, wo vorhanden
• Navigationsmenüs
• Bereichs- bzw. Übersichtsansichten, etwa Produktlisten, Verkehrsrouten, Nachrichten, Standorte, Fragen usw.
• Einzelansichten mit dazugehörigen Funktionen, etwa Filterung, Bestellvorgänge, multimediale Inhalte (Video), 3D-Ansichten
• Popover oder Dialoge, die sich auf Ansichten öffnen
• Karten, oft mit Zusatzfunktionen (Suche)
• Warenkorb und Checkout-Prozesse
• Nutzerprofil-Ansichten
• Ansichten mit App-Voreinstellungen
• Technische Dokumentation

Eingebundene Inhalte anderer Anbieter (etwa in Webviews) gehören grundsätzlich zum Prüfgegenstand. Ausgeschlossen werden können sie nur, sofern sie für Nutzende klar abgrenzbar sind und die Nutzung der wesentlichen Funktionen der App nicht betreffen. So kann man beispielsweise eine Registrierung über ein Formular in einem Webview nicht vom Prüfgegenstand ausschließen.

4.2. Zulässige Abgrenzung des Prüfgegenstandes

Es können auch Teilbereiche von Apps geprüft werden. Aber nicht jede Abgrenzung ist zulässig: Die Abgrenzung muss plausibel und akzeptabel sein. Das bedeutet: Das eigentliche Angebot kann normalerweise nicht ausgeklammert werden, die zu prüfende App muss für sich (also ohne den ausgeklammerten Bereich) sinnvoll nutzbar sein. Orientierung bietet die Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0: Sie lässt zu, Unterbereiche unabhängig von der Hauptseite zu prüfen, schließt aber aus, bei der Prüfung der Hauptseite Unterbereiche auszuklammern.

Falls nicht die gesamte App geprüft wird, muss die Abgrenzung des Prüfgegenstandes ausdrücklich festgelegt und dokumentiert werden.
Es muss leicht nachvollziehbar sein, worauf sich ein Prüfzeichen bezieht und welche Bereiche der App ausgeklammert wurden.

5. Prüfbarkeit der App #

Im Zuge der Festlegung des Prüfgegenstandes wird auch geklärt, ob eine App überhaupt sinnvoll vollumfänglich geprüft werden kann. Manchmal sind ganze Bereiche einer App aufgrund der gewählten Technologie z.B. für Screenreader oder Tastaturnutzer vollkommen unzugänglich. Hier ist gegebenenfalls an den Kunden zurückzumelden, dass eine Prüfung nicht zielführend erscheint.

6. Auswahl von Ansichten #

Bei umfangreichen Apps ist die vollständige Prüfung sämtlicher Ansichten praktisch ausgeschlossen, sie wäre zu aufwendig. Für die Prüfung werden daher einzelne Ansichten sowie deren Zustände und Prozesse ausgewählt. Diese Auswahl muss repräsentativ sein: Das Ergebnis der Prüfung soll übertragbar sein und somit für die gesamte App gelten.

Fragestellungen sind hierbei:

• Welche Ansichten sind besonders wichtig für die gesamte Nutzbarkeit des Auftritts, z.B. Eingangsseite, Login-Seiten, Formulare
• Welche Funktionalitäten bietet die App?
• Welche unterschiedlichen Typen von Ansichten sind vorhanden? Dies betrifft etwa Startansichten, Navigation, Registrierungs- oder Bestellformulare, Suche und Filterung, Karten, Produktinfos usw.
• Welche Prozesse bietet die App? Welche zusätzlichen Zustände gibt es bei Ansichten?

6.1. Analyse der App #

In einem ersten Schritt wird die App ausführlich untersucht, um ein grundsätzliches Verständnis für den Zweck, die Bedienung und die Funktionalitäten des Angebots zu erlangen.

6.2. Auswahl von Ansichten durchführen #

Nach der Analyse der App wird die Auswahl von Ansichten getroffen.

6.2.1 Alle Ansichten #

Im Idealfall können bei einfachen Apps alle Ansichten geprüft werden.

6.2.2. Unabhängige repräsentative Auswahl #

Eine repräsentative Auswahl von Ansichten hat zum Ziel, alle wichtigen Typen von Ansichten einzubeziehen und dabei die Anzahl zu prüfender Ansichten möglichst gering zu halten. So kann z.B. eine Produktseite mit Bestellformular stellvertretend für viele andere geprüft werden. Wenn ein Test veröffentlicht werden und als Konformitätsnachweis dienen soll, muss eine repräsentative Auswahl unabhängig sein, darf also nicht vom Auftraggeber vorgegeben werden. Das Ergebnis des Auswahlverfahrens darf für Außenstehende nicht vorhersehbar sein. Das verhindert, dass Auftraggeber nur jene Ansichten selektiv optimieren, die geprüft werden.

6.2.3. Anzahl der Ansichten #

Die Anzahl der auszuwählenden Ansichten richtet sich nach der Komplexität der App, also der Anzahl unterschiedlicher Inhalte und Prozesse. Bei sehr einfachen Apps können es gegebenenfalls nur zwei oder drei Ansichten sein, bei komplexen Apps sind es oft Dutzende.

6.2.4. Sämtliche Barrieren erfassen #

Das Ziel ist, mit möglichst wenigen ausgewählten Ansichten möglichst alle wesentlichen Typen von Ansichten und Prozesse und damit alle vorhandenen Barrieren zu erfassen. Erst auf dieser Basis ist eine verlässliche Aussage über die Barrierefreiheit der gesamten App möglich.

6.2.5. Ansichten, die Dokumentation bieten, miteinbeziehen (auch die "Erklärung zur Barrierefreiheit") #

Die neuen Prüfschritte aus Kapitel 12 der EN 301 549 "Dokumentation und Support" verlangen die Einbeziehung von Ansichten, die technische Dokumentation bieten (wenn vorhanden). Das betrifft etwa:

• Einstellungen der App, etwa für Benachrichtigungs-Einstellungen
• Ansichten, die bestimmte Funktionen oder auch Tastaturkurzbefehle erläutern
• Wo vorhanden, die Dokumentation zusätzlicher Barrierefreiheitsfunktionen (z.B. Vorlesefunktionen, Dark Mode, Schriftgröße, usw.)
• Die "Erklärung zur Barrierefreiheit", soweit in der App vorhanden

6.2.6. Unterschiedliche Zustände von Ansichten einbeziehen #

Viele Apps haben zusätzliche Zustände, etwa Pop-overs, Dialoge, Toast-Messages oder Fehlermeldungen, die bei Aktivierung bestimmter Elemente erscheinen. Auswahlen von Checkboxen bzw. Schaltern können weitere Bereiche einblenden. Diese Zustände müssen durch Interaktion mit der Ansicht identifiziert und in die Prüfung einbezogen werden. Dazu gehören auch unsichtbare Zustände, etwa wenn durch den Screenreader auf Elementen verfügbare Aktionen angezeigt werden.

Eine andere Kategorie von Zuständen sind Elemente, die erst nach Interaktion mit der App erscheinen, etwa nach Eingabe eines Nutzerprofils oder bestimmter Präferenzen, nach dem Abonnieren von Nachrichtenfeeds oder nach dem Auswählen, Merken, oder Bestellen von Produkten. Interaktionen können sich in verschiedener Weise und an verschiedenen Orten zeigen, etwa durch zusätzliche Einträge (wie "3 neue Nachrichten") bei Bedienelementen oder durch neue Einträge in Ansichten wie Warenkorb, Bestellhistorie, zuletzt gesuchte Transportverbindungen, präferierte Orte usw. Auch diese Zustände müssen erkannt und hervorgerufen und dann in die Prüfung einbezogen werden.

6.2.7. Prozesse einbeziehen #

Bei Apps, in denen die Abfolge zusammengehöriger Schritte einen Prozess bildet, soll der gesamte Prozess einbezogen werden. Wiederholen sich Seiten, etwa bei einem Quiz mit immer gleichem Layout, reicht die Einbeziehung eines dieser Prozess-Schritte. Wenn jedoch Prozess-Schritte neue Inhalte bieten, müssen diese in die Prüfung mit einbezogen werden.

6.3. Identifikation der Ansichten #

Damit Bewertungen nachvollziehbar sind, muss klar sein, auf welche Ansicht der App sie sich beziehen. Die für die Prüfung ausgewählten Ansichten müssen daher (in der Original-App) zu identifizieren sein. Da App-Ansichten nicht über eine URL identifizierbar sind, ist es wichtig, die jeweilige Ansicht zu benennen und den Navigationsweg zu ihr zu dokumentieren bzw. die Bedingungen zu nennen, unter denen sie Erscheint (z. B. Ansicht nach Eingabe von Suchbegriff "Hose" und Filterung nach "Damen / Jeans").

In der Dokumentation von Prüfergebnissen ist darauf zu achten, dass Mängel, die auf bestimmten Zuständen einer Ansicht auftreten, klar auf diese bezogen werden und gegebenenfalls nötige Interaktionsschritte und Orte klar benannt werden.

Wenn zusätzliche Zustände die Ansichten-Inhalte wesentlich verändern (z.B. ein komplexes Pop-over für eine Filterung aufrufen) können sie auch als weitere zu prüfende Ansicht definiert werden. Wie der Zustand aufgerufen wird, wird dann in der Auswahl der Ansichten beschrieben.

6.4 Dokumentation ausgewählter Ansichten #

Viele Apps werden häufig aktualisiert, die Prüfung ist nur eine Momentaufnahme. Bei vielen ändern sich Inhalte häufig (etwa bei eCommerce Apps). Bei der Identifikation von Ansichten sollte daher darauf geachtet werden, Ansichten generisch, aber dennoch ausreichend konkret zu beschreiben. Auch erzeugt die Prüfung selbst Änderungsbedarf: In der Prüfung ermittelte Barrieren sollen behoben werden. Prinzipiell würde es deshalb Sinn ergeben, die geprüften Ansichten zum Zeitpunkt der Prüfung zu dokumentieren. Das BIK Prüfwerkzeug erlaubt zu diesem Zweck die Einbindung von Screenshots, die oft helfen, die Ansicht zu identifizieren und Mängel konkret zuzuordnen, selbst wenn die spezifischen Inhalte nicht länger verfügbar sein sollten.

Mit dem BITV-Test bewertete Apps (nur Prüfungen, die für eine Veröffentlichung geeignet sind) können zukünftig in der Ergebnisliste BIK BITV-Test (App) (Link folgt) eingesehen werden.

7. Prüfung #

Dieser Abschnitt beschreibt den Rahmen der eigentlichen Prüfung. Grundlage für die Bewertung ist das im Verzeichnis der Prüfschritte festgelegte Verfahren. Die Prüfschritte können unabhängig voneinander bewertet werden, eine feste Reihenfolge für die Bearbeitung der Prüfschritte gibt es nicht.

7.1. Prüfgegenstand (einzelne Ansicht oder App insgesamt) #

Die meisten Prüfschritte beziehen sich auf Merkmale einzelner Ansichten. Sie können für einzelne Ansichten eines Webauftritts erfüllt sein und für andere nicht. Diese Prüfschritte müssen auf alle für die Prüfung ausgewählten Ansichten einzeln angewendet werden.

Beispiel: Auf verschiedenen Ansichten einer App werden verschiedenartige Formulare angezeigt Es kann sein, dass diese unterschiedlich umgesetzt sind. Es ist nicht ungewöhnlich, dass verschiedene Teams mit unterschiedlichen Werkzeugen und Kompetenzen für verschiedene Bereiche einer App verantwortlich sind, Die Ansichten müssen deshalb einzeln geprüft werden.

Einige Prüfschritte beziehen sich allerdings nicht auf bestimmte Ansichten, sondern auf die gesamte App. Dies sind:

• 5.2 Aktivierung von Barrierefreiheitsfunktionen
• 5.5.2 Unterscheidbarkeit der bedienbaren Elemente
• 5.6.1 Taktiler oder auditiver Status
• 5.6.2 Visueller Status
• 12.1.1 Barrierefreiheits- und Kompatibilitätsfunktionen
• 12.1.2 Barrierefreie Dokumentation
• 12.2.2 Informationen zu Barrierefreiheits- und Kompatibilitätsfunktionen
• 12.2.3 Effektive Kommunikation
• 12.2.4 Barrierefreie Dokumentation (vom Support)

Bei diesen Prüfschritten gibt es nur eine Bewertung, die für die App als Ganzes gilt.

7.2. Anwendbarkeit #

Die meisten Prüfschritte sind nur unter bestimmten Voraussetzungen anwendbar. Prüfschritt 11.3.3.2 Beschriftungen (Labels) oder Anweisungen ist zum Beispiel nur anwendbar, wenn die zu prüfende Ansicht ein Formular enthält, etwa für die Sucheingabe. Prüfschritt 12.1.2 Barrierefreie Dokumentation ist nur anwendbar, wenn innerhalb der App eine technische Dokumentation (bzw. Produktdokumentation) bereitgestellt wird. Zunächst ist daher zu klären, ob ein Prüfschritt auf die zu prüfende Ansicht oder auf die App anwendbar ist.

Bei den Prüfschritten sind Bewertungsoptionen und die Anwendbarkeit individuell festgelegt. Die Prüfschritte enthalten im Abschnitt 1. "Anwendbarkeit des Prüfschritts" jeweils detaillierte Hinweise, ob sie auf den zu prüfenden Gegenstand überhaupt anwendbar sind.

7.3. Bewertungsalternativen #

Für anwendbare Prüfschritte erfolgt anschließend die eigentliche Bewertung des Prüfschritts. Für einige wenige Prüfschritte sind nur die beiden Bewertungsalternativen "erfüllt" und "nicht erfüllt" vorgesehen.

Für andere Prüfschritte sind die Bewertungsalternativen "erfüllt", "eher erfüllt", "teilweise erfüllt", "eher nicht erfüllt" und "nicht erfüllt" möglich.

In der Ergebnisauswertung führen nach Abschluss der Prüfung alle Prüfschritte, die mit „teilweise erfüllt“ oder schlechter bewertet wurden, zu Einstufung der übergeordneten Anforderung als "nicht erfüllt". Anforderungen sind im Ergebnis nur dann "erfüllt", wenn alle zugeordneten Prüfschritte mit "eher erfüllt" oder "erfüllt" bewertet wurden (siehe Abschnitt 9).

7.4. Bewertung #

Grundlagen der Bewertung sind:

1. Die Anwendung des Prüfschritts auf den Prüfgegenstand nach dem im Abschnitt "Prüfung" beschriebenen Verfahren
2. die bisherige Bewertungspraxis (siehe Abschnitt 3.4).

Die Ergebnisse der Prüfung sollen für Dritte im Detail nachvollziehbar und nachprüfbar sein. Damit dies möglich ist, werden Bewertungen gegebenenfalls mit Anmerkungen versehen. Sobald eine Bewertung schlechter als "erfüllt" ausfällt, weil ein Mangel vorliegt, ist eine Anmerkung, die den Mangel beschreibt und sagt, welches Element der Ansicht betroffen ist, zwingend erforderlich.

Wann immer möglich sollten zusätzlich zur Beschreibung des Mangels Umsetzungsempfehlungen gegeben werden. Diese werden sich in der Regel auf die empfohlene Umsetzung bzw. das erwünschte Verhalten aus Nutzersicht beziehen, z.B. "Beschriftung und Eingabefeld gruppieren" oder "Fokus nach Öffnen des Menüs in das Menü versetzen". Der Prüfbericht enthält also in der Regel keine spezifischen technische Hinweise für die Umsetzung durch Programmierer. Die öffentlich dokumentierten Prüfschritte enthalten jedoch an vielen Stellen Links auf relevante Code-Beispiele in einer Reihe von gängigen Entwicklungsumgebungen, etwa die native Entwicklung in Android / Kotlin oder iOS / Swift oder Entwicklungs-Frameworks wie Xamarin, Flutter, oder REACT Native.

8. Auswertung BITV-Test (App) / WCAG2ICT-Test (App) #

Auf Basis der einzelnen Bewertungen wird ein HTML-Prüfbericht und parallel ein PDF-Prüfbericht erstellt. Prüfberichte von BITV-Tests von Apps mit unabhängiger und repräsentativer Auswahl von Ansichten durch die Prüfstelle können Anbieter auf Wunsch veröffentlichen, um darauf vom Prüfzeichen aus zu verlinken.

Der Bewertungsansatz hat sich durch die Aufgabe der einstmaligen Punktebewertung und der Ausrichtung an den Konformitätsansatz der WCAG deutlich verändert.

8.1. Gesamtbewertung der App #

Eine Gesamtbewertung der App wird nicht vorgenommen. Die Berechnung eines Gesamtergebnisses in Punkten (Durchschnitt der Bewertungen der Seiten in der Auswahl von Ansichten) widerspricht dem derzeitigen Konformitätsansatz der WCAG, welche Konformität nur auf Ebene einzelner Seiten betrachtet. Der BIK BITV-Test (App) überträgt den gleichen Konformitätsansicht auf Ansichten.

8.2. Bewertung für einzelne Ansichten #

Der HTML- und der PDF-Prüfbericht zeigen für jede einzelne geprüfte Ansicht, wie viele der Anforderungen nicht erfüllt wurden (BITV-Test (App): in 110 Prüfschritten werden 105 Anforderungen getestet / WCAG-Test: in 53 Prüfschritten werden 48 Anforderungen getestet).

8.3. Konformität gemäß BITV / WCAG #

Die Prüfschritte des BITV-Tests (App) basieren auf den Anforderungen der Barrierefreie-Informationstechnik-Verordnung (BITV) 2.0. Durch den direkten Verweis der im Mai 2019 aktualisierten BITV 2.0 auf die geltende EN 301 549 (aktuell: EN 301 549 V3.2.1 (2021-03) (PDF, 2,17 MB)). Die EN definiert in Annex A, Tabelle A.2 Anforderungen, die für mobile Anwendungen (falls anwendbar) gelten.

9. Umgang mit dem Bewertungsansatz gemäß WCAG #

In den Web Content Accessibility Guidelines (WCAG) 2.1 ist Konformität für eine der Konformitätsstufen (A, AA, AAA) nur dann gegeben, wenn eine Seite alle Erfolgskriterien erfüllt.

9.1. Ergebnis für einzelne Anforderungen bzw. Erfolgskriterien #

Im Test sind den Anforderungen / Erfolgskriterien ein oder mehrere Prüfschritte zugeordnet. Eine Punktebewertung und eine Gewichtung einzelner Prüfschritte sind nicht vorgesehen. In der Ergebnisdarstellung gibt es deshalb nur die Unterscheidung: Anforderung / Erfolgskriterium "erfüllt" oder "nicht erfüllt".

Für den öffentlichen Bericht werden die in der Prüfung ermittelten differenzierten Bewertungen entsprechend generiert:

• Alle Prüfschritte, die mit "teilweise erfüllt" oder schlechter bewertet wurden, bedeuten ein "nicht erfüllt" der übergeordneten Anforderung,
• Alle Prüfschritte, die mit "erfüllt oder "eher erfüllt" bewertet wurden, bedeuten ein "erfüllt" der übergeordneten Anforderung.

9.2. Umgang mit der Bewertung "eher erfüllt" #

Ist es legitim, die Anforderung / das Erfolgskriterium auch dann als "erfüllt" zu betrachten, wenn zugeordnete Prüfschritte mit "eher erfüllt" bewertet wurden?

In den WCAG ist nur die Unterscheidung "Erfolgskriterium erfüllt / nicht erfüllt" vorgesehen. In vielen Prüfschritten ist diese Bewertung aber nicht immer klar und eindeutig zu vergeben - es gibt einen Interpretationsspielraum. Ein Beispiel: Eine Grafik ist zwar mit einem Alternativtext versehen, der Alternativtext beschreibt das Bild aber nicht optimal. Im BITV-Test würde dann die Bewertung "eher erfüllt" vergeben werden. Die Auswertung nach WCAG verlangt aber eine eindeutige Antwort. Nun müssen sich Prüfende entscheiden, ob das Erfolgskriterium trotz kleiner Mängel erfüllt ist oder nicht. Setzen sie das Erfolgskriterium auf "nicht erfüllt", ist Konformität für die ganze Ansicht nicht mehr möglich.

Grundsätzlich ist ein Test nur sinnvoll, wenn es auch die Möglichkeit gibt, den Test zu bestehen. Die Konformität nach BITV bzw. WCAG soll zumindest für einzelne Ansichten ein erreichbares Ziel sein. Aus diesem Grund erscheint es legitim und sinnvoll, geringfügige Mängel zwar anzumerken und zu beschreiben, aber nicht als Knock-out-Kriterium zu bewerten.

9.3. Konformität für einzelne Ansichten #

Konformität kann gemäß WCAG (WCAG Conformance Requirements) nur für einzelne Web-Seiten definiert werden. Diesen Ansatz überträgt der BIK BITV-Test (App) auf Ansichten der App. Damit für eine Ansicht die Konformität bestätigt werden kann, müssen folgende Voraussetzungen erfüllt sein:

1. Aussagen zur Barrierefreiheit gelten für eine der drei Konformitätsstufen A, AA, AAA. Sämtliche Erfolgskriterien einer Stufe müssen erfüllt sein.

2. Die Ansicht wurde vollständig getestet, d.h. alle anwendbaren Prüfschritte wurden auf die gesamte zu testende Ansicht bezogen.

3. Bei Ansichten, die Teil eines Prozesses sind, wurde der gesamte Prozess geprüft und als konform bewertet.

4. Auf der betreffenden Ansicht werden Techniken benutzt, die von den assistiven Technologien (den systemseitigen Screenreadern) unterstützt werden.

5. Ob bei Apps die Möglichkeit von Alternativversionen für nicht barrierefreie Inhalte genutzt werden kann, ist eine offene Frage, die zurzeit im Prozess der Revision des WCAG2ICT-Dokuments diskutiert wird. Folgende Techniken sind jedoch immer störend und können in keinem Fall durch eine Alternativversion kompensiert werden:

   • Audio wird automatisch abgespielt

   • Es gibt eine Tastaturfalle
   • Sich bewegende Elemente können nicht angehalten, beendet oder ausgeblendet werden
   • Es gibt stark blinkende oder flackernde Elemente

10. Prüfbericht #

Der Prüfbericht in den Varianten HTML und PDF enthält alle Ergebnisse des Tests, nach Prüfschritten und geprüften Ansichten geordnet. So können Verantwortliche der App und Entwicklungsteams leicht sehen, wo Verbesserungen erforderlich sind. Bei Veröffentlichung des Prüfreports sind die Ergebnisse auch für Fachleute oder für Nutzende nachvollziehbar.

10.1. Inhalte des Prüfberichts #

Der Prüfbericht wird auf Basis der Ergebnisse des Tests automatisch generiert. Sowohl die HTML- als auch die PDF-Version sind barrierefrei, die PDF-Version ist PDF/UA-konform. Kern des Berichts sind die Ergebnisse (Bewertungen und Anmerkungen) der einzelnen Prüfschritte und Ansichten.

Bestandteile des Prüfberichts sind:

• Datum oder Zeitraum der Prüfung
• Name der Prüfer*in und der Prüfstelle
• Angaben zur Bestimmung des Prüfgegenstands (Store-Adresse, von der Prüfung ausgenommene Bereiche oder Elemente der App)
• Auflistung der geprüften Ansichten, Angaben zu mitgeprüften Zuständen, gegebenenfalls Erläuterungen zur Auswahl und zur Identifikation der ausgewählten Ansichten
• Ausgabe der Konformität für einzelne Ansichten
• Ergebnis für die einzelnen Prüfschritte für jede Ansicht (konform / nicht konform), gegebenenfalls mit Anmerkungen der Prüfer*in
• Verweis auf die Beschreibung des Prüfverfahrens
• Farbcodierte Spinnengrafik für den Gesamteindruck des Ergebnisses
• Tabellarische Ergebnis-Übersicht als interaktiver Index
• Screenshots zur Identifikation bzw. Ortsbestimmung von Mängeln
• QR-Code zum Aufruf des Online-Prüfberichts in der Druckversion

11. Veröffentlichung von Prüfergebnissen #

Prüfberichte von BITV-Tests (App) können veröffentlicht werden, wenn eine unabhängige und repräsentative Auswahl von Ansichten von der Prüfstelle vorgenommen wurde. Eine Veröffentlichung darf nur vollständig erfolgen, alle Angaben des Prüfberichts müssen eingeschlossen werden.

Bestandteil des Gesamtergebnisses ist die hinreichend klare Angabe des Prüfgegenstandes. Wenn die App nur teilweise geprüft worden ist, wenn also z. B. bestimmte Bereiche von der Prüfung ausgenommen worden sind, dann muss das angegeben werden. Dort, wo (z. B. mit einem Prüfzeichen) über das Prüfergebnis informiert wird, steht dann zum Beispiel: "Nicht in die Prüfung eingeschlossen war die Barrierefreiheit der über Webview eingebundenen Marketing-Information."

11.1. Verwendung der BIK-Prüfzeichen #

Es gibt zwei unterschiedliche Prüfzeichen:

• BIK BITV-Test Prüfbericht und BIK WCAG2ICT-Test Prüfbericht: Diese Prüfzeichen können Angebote tragen, die auf Basis einer unabhängigen und repräsentativen Seitenauswahl durch die Prüfstelle im BIK BITV- oder WCAG2ICT-Test geprüft wurden. Die Prüfzeichen geben keinen Hinweis auf die Bewertung und bedeutet nicht, dass das geprüfte Angebot BITV- oder WCAG2ICT-konform ist. Sie dürfen nur eingesetzt werden, wenn sie auf den online vorgehaltenen BITV-Test (App) oder WCAG2ICT-Test Prüfbericht verlinken, der bestehende Mängel detailliert aufführt.

• BIK BITV-konform (geprüfte Ansichten) und BIK WCAG2ICT-konform (geprüfte Ansichten): Diese Prüfzeichen können verwendet werden, wenn in einem BIK BITV- oder WCAG2ICT-Test für alle geprüften Ansichten einer durch die Prüfstelle vorgenommenen unabhängigen und repräsentativen Auswahl von Ansichten alle Anforderungen als "erfüllt" bewertet wurden (das heißt, alle Prüfschritte wurden mit "erfüllt" oder "eher erfüllt" bewertet). Auch diese Prüfzeichen dürfen nur eingesetzt werden, wenn sie auf den Online-Prüfbericht verlinken.

Der Anbieter der App befolgt dabei die Regeln für die Einbindung der BIK-Prüfzeichen.

BIK Prüfzeichen haben keine begrenzte Gültigkeit. Aufgrund des dokumentierten Prüfdatums im verlinkten Prüfbericht wird jedoch deutlich, wann die App geprüft wurde. Je aktueller das Datum, desto größer ist die Aussagekraft des Prüfergebnisses und umgekehrt.

11.2. Konformitätserklärung nach WCAG #

Das hier beschriebene Prüfverfahren ist an die Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0 angelehnt. Aus diesem Grund ist es möglich, neben der Bewertung einzelner Ansichten Rückschlüsse auf die Zugänglichkeit des gesamten Prüfgegenstand (gesamte App bzw. Teilbereiche) zu ziehen und eine entsprechende Erklärung abzugeben.

Der Anbieter der App befolgt dabei die Regeln für die Einbindung einer Konformitätserklärung nach WCAG.

11.3 Erklärung zur Barrierefreiheit #

Nutzt der Anbieter der App in seiner Erklärung zur Barrierefreiheit den BITV-Test (App) als Nachweis für Konformität aufgrund einer "Bewertung durch einen Dritten" (vgl. § 7 Absatz 5 BITV 2.0), kann dies nur mit Hilfe eines veröffentlichten Tests geschehen (also ein Test mit einer unabhängigen und repräsentativen Auswahl von Ansichten). Bindet der Anbieter das Prüfzeichen in seine Erklärung ein, befolgt er die damit verbundenen Regeln.

12. Nutzung des Verfahrens #

Die BIK Prüfschritte sind auf GitHub und hier auf der BITV-Test-Website unter Test-Methodik offen dokumentiert und bilden die Grundlage des BIK Prüfverfahrens.

Ein BITV-Test (App) nach dem BIK Prüfverfahren kann nur von BIK Prüfstellen durch qualifizierte BIK Prüfende durchgeführt werden. Zentral wichtig hierfür sind die im Prüfverfahren festgelegten Abläufe, die durch ausgebildete und erfahrene BIK Qualitätssichernde begleitet werden.

Aufgaben der BIK Qualitätssicherung:

• Ist das Angebot überhaupt im Konformitätstest prüfbar? Bei der Beurteilung werden die Konformitätsbedingungen der EN bzw. der WCAG (siehe EN 9.6 WCAG conformance requirements) zugrunde gelegt.
• Dürfen bestimmte Inhalte ausgeschlossen werden bzw. ist das zu prüfende Angebot von diesen klar abgrenzbar?
• Ist die Auswahl von Ansichten hinreichend repräsentativ?
• Ist die Qualität der Prüfergebnisse gut? Wurden Dinge übersehen, falsch zugeordnet oder falsch beurteilt?
• Sind Empfehlungen und Umsetzungshinweise für Entwickler korrekt und sinnvoll?

Eine Nutzung der BIK Prüfschritte außerhalb der in den BIK Prüfverfahren festgelegen Abläufe ohne BIK Qualitätssicherung ist kein BIK BITV-Test.

BIK Markenschutz #

BIK ist eine seit 2004 beim Deutschen Patent- und Markenamt eingetragene und geschützte Marke. Markenschutz besteht auch für die unter der Marke entwickelten und registrierten Dienstleistungen, etwa den BIK BITV-Test. Wir betrachten es als markenrechtlichen Verstoß, Dienstleistungen anzubieten, die identische oder ähnliche Bezeichnungen nutzen bzw. für Verbraucher*innen mit unseren BIK Dienstleistungen verwechslungsfähig sind.