-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
9.1.4.4 Text auf 200% vergrößerbar: Vorgabe der Browserfenstergröße #460
Comments
Also 1280 mag in einer Agentur unüblich sein. Aber ich kenne zum Teil ältere Herrschaften die vergrößern um alles lesen zu können mit solchen Monitoren zu Hause, die sie vor 15 Jahren gekauft haben. Das meist verkaufte Smartphone war 2023 ein Samsung für 150,- Euro. Mein Monitor hat über 3000 Pixel, ich habe immer zwei Fenster (mindestens) nebeneinander. Und ich vergrößere auch schon alles mindestens auf 125%, eher auf 150%. Das sind zwar mehr als 1280, aber weniger als 1920. Ich glaube, manche Menschen leben in einem Elfenbein-Turm und designen an echten Menschen vorbei. Das nur zum Thema unrealistisch, schwer vermittelbar usw. Was das als Test-Kriterium angeht: wir können uns gerne einigen auf andere/ weitere Varianten, aber wir brauchen IMHO ein standardisiertes Vorgehen für vergleichbare Bewertungen im Prüfverbund. Just my 2 Cent. |
Ich glaube, das ist eine ähnliche Problematik wie bei WCAG 1.4.12 (Textabstände), wo auch keine Fenstergröße vorgegeben ist. Vergleiche die Diskussion im Issue #273. In den WCAG Understanding wird bei 1.4.4 die Breite von 1280 px in einer Note erwähnt. Ebenso werden die 1280 px bei WCAG 1.4.10 als Ausgangsgröße für die 400 % genannt. Im Allgemeinen würde ich aber wie bei 1.4.12 sagen, dass die 200 % Vergrößerung prinzipiell in jeder Breite funktionieren müssen. Vielleicht kann man als Grenze annehmen, dass die Vergrößerung nicht zu weniger als 320 px Breite aus 1.4.10 führt, also dass 640 px Breite die minimale Breite für 200 % Vergrößerung sein muss. Aber es ist nur erschlossen, steht nirgendwo explizit. |
Schließe mich meinen Vorrednern an. Eigentlich müssten wir in allen Größen Testen. Da das nicht leistbar ist, müssen wir uns festlegen. Man kann es als auch so sehen. 1280 Pixel sind in Zeiten des Responsive Designs kein unverhältnismäßiger Mehraufwand. Wir hätten die Festlegung noch viel niedriger setzten können. Was würden alle fluchen, wenn wir mit 640px testen würden ;) Also ich bin ebenfalls dafür den Prüfschritt so belassen und ein Hinweis ergänzen. Noch ein Hinweis 1280 px sind recht verbreitet. Microsoft Accessibility Insights testet auch mit dieser Festlegung. |
Es kam die Frage auf, warum wir 9.1.4.4 bei einer Browserfesntergröße von 1280x768 px prüfen. Es wurde argumentiert, die Auflösung sei nicht mehr zeitgemäß. Es wurde argumentiert, dass mit Auflösungen von mindestens 1920x1080 (FullHD) gearbeitet wird. Gerade bei Webanwendungen sei es nicht einfach, den Entwicklungsteams zu vermitteln, warum Oberflächen bei einer Auflösung von 1280x768 vergrößert werden müssten.
Wir haben intern diskutiert und es ist richtig, der normative Text der WCAG gibt keine Browserfenstergröße vor. Normativ sollte sich Text in jeder Viewportgröße um 200% vergrößern lassen. D.h. wir müssten eingentlich die Vorgabe 1280 x 768px rausnehmen, aber dürften auch keine größere Viewportgröße festlegen.
Praktisch ergibt sich aber dennoch die Frage, wie dann zu testen sei. Es gibt ja Fälle, in denen bei einer Viewportgröße von 1280x 768px Fehler auftreten. D.h. nur bei größeren Viewportgrößen zu testen würde auch nicht der WCAG entsprechen.
Zudem ist wohl nicht davon auszugehen, dass Nutzende ihr Browserfenster immer auf Fullscreen eingestellt haben. Ein üblicher Usecase ist durchaus, dass Nutzende Dokumente parallel offen haben. Wir unterscheiden nicht zwischen Fachanwendung und informationsorientierter Website.
Gibt es Meinungen zum praktischen Umgang mit dem Problem? Eine Idee wäre, die Prüfanleitung so zu belassen, aber einen Hinweis zu ergänzen, der die Problematik erklärt?
The text was updated successfully, but these errors were encountered: