Wir kennen schon alles: #html5, #css3, #responsive webdesign, #mobile first und #flex layout. Und das alles #barrierefrei? Aber klar doch, weil mir #accessibility einfach Spass macht.
24 Gedanken zu “WCAG 2 und die reine Textvergrößerung”
Vielen Dank für die Ausarbeitung. Keine Frage, auf Stufe AAA sollte das horizontale Scrollen vermieden werden – in einem maximierten Fenster eines handelsüblichen Bildschirms. Nur dazu hält sich die WAI etwas bedeckt, finde ich. Das Erfolgskriterium auf Stufe AA ist m.E. fast schon obsolet, denn so wie es formuliert ist, ist es eine Sache des User Agents. Nochmal im direkten Vergleich.
In realen Projekten habe ich auch die Erfahrung gemacht, dass ein flüssiges Layout von Sehbehinderten abgelehnt wurde, weil sie es gewohnt waren, mit einem Seitenzoom zu arbeiten.
Stimme ich Dir zu – die WAI hat ja jetzt auf Nachfragen eindeutiger gesagt, dass auch Page Zoom auf AAA hinreichen kann, wenn es das Layout mitbringt. Das halte ich aber für eine gewagte These, moderne Webseiten sehen heute nicht mehr aus wie einfache Konstrukte. Ich hab mal einen Kurztest von Newsseiten gemacht, da scrollt 1/3 immer im Page Zoom bzw. man muss 1/3 hin und her scrollen, um den ganzen Satz zu lesen. Das halte ich schon für sehr anstrengend.
Mir erscheint der “Rückzug” auf den Page Zoom – hier mal synonym mit “fixem” Layout – schlicht aus den aktuellen Layoutentwicklungen heraus rückwärtsgewandt. Aber vielleicht bin ich dann schlicht zu sehr schon im Flexiblen unterwegs, dass ich mich noch mit “fixem” Layout beschäftigen will.
Ich hab neulich ein Problem gehabt, dass FF 7 (vermutlich auch vorherige) bei reinem Textzoom absolut positionierte Elemente verschiebt. Das war in dem Fall besonders ärgerlich, weil durch den Slider das Layout versaut wurde, obwohl extra genug Platz für den Text gelassen wurde. Eine Lösung habe ich leider nicht gefunden, weshalb das Ganze zwar mit 200% funktioniert, aber sehr verschoben aussieht.
Übrigens bin ich sehr begeistert von Media Queries. Allerdings ist das sehr aufwendig vor allem bei komplexen Designs und das wird noch sehr lange dauern, bis sich die Technik dauerhaft durchsetzt. Leider kann ich wegen NDA keine Beispiele nennen. :-(
Ich kann da jetzt schwer was dazu sagen, wenn ich die Seite nicht sehen kann. :) Aber absolute Positionierungen können immer heikel bei Vergrößerung sein.
Je komplexer das Design, desto mehr sollte man nicht nur auf Media Queries alleine setzen. Immer auch ein flexibles Layer mit kombinieren. Sonst kommt man aus den Queries nicht mehr raus. Sie sind ja letztlich nur ein Hilfsmittel, damit man bestimmte Layout- oder Auflösungspunkte modifizieren kann. Mehr aber auch nicht.
Ich benutze von http://978.gs/ alle Layouts mit Media Queries. Flexible Designs sind mir immer suspekt. *gg* Ich gebe bei den Breiten lieber Pixel an (kA warum).
Wir sind dann also bei der letzten Interpretation wieder auf dem Level des IE 6 angekommen – wenn der Kunde eine reine Textvergrößerung für sein Projekt wünscht, dann wird zum Standard – Page Zoom – auch noch die reine Textvergrößerung optimiert. Durchaus ein Standpunkt – und wenn ich mal unken darf – einer, der sich durchsetzen wird.
Zum Level des IE6: jein. Page-zoom ist – zumindest in Geckos – eine relativ junge Geschichte. Hinzu kommt, was ich in Deinem (etwas zu) ausführlichen Artikel vermisse, ist der Blick auf die (Desktop-)Auflösung. Ich benötige keinen IE6 um auf meinem “Reisecomputer” Page-zoom zur Hölle zu wünschen. Auch auf meinem Schreibtisch-rechner habe ich Page-zoom deaktiviert. Deine Unkenrufe kann ich so auch nicht nachvollziehen; ich vermute die Geschichte wird sich auf einem Stück Papier in irgendwelchen Wcag- oder anderen Richtlinien(!) tatsächlich als Standard wiederfinden, da draussen aber, im Internet, werden Web”designer” weiterhin das machen, was sie seit dem Tag, an dem im FF der page-zoom auf default gesetzt wurde machen: hübsche Designs mit hässlichen Scrollbalken versehen.
P.s.: ich bin nicht so “verbittert” weil ich sehbehindert bin, sondern weil ich gern bequem sitze… ;)
Ich frage mich seit einiger Zeit, warum nicht alle Browser-Hersteller die Umbruch-Funktion des mobilen Webkit (z.B. auf Android-Geräten) kopieren. Da bricht der Text einfach immer am rechten Rand um (reflow), egal wie groß die Darstellung ist. Ganz anders ist es bei iOS-Geräten. Der mobile Safari hat diese Funktion nicht. Für sehbehinderte IPad-Nutzer ein Greuel! Genauso stimme ich mike zu, dass die reine Zoom-Funktion auf z.B. Netbooks nahezu unbrauchbar ist. Daher ist eine reine Textvergrößerung, wenn schon eine Reflow-Funktion fehlt, unterwegs meist besser nutzbar. Vielleicht sollte eine Forderung an Browser-Hersteller, neben den üblichen Funktionen auch Reflow mit anzubieten (der Adobe-Reader bietet das mit seiner Umfließen-Funktion), in die Diskussion mit aufgenommen werden. Ich als sehbehinderter Nutzer scrolle jedenfalls lieber senkrecht als waagrecht. Daher lese ich Webseiten unterwegs grundsätzlich auf meinem Smartphone, auch wenn ich ein Notebook dabei habe und die Nutzung eines größeren Bildschirms die Arbeit erleichtern würde. Also wenn wir uns schon mangels ausreichender Funktionalität bei unseren Lieblingsbrowsern den Kopf über die richtige Auslegung von 1.4.4. bzw. 1.4.8. zerbrechen, dann sollten wir dabei nicht nur die übliche Bürosituation (übrigens immer häufiger bei 1920×1080!) im Kopf haben, sondern den rasant üblicher werdenden Zustand des mobilen Browsens bedenken. Oder wollen wir einen Zustand befördern, in dem es immer mehr Seiten in der Form http://mobil.irgendwas.tld oder http://irgendwas.tld/m gibt? Eine Auslegung von 1.4.4 und 1.4.8 rein in Richtung Page-Zoom würde nach meiner Ansicht genau dies forcieren.
Interessanterweise hat Opera auf Desktop – Mobile müsste ich mal testen – diese Reflow-Funktion zum Anwählen. Wußte ich bis dato nicht. Klar, das wäre wirklich eine Option, die jeder Browserhersteller einbauen könnte, dann wäre schon viel erledigt.
Das mit dem Ausrichten nach der “handelsüblichen” Auflösung ist auch so ein Punkt, der mir nicht ganz klar ist. Wäre dann 1920 gemeint, weil das oder auch noch mehr – keine Ahnung – grade handelsüblich ist? Das kommt dem Page Zoom ja entgegen. Aber das WCAG 2.0 schränkt das ja gleichzeitig wieder ein, wenn es darauf hinweist, dass man nicht davon ausgehen kann, dass alle sofort auf das Handelsübliche updaten.
Und ja, mit der Ausrichtung auf den Page Zoom geht man da in Richtung Mobile meint schon, dass man das horizontale Scrollen irgendwie in den Griff kriegen muss. Sei es mit mobilen Extraseiten oder durch x Media Queries, mit denen man dann hofft, das zu dämpfen. Ich denke nicht, dass das fixe Layout damit wirklich eine Zukunft haben kann.
Ich meinte das gerade umgekehrt – auch wenn der Vergleich mit dem IE6 etwas hinkt -. Den Textzoom gibt es ja schon etwas länger als den Page Zoom und die Optimierung auf die reine Textvergrößerung wird zu einem Addon werden wie die Optimierung für den IE6. Mit diesem Vergleich war aber nicht die gleiche Wertung wie in Bezug auf den IE6 gemeint.
Ich sehe das durchaus schon in der Praxis als Standard, nur für den Pagezoom zu optimieren, weil da braucht man ja nix mehr dafür tun, das geht ja auch schon. Was im technischen Detail ja nicht stimmt. Aber das hat sich schon so durchgesetzt, meiner Meinung nach. Aber Du hast da andere Daten, fein. :)
Ich seh das wie Mike. Um nicht in den Bildschirm kriechen zu müssen habe ich die Schriftgröße und Mindestschriftgröße entsprechend angepasst. Das Fazit: Auf gefühlt jeder 2. Website gibt es irgendwo Text, der abgeschnitten ist, oder Steuerelemente, die überlagert werden. Da hilft der Pagezoom dann auch nichts.
Danke für das Aufgreifen des Themas. Was mir (beileibe nicht nur bei dir) noch ein wenig fehlt ist ein Hinweis auf den Zusammenhang von Textzoom und individuellen Voreinstellungen. Zoom greift meist/häufig erst, wenn das Kind schon im Brunnen ist, eine Seite (mal wieder) mit zu kleinen Schriften daherkommt. Pagezoom erzwingt dann u.U. horizontales Scrollen und macht die Darstellung unübersichtlich. Textzoom sorgt häufig genug für überlappenden oder unlesbare Textteile ein Test prüft aber gleichzeitig auch die Stabilität bei abweichenden Voreinstellungen und ist m.E. deswegen unverzichtbar. In dem Moment, in dem Fließtext mit Pixel- oder u.U. auch %-basierten Containergrößen kombiniert wird, kann es zu Konflikten kommen, die viel zu oft nicht vorausgesehen und abgefangen werden.
Dabei müsste man wahrscheinlich nochmal differenzieren zwischen der Berücksichtigung der Bedürfnisse stark Sehbehinderter – denen häufig auch mit den postulierten 200% nicht geholfen sein dürfte – und den fast Normalsichtigen an Systemen mit hoher Auflösung, ungewöhnlichem Leseabstand oder leichter Fehlsichtigkeit. Letztere könnten sich durch das Einstellen einer größeren Basisschriftgröße oder einer Mindestschriftgröße wunderbar behelfen, in der Praxis klappt das leider viel zu oft nicht und bei einer Beschränkung auf den Pagezoom-Test wird das auch noch legitimiert.
Klar – es ging mir hier nicht darum, die konkreten Anwendungs- und Nutzungssituationen rauszuarbeiten, sondern wie die technische Sachlage sich im WCAG 2.0 und BITV 2.0 darstellt. Da das WCAG 2.0 mit seinen konkreten Erfolgskriterien und Techniken die erste Anlaufstelle für die barrierefreie Umsetzung ist, ist die Frage, ob der Page Zoom hinreicht, schon wichtig.
Freilich geht es weiter darum, sich das Ergebnis des WCAG 2.0 anzusehen und mit weiteren Kenntnissen anzureichern und abzuwägen. Aber die Frage ist, wenn es jetzt mal um Breitenwirkung gehen soll, welcher Entscheider oder Entwickler macht das. Schön wäre es, wenn – aber ich kenne jetzt schon die Frage: Sind wir WCAG 2 und BITV 2 konform, wenn wir für das Projekt nur auf den Page Zoom setzen. Und die Antwort – wenn die Frage an mich gestellt wäre – ist nun mal ja. Und mit Unterstützung des Page Zoom meinen die meisten halt – fixes Layout.
Ein schöner Artikel, den ich übrigens nicht zu lang finde. Vieles in der Barrierefreiheit lässt sich nicht mit einigen wenigen Absätzen erklären.
Ich denke, dass man die Ebenen Umsetzung / Beratung und Testen trennen muss. Auch nach der Klärung des W3C im März dieses Jahres, dass der Page Zoom für die Erfüllung des Erfolgskriterium ausreicht, wird man ja nicht daran gehindert, dafür zu sorgen, dass auch die reine Textvergrößerung in den gängigen Browsern verlustfrei funktioniert oder dies so zu empfehlen und beraten. Bei einem Test hingegen sollte es nur auf eines ankommen: ist das Erfolgskriterium erfüllt oder nicht. Das Erfolgskriterium ist klar erfüllt, wenn der Page Zoom funktioniert. Welche Haltung man dazu hat, ist letztlich zumindest dann “egal” oder sollte es sein, wenn ein Test wirklich die WCAG 2.0 prüfen soll.
Ja, stimmt – ich sollte das nächste Mal mehr trennen. Mir kommt immer der Entwickler dazwischen. :)
Beim Testen stimme ich Dir zu. Jedes Testverfahren, das nach WCAG 2.0 testet, muss sich nach den Anforderungen richten. Ich weiß nicht, ob es sinnvoll ist, da eigene Anforderungen noch mitzunehmen ins Testverfahren. Der BITV-Test testet ja nach AA und somit muss nur auf Page Zoom getestet werden. Der derzeitige Prüfschritt testet aber auf AAA.
Das mit dem Entwickler, der selbst entscheiden kann, ist nur bedingt so. Weil man wirklich in der Zwickmühle ist, dass die Frage gestellt wird: Was muss ich machen, damit ich bei der Vergrößerung die Mindestanforderung für BITV 2 / WCAG 2 erfülle. Und da müsste ich dann lügen auf AA, wenn ich mehr als den Page Zoom fordere. Was in den meisten Fällen meint, gut – dann machen wir alles fix im Layout.
Freilich sind wir heute aktuell in einer besseren Ausgangslage also vor ein paar Jahren. Durch Mobile und einer starken Forderung nach mehr Flexibilität des Layouts kann man anders argumentieren. Wenngleich Erfüllung des Page Zooms ja nicht ausschließt, dass man ein flexibles Layout anbietet.
Sicher: wird man gefragt, was “ausreicht”, um das Erfolgskriterium zu erfüllen, dann ist die Antwort: Page Zoom. Wird man gefragt, was man empfiehlt, dann ist für mich die Antwort klar: auch die reine Textvergrößerung.
“Ich weiß nicht, ob es sinnvoll ist, da eigene Anforderungen noch mitzunehmen ins Testverfahren.”
Das kann man machen. Nur muss dann allen klar sein, dass man nicht mehr Konformität mit WCAG 2.0/BITV 2.0 misst, sondern eben eigene Anforderungen und dass dies zwangsläufig zur Inkompatibilität führt, wenn eine Aussage zur Konformität mit den Richtlinien bei raus kommen soll.
Ich denke für das Testen ist sozusagen eine “leidenschaftslose”, nüchterne Haltung wichtig, da das Ergebnis nicht von den persönlichen Vorlieben hinsichtlich bestimmter Techniken abhängen darf.
Stimme ich Dir zu – auch bei der “leidenschaftslosen” Haltung. Ich denke, das hier auch mehrere Interventionen möglich sind.
Es muss geklärt werden, für welche Nutzergruppen die reine Textvergrößerung wichtig ist. Also zuerst das Sammeln von Daten. Dann kann man auch in der WAI eine Anfrage einbringen. Es gibt ja ohnehin eine Debatte, ob die Bedürfnisse von Sehbehinderten zu wenig in die WCAG 2.0 eingeflossen sind. Mir fehlen da die konkreten Daten. Aber ich denke, da wird sich noch was bewegen.
Bis dahin wird man nur auf den Page Zoom setzen.
Ein anderer Zugang ist – etwa von meiner technischen Seite -, dass aktuelle Layout-Entwicklungen gänzlich weg vom Statischen gehen und auf Dynamik und Elastik setzen. Daher stellt sich für mich die Frage nicht, mach ich jetzt wieder Text mit Pixel.
“Der BITV-Test testet ja nach AA und somit muss nur auf Page Zoom getestet werden. Der derzeitige Prüfschritt testet aber auf AAA.”
Aus meiner Sicht wird weder AA noch AAA getestet, sondern eine komplett eigene Anforderung. Der Prüfschritt im BITV-Test ist dann erfüllt:
“Bei Nur-Text-Vergrößerung auf 150% in Firefox beziehungsweise “sehr groß” im Internet Explorer sind alle Inhalte lesbar und alle Funktionen nutzbar.”
Nur: es gibt kein Erfolgskriterium, das 150% fordern würde. In beiden EK ist stets von 200% die Rede, also muss man auch eine Seite auf 200% testen und nicht auf etwas anderes. Wenn man 150% testet, dann beantwortet man nicht mehr die Frage, ob das EK (200%) erfüllt ist oder nicht.
Ja, darüber wird diskutiert werden – auch beim BITV-Test. Ich denke auch, dass es etwas haarig wird, wenn man eigene Werte anlegt, weil höhere Werte etwa schwierig zu realisieren sind oder unrealistisch. Das würde je rückschliessen lassen, dass die reine Textvergrößerung eben nicht mit gemeint ist im Erfolgskriterium.
Mit der allgemeinen Anforderung zum Seitenzoom (1.4.4, Konformitätsstufe AA) wird unter dem Strich gesagt, dass Inhalte sich auf 200% vergrößern lassen müssen, auch wenn dadurch horizontales Scrollen entsteht. Bei Erfolgskriterium 1.4.8 (Konformitätsstufe AAA) soll bei Vergrößerung das horizontale Scrollen vermieden werden. Dennoch wird hier davon ausgegangen, dass der Seitenzoom (Funktion des Browsers) immer zu horizontalem Scrollen führt (Ausnahmen, siehe Kommentare oben).
Hierzu zwei Anmerkungen:
1. Ein Seitenzoom bedeutet keinesfalls, dass horizontales Scrollen bewirkt wird. Auf http://www.barrierefreies-webdesign.de bricht das Layout beispielsweise auch bei Seitenzoom um und nicht nur bei Textvergrößerung. Das geht aber nur bei aktiviertem JavaScript. 3. Ich behaupte, dass das Vermeiden des horizontalem Scrollen auf Konformitätsstufe AAA statt auf Konformitätsstufe AA weniger mit den Anforderungen der Nutzer zu tun hat, sondern mehr mit der Umsetzbarkeit. Alleine mit HTML und CSS ist das Vermeiden von horizontalem Scrollen und und die Erhaltung eines halbwegs ansehnlichen Layouts nicht möglich. Abgesehen von den unterschiedlichen Verhaltensweisen der Browser stellt die gegenseitige Einflussnahme von Textvergrößerung einerseits und Fensterverkleinerung/Verringerung der Bildschirmauflösung andererseits eine äußerst diffizile technische Angelegenheit dar. Dies auf Stufe AA zu platzieren würde praktisch gesehen bedeuten, dass die Anforderung technisch kaum noch überprüfbar ist und außerdem kaum eine Seite die Konformitätsstufe AA erreichen kann.
Überhaupt stellen viele Anforderungen der Konformitätsstufe AAA solche Anforderungen, die schlecht oder zumindest unzuverlässig überprüft werden können. Deswegen ist völlig richtig, dass das flüssige Layout auf Konformitätsstufe AAA steht.
Ansonsten stellt der Seitenzoom nur einer von vielen möglichen Techniken zur Schriftvergrößerung dar. Der reine Seitenzoom ist ohne JavaScript zweckmäßig auf Konformitätsstufe AA, weil sie technisch gut überprüfbar ist. Das soll aber keinen daran hindern, Techniken mit JavaScript einzusetzen, die ein flüssiges Layout erwirken.
Aber zuerst hat doch die Anforderung, horizontales Scrollen zu vermeiden, mit dem Nutzer zu tun. Wenn Nutzer das nicht brauchen oder fordern würden, bräuchten wir es auch nicht umsetzen. ;)
Doch: heute ist es durchaus möglich – siehe meine eigene Seite – mit Hilfe von HTML und CSS sowohl für den Page Zoom als auch die reine Textvergrößerung Seiten ohne horizontales Scrollen zu erzeugen. Dazu reicht eine flexibles Layout mit Media Queries. Geht man dann noch von mobiler Flexibilität aus, kann man mit Mobile First starten. Das Ergebnis ist dann halt bei 200% Page Zoom, dass man die mobile Variante erhält. Was aber bei der Vergößerung durchaus gut lesbar ist. Ich würde für solche Optimierung kein Javascript nutzen.
Wie gesagt, ich denke nicht, dass man Javascript nutzen muss, um ein gut lesbares Layout für viele Nutzeranforderungen zu erstellen. Dazu haben wir schlicht mittlerweile einfach mehr Standard-Möglichkeiten als noch vor Jahren.
Na, das nenne ich mal AAA für Seitenzoom und AAA für Textvergrößerung. Auf dieser Seite funktioniert das sehr schön (auch wenn zwischendrin ein horizontaler Scrollbalken erschien und danach wieder verschwand; IE8;1360px;Seitenzoom). Hatte ich bislang gar nicht in Erwägung gezogen.
Vielen Dank für die Ausarbeitung. Keine Frage, auf Stufe AAA sollte das horizontale Scrollen vermieden werden – in einem maximierten Fenster eines handelsüblichen Bildschirms. Nur dazu hält sich die WAI etwas bedeckt, finde ich. Das Erfolgskriterium auf Stufe AA ist m.E. fast schon obsolet, denn so wie es formuliert ist, ist es eine Sache des User Agents. Nochmal im direkten Vergleich.
In realen Projekten habe ich auch die Erfahrung gemacht, dass ein flüssiges Layout von Sehbehinderten abgelehnt wurde, weil sie es gewohnt waren, mit einem Seitenzoom zu arbeiten.
Stimme ich Dir zu – die WAI hat ja jetzt auf Nachfragen eindeutiger gesagt, dass auch Page Zoom auf AAA hinreichen kann, wenn es das Layout mitbringt. Das halte ich aber für eine gewagte These, moderne Webseiten sehen heute nicht mehr aus wie einfache Konstrukte. Ich hab mal einen Kurztest von Newsseiten gemacht, da scrollt 1/3 immer im Page Zoom bzw. man muss 1/3 hin und her scrollen, um den ganzen Satz zu lesen. Das halte ich schon für sehr anstrengend.
Mir erscheint der “Rückzug” auf den Page Zoom – hier mal synonym mit “fixem” Layout – schlicht aus den aktuellen Layoutentwicklungen heraus rückwärtsgewandt. Aber vielleicht bin ich dann schlicht zu sehr schon im Flexiblen unterwegs, dass ich mich noch mit “fixem” Layout beschäftigen will.
Ich hab neulich ein Problem gehabt, dass FF 7 (vermutlich auch vorherige) bei reinem Textzoom absolut positionierte Elemente verschiebt. Das war in dem Fall besonders ärgerlich, weil durch den Slider das Layout versaut wurde, obwohl extra genug Platz für den Text gelassen wurde. Eine Lösung habe ich leider nicht gefunden, weshalb das Ganze zwar mit 200% funktioniert, aber sehr verschoben aussieht.
Übrigens bin ich sehr begeistert von Media Queries. Allerdings ist das sehr aufwendig vor allem bei komplexen Designs und das wird noch sehr lange dauern, bis sich die Technik dauerhaft durchsetzt. Leider kann ich wegen NDA keine Beispiele nennen. :-(
Ich kann da jetzt schwer was dazu sagen, wenn ich die Seite nicht sehen kann. :) Aber absolute Positionierungen können immer heikel bei Vergrößerung sein.
Je komplexer das Design, desto mehr sollte man nicht nur auf Media Queries alleine setzen. Immer auch ein flexibles Layer mit kombinieren. Sonst kommt man aus den Queries nicht mehr raus. Sie sind ja letztlich nur ein Hilfsmittel, damit man bestimmte Layout- oder Auflösungspunkte modifizieren kann. Mehr aber auch nicht.
Ich benutze von http://978.gs/ alle Layouts mit Media Queries. Flexible Designs sind mir immer suspekt. *gg* Ich gebe bei den Breiten lieber Pixel an (kA warum).
Jeder wie er möchte. Wenngleich ich denke, dass fixe Layouts mit Media Queries nicht flexibler werden. Im Übrigen gibt es ja auch flexible Grids.
Pingback: Leselinks auf der Flucht – Codecandies
Zum Level des IE6: jein. Page-zoom ist – zumindest in Geckos – eine relativ junge Geschichte.
Hinzu kommt, was ich in Deinem (etwas zu) ausführlichen Artikel vermisse, ist der Blick auf die (Desktop-)Auflösung. Ich benötige keinen IE6 um auf meinem “Reisecomputer” Page-zoom zur Hölle zu wünschen. Auch auf meinem Schreibtisch-rechner habe ich Page-zoom deaktiviert.
Deine Unkenrufe kann ich so auch nicht nachvollziehen; ich vermute die Geschichte wird sich auf einem Stück Papier in irgendwelchen Wcag- oder anderen Richtlinien(!) tatsächlich als Standard wiederfinden, da draussen aber, im Internet, werden Web”designer” weiterhin das machen, was sie seit dem Tag, an dem im FF der page-zoom auf default gesetzt wurde machen:
hübsche Designs mit hässlichen Scrollbalken versehen.
P.s.: ich bin nicht so “verbittert” weil ich sehbehindert bin, sondern weil ich gern bequem sitze… ;)
Ich frage mich seit einiger Zeit, warum nicht alle Browser-Hersteller die Umbruch-Funktion des mobilen Webkit (z.B. auf Android-Geräten) kopieren. Da bricht der Text einfach immer am rechten Rand um (reflow), egal wie groß die Darstellung ist. Ganz anders ist es bei iOS-Geräten. Der mobile Safari hat diese Funktion nicht. Für sehbehinderte IPad-Nutzer ein Greuel! Genauso stimme ich mike zu, dass die reine Zoom-Funktion auf z.B. Netbooks nahezu unbrauchbar ist. Daher ist eine reine Textvergrößerung, wenn schon eine Reflow-Funktion fehlt, unterwegs meist besser nutzbar. Vielleicht sollte eine Forderung an Browser-Hersteller, neben den üblichen Funktionen auch Reflow mit anzubieten (der Adobe-Reader bietet das mit seiner Umfließen-Funktion), in die Diskussion mit aufgenommen werden.
Ich als sehbehinderter Nutzer scrolle jedenfalls lieber senkrecht als waagrecht. Daher lese ich Webseiten unterwegs grundsätzlich auf meinem Smartphone, auch wenn ich ein Notebook dabei habe und die Nutzung eines größeren Bildschirms die Arbeit erleichtern würde.
Also wenn wir uns schon mangels ausreichender Funktionalität bei unseren Lieblingsbrowsern den Kopf über die richtige Auslegung von 1.4.4. bzw. 1.4.8. zerbrechen, dann sollten wir dabei nicht nur die übliche Bürosituation (übrigens immer häufiger bei 1920×1080!) im Kopf haben, sondern den rasant üblicher werdenden Zustand des mobilen Browsens bedenken. Oder wollen wir einen Zustand befördern, in dem es immer mehr Seiten in der Form http://mobil.irgendwas.tld oder http://irgendwas.tld/m gibt? Eine Auslegung von 1.4.4 und 1.4.8 rein in Richtung Page-Zoom würde nach meiner Ansicht genau dies forcieren.
Interessanterweise hat Opera auf Desktop – Mobile müsste ich mal testen – diese Reflow-Funktion zum Anwählen. Wußte ich bis dato nicht. Klar, das wäre wirklich eine Option, die jeder Browserhersteller einbauen könnte, dann wäre schon viel erledigt.
Das mit dem Ausrichten nach der “handelsüblichen” Auflösung ist auch so ein Punkt, der mir nicht ganz klar ist. Wäre dann 1920 gemeint, weil das oder auch noch mehr – keine Ahnung – grade handelsüblich ist? Das kommt dem Page Zoom ja entgegen. Aber das WCAG 2.0 schränkt das ja gleichzeitig wieder ein, wenn es darauf hinweist, dass man nicht davon ausgehen kann, dass alle sofort auf das Handelsübliche updaten.
Und ja, mit der Ausrichtung auf den Page Zoom geht man da in Richtung Mobile meint schon, dass man das horizontale Scrollen irgendwie in den Griff kriegen muss. Sei es mit mobilen Extraseiten oder durch x Media Queries, mit denen man dann hofft, das zu dämpfen. Ich denke nicht, dass das fixe Layout damit wirklich eine Zukunft haben kann.
Ich meinte das gerade umgekehrt – auch wenn der Vergleich mit dem IE6 etwas hinkt -. Den Textzoom gibt es ja schon etwas länger als den Page Zoom und die Optimierung auf die reine Textvergrößerung wird zu einem Addon werden wie die Optimierung für den IE6. Mit diesem Vergleich war aber nicht die gleiche Wertung wie in Bezug auf den IE6 gemeint.
Ich sehe das durchaus schon in der Praxis als Standard, nur für den Pagezoom zu optimieren, weil da braucht man ja nix mehr dafür tun, das geht ja auch schon. Was im technischen Detail ja nicht stimmt. Aber das hat sich schon so durchgesetzt, meiner Meinung nach. Aber Du hast da andere Daten, fein. :)
Ich seh das wie Mike. Um nicht in den Bildschirm kriechen zu müssen habe ich die Schriftgröße und Mindestschriftgröße entsprechend angepasst. Das Fazit: Auf gefühlt jeder 2. Website gibt es irgendwo Text, der abgeschnitten ist, oder Steuerelemente, die überlagert werden. Da hilft der Pagezoom dann auch nichts.
Das spricht ja nicht gegen den Pagezoom, sondern gegen die Seiten, die dafür nicht optimiert sind.
Danke für das Aufgreifen des Themas. Was mir (beileibe nicht nur bei dir) noch ein wenig fehlt ist ein Hinweis auf den Zusammenhang von Textzoom und individuellen Voreinstellungen.
Zoom greift meist/häufig erst, wenn das Kind schon im Brunnen ist, eine Seite (mal wieder) mit zu kleinen Schriften daherkommt. Pagezoom erzwingt dann u.U. horizontales Scrollen und macht die Darstellung unübersichtlich. Textzoom sorgt häufig genug für überlappenden oder unlesbare Textteile ein Test prüft aber gleichzeitig auch die Stabilität bei abweichenden Voreinstellungen und ist m.E. deswegen unverzichtbar. In dem Moment, in dem Fließtext mit Pixel- oder u.U. auch %-basierten Containergrößen kombiniert wird, kann es zu Konflikten kommen, die viel zu oft nicht vorausgesehen und abgefangen werden.
Dabei müsste man wahrscheinlich nochmal differenzieren zwischen der Berücksichtigung der Bedürfnisse stark Sehbehinderter – denen häufig auch mit den postulierten 200% nicht geholfen sein dürfte – und den fast Normalsichtigen an Systemen mit hoher Auflösung, ungewöhnlichem Leseabstand oder leichter Fehlsichtigkeit. Letztere könnten sich durch das Einstellen einer größeren Basisschriftgröße oder einer Mindestschriftgröße wunderbar behelfen, in der Praxis klappt das leider viel zu oft nicht und bei einer Beschränkung auf den Pagezoom-Test wird das auch noch legitimiert.
Klar – es ging mir hier nicht darum, die konkreten Anwendungs- und Nutzungssituationen rauszuarbeiten, sondern wie die technische Sachlage sich im WCAG 2.0 und BITV 2.0 darstellt. Da das WCAG 2.0 mit seinen konkreten Erfolgskriterien und Techniken die erste Anlaufstelle für die barrierefreie Umsetzung ist, ist die Frage, ob der Page Zoom hinreicht, schon wichtig.
Freilich geht es weiter darum, sich das Ergebnis des WCAG 2.0 anzusehen und mit weiteren Kenntnissen anzureichern und abzuwägen. Aber die Frage ist, wenn es jetzt mal um Breitenwirkung gehen soll, welcher Entscheider oder Entwickler macht das. Schön wäre es, wenn – aber ich kenne jetzt schon die Frage: Sind wir WCAG 2 und BITV 2 konform, wenn wir für das Projekt nur auf den Page Zoom setzen. Und die Antwort – wenn die Frage an mich gestellt wäre – ist nun mal ja. Und mit Unterstützung des Page Zoom meinen die meisten halt – fixes Layout.
Ein schöner Artikel, den ich übrigens nicht zu lang finde. Vieles in der Barrierefreiheit lässt sich nicht mit einigen wenigen Absätzen erklären.
Ich denke, dass man die Ebenen Umsetzung / Beratung und Testen trennen muss. Auch nach der Klärung des W3C im März dieses Jahres, dass der Page Zoom für die Erfüllung des Erfolgskriterium ausreicht, wird man ja nicht daran gehindert, dafür zu sorgen, dass auch die reine Textvergrößerung in den gängigen Browsern verlustfrei funktioniert oder dies so zu empfehlen und beraten. Bei einem Test hingegen sollte es nur auf eines ankommen: ist das Erfolgskriterium erfüllt oder nicht. Das Erfolgskriterium ist klar erfüllt, wenn der Page Zoom funktioniert. Welche Haltung man dazu hat, ist letztlich zumindest dann “egal” oder sollte es sein, wenn ein Test wirklich die WCAG 2.0 prüfen soll.
Ja, stimmt – ich sollte das nächste Mal mehr trennen. Mir kommt immer der Entwickler dazwischen. :)
Beim Testen stimme ich Dir zu. Jedes Testverfahren, das nach WCAG 2.0 testet, muss sich nach den Anforderungen richten. Ich weiß nicht, ob es sinnvoll ist, da eigene Anforderungen noch mitzunehmen ins Testverfahren. Der BITV-Test testet ja nach AA und somit muss nur auf Page Zoom getestet werden. Der derzeitige Prüfschritt testet aber auf AAA.
Das mit dem Entwickler, der selbst entscheiden kann, ist nur bedingt so. Weil man wirklich in der Zwickmühle ist, dass die Frage gestellt wird: Was muss ich machen, damit ich bei der Vergrößerung die Mindestanforderung für BITV 2 / WCAG 2 erfülle. Und da müsste ich dann lügen auf AA, wenn ich mehr als den Page Zoom fordere. Was in den meisten Fällen meint, gut – dann machen wir alles fix im Layout.
Freilich sind wir heute aktuell in einer besseren Ausgangslage also vor ein paar Jahren. Durch Mobile und einer starken Forderung nach mehr Flexibilität des Layouts kann man anders argumentieren. Wenngleich Erfüllung des Page Zooms ja nicht ausschließt, dass man ein flexibles Layout anbietet.
Sicher: wird man gefragt, was “ausreicht”, um das Erfolgskriterium zu erfüllen, dann ist die Antwort: Page Zoom. Wird man gefragt, was man empfiehlt, dann ist für mich die Antwort klar: auch die reine Textvergrößerung.
“Ich weiß nicht, ob es sinnvoll ist, da eigene Anforderungen noch mitzunehmen ins Testverfahren.”
Das kann man machen. Nur muss dann allen klar sein, dass man nicht mehr Konformität mit WCAG 2.0/BITV 2.0 misst, sondern eben eigene Anforderungen und dass dies zwangsläufig zur Inkompatibilität führt, wenn eine Aussage zur Konformität mit den Richtlinien bei raus kommen soll.
Ich denke für das Testen ist sozusagen eine “leidenschaftslose”, nüchterne Haltung wichtig, da das Ergebnis nicht von den persönlichen Vorlieben hinsichtlich bestimmter Techniken abhängen darf.
Stimme ich Dir zu – auch bei der “leidenschaftslosen” Haltung. Ich denke, das hier auch mehrere Interventionen möglich sind.
Es muss geklärt werden, für welche Nutzergruppen die reine Textvergrößerung wichtig ist. Also zuerst das Sammeln von Daten.
Dann kann man auch in der WAI eine Anfrage einbringen. Es gibt ja ohnehin eine Debatte, ob die Bedürfnisse von Sehbehinderten zu wenig in die WCAG 2.0 eingeflossen sind.
Mir fehlen da die konkreten Daten. Aber ich denke, da wird sich noch was bewegen.
Bis dahin wird man nur auf den Page Zoom setzen.
Ein anderer Zugang ist – etwa von meiner technischen Seite -, dass aktuelle Layout-Entwicklungen gänzlich weg vom Statischen gehen und auf Dynamik und Elastik setzen.
Daher stellt sich für mich die Frage nicht, mach ich jetzt wieder Text mit Pixel.
Noch ein kurzer Kommentar hinterher:
“Der BITV-Test testet ja nach AA und somit muss nur auf Page Zoom getestet werden. Der derzeitige Prüfschritt testet aber auf AAA.”
Aus meiner Sicht wird weder AA noch AAA getestet, sondern eine komplett eigene Anforderung. Der Prüfschritt im BITV-Test ist dann erfüllt:
“Bei Nur-Text-Vergrößerung auf 150% in Firefox beziehungsweise “sehr groß” im Internet Explorer sind alle Inhalte lesbar und alle Funktionen nutzbar.”
Nur: es gibt kein Erfolgskriterium, das 150% fordern würde. In beiden EK ist stets von 200% die Rede, also muss man auch eine Seite auf 200% testen und nicht auf etwas anderes. Wenn man 150% testet, dann beantwortet man nicht mehr die Frage, ob das EK (200%) erfüllt ist oder nicht.
Ja, darüber wird diskutiert werden – auch beim BITV-Test. Ich denke auch, dass es etwas haarig wird, wenn man eigene Werte anlegt, weil höhere Werte etwa schwierig zu realisieren sind oder unrealistisch. Das würde je rückschliessen lassen, dass die reine Textvergrößerung eben nicht mit gemeint ist im Erfolgskriterium.
Da stimme ich mit Dir überein.
Ein Nachtrag auch von mir:
Mit der allgemeinen Anforderung zum Seitenzoom (1.4.4, Konformitätsstufe AA) wird unter dem Strich gesagt, dass Inhalte sich auf 200% vergrößern lassen müssen, auch wenn dadurch horizontales Scrollen entsteht. Bei Erfolgskriterium 1.4.8 (Konformitätsstufe AAA) soll bei Vergrößerung das horizontale Scrollen vermieden werden. Dennoch wird hier davon ausgegangen, dass der Seitenzoom (Funktion des Browsers) immer zu horizontalem Scrollen führt (Ausnahmen, siehe Kommentare oben).
Hierzu zwei Anmerkungen:
1. Ein Seitenzoom bedeutet keinesfalls, dass horizontales Scrollen bewirkt wird. Auf http://www.barrierefreies-webdesign.de bricht das Layout beispielsweise auch bei Seitenzoom um und nicht nur bei Textvergrößerung. Das geht aber nur bei aktiviertem JavaScript.
3. Ich behaupte, dass das Vermeiden des horizontalem Scrollen auf Konformitätsstufe AAA statt auf Konformitätsstufe AA weniger mit den Anforderungen der Nutzer zu tun hat, sondern mehr mit der Umsetzbarkeit. Alleine mit HTML und CSS ist das Vermeiden von horizontalem Scrollen und und die Erhaltung eines halbwegs ansehnlichen Layouts nicht möglich. Abgesehen von den unterschiedlichen Verhaltensweisen der Browser stellt die gegenseitige Einflussnahme von Textvergrößerung einerseits und Fensterverkleinerung/Verringerung der Bildschirmauflösung andererseits eine äußerst diffizile technische Angelegenheit dar. Dies auf Stufe AA zu platzieren würde praktisch gesehen bedeuten, dass die Anforderung technisch kaum noch überprüfbar ist und außerdem kaum eine Seite die Konformitätsstufe AA erreichen kann.
Überhaupt stellen viele Anforderungen der Konformitätsstufe AAA solche Anforderungen, die schlecht oder zumindest unzuverlässig überprüft werden können. Deswegen ist völlig richtig, dass das flüssige Layout auf Konformitätsstufe AAA steht.
Ansonsten stellt der Seitenzoom nur einer von vielen möglichen Techniken zur Schriftvergrößerung dar. Der reine Seitenzoom ist ohne JavaScript zweckmäßig auf Konformitätsstufe AA, weil sie technisch gut überprüfbar ist. Das soll aber keinen daran hindern, Techniken mit JavaScript einzusetzen, die ein flüssiges Layout erwirken.
Aber zuerst hat doch die Anforderung, horizontales Scrollen zu vermeiden, mit dem Nutzer zu tun. Wenn Nutzer das nicht brauchen oder fordern würden, bräuchten wir es auch nicht umsetzen. ;)
Doch: heute ist es durchaus möglich – siehe meine eigene Seite – mit Hilfe von HTML und CSS sowohl für den Page Zoom als auch die reine Textvergrößerung Seiten ohne horizontales Scrollen zu erzeugen. Dazu reicht eine flexibles Layout mit Media Queries. Geht man dann noch von mobiler Flexibilität aus, kann man mit Mobile First starten. Das Ergebnis ist dann halt bei 200% Page Zoom, dass man die mobile Variante erhält. Was aber bei der Vergößerung durchaus gut lesbar ist. Ich würde für solche Optimierung kein Javascript nutzen.
Wie gesagt, ich denke nicht, dass man Javascript nutzen muss, um ein gut lesbares Layout für viele Nutzeranforderungen zu erstellen. Dazu haben wir schlicht mittlerweile einfach mehr Standard-Möglichkeiten als noch vor Jahren.
Na, das nenne ich mal AAA für Seitenzoom und AAA für Textvergrößerung. Auf dieser Seite funktioniert das sehr schön (auch wenn zwischendrin ein horizontaler Scrollbalken erschien und danach wieder verschwand; IE8;1360px;Seitenzoom). Hatte ich bislang gar nicht in Erwägung gezogen.