sprungmarker testet

WCAG 2 und die reine Textvergrößerung

Manche Themen flammen kurz in Artikeln und Kommentaren auf, aber letztlich fragt sich der barrierefreie Entwickler, ob er jetzt genug an der Hand hat, um Empfehlungen und Entscheidungen abgeben zu können. Ein Thema, das jüngst kurz in der Debatte war und gerade wieder ist, ist die reine Textvergrößerung. Die Frage dabei ist, setzt die WCAG 2.0 noch auf die reine Textvergrößerung oder ist die Vergrößerung der gesamten Seite mit Hilfe des Page Zooms hinreichend.

WCAG 2.0 und BITV 2.0: Textvergrößerung im Vergleich

Bevor wir uns jedoch mit der reinen Textvergrößerung beschäftigen, ist es notwendig, kurz auf die Textvergrößerung allgemein einzugehen. Auch nach dem kürzlichen Inkrafttreten der BITV 2.0 stellt sich diese Frage nicht wirklich neu, aber die Erfolgskriterien der WCAG 2.0 entsprechen im wesentlichen der BITV 2.0 zur Textvergrößerung: Veränderbare Textgröße (1.4.4 BITV Priorität I, WCAG 2.0 AA) und Visuelle Präsentation (1.4.8 BITV Priorität II, WCAG 2.0 AAA).

Screenshot Einstellung reine Textvergrößerung im IE 9
Auswahl reine Textvergrößerung IE9

Die Unterscheidungen liegen im Detail – aber da Details in der Barrierefreiheit durchaus einen großen Unterschied machen können, zeige ich diese auf. Nach BITV 2.0 ist es auf Priorität I nötig, dass sich Text ohne assistive Technologie auf bis zu 200% vergrößern lässt. Wichtig dabei ist, dass inhaltlich nichts verloren geht und noch alles funktioniert. Die Frage dabei wird sein, wie definiert man Verlust? Inhaltlich ist das leichter verständlich, funktional wird es schon haariger.

Der Text lässt sich ohne assistive Technologie bis auf 200 % vergrößern, ohne dass es zu einem Verlust von Inhalt oder Funktionalität kommt.

Quelle: BITV 2.0: 1.4.4 Veränderbare Textgröße

Die WCAG 2.0 schränkt gerne ihre Erfolgskriterien weiter ein und so trifft diese Vergrößerung von Text auf 200% auf Captions und Schriftgrafiken nicht zu. Für Schriftgrafik, die man ohnehin nicht wirklich verwenden soll, ist das einleuchtend. Wird sie mit dem Page Zoom hochgezogen, wird die Grafik dadurch nicht besser und fast immer schwerer lesbar. Warum Captions etwa bei Videos nicht ebenso vergrößerbar sein sollen, ist weniger klar. Ist der Player flexibel gebaut, werden auch die Captions mit vergrößert und in HTML5 Playern skaliert beides im Page Zoom mit. Aber interessant sind die Einschränkungen allemal, weil sich die Frage stellt, ob die BITV 2.0 dann für beides eine hinreichende Vergrößerung fordert.

Textvergrößerung = Page Zoom?

Ist auf dieser Stufe (WCAG 2.0 AA, BITV 2.0 Priorität 1) nun denkbar, dass mit Textvergrößerung nur der Page Zoom gemeint sein kann. Und genau hier hake ich jetzt ein und ich kann verraten: Ja, genau der Page Zoom ist auf dieser Stufe gemeint.

Screenshot Auswahl der reinen Textvergrößerung in Firefox
Auswahl reine Textvergrößerung Firefox

Das Problem mit den WCAG 2.0 ist, dass sie mitunter durchaus zu unterschiedlichen Interpretationen einlädt – jeder kann da sein eigener Exeget werden. Was dann bei so wichtigen Fragestellungen, wie denn nun mit der reinen Textvergrößerung umgehen, zu erhitzten Debatten führt. Der BITV-Test hat in seinem Artikel Textvergrößerung: warum Zoom-Vergrößerung nicht ausreicht auf diese Schwierigkeit hingewiesen, die ausführlichere englische Version hat dann einige Debatten ausgelöst.

Das Problem im Umgang mit dem WCAG 2.0 ist, dass man nicht etwa aus einem Fehlerbeispiel hochrechnen kann und den darin dargestellten Fehlerfall und seine Lösung als ausreichende Technik für das Erfolgskriterium nutzen kann. Unter verbreitete Fehler für 1.4.4. veränderbare Textgröße findet sich das Beispiel F69. Die Beispiele, die darin aufgeführt werden, sprechen dafür, dass auch die reine Textvergrößerung mit gemeint sein könnte. Beide Code-Beispiele spiegeln die Problematik wieder, dass der Text flexibel vergrößert werden kann, aber der ihn umgebende Behälter eine feste Breite und  – was problematischer ist – eine feste Höhe hat.

Nutzt man den Page Zoom für diese beiden Beispielfälle, gibt es keine Probleme. Voraussetzung ist natürlich, dass der Browser diesen auch implementiert hat. Bei der reinen Textvergrößerung, die einige Browser zusätzlich anbieten, läuft der Text entweder über den Behälter hinaus und über den nächsten Text oder wird schlicht abgeschnitten. Auch das erwähnte Beispiel bei Vergrößerungen von absoluten Positionierungen kann zu diesen Problemen führen, aber weit weniger im Page Zoom. Suggeriert wird in diesen Fehlerbeispielen, dass der reine Textzoom hierbei eine tragende Rolle spielt.

Screenshot Auswahl reine Textvergrößerung in den Einstellungen von Chrome
Auswahl reine Textvergrößerung Chrome

Und daran hat sich auch die Debatte entfacht: an diesem Interpretationsspielraum zwischen Fehler F69 und der Aussage des Erfolgskriteriums. Der BITV-Test sieht da durchaus eine Verbindung – und es ist ja nicht von der Hand zu weisen, wenn auch nur eine implizite und keine, die über die hinreichenden Techniken weiter angesprochen wird. In den Kommentaren aus dem englischsprachigen Bereich kam daher auch sofort die Kritik, dass das eine Überinterpretation sei und man das Erfolgskriterium Textvergrößerung so verstehen sollte: Hinreichend ist es, wenn eine Seite mit Page Zoom entsprechend skaliert, aber wenn die reine Textvergrößerung genutzt wird – was von der Projektanforderung abhängig gemacht wird, dann muss auch diese funktionieren.

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.

Reine Textvergrößerung = Level AAA und Priorität 2?

Auf Level AAA und Priorität 2 stimmen WCAG 2.0 und BITV 2.0 hinsichtlich Textvergrößerung überein:

der Text kann im Vollbildmodus ohne assistive Technologie bis auf 200 % vergrößert werden, ohne dass die Nutzerinnen oder Nutzer eine Textzeile horizontal scrollen müssen.

Quelle: BITV 2.0 – 1.4.9 Visuelle Präsentation

Auf Level AAA und Priorität 2 kommen also folgende Bedingungen hinzu: der Vollbildmodus und dass bei 200% nicht horizontal gescrollt wird. Vollbildmodus meint die jeweils aktuelle Standardauflösung des Browsers (ich würde das heute nicht mehr nur auf den Desktop reduzieren wollen). Interessanterweise wird das Erfolgskriterium 1.4.9 Visuelle Präsentation nur auf Desktop- und Laptop-Browser angewendet.

Das horizontale Scrollen ist nur pro Zeile zu verstehen und wird nicht auf mehrspaltiges Layout bezogen. Ist der Hauptbereich im sichtbaren und lesbaren Bereich ohne Scrollen, ist das hinreichend. Für den Seitenbereich scrollt man dann horizontal nach rechts und liest dort innerhalb des sichtbaren Bereichs. Das ist eine wichtiger Punkt, weil man daran gut erkennen kann, dass es auch hier hauptsächlich um den Page Zoom geht.

Screenshot Auswahl reine Textvergrößerung in Safari
Auswahl reine Textvergrößerung Safari

Freilich finden sich auf diesem Level dann mehr ausreichende Techniken, die nicht nur den Text sondern auch das ihn umgebende Layout flexibler machen wie etwa Erfolgskriterium G146 liquides Layout. Zwingend dazu muss jedoch noch eine weitere flexible Technik dazu kombiniert werden wie Schriftgröße in Prozenten (C12).

Man kann deutlich den Anforderungsanstieg von AA auf AAA für die Textvergrößerung erkennen. Auf AA kann man noch wählen zwischen:

  • man unterstützt nur den bestehenden Page Zoom (G142)
  • man macht sowohl Schriftgröße als auch sie umgebende Layoutcontainer flexibel (Hier findet man auch schon die Option für Liquides Layout – G146)
  • man kann einen Text-Switcher einbauen, der unterschiedliche Vergrößerungen zulässt (G178)
  • G179 scheint sehr ähnlich G146.

Man hat also auf AA noch die Wahl, kann jedoch ebenso schon auf ein liquides, flexibles Layout setzen.

Auf Level AAA hat man dann im Grunde nur noch die Option des liquiden Layouts (G146) oder man hat einzelne Bereiche oder Seiten, die horizontal scrollen müssen wie etwa Diagramme (C26). Diese Einzelseiten versieht man dann mit einem Layout-Switcher, um zwischen dem liquiden Standardlayout und dem Layout, das horizontal scrollt, zu wechseln.

Die Fehlerbeispiele aus Level AA F69 würden dann auch besser für AAA passen, wenn es darum geht, sowohl Text als ihn umgebendes Layout flexibel zu halten.

Geht es um die Flexibilität der Textvergrößerung findet sich diese als eine von mehreren Optionen auf Level AA, auf AAA ist sie unumgänglich, will man ein komplexeres Layout als den Beispiel-Zweispalter wirklich lesbar halten auf 200% Vergrößerung. Der Page Zoom ist da dann auch nur noch sehr bedingt eine nutzbare Option, wenn der jeweils fokussierte Lesebereich pro Zeile ohne horizontales Scrollen klappen soll.

Screenshot Auswahl Page Zoom in den Einstellungen von Opera
Auswahl Page Zoom Opera mit Option „an Breite anpassen“

Insofern wird auf Level AA letztlich nur der Page Zoom gefordert, aber es überlässt dem Entwickler oder dem Entscheider, welche ausreichende Technik gewählt wird. Das lässt sich ja an den Überscheidungen der Techniken ablesen, auch wenn für AAA der Page Zoom dann nicht mehr reichen wird.

Detlev Fischer vom BITV-Test hat diese Debatte um die reine Textvergrößerung an die WAI weitergetragen und einen Konflikt gemeldet (Comment LC-2513). Vor einigen Tagen kam von der WAI die Antwort, dass das Fehlerbeispiel F69 nicht nur auf die reine Textvergrößerung bezogen sei sondern auch auf den Page Zoom. Der Fehler beziehe sich auf beides. Sie werden daher ein weiteres Beispiel für einen Fehler mit Page Zoom zur Verfügung stellen. Aber: Für die Erfüllung des Erfolgskriterium sei der Page Zoom ausreichend.

Wir befinden uns bereits auf Level AA in flexiblen Zeiten

Ich denke, es ist nicht wirklich sinnvoll, die reine Textvergrößerung vom Page Zoom zu separieren. Beides kann, wie man in Hellbusch / Probiesch Barrierefreiheit verstehen und umsetzen in Beispielen nachlesen kann, durchaus auch kombiniert werden. Spätestens dann wird es für beide Zoom-Techniken eng bei zu wenig Flexibilität.

Und mit unseren aktuellen Layout- und Contenttechniken wie Mobile First oder Responsive Web Design und CSS Flexible Box Layout Module findet ohnehin eine Renaissance des Flexiblen statt. Sich dabei noch mit dem Desktop-Modell aufzuhalten, ein fixes Layout mit x-fachen Media Queries für x-Auflösungen zu stützen, dass der Page Zoom dann irgendwie schon noch überall passt und man dann irgendwie Level AA erreicht hat, das kann es letztlich nicht sein, das ist weder aktuell robust noch nach vorne stabil.

Screenshot Auswahl reine Textvergrößerung in Camino
Auswahl reine Textvergrößerung Camino

Mag auch die reine Textvergrößerung nicht mehr wirklich im barrierefreien Debatten-Fokus bleiben, kann sie einfach mal so nebenbei schlicht in die Flexibilität mitgenommen werden. Sicherlich gibt es in der Kombination unterschiedlicher Browser, Media Queries und der reinen Textvergrößerung ein paar Aha-Erlebnisse, aber mehr als ein kurze Lernphase ist nicht nötig, um diese Zoom-Option flexibel zu gestalten und zu integrieren.

Klar – für den BITV-Test stellt sich tatsächlich die Frage, ob der Prüfschritt 1.4.4.a Schriftgröße variabel wirklich in dieser Form beibehalten werden kann bzw. wie die Prüfung auf Level AA und Priorität da aussehen kann.

Screenshot Auswahl reine Textvergrößerung in OmniWeb
Auswahl reine Textvergrößerung OmniWeb

Und letztlich ist die Debatte Page Zoom versus einfache Textvergrößerung eine irreführende. Es geht darum, wie flexibel lege ich Inhalt und Layout für aktuelle und zukünftige Ausgaben an. Der Page Zoom unterstützt fix und flexibel, die reine Textvergrößerung auch. Die Frage ist dabei nur, wie gut les- und nutzbar ist das Ergebnis.

Skurriles Update zum Schluss: Page Zoom reicht auch auf AAA?

Heute liest man eine erneute Antwort in der WAI Liste zum Thema Erfolgskriterium 1.4.4 von Gregg Vanderheiden, der wohl aus WAI-Sicht argumentiert: Es würde vom Layout der Seite abhängen, ob der Page Zoom nicht auch für AAA – also Erfolgskriterium 1.4.8 – hinreichen kann, wenn der Hauptbereich jeweils lesbar bleibt ohne horizontales Scrollen.

25 Antworten auf “WCAG 2 und die reine Textvergrößerung”

  1. 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.

    1. 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.

  2. 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. 🙁

    1. 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.

        1. 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.

  3. […] barrierefreien Entwickler lernen wir unter »WCAG 2 und die reine Textvergrößerung« kennen. Aber mal im Ernst: ein trockenes Thema. Wer wissen will, wie Barrierefreiheit tickt, […]

  4. 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… 😉

    1. 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.

      1. 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.

    2. 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. 🙂

    3. 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.

  5. 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.

    1. 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.

  6. 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.

    1. 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.

  7. 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.

    1. 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.

  8. 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.

    1. 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.

  9. 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.

    1. 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.

      1. 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.

  10. […] Maßeinheiten sollten für ein flüssiges Layout eingesetzt werden, denn erst dann kann der Nutzer einen zusätzlichen Nutzen daraus ziehen, indem bei Textvergrößerung auf das horizontale Scrollen verzichtet wird. Mit einem […]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert