Accessibility Nutrition Labels ausfüllen? App-Store-Abnahmecheckliste 2026

Was vor dem Ausfüllen als Nachweis zählt

Apple beschreibt die Labels über die Aufgaben, die Nutzer in einer App erledigen, und nicht über eine Liste verwendeter APIs. Die Grundlage ist daher eine Aufgabenmatrix: Welche Aktion muss nach dem Download funktionieren, welche davon ist für den Hauptnutzen unverzichtbar und an welcher Stelle kann eine unterstützende Funktion die Bedienung tatsächlich ermöglichen?

Zu den üblichen Prüfpunkten gehören:

1. der erste Start einschließlich Berechtigungsdialogen;
2. Registrierung und Login;
3. Suche, Navigation und Auswahl eines Inhalts;
4. der zentrale Geschäftsablauf, etwa Bestellung, Abonnement oder Erstellung eines Dokuments;
5. Einstellungen, Kontoänderungen und Abmeldung;
6. Fehlerbehandlung, Wiederholung und Rückkehr nach einem abgebrochenen Schritt.

Ein einzelner Bildschirm, der mit VoiceOver bedienbar ist, belegt deshalb noch nicht, dass die gesamte App VoiceOver unterstützt. Wenn der Login funktioniert, der Kaufdialog aber nicht fokussierbar ist, darf daraus keine uneingeschränkte Unterstützung für den gesamten Ablauf abgeleitet werden.

Für jede Aufgabe sollte das Team mindestens folgende Informationen festhalten:

• Gerät und Betriebssystem;
• verwendete Eingabemethode;
• Startzustand und Testkonto;
• genaue Handlungsschritte;
• erwartetes Ergebnis;
• tatsächliches Ergebnis;
• Fehler, Umgehungslösung oder Abbruch;
• Entscheidung für oder gegen das entsprechende Label.

Die Apple-Übersicht zu Accessibility Nutrition Labels ist dabei die maßgebliche Referenz für Aufgabenabdeckung und Bewertungslogik. Quellcode allein, etwa ein vorhandener accessibilityLabel-Modifier, gehört nur in die technische Fehleranalyse, nicht in den eigentlichen Nachweis.

Sind Accessibility Nutrition Labels derzeit verpflichtend?
Nach dem von Apple bestätigten Stand vom 07.09.2026 sind die Angaben zunächst freiwillig. Apple hat zugleich angekündigt, dass sie künftig für neue Apps und Updates erforderlich werden sollen; ein einheitliches, offiziell bestätigtes Datum für den verpflichtenden Start ist in den hier zugrunde gelegten Apple-Unterlagen jedoch nicht veröffentlicht. Deshalb sollten Teams nicht auf ein vermutetes Stichtagsdatum warten, aber auch keine nicht geprüften Angaben vorsorglich veröffentlichen.

Erste Prüfstufe: Häufige Aufgaben vollständig durchspielen

Die wichtigste Entscheidung fällt nicht bei der Auswahl eines Kontrollkästchens, sondern bei der Definition der Testpfade. Für jede häufige Aufgabe wird ein eigener Durchlauf angelegt. Dabei beginnt der Test nicht erst auf dem Zielbildschirm, sondern mit dem Zustand, in dem ein neuer oder abgemeldeter Nutzer die App tatsächlich vorfindet.

Ein belastbarer Durchlauf enthält beispielsweise:

• App starten und zum ersten nutzbaren Bildschirm gelangen;
• Hinweis- und Berechtigungsdialoge verstehen und bedienen;
• Testkonto anmelden;
• erforderliche Daten eingeben und Fehler korrigieren;
• zentrale Aktion ausführen;
• Erfolgsmeldung oder Statusänderung wahrnehmen;
• zum nächsten Schritt navigieren;
• Aufgabe nach einer Unterbrechung wieder aufnehmen.

Besonders kritisch sind benutzerdefinierte Steuerelemente, verschachtelte Listen, Bottom Sheets, modale Fenster, horizontale Wischgesten und Statusanzeigen, die nur durch Farbe oder Animation vermittelt werden. Ein Standardbutton kann korrekt funktionieren, während ein visuell ähnlich gestaltetes eigenes Steuerelement weder einen Namen noch einen verständlichen Zustand besitzt.

Die folgende Matrix verhindert, dass technische Unterstützung, einzelne Bildschirmtests und eine echte Aufgabenabnahme vermischt werden:

VoiceOver und Voice Control getrennt abnehmen

VoiceOver und Voice Control prüfen nicht dasselbe. VoiceOver benötigt eine sinnvolle Fokusreihenfolge, verständliche Namen, Zustände und Werte sowie eine erreichbare Aktion. Voice Control muss dagegen Befehle oder sichtbare Ziele zuverlässig zuordnen können. Ein erfolgreicher VoiceOver-Test erlaubt daher nicht automatisch die Erklärung, dass Voice Control unterstützt wird.

Bei VoiceOver sollte die Testperson unter anderem prüfen:

• Wird der Fokus beim Öffnen eines Dialogs an eine sinnvolle Stelle gesetzt?
• Wird der Titel eines Elements vorgelesen?
• Sind Rolle, Zustand und Wert verständlich?
• Wird eine Zustandsänderung angesagt?
• Bleibt die Fokusreihenfolge bei dynamischen Inhalten logisch?
• Kann der Nutzer einen Fehler erkennen und den Vorgang korrigieren?
• Sind individuelle Gesten auch mit einer alternativen Bedienhandlung ausführbar?

Die offiziellen VoiceOver-Evaluationskriterien sollten direkt neben dem Aufgabenprotokoll verwendet werden. Die Beurteilung „Fokus sichtbar“ genügt nicht, wenn die Vorlesereihenfolge die Bedeutung der Oberfläche verändert.

Für Voice Control werden dieselben Aufgaben separat ausgeführt. Zu dokumentieren sind beispielsweise Sprachbefehle für Navigation, Auswahl, Eingabe und das Schließen eines Dialogs. Wenn ein Element nur durch eine nicht ausgesprochene Wischbewegung erreichbar ist oder mehrere gleich benannte Ziele existieren, muss der Pfad als nicht bestanden oder eingeschränkt bewertet werden. Maßgeblich sind die Apple-Kriterien für Voice Control.

Zweite Prüfstufe: Text, Kontrast und Bewegung nicht zusammenfassen

Größerer Text, dunkle Darstellung, Kontrast, Farbverwendung und reduzierte Bewegung sind getrennte Prüfdimensionen. Ein Team sollte nicht mit einem einzigen Screenshot belegen, dass sämtliche visuellen Labels erfüllt sind.

Bei größeren Texten wird ein vollständiger Aufgabenpfad geprüft. Zu suchen ist nicht nur nach abgeschnittenen Überschriften, sondern auch nach:

• überdeckten Schaltflächen;
• Text, der nicht mehr in einer Karte oder Tabelle sichtbar ist;
• fehlender Scrollbarkeit;
• abgeschnittenen Fehlermeldungen;
• Dialogen, deren Bestätigung außerhalb des sichtbaren Bereichs liegt;
• Layouts, in denen Werte ohne ihre Bezeichnung erscheinen.

Die Apple-Kriterien für Larger Text legen die jeweiligen Anforderungen und Bewertungsbedingungen fest. Da sich Grenzwerte und Darstellungsanforderungen ändern können, sollten Teams keine selbst erfundenen Prozentangaben oder pauschalen Mindestgrößen in das interne Prüfprotokoll übernehmen.

Für dunkle Darstellung und Kontrast wird geprüft, ob der zentrale Ablauf in der realen App verständlich bleibt. Informationen dürfen nicht ausschließlich durch Farbe vermittelt werden. Ein roter Fehlerhinweis benötigt beispielsweise zusätzlich Text, ein Symbol oder eine andere erkennbare Kennzeichnung. Bilder, Statuschips und Diagramme werden dabei nicht isoliert betrachtet, sondern innerhalb der Aufgabe, in der sie eine Entscheidung beeinflussen.

Die Human Interface Guidelines zur Barrierefreiheit helfen bei der Gestaltung, ersetzen aber nicht den Aufgabenlauf mit der veröffentlichten oder zur Veröffentlichung vorgesehenen Version.

Bei reduzierter Bewegung sind Übergänge, automatisch bewegte Inhalte, Parallaxeffekte und animierte Zustandsänderungen relevant. Die Prüfung lautet nicht „Animation ist im Code abschaltbar“, sondern: Kann die Person bei aktivierter Einstellung weiterhin erkennen, was sich geändert hat, wohin der Fokus gelangt und ob die Aufgabe abgeschlossen wurde? Die Kriterien für Reduced Motion geben den dafür vorgesehenen Bewertungsrahmen vor.

Dritte Prüfstufe: Medien nur bei tatsächlicher Relevanz deklarieren

Untertitel und Audiobeschreibungen sind nur dann sinnvoll zu bewerten, wenn Medieninhalte für die Nutzung der App vorhanden sind. Ein Hilfetext, ein Transkript oder eine normale Textbeschreibung ist nicht automatisch ein Untertitel und auch keine Audiobeschreibung.

Zuerst wird deshalb für jede häufige Aufgabe festgestellt:

• Gibt es ein Video, Audio oder eine andere zeitbasierte Medienwiedergabe?
• Muss dieser Inhalt verstanden werden, um die Aufgabe abzuschließen?
• Sind wichtige gesprochene Inhalte als Untertitel verfügbar?
• Werden wesentliche visuelle Informationen zusätzlich beschrieben?
• Funktionieren diese Informationen bei pausierter, gestarteter und unterbrochener Wiedergabe?
• Sind die relevanten Sprachversionen und Medienvarianten abgedeckt?

Die Apple-Kriterien für Captions und für Audio Descriptions müssen getrennt angewandt werden. Wenn nur ein nebensächliches Einführungsvideo Untertitel besitzt, der zentrale Schulungs- oder Kaufpfad aber ein anderes Video verwendet, darf die Abdeckung nicht pauschal auf die gesamte App übertragen werden.

Vierte Prüfstufe: Gerätefamilien separat bewerten

Müssen App-Store-Barrierefreiheitslabels für verschiedene Geräte separat ausgefüllt werden?
Die Bewertung muss sich an den von der App unterstützten Gerätefamilien und den dort tatsächlich möglichen Aufgaben orientieren. Ein bestandenes iPhone-Szenario darf nicht ungeprüft als Ergebnis für iPad oder Mac kopiert werden. Layout, Tastatureingabe, Pointer-Bedienung, Fenstergröße, Plattformkontrollen und Dialogverhalten können den Ablauf verändern.

Für jede unterstützte Gerätefamilie sollte das Team daher eine eigene Zeile oder ein eigenes Protokoll führen. Besonders zu prüfen sind:

• Login und Eingabe mit Bildschirmtastatur beziehungsweise physischer Tastatur;
• Split View, größere Fenster und geänderte Orientierung;
• Fokuswechsel zwischen App-Bereich, Dialog und Systemelement;
• Pointer- oder Trackpad-Bedienung;
• Plattformunterschiede bei Menüs, Tabellen und Navigation;
• Simulator- oder Hardwarebesonderheiten, die den realen Ablauf beeinflussen.

Ein Label kann für eine Gerätefamilie ungeeignet sein, wenn die entsprechende Funktion dort nicht Teil des App-Erlebnisses ist. Diese Entscheidung sollte mit der aktuellen Auswahl in App Store Connect und der jeweiligen offiziellen Bewertungshilfe abgeglichen werden, statt aus einer älteren Projektvorlage übernommen zu werden.

Warum erscheint ein Label nach der Veröffentlichung nicht sofort?
Die Darstellung kann davon abhängen, ob die Erklärung korrekt gespeichert, der passende App-Datensatz aktualisiert und die Veröffentlichung der Metadaten verarbeitet wurde. Teams sollten deshalb zunächst den Status in App Store Connect, die ausgewählte Version und die öffentliche Produktseite vergleichen. Eine verspätete Anzeige ist kein Beleg dafür, dass ein nicht gespeicherter oder falsch zugeordneter Test automatisch anerkannt wurde. Der Ablauf zum Verwalten der Angaben ist in Apples Anleitung zur Verwaltung von Accessibility Nutrition Labels beschrieben.

Fünfte Prüfstufe: Eine nachvollziehbare Evidenzmappe anlegen

Vor der Freigabe werden Testergebnisse in einer Evidenzmappe zusammengeführt. Sie muss nicht öffentlich sein, sollte aber bei einer internen Rückfrage oder einer späteren Regression verständlich bleiben. Konten, App-Namen, Bundle IDs, Testnutzer, Screenshots und Protokolldateien sind dabei zu anonymisieren.

Eine geeignete Ordnerstruktur kann so aussehen:

accessibility-release/
├── 01-common-tasks/
├── 02-voiceover/
├── 03-voice-control/
├── 04-visual-settings/
├── 05-media/
├── 06-device-families/
└── 07-release-decision/

Zu jedem Testfall gehören mindestens die Build-Kennung, das Gerät, die aktivierten Systemeinstellungen, der Ablauf, das Ergebnis und die Entscheidung. Für die abschließende Entscheidung genügt ein maschinenlesbares Protokoll, sofern es mit den Screenshots und Fehlerberichten verknüpft ist:

{
  "task": "Konto anmelden und zentrale Aktion ausführen",
  "device_family": "iPhone",
  "assistive_technology": "VoiceOver",
  "build": "release-candidate",
  "result": "passed",
  "evidence": [
    "login-focus-order.txt",
    "purchase-dialog-recording.mov"
  ],
  "label_decision": "declare only after release review"
}

Das Beispiel ist eine Dokumentationsvorlage, keine Aussage über ein bestimmtes Projekt. In einer echten Freigabe müssen die Einträge aus den tatsächlichen Testläufen stammen. Die App-Store-Connect-API-Dokumentation für Accessibility Declarations ist relevant, wenn ein Team die Angaben automatisiert verwaltet. Automatisierung kann Eingabefehler verringern, ersetzt aber weder VoiceOver- noch Voice-Control-Tests.

Remote-Mac-Umgebung für wiederholbare Regressionen

Ein lokaler Mac ist nicht immer dauerhaft verfügbar, wenn mehrere Simulatorzustände, Testaccounts und verschiedene Release-Kandidaten parallel benötigt werden. In diesem Fall kann ein gemieteter Mac als getrennte Regressionumgebung sinnvoll sein, sofern das Team Zugriffsrechte, Datenschutz, Bildschirmübertragung und Aufbewahrung der Testdaten kontrolliert.

Für einen wiederholbaren Ablauf sollte das Team:

1. einen dedizierten Testbenutzer ohne Produktionsdaten anlegen;
2. Repository und Testkonfiguration reproduzierbar bereitstellen;
3. Accessibility Inspector und die benötigten Simulatoren installieren;
4. Systemeinstellungen für VoiceOver, größere Texte, dunkle Darstellung und reduzierte Bewegung dokumentieren;
5. dieselben Aufgaben in derselben Reihenfolge ausführen;
6. Protokolle und Screenshots nach dem Test verschlüsselt oder zugriffsbeschränkt ablegen;
7. die Testumgebung vor dem nächsten Build auf einen definierten Zustand zurücksetzen.

Bei NodeMini kann ein Entwickler je nach gewähltem Zeitraum auf einen verwalteten Mac über VNC, SSH oder eine Webkonsole zugreifen. Das eignet sich besonders für eine isolierte Test- und Build-Umgebung, wenn ein Team die Prüfungen nicht auf dem persönlichen Arbeitsgerät halten möchte. Für die Entscheidung zwischen eigener Hardware und einem gemieteten Mac können die Informationen zu Mac-mini-Bestellungen als zusätzlicher Kosten- und Betriebsvergleich dienen. Wer außerdem den Einfluss des Rechenzentrumsstandorts auf Zugriffsweg und Betriebsorganisation vergleichen möchte, kann die Mac-mini-Option im Silicon-Valley-Rechenzentrum heranziehen.

Die Remote-Umgebung ist jedoch kein Ersatz für jede Prüfung. Physische Geräte, bestimmte Eingabevarianten und produktive Konten müssen dort getestet werden, wo sie tatsächlich verwendet werden. Außerdem dürfen sensible Kundendaten, persönliche Apple-IDs und nicht anonymisierte Screenshots nicht unkontrolliert auf einer gemeinsam verwalteten Infrastruktur landen. Für CI/CD- oder Simulatorläufe sollte die Umgebung deshalb klar von Produktionszugängen getrennt sein.

Veröffentlichung mit einer kurzen Entscheidungsprüfung

Vor dem Absenden des Updates sollte ein zweiter Entwickler oder eine zweite Entwicklerin nicht nur die Auswahl in App Store Connect anklicken, sondern die Entscheidung aus der Evidenzmappe zurückverfolgen. Folgende Checkliste kann direkt in das Release-Ticket übernommen werden:

• [ ] Häufige Aufgaben sind vor dem Test schriftlich definiert.
• [ ] Erster Start, Login, zentrale Aktion, Einstellungen und Fehlerpfad wurden berücksichtigt.
• [ ] VoiceOver und Voice Control wurden getrennt getestet.
• [ ] Fokusreihenfolge, Namen, Werte, Zustände und Aktionen sind dokumentiert.
• [ ] Benutzerdefinierte Kontrollen, Dialoge und Gesten wurden nicht ausgelassen.
• [ ] Größere Texte wurden in vollständigen Aufgabenpfaden geprüft.
• [ ] Dunkle Darstellung, Kontrast und nichtfarbliche Unterscheidungen wurden bewertet.
• [ ] Reduzierte Bewegung wurde mit einem realen Ablauf geprüft.
• [ ] Untertitel und Audiobeschreibungen wurden nur bei relevanten Medien bewertet.
• [ ] iPhone, iPad und Mac wurden nicht durch kopierte Ergebnisse gleichgesetzt.
• [ ] Testkonto, App-Name, Bundle ID und Screenshots sind anonymisiert.
• [ ] Label-Auswahl, veröffentlichter Build und öffentliche Produktdarstellung stimmen überein.
• [ ] Nicht bestandene oder ungeprüfte Punkte sind nicht als Unterstützung deklariert.
• [ ] Ein Regressionstermin für die nächste Version ist im Entwicklungsprozess eingetragen.

Der sachlich richtige Ausgang ist bei Unsicherheit nicht eine großzügige Auswahl, sondern ein noch nicht deklariertes Label mit offenem Prüfpunkt. Nach einer Reparatur muss die gesamte betroffene häufige Aufgabe erneut durchgespielt werden; ein erneuter Blick auf den geänderten Code reicht nicht aus.

Für Teams, die lediglich vor einem einzelnen Release testen, ist ein eigener Mac unter Umständen unnötig. Wer jedoch wiederholt Xcode-Builds, mehrere Simulatorzustände und Accessibility-Regressionen ausführen muss, sollte die Betriebsform getrennt bewerten: Ein gekaufter Mac bietet langfristige Kontrolle, bindet aber Kapital und muss selbst gewartet werden; lokale Hardware kann bei mehreren Plattformständen schnell knapp werden. Eine zeitweise lokale Installation auf einem persönlichen Rechner erschwert außerdem reproduzierbare Zustände und die Trennung von Teamzugängen. Ein Remote-Mac von NodeMini kann hier die geeignetere Zwischenlösung sein, weil der Entwickler eine eigene Testumgebung für einen begrenzten Zeitraum aufbauen kann, ohne sofort zusätzliche Hardware dauerhaft zu kaufen. Für langfristige, sehr intensive Nutzung oder Tests mit zwingend erforderlichen physischen Geräten bleibt eigene Hardware die ehrlichere Wahl.

Entscheidend ist in allen Fällen dieselbe Reihenfolge: erst reale Aufgaben auf jeder unterstützten Gerätefamilie ausführen, dann die Evidenz prüfen und erst danach Accessibility Nutrition Labels in App Store Connect veröffentlichen.