Was wird geprüft?
Inhalte der App sollen bei einer Viewport-Breite von 320 CSS Pixeln so angezeigt werden, dass alle Informationen und Funktionen verfügbar sind, ohne dass Nutzer horizontal scrollen müssen. Ausgenommen sind Inhalte, für deren Nutzung ein zweidimensionales Layout erforderlich ist, etwa Datentabellen oder Karten (siehe Abschnitt Ausnahmen). Die Inhalte mobiler Apps sind meist standardmäßig für die Ansicht im Hochkant-Format optimiert, auch wenn die heute verbreiteten Mobilgeräte hochkant meist eine etwas größere Viewportbreite als 320 CSS-Pixel haben. Damit ist dieser Prüfschritt in der Regel erfüllt. Zu prüfen ist, ob es Inhalte gibt, die nicht in den schmalen Viewport passen, aber nicht unter die Ausnahmen zu rechnen sind.
Native Apps, auch die gängigen Browser, verfügen in der Regel nicht über die Möglichkeit, innerhalb der App den Zoomfaktor zu ändern, wie dies über die Zoom-Funktion in Desktop-Browsern geschieht. Dort führt das Hineinzoomen bei responsiven Sites zum Umbruch in eine andere Darstellung. Manche Apps zeigen ein anderes Layout der Inhalte, wenn das Gerät ins Querformat gedreht wird oder wenn die App auf einem Tablet mit größerer Viewportbreite geladen wird. Für diese ist bei Apps, die selbst eine Zoom-Vergrößerung implementieren, die Ansicht nach Vergrößerung auf 320 CSS-Pixel zu prüfen.
Ausnahmen
Von der Anforderung ausgenommen sind Inhalte der Ansicht, für deren Nutzung ein zweidimensionales Layout erforderlich ist und die auf eine geringe Viewportbreite verkleinert nicht sinnvoll nutzbar sind, z.B.:
Bilder, die Infomationen enthalten, die bei Verkleinerung nicht mehr erkennbar bzw. lesbar sind
Landkarten
Diagramme
Videos
Spiele
Präsentationen
Datentabellen
Anwendungs-Schnittstellen, in denen die Bearbeitung von Inhalten die permanente Verfügbarkeit von Werkzeugleisten erfordert.
Warum wird das geprüft?
Alle Inhalte, die gut umbrechen können, sollen in den Viewport mit Breite von 320 CSS-Pixeln passen, um die mühsame Bedienung über horizontales Scrollen oder Verschieben über Ziehgesten zu vermeiden. Zu solchen Inhalten, die gut umbrechen können, zählen nicht nur Fließtexte, sondern z.B. auch Formulare und Menüs.
Wenn Apps angepasste Layouts für breitere Viewports bieten, soll sich das Layout an schmalere Viewport-Breiten anpassen, etwa, wenn Apps nebeneinander in Splitscreen-Ansichten dargestellt werden. Werden beide Bildschirm-Ausrichtungen unterstützt, ändert sich mit der Ausrichtung des Geräts auch die Viewport-Breite, an die sich Inhalte anpassen sollten.
Normativ verlangt wird jedoch nur eine Darstellung bei 320 CSS Pixeln Breite, ohne dass ein Scrollen in beide Richtungen notwendig ist.
Wie wird geprüft?
1. Anwendbarkeit des Prüfschritts
Der Prüfschritt ist immer anwendbar.
Laut EN 301 549 Version 3.2.1 ist dieser Prüfschritt auf Software und damit auch auf mobile Apps anwendbar. In der Regel ist er schon dadurch erfüllt, dass alle Inhalte auf die Ausgabe innerhalb des Hochkant-Viewports optimiert sind. Der Viewport auch kleinerer aktueller Smartphones ist allerdings in der Regel breiter als 320 CSS Pixel. So hat das kleinste aktuelle iPhone, das iPhone 13 mini, eine Viewportbreite von 360 CSS-Pixeln. Das Samsung Galaxy S21 Ultra hat eine Viewportbreite von 384 CSS-Pixeln.
Im Kontext der WCAG2ACT Task Force der Accessibility Guidelines Working Group läuft eine Diskussion, ob und wie Reflow auch auf Nicht-Web-Inhalte anzuwenden wäre.
2. Prüfung
2.1 Standard-Hochkant-Ansicht mit Viewportbreite von 320 CSS-Pixeln
Wenn kein geeignetes Gerät mit exakt 320 CSS Pixeln Viewportbreite vorhanden ist, wird die Prüfung auf einem anderen möglichst kleinen Smartphone durchgeführt.
Gibt es in der Hochkant Ansicht Informationen oder Funktionen, die nicht unter die Ausnahmen fallen und die nicht verfügbar sind bzw. nur über horizontales Scrollen / Verschieben erreichbar sind?
2.2 Prüfung von Apps mit breiterem Layout und Zoomfunktion
Vorbedingung 1: Hat die App selbst eine Zoomfunktion (es geht nicht um den Zoom bzw. die Vergrößerung über die Bedienungshilfen des Betriebssystems)?
Vorbedingung 2: Stellt die App Inhalte auf Geräten mit breiteren Viewports (oder nach Drehen des Smartphones ins Querformat) in einem anderen Layout dar als auf dem Smartphone im Hochkant-Format?
Ist eine der Vorbedingungen nicht erfüllt, wird die Prüfung abgebrochen, es zählt das Ergebnis der Prüfung unter 2.1.
Falls beide Vorbedingungen erfüllt sind: Die Inhalte soweit über den App-Zoom vergrößern, bis näherungsweise eine Viewport-Breite von 320 CSS-Pixeln erreicht ist (siehe dazu Hinweise unter Punkt 3.2 Vergrößerung auf Viewportbreite von 320 CSS-Pixel)
Gibt es in der App Informationen oder Funktionen, die nun nicht mehr verfügbar sind oder abgeschnitten werden und die nicht unter die Ausnahmen fallen?
Für Hinweise zur Prüfpraxis können Sie auf GitHub ein Issue zur diesem Prüfschritt erstellen.
3. Hinweise
3.1 Praktische Aspekte der Prüfung: Geräte zum Testen
Oft wird für die Prüfung kein Gerät mit exakt 320 CSS Pixeln Viewportbreite und aktuellem Betriebssystem zur Verfügung stehen. Deshalb ist es unvermeidlich, auf einem gängigen Gerät mit etwas größerer Viewportbreite zu testen (etwa ein iPhone 13 mini, oder ein Samsung Galaxy A12, beide mit 360 CSS Pixeln Viewport-Breite).
Werden Apps getestet, die Layouts für breitere Ansichten bieten und eine Zoomfunktion implementieren, ist zu prüfen, ob die Querformat-Ansicht auf dem Smartphone bereits ein abweichendes Layout bietet. Viele Apps werden nur in der Hochkant-Ansicht angeboten (und erfüllen damit nicht Anforderung 11.1.3.4 "Keine Beschränkung der Bildschirmausrichtung") oder sie zeigen die App-Inhalte auch im Querformat nur in einem Teil des Displays, der der Viewportbreite bei Hochkant-Ansicht enspricht. Ggf. muss ein Tablet mit breiterem Viewport verwendet werden.
3.2 Vergrößerung auf Viewportbreite von 320 CSS-Pixel
Die Textgröße in den Einstellungen des Betriebssystems (und falls vorhanden in der App selbst) sollte auf die Standardgröße eingestellt sein (100%).
Abhängig vom genutzten Testgerät kann beim Hineinzoomen die Breite von 320 CSS-Pixeln ggf. nur näherungsweise erreicht werden. Bei einer Vergrößerungsstufe von 200% wäre die Viewportbreite in CSS-Pixeln halbiert. Je nach genutztem Gerät muss also verschieden stark vergrößert werden, um 320 CSS-Pixel näherungsweise zu erreichen.
Beispiel: Bei einem iPad Air (2020) mit 1112 CSS-Pixeln Breite wäre z.B. eine Vergrößerung um 347,5% notwendig, um exakt 320 CSS-Pixel Viewportbreite zu erreichen. Ist die CSS-Viewportbreite des Displays nicht bekannt, lässt diese sich in der Regel aus der physischen Auflösung des Displays und dem genutzten Pixel-Verhältnis (pixel ratio) berechnen. Die meisten aktuellen Geräte haben heute eine pixel ratio zwischen 3 und 4. So hat etwa ein Samsung Note 8 eine physische Auflösung von 1440 x 2960 Geräte-Pixeln, was bei einem Faktor 4 zu einer Auflösung von 360 x 740 CSS-Pixeln führt. Hier müsste also auf 230% vergrößert werden, um näherungsweise die Viewport-Breite von 320 CSS-Pixeln einzustellen.
Sind 320 CSS-Pixel nicht exakt einstellbar, sollte der nächsthöhere Stufenwert der Zoom-Vergrößerung verwendet werden.
3.3 Zoomfunktion auch bei Apps?
Im Kontext mobiler Apps mit der Ausgabe auf einem meist viel kleinerem Display kommen für sehbehinderte Nutzende heute meist systemseitige Methoden der Textvergrößerung zum Tragen: Einmal die Einstellung größerer Schrift in den Bedienungshilfen, die sich auf die Darstellung auswirkt, wenn Entwickler in der App dynamische Fonts verwenden, und dann die Bedienungshilfen Vergrößerung (Android) bzw. Zoom (iOS), deren Nutzung nicht zu einem Umbruch der Inhalte führt. Eine Ausnahme ist der Dolphin-Browser (Android), der Textumbruch umsetzt. Werden Apps auf Tablets mit größeren Viewport-Breiten angezeigt, wäre die Zoomvergrößerung hier ebenso hilfreich wie auf dem Desktop. Sie wird aber von nativen Apps (einschließlich mobilen Browsern) zurzeit kaum angeboten.
3.4 Angepasste Ansichten für breitere Viewports
Aus dem normativen Text ist keine Verpflichtung abzuleiten, dass für größere Viewportbreiten ein angepasstes Layout angeboten werden muss.
3.5 Lese- und Schreibrichtung
Dieser Prüfschritt beschränkt sich auf Inhalte, deren primäre Schreibrichtung waagerecht ist, wie bei der für die meisten westlichen Sprachen benutzten lateinischen Schrift. Die zugrunde liegende WCAG-Anforderung gilt in ähnlicher Weise für Inhalte mit vertikaler Schreibrichtung.
4. Bewertung
Nicht erfüllt
Die App hat eine Zoomfunktion. Beim Zoomen auf 320 CSS Pixel Viewportbreite gibt es Informationen oder Funktionen, die nicht mehr verfügbar sind oder abgeschnitten werden, und die nicht unter die Ausnahmen fallen.
Quellen
Allgemein
WCAG 1.4.10 Reflow: Understanding Reflow (zur Zeit nur auf Englisch verfügbar)
Appt.org Guidelines: Reflow. Beispiele für die Umsetzung vergrößerbaren umbrechenden Texts in den Umgebungen Android, iOS, Flutter, React Native und Xamarin. Hier wird Reflow auf das Verhalten von Text bei Übernahme nutzerdefinierter Systemeinstellungen bezogen.
Android
Appt.org: Reflow on Android
Einordnung des Prüfschritts nach WCAG 2.1
Guideline
Success Criterion
1.4.10 Reflow (Level AA)