Wie führt man Barrierefreiheitstests auf dem iPhone Duo durch? Abnahmeliste 2026 für die Kompatibilität mit dem iPhone 18 Pro

Eine Formularseite ist halb ausgefüllt, das iPhone Duo wird aufgeklappt, und VoiceOver springt an den Anfang zurück; gleichzeitig verschwinden Eingaben und die Bestätigungsschaltfläche aus dem erreichbaren Bereich.

Die schnellste Lösung: Beginnen Sie mit den gemeinsamen Kernaufgaben auf dem iPhone 18 Pro und ergänzen Sie auf dem iPhone Duo gezielt Tests für Displaywechsel, Fokusfortsetzung und Statuswiederherstellung. Kritische Formulare, Identitätsprüfungen und Transaktionen müssen vor der Veröffentlichung mit VoiceOver auf echter Hardware geprüft werden.

Für welche Teams diese Abnahmeliste gedacht ist

Diese Anleitung richtet sich an iOS-Entwickler, QA-Verantwortliche, Accessibility-Verantwortliche und Unternehmen, die eine App ausliefern müssen. Ein allgemeines App-Team kann damit eine gemeinsame Mindestbasis für beide Gerätekategorien definieren. Für Finanz-, Medizin- oder Behördenanwendungen kommen zusätzliche Nachweise, besonders kritische Nutzeraufgaben und strengere Freigaberegeln hinzu.

Wir gehen dabei nicht davon aus, dass sich das Verhalten des iPhone Duo automatisch aus der bisherigen iPhone-Erfahrung ableiten lässt. Apple stellt eigene Entwicklungsinformationen für das iPhone Duo sowie Unterlagen zu adaptiven Layouts bereit; konkrete Reaktionen von VoiceOver, Fokus und unterstützenden Eingabemethoden müssen mit dem verfügbaren SDK, den Testwerkzeugen und echter Hardware überprüft werden. Die offiziellen Entwicklungsinformationen zum iPhone Duo bilden deshalb den technischen Ausgangspunkt, nicht eine Abkürzung für die Abnahme.

Stand der Prüfung: Dieser Beitrag wurde zuletzt am 17.09.2026 aktualisiert. Die methodischen Aussagen wurden gegen Apples Dokumentation zu Accessibility, Human Interface Guidelines und iPhone-Duo-Entwicklung abgeglichen. Vor einer Freigabe sollten Sie die Ergebnisse mit dem tatsächlich verwendeten SDK, der installierten Systemversion und der jeweiligen Build-Nummer erneut prüfen.

Der erste Fehler ist oft kein Absturz, sondern eine unvollständige Aufgabe

Eine App kann stabil laufen und trotzdem für einen Nutzer mit unterstützenden Technologien nicht bedienbar sein. In unseren Abnahmen treten typischerweise vier voneinander unabhängige Fehlerklassen auf:

• Vergrößerte Schrift schiebt eine Bestätigungs- oder Abbruchaktion aus dem erreichbaren Bereich.
• Ein Displaywechsel setzt den VoiceOver-Fokus auf den Seitenanfang, auf ein verborgenes Element oder in einen neuen Navigationskontext.
• Der sichtbare Zustand bleibt erhalten, während Eingaben, Auswahl, Fehlermeldung oder Wiedergabeposition verloren gehen.
• Eine Kernaktion ist nur über Ziehen, präzise Gesten, Hover-Zustände oder eine nicht beschriftete Steuerung erreichbar.

Diese Probleme dürfen nicht zu einer einzigen Kategorie „Layoutfehler“ zusammengefasst werden. Ein abgeschnittener Hinweis ist ärgerlich; ein verlorener Betrag in einem Zahlungsformular oder ein verschwundener Identitätsprüfungsschritt kann die gesamte Aufgabe blockieren.

Für die Priorisierung verwenden wir drei Schweregrade:

1. Blockierend: Eine unverzichtbare Nutzeraufgabe kann mit der vorgesehenen unterstützenden Technologie nicht abgeschlossen werden.
2. Deutlich einschränkend: Die Aufgabe bleibt möglich, erfordert aber einen nicht erkennbaren Umweg, verliert Kontext oder verursacht ein hohes Fehlerrisiko.
3. Visuelle Abweichung: Die Darstellung ist unsauber, die vollständige Aufgabe bleibt jedoch ohne zusätzlichen Kontextverlust erreichbar.

Diese Einstufung ist eine interne Abnahmeregel, keine Aussage über eine automatisch erfüllte rechtliche Konformität. Die Apple-Richtlinien für barrierefreie Gestaltung helfen bei der Gestaltung, ersetzen aber keine Prüfung des konkreten Nutzerablaufs.

Texte, Schaltflächen und Formulare müssen in jeder relevanten Größe erreichbar bleiben

Dynamic Type wird häufig auf einer einzelnen Seite kontrolliert: Die Schrift wird vergrößert, ein Screenshot sieht plausibel aus, und der Test endet. Für eine echte Abnahme reicht das nicht. Entscheidend ist, ob die Aufgabe mit vergrößerter Schrift weiterhin abgeschlossen werden kann.

Auf dem iPhone 18 Pro prüfen wir zunächst die gemeinsamen Kernaufgaben. Auf dem iPhone Duo wiederholen wir diese Prüfung in den für die App relevanten Displayzuständen. Dabei sind mindestens folgende Kombinationen zu betrachten:

• normale Schrift und deutlich vergrößerte Schrift;
• aktivierte fette Schrift;
• aktivierte Schaltflächenformen;
• lange Überschriften, mehrzeilige Fehlermeldungen und lokalisierte Texte;
• Tastatur sichtbar und Tastatur ausgeblendet;
• Formular mit bereits eingetragenen Werten und Formular nach einer Validierungsfehlermeldung.

Die Apple-Anleitung zu Dynamic Type und Typografie ist die passende Referenz für die typografische Grundlage. Für die Abnahme formulieren wir daraus konkrete Fragen: Ist die Schaltfläche zum Absenden noch erreichbar? Bleibt „Zurück“ von „Abbrechen“ unterscheidbar? Wird ein Pflichtfeld nach der Fehlermeldung angesagt und erneut fokussiert? Kann ein Nutzer zum nächsten Eingabefeld gelangen, ohne eine nicht sichtbare oder nicht beschriftete Zone suchen zu müssen?

Erfahrung aus der Abnahme: Ein scrollbarer Inhalt genügt nicht, wenn die primäre Aktion in einer festen Fußzeile liegt und diese bei großer Schrift überlagert wird. Prüfen Sie die gesamte Aktion, nicht nur den sichtbaren Text.

Der Displaywechsel benötigt eine eigene Fokusprüfung

Beim iPhone Duo ist „aufgeklappt“ oder „zusammengeklappt“ kein bloßer Größenwechsel. Für die App kann sich der verfügbare Raum verändern, eine Navigation neu angeordnet werden oder eine bisher verborgene Struktur sichtbar werden. Genau an dieser Grenze entstehen die schwierigsten VoiceOver-Fehler.

Wir prüfen vor dem Wechsel immer einen definierten Zustand. Dazu gehören das zuletzt angesagte Element, die aktuelle Listenposition, der Navigationspfad und der Inhalt eines offenen Dialogs. Danach wird das Gerät geöffnet oder geschlossen, ohne die Aufgabe künstlich neu zu starten. Anschließend dokumentieren wir:

• Bleibt der Fokus beim logisch gleichen Element?
• Wird ein neu angeordnetes Element genau einmal angesagt?
• Springt der Fokus an den Anfang, auf ein verborgenes Element oder in einen Dialoghintergrund?
• Bleibt die Position in einer Liste oder einem mehrstufigen Formular verständlich?
• Kann der Nutzer mit Zurück- und Vorwärtsbewegungen wieder in den vorherigen Kontext gelangen?

Eine Anwendung kann auf visueller Ebene korrekt neu layouten und dennoch für VoiceOver einen falschen Fokuspfad liefern. Die Dokumentation zu UIAccessibility.post und layoutChanged ist dabei relevant, weil eine Layoutänderung nicht nur visuell, sondern auch als zugängliche Zustandsänderung behandelt werden muss. Welche Benachrichtigung im konkreten Ablauf richtig ist, darf nicht pauschal angenommen werden; sie muss mit der tatsächlichen Navigation und dem Nutzerziel übereinstimmen.

Der Simulator ist für frühe Fehlerhinweise hilfreich. Er kann zeigen, dass eine Ansicht nach dem Zustandswechsel falsch aufgebaut wird oder ein Element doppelt im Accessibility-Baum erscheint. Ob VoiceOver den Übergang sinnvoll ansagt und ob sich der Fokus tatsächlich fortsetzen lässt, entscheiden wir erst auf echter Hardware.

Zustände müssen während einer laufenden Aufgabe erhalten bleiben

Der wichtigste Unterschied zwischen einem Layouttest und einer Accessibility-Abnahme liegt in der laufenden Aufgabe. Wir wechseln das Display nicht auf einer leeren Startseite, sondern mitten in einem Vorgang, dessen Zustand nicht ohne Weiteres wiederhergestellt werden kann.

Geeignete Szenarien sind:

• Anmeldung nach Eingabe des Benutzernamens, aber vor der Bestätigung;
• Identitätsprüfung mit bereits ausgewähltem Verfahren;
• Warenkorb oder Zahlungsformular mit eingetragenen Daten;
• Bearbeitung eines längeren Textes;
• Medienwiedergabe an einer definierten Position;
• Formular nach einer Fehlermeldung, bevor das fehlerhafte Feld korrigiert wurde.

Nach dem Wechsel kontrollieren wir nicht nur, ob die App geöffnet bleibt. Wir vergleichen den vorher dokumentierten Zustand mit dem Zustand danach: Eingabewerte, ausgewählte Optionen, Fehlermeldungen, Fokus, Listenposition und Wiedergabeposition. Ein technisch nicht abgestürzter Prozess ist nicht automatisch barrierefrei.

Bei sensiblen Anwendungen muss zusätzlich geklärt werden, welche Daten überhaupt in Testprotokolle gelangen dürfen. Screenshots, VoiceOver-Aufzeichnungen und Konsolenprotokolle sollten mit synthetischen Konten erstellt, minimiert gespeichert und nach den internen DSGVO-Regeln behandelt werden. Die Build-Nummer und Systemversion gehören in den Nachweis; echte personenbezogene Inhalte gehören dort nicht hinein.

Unterstützende Eingaben werden anhand realer Aufgaben priorisiert

Wir testen VoiceOver, Voice Control, Switch Control und externe Tastaturen nicht als bloße Namensliste. Jede Methode muss an einer Aufgabe bewertet werden, bei der ein Nutzer tatsächlich scheitern könnte.

Bei Voice Control prüfen wir, ob wichtige Elemente stabile und verständliche Namen haben. Bei einer externen Tastatur kontrollieren wir Fokusreihenfolge, sichtbare Rückmeldung, Aktivierung und Rückkehr aus Dialogen. Bei Switch Control achten wir darauf, dass interaktive Elemente erreichbar sind und kein feinmotorischer Gestenablauf die einzige Möglichkeit bleibt.

Die Apple-Leitlinien für Tastaturinteraktion sind besonders nützlich, wenn eine App bisher primär über direkte Berührung geprüft wurde. Ein sichtbares Element ohne sinnvolle Fokusreihenfolge ist für Tastaturnutzer nicht ausreichend. Ebenso darf ein Status nicht ausschließlich durch Farbe oder eine kurze Animation vermittelt werden.

Die offizielle Anleitung zu Accessibility-Tests unterstützt die Trennung von Prüfmethoden. Wir ordnen die Arbeit in drei Ebenen:

1. Statische Prüfung: Labels, Rollen, Werte, Kontrastprobleme und offensichtliche Strukturfehler.
2. Automatisierte Regression: Wiederholbare Zustände und erwartete UI-Strukturen mit XCTest.
3. Manuelle Nutzung: VoiceOver, Displaywechsel, Tastatur, Voice Control und Switch Control in einer vollständigen Aufgabe.

Der Accessibility Inspector ist in der ersten Ebene sehr wertvoll. Er zeigt jedoch nicht zuverlässig, ob ein Mensch mit VoiceOver einen Kauf, eine Anmeldung oder eine Formularänderung unter realen Zustandswechseln abschließen kann.

Mit dieser Abnahmeliste bleibt die Matrix beherrschbar

Wir empfehlen, nicht jede theoretische Kombination aus Funktion, Schriftgröße, Eingabemethode und Displayzustand zu vervielfachen. Die Auswahl sollte vom Risiko der Nutzeraufgabe ausgehen.

• [ ] Drei Aufgaben mit dem höchsten Schaden bei einem Abbruch festlegen, zum Beispiel Anmeldung, Zahlung oder medizinische Eingabe.
• [ ] Gemeinsame Kernaufgaben auf dem iPhone 18 Pro mit vergrößerter Schrift, fetter Schrift und Schaltflächenformen prüfen.
• [ ] Dieselben Kernaufgaben auf dem iPhone Duo in den für die App relevanten Außen- und Innenzuständen ausführen.
• [ ] Vor jedem Displaywechsel Fokus, Listenposition, Dialogstatus und Eingabewerte dokumentieren.
• [ ] Das iPhone Duo während einer laufenden Aufgabe öffnen oder schließen, ohne die App neu zu starten.
• [ ] Nach dem Wechsel alle Eingaben, Auswahlwerte, Fehlermeldungen und die Wiedergabeposition abgleichen.
• [ ] VoiceOver mit gesprochenem Feedback und nicht nur mit einer statischen Accessibility-Struktur prüfen.
• [ ] Voice Control, Switch Control und externe Tastatur an mindestens einer vollständigen Kernaufgabe einsetzen.
• [ ] Elemente markieren, die nur über Ziehen, Hover oder eine besonders genaue Geste funktionieren.
• [ ] Für jeden Fehler Schweregrad, reproduzierbare Schritte, betroffene Gerätekategorie, Systemversion und Build-Nummer erfassen.
• [ ] Blockierende Fehler vor der Veröffentlichung schließen und die Korrektur auf der betroffenen Gerätekategorie erneut prüfen.
• [ ] Für nicht blockierende Fehler eine verantwortliche Person, eine konkrete Übergangslösung und eine Zielversion festlegen.

Die automatisierten Abläufe können mit XCTest wiederholt werden. Sie sollten aber nicht so gestaltet sein, dass nur das Vorhandensein eines Elements geprüft wird. Ein Test, der lediglich feststellt, dass eine Schaltfläche existiert, beweist nicht, dass sie nach einem Displaywechsel fokussierbar, verständlich benannt und mit der vorgesehenen Eingabemethode ausführbar ist.

Vergleich der Prüfebenen und Geräte

Diese Tabelle ist kein Versprechen, dass jede App mit exakt derselben Matrix auskommt. Eine Medien-App benötigt andere Zustandsprüfungen als eine Anwendung mit Identitätsprüfung. Maßgeblich sind die Folgen eines Fehlers, nicht die Anzahl der durchlaufenen Bildschirme.

Veröffentlichungsnachweis und Kapazitätsplanung

Für jede Freigabe bewahren wir mindestens den betroffenen Gerätezustand, die Systemversion, die Build-Nummer, die verwendete Eingabemethode, die Ausgangsbedingungen und das Ergebnis auf. Bei einem Fokusfehler gehört zusätzlich eine kurze Beschreibung des zuletzt angesagten Elements in den Nachweis. Bei einem Statusfehler müssen die Werte vor und nach dem Wechsel vergleichbar sein.

Wenn die Matrix die vorhandene Umgebung überlastet, sollte die Arbeit in Bau- und Prüfschritte getrennt werden. Statische Prüfungen und automatisierte Regressionen können in eine gemeinsame CI/CD-Pipeline verschoben werden. Die manuelle VoiceOver-Abnahme benötigt dagegen ein reserviertes echtes Gerät, eine stabile Fernbedienung und eine dokumentierte Übergabe. Mehr Maschinen lösen Build- oder Parallelitätsengpässe, ersetzen aber keine Person, die die Aufgabe mit unterstützender Technologie tatsächlich ausführt.

Bei einer temporären Umgebung müssen Sie zusätzlich Datenschutz, Zugriffskontrolle, Bildschirmübertragung, Protokollaufbewahrung und die Rückgabe der Testdaten festlegen. Für eine einmalige Release-Spitze kann eine gemietete Mac-Umgebung sinnvoller sein als eine dauerhaft ungenutzte Kapazität. Für dauerhaft hohe Last, lokale Peripherie oder langfristige Gerätekontrolle ist ein eigener Geräte- und Mac-Bestand oft die bessere Lösung.

Häufige Fragen zur Abnahme

Verliert VoiceOver beim Zusammenklappen des iPhone Duo den Fokus?

Das lässt sich nicht zuverlässig aus dem Verhalten eines herkömmlichen iPhone ableiten. Beim iPhone Duo müssen Sie den Fokus vor und nach dem Wechsel zwischen Außen- und Innendisplay auf einem echten Gerät prüfen. Dokumentieren Sie dabei das zuletzt angesagte Element, die Listenposition, den Navigationskontext und mögliche Layoutänderungen. Der Simulator kann logische Fehler früh sichtbar machen, ersetzt diese Prüfung aber nicht.

Wie testen Sie Dynamic Type auf den beiden Displays des iPhone Duo?

Prüfen Sie mindestens die gemeinsamen Kernaufgaben auf dem iPhone 18 Pro und auf beiden relevanten Displayzuständen des iPhone Duo. Vergrößern Sie die Schrift stufenweise, aktivieren Sie zusätzlich fette Schrift und Schaltflächenformen und kontrollieren Sie danach Eingabefelder, Fehlermeldungen, Bestätigungs- und Abbruchaktionen. Entscheidend ist nicht nur die sichtbare Darstellung, sondern ob die Aufgabe vollständig erreichbar bleibt.

Sind für die Barrierefreiheitsabnahme zwei echte Geräte erforderlich?

Für eine belastbare Abnahme kritischer Aufgaben sollten beide Gerätekategorien mit echten Geräten vertreten sein. Ein iPhone 18 Pro deckt die gemeinsame Grundfunktion ab; das iPhone Duo ergänzt Displaywechsel, Fokusfortsetzung und Statuswiederherstellung. Statische Prüfungen, Simulatoren und automatisierte Tests reduzieren den Aufwand, können aber keine verlässliche Aussage über die tatsächliche Nutzung unterstützender Technologien auf der Hardware liefern.

Kann Accessibility Inspector einen manuellen VoiceOver-Test ersetzen?

Nein. Accessibility Inspector hilft, fehlende Labels, Rollen, Werte und bestimmte Strukturprobleme früh zu erkennen. Er bewertet jedoch nicht vollständig, ob eine Person eine Anmeldung, einen Kauf oder eine Formularaufgabe mit VoiceOver ohne Kontextverlust abschließen kann. Für kritische Abläufe benötigen Sie deshalb eine manuelle Prüfung mit gesprochenem Feedback, Fokusbewegung, Rückkehr aus Dialogen und tatsächlicher Bedienung.

Wie lässt sich eine Regression mit zwei Geräten sinnvoll verkleinern?

Reduzieren Sie nicht wahllos die Gerätezahl, sondern gruppieren Sie nach Risiko. Prüfen Sie gemeinsame Kernaufgaben zuerst auf dem iPhone 18 Pro und führen Sie anschließend auf dem iPhone Duo nur die zusätzlichen Zustandswechsel und besonders kritischen Abläufe aus. Login, Identitätsprüfung, Bearbeitung, Zahlung und Medienwiedergabe sollten trotz einer verkleinerten Matrix mindestens einmal als vollständige reale Aufgabe auf beiden Gerätekategorien geprüft werden.

Fazit: Erst Aufgaben auswählen, dann die Umgebung erweitern

Eine reine Prüfung auf dem iPhone 18 Pro ist für gemeinsame Kernfunktionen ein sinnvoller Start, aber sie beantwortet nicht die Fragen des iPhone Duo: Bleibt VoiceOver beim Displaywechsel im richtigen Kontext? Bleiben Eingaben und Auswahl erhalten? Ist die primäre Aktion auch bei großer Schrift und alternativen Eingaben erreichbar?

Markieren Sie deshalb zuerst drei Aufgaben, die nicht fehlschlagen dürfen, und führen Sie dafür die gemeinsame Prüfung, den Zustandswechsel und die manuelle VoiceOver-Abnahme durch. Wenn Builds, Simulatoren oder die Zusammenarbeit bei dieser Matrix regelmäßig warten müssen, kann eine zusätzliche Mac-Umgebung von zekmac die Testkapazität kurzfristig erweitern. Das ersetzt weder echte Geräte noch die manuelle Abnahme, kann aber die unabhängige Validierung organisatorisch entlasten.