sprungmarker testet

Die Barrierefreiheit heranzoomen: ein Ausblick

Als ich letzthin den Relaunch von zeldman.com ein wenig unter die barrierefreie Lupe genommen habe und dabei das fixe Pixel-Layout etwas überrascht zur Kenntnis genommen habe, gab es sofort Kritik. Sieht man sich die Diskussion in Sachen Pixel-Revival und Page Zoom in den aktuellen Browsern an, spürt man, wir bewegen uns offenbar auf wieder unsicherem Terrain.

Unsicheres Terrain wäre ja durchaus nichts ungewohntes – schon gar nicht in der barrierefreien Optimierung. Leider ist die Diskussion eher durch die übliche Abgrenzungsstrategie gekennzeichnet – was den Frontendbereich nur zu oft kennzeichnet: Ist es nicht Flash, gegen das man sich absetzt, dann sind es jetzt flexiblere Layoutformen – insbesondere elastisches Layout in em realisiert. Und wenn gar nichts mehr hilft, dann fängt man schlicht an zu mauern und gibt dem Pixel die Alleinherrschaft zurück, die er im übrigen nie verloren hat.

Da die Debatte sehr disparat und gustogesteuert verläuft, ist es schwierig, generelle Linien zu ziehen. Ganz abgesehen davon, dass ohnehin nur ein halber Blick in die Glaskugel möglich ist. Wir werden aber trotzdem versuchen, die Kleinteiligkeit der Argumentation auf eine etwas solidere Basis zu setzen mit dem Blick auf die barrierefreie Gesetzgebung, denn letztlich können wir noch so sehr unsere Favoriten ins Rennen schicken, will man nach den gesetzlichen Vorgaben eine Webseite realisieren, müssen diese zurücktreten. Und setzt man sich schließlich auch wirklich mit den Wünschen und Problemen der Nutzer auseinander, wir ein endlosen horizontales Scrollen eben doch wichtig,

Der pragmatische Zoom (Level AA)

Der pragmatische Zoom entspricht der browsereigenen Zoom-Funktion. Mittlerweile in fast allen Browsern funktionstüchtig liegen zwei Varianten vor: entweder die bis dato genutzte reine Schriftvergrößerung oder die neue Insgesamt-Vergrößerung. Dabei ist es sekundär, wie die Webseite realisiert wurde – auch fixes Pixel-Layout wird vergrößert. Spannende Experimente lassen sich machen, wenn man unterschiedliche Zoom-Stufen beider Varianten auch noch kombiniert. 😉

Sehen wir uns doch für diesen pragmatischen Ansatz die barrierefreie Gesetzgebung und den BIENE-Bewerb an. Am einfachsten kommt die BIENE daher:

14.1 Skalierbarkeit der Schriftgröße über die Browserfunktionalität
Prüfen Sie, ob mindestens Fließtext und Navigationselemente ausreichend vergrößert dargestellt werden und ob bei vergrößerter Ansicht die Lesbarkeit durch das Layout unterstützt wird.

Quelle: Prüfschritte der Kriterien zum Biene-Wettbewerb 2009

In Sachen Skalierbarkeit der Schriftgröße hat sich zu den Kriterien 2008 nichts verändert, was auch immer ausreichend meint, es bleibt eine Auslegungssache. Weder Zoom-Stufe noch eine genauere Festlegung von Problemen, die die Lesbarkeit bei Vergrößerung mit sich bringen kann, wird hier ausgeführt. Sicherlich liegen der BIENE weitere interne Kriterien vor. Interessant ist dabei auch, dass die BIENE ihre Kriterien eigentlich einem Update auf das WCAG 2 unterzogen hat. Das WCAG 2 bietet da aber durchaus schon genauere Festlegungen an:

1.4.4 Resize text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA)

Quelle: WCAG 2

Das WCAG 2 ist hier in zwei Aspekten schon viel genauer als die BIENE: Einerseits gibt sie eine exakte Zoom-Stufe an und andererseits werden Probleme der Lesbarkeit angesprochen etwa wenn durch die Vergrößerung Inhalt verloren geht oder Funktionalität. Freilich stellt sich auch die Frage, was mit dem Vergrößern um 200% genau zu verstehen ist, davon auszugehen ist jedoch bei Pixel-Layout, dass große Teile der Webseite in den horizontalen Scrollbereich verschwinden – als Beispiel kann man das etwa mit Miele testen -, egal wie die 200% dann tatsächlich ausgelotet werden. Der BITV-Test der BIK ist zwar noch in Überarbeitung, aber es wurden schon einzelne Bereiche an das WCAG 2 inhaltlich angepasst – so auch die Skalierbarkeit. Der neue BITV-Test wird dann folgende Skalierbarkeit fordern:

Zoombarkeit um 200 Prozent bei einer Fenstergröße von 1024×768 im Internet Explorer und in Firefox mit der jeweils browsereigenen Zoomfunktion.

Quelle: BIK: Teil 5: Schriftgrößen und Skalierbarkeit

Getestet wird die Zoomfunktion dann auch mit aktuellen Browsern wie Firefox 3 und ab Internet Explorer 7. Was macht man aber wirklich mit einem fast endlosen horizontalen Scrollen?

Der perfektionierte Zoom (Level AAA)

Auch der perfektionierte Zoom setzt auf der browser-eigenen Zoomfunktion auf, nimmt sich jedoch der Probleme wie etwa dem horizontale Scrollen an. Das Pixel-Layout lassen wir dann jedoch hinter uns. Dass es sich hierbei um eine Optimierung handelt, kann man schon dem WCAG 2 entnehmen, denn eine derartige Optimierung wird erst auf Level AAA gefordert.

1.4.8 Visual Presentation: For the visual presentation of blocks of text, a mechanism is available to achieve the following: (Level AAA) (…) Text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window.

Quelle: WCAG 2

Neu an der WCAG 2 ist, dass sie immer auch Techniken anbietet, wie die Kriterien erfüllt werden können. Diese Techniken sind dann unterteilt in ausreichend und beratend – ich würde das eher mit zusätzlich übersetzen. Um horizontalem Scrollen bei Vergrößerung zu entgehen, wird ein liquides Layout in Prozenten empfohlen und etwa auch die Schrift in Prozenten oder em und die Behälter der Webseite in Prozenten zu realisieren. Interessanterweise wird dadurch dem elastischen Layout eine Absage erteilt, lediglich Schrift soll noch in em anlegt werden. Es ergibt sich auch eine gewisse technische Doppelung, ein liquides Layout realisiert ja bereits die Behälter in Prozenten.

Gänzlich merkwürdig – und das ist genau, warum ich die Techniken des WCAG 2 auch kritisch sehe – ist es dann, als hinreichend ein liquides Layout plus eine Javascript-Funktion anzubieten, die etwa mit offsetwidth garantiert, dass alles richtig mitskaliert. Und wie vieles im WCAG 2 gibt es hier auch wieder die Möglichkeit, dem Nutzer einen Switcher oder Button anzubieten, der das Layout dann entsprechend modifiziert oder wechselt und so das horizontale Scrollen verhindert. Die Frage bei dieser Lösung darf man dann schon stellen, warum zwei Layouts generieren, wenn man eines optimieren kann.

Auch der BITV-Test geht hier konform mit dem WCAG 2, unterscheidet jedoch nicht in den beiden Leveln, sondern in den Zoomformen. Auf Level AAA wird nur mit der reinen Schriftvergrößerung getestet.

Entsprechend wird dann im BITV-Test geprüft, ob bei einer reinen Schriftvergrößerung von 200% (beziehungsweise „sehr groß“ im Internet Explorer) und einer Fenstergröße von 1024×768 jede Spalte einzeln in ihrer ganzen Breite in das Fenster passt und alle Inhalte ohne Überlappungen lesbar bleiben.

Quelle: BIK: Teil 5: Schriftgrößen und Skalierbarkeit

Meiner Meinung nach sitzt die BIK hier einem Missverständnis auf. Das WCAG 2 fordert zwar, dass Textblöcke ohne horizontales Scrollen auf 200% vergrößerbar sind, aber Pixel-Layout scheidet dabei definitiv aus. Bei einer fixen Größe, ohne das die Behälter mitskalieren, landet man nur bei abgeschnittenem, sich überlagerndem Inhalt. Dieses Problem hat uns ja all die Jahre begleitet, wenn wir nur die Schrift etwa mit em umgesetzt haben. Das interessante bei den Techniken des WCAG 2 hier ist ja, dass sie genau dieses Problem in den Griff bekommen wollen – auch der Behälter muss mitwachsen. Warum lässt die BIK hier einen Spielraum, der technisch bei Vergrößerung kaum anders zu lösen ist?

Wenn man sich schon so auf die reine Schriftvergrößerung fixiert, dann sollte man nur mit dem browser-internen Zoom testen. Oder man gibt zu, dass man vom Entwickler ein elastisches oder ein liquides Layout fordert. Ansonsten suggeriert das, wir würden einfach so weiter machen wie bisher und schlicht die Schrift flexibel halten. Da geht, meiner Meinung nach, das WCAG 2 eindeutig einen zukunftsfähigeren Weg, auch wenn er für den Entwickler steiniger ist. Die BIK akzeptiert ebenfalls ein alternatives Layout, dass die Nutzung ohne horizontales Scrollen möglich macht.

Ein robustes Fazit

Sieht man sich die Gesetzgebung des WCAG 2 in Stufen an, ist klar, dass der Entwickler erst wirklich auf Level AAA gefordert ist. Hier wird sich zeigen, welche optimierten Mischformen sich durchsetzen werden. Ich fürchte, es wird nicht nur ein liquides Layout sein, es ist auch eine Mischung aus liquid und elastisch denkbar. Ganz klar wird für Webseiten, die sich mit dem Level AA begnügen wollen oder müssen, das Pixel-Layout die erste Wahl sein – insofern wird es schon ein gewisses statisches Revival geben. Schwieriger wird es schon mit der BITV 2 und dem BITV-Test sein, der sich noch nicht ganz auf der Höhe des WCAG 2 befindet – gut auf die BTIV 2 warten wir ja noch.

Auch ist das Thema Alternativversion ein großes Thema in der WCAG 2, insofern ist auch zu erwarten, dass es hier ein Revival geben wird. Gut vorstellbar wäre ein Szenario, dass eine Webseite im ersten Schritt Sklarierbarkeit nur auf Level AA realisiert, aber für Level AAA eine Alternativversion nachrüstet. Das könnte durchaus eine gängige Lösung werden. Freilich sollte Barrierefreiheit nicht in dieser stufigen Form optimiert werden, schließlich geht es doch um Nutzer und deren Probleme. Aber wir entwickeln auch nach den gesetzlichen Vorgaben und dadurch ergeben sich auch so stufige Möglichkeiten und Schrägkeiten. 🙂

Aber nicht nur lohnt der Blick auf die konkreten Nutzerprobleme – wie sie etwa Zoe Mickley Gillenwater in Why browser zoom shouldn’t kill flexible layouts sehr gut zusammengefasst hat -, sondern auch auf die Robustheit von Lösungen. Nicht umsonst ist eines der WCAG 2 Prinzipien Robustheit: Wir entwickeln in die Zukunft. Ganz abgesehen von einer guten Portion Flexibilität ist vor allem Wartbarkeit und Robustheit in der Entwicklung von Webseiten wichtig. Drew McLellan hat das in The Fallacy of Page Zooming sehr gut zugespitzt: You have to build to be robust. It is the nature of the web to be robust. Insofern geht es nicht nur darum, Layoutformen gegeneinander auszuspielen, sondern vor allem darum, Layoutformen für uns alle und für eine robuste Zukunft zu entwickeln.

Oder – wie Drew McLellan so schön sagt: Users can turn (that) feature off.

13 Antworten auf “Die Barrierefreiheit heranzoomen: ein Ausblick”

  1. […] Zoomen ist nicht einfach, auch wenn man sich scheinbar, dank moderner Browser, keinen Kopf mehr darüber machen muss: Die Barrierefreiheit heranzoomen […]

  2. Hallo Sylvia,

    super Artikel – ich versuch mal eine Antwort als Mitglied des Testentwicklungsteams bei BIK.

    Erstmal vorweg um möglichen Missverständnissen vorzubeugen: der BITV-Test-Prüfschritt zur Schriftskalierung ist noch nicht überarbeitet, da sind wir derzeit gerade bei. Der Neuentwurf des Prüfschritts wird Ende Juli veröffentlicht und steht dann bis zum Inkrafttreten noch eine Weile zur öffentlichen Diskussion. Der Artikel, den du zitierst, sollte nur grob skizzieren in welche Richtung es gehen wird und war offensichtlich teilweise missverständlich. Ich versuche mal mit anderen Worten darzustellen, was wir mit dem Prüfschritt vorhaben, der sich natürlich an den WCAG 2 orientieren soll.

    Erstmal stellt sich ja die Frage: was heißt 200%? Wenn man das Zoomen in Firefox 3 testet anhand einer einfachen Box z.B. in der Ausgangsgröße 10em x 10em, dann stellt man fest, dass man sechs mal vergrößern muss, bis die Box doppelt so groß ist, also um 200% größer. In FF 2 sind die Vergrößerungsstufen anders, da muss man nur drei mal vergrößern, um auf 200% zu kommen. Bislang waren’s im BITV-Test nur zwei Vergrößerungsstufen in FF2 (= 150%). Die neuen 200% sind also auf jeden Fall eine deutlich höhere Anforderung als bisher.

    Bezogen auf die Komplett-Zoom-Funktion neuer Browser ist das trotzdem erstmal keine Verschärfung – im Gegenteil, solange das ganze Layout proportional vergrößert wird, kann sich nichts überlappen oder abgeschnitten werden. Der große Nachteil ist allerdings natürlich der Querscrollbalken.

    Will man aber mit den Nur-Text-Vergrößerungsfunktionen älterer Browser auf 200% vergrößern, wird das bei mehrspaltigen Layouts problemlos nur dann funktionieren, wenn die Breiten der Spalten/Container in em angegeben sind und diese sich dadurch letztlich genau so verhalten wie beim Komplett-Zoom in neuen Browsern. Bei fluiden Layouts mit %-basierten Breiten oder Kombinationen aus % und em mit max-/min-width etc. wird es in vielen Fällen zu Problemen mit sich überlappenden oder abgeschnittenen Inhalten kommen, oder Spalten brechen nach unten weg und das Layout wird unübersichtlich.

    Außerdem hängt es bei vielen fluiden Layouts auch stark von der Ausgangsgröße des Browserfenster ab, wie weit man problemlos skalieren kann. Man braucht also für den BITV-Test als Ausgangsbasis erstmal eine festgelegte Browserfenstergröße, sonst wären die Prüfergebnisse von den Vorlieben des Prüfers abhängig. Die WCAG 2 geben allerdings keine Ausgangsgröße an.

    Wir denken, dass es nicht ausreicht, nur mit modernen Komplett-Zoom-Funktionen zu prüfen – das hat aus Nutzersicht den eindeutigen Nachteil des Querscrollbalkens. Ich finde, die WCAG 2 machen es sich da auf Level AA ein bisschen zu einfach, Zoomen allein kann es meiner Meinung nach nicht sein. Der BITV-Test-Prüfschritt wird hoffentlich mehr testen als nur das, denn wir möchten keinen Prüfschritt entwickeln, der Pixellayouts begünstigt und Webdesigner völlig von der Verantwortung befreit, sich um eine möglichst gute Skalierbarkeit zu kümmern.

    Zwar gefällt das Komplett-Zoomen offenbar vielen Nutzern, es gibt aber auch viele, die die Schrift vergrößern möchten, ohne dabei mit kilometerlangen Querscrollbalken konfrontiert zu werden. Das möchten wir in dem Prüfschritt gerne berücksichtigen, er soll auf keinen Fall bloß noch formalen Charakter haben, sondern nutzerorientiert bleiben. 200% Vergrößerung ist allerdings bei Nur-Text-Vegrößerung eine arg hohe Anforderung, die fluide Layoutformen benachteiligt.

    So weit die Schwierigkeiten. Das Prüfverfahren wird voraussichtlich Folgendes beinhalten (die Feinheiten sind gerade noch in der Diskussionen – Anmerkungen sind deshalb sehr willkommen!):

    1. Im IE 7 bei 1024×768 auf 200% zoomen
    2. Im IE 7 bei 1024×768 nur die Schrift auf „sehr groß“ stellen
    3. In Firefox 3 bei 1024×768 auf 200% zoomen (= 6 x vergrößern)
    4. In Firefox 3 bei 1024×768 nur die Schrift auf 200% vergrößern (= 6 x vergrößern)

    Die Punkte 1. und 3. werden fast immer erfüllt sein, das ist ja vor allem Browsersache und man müsste als Webentwickler schon mutwillig dagegen arbeiten, um die Anforderungen an Komplett-Zoombarkeit nicht zu erfüllen. Punkt 2. ist sogar noch etwas lockerer als die aktuelle Anforderung im BITV-Test (aktuell muss man im IE bei 800×600 auf „sehr groß“ vergrößern).

    Punkt 4. ist allerdings nicht so einfach. Es bevorzugt tendenziell em-basierte Zoomlayouts gegenüber fluiden Layoutformen, es ist außerdem eine viel strengere Anforderung als bisher. Wir überlegen deshalb noch, wie wir da am besten eine gewisse Abmilderung einbauen.

    Eine Möglichkeit wäre, für die reine Schriftvergrößerung nicht 200% zu verlangen, sondern wie bisher nur 150%. Damit gäbe es auch eine gewisse Rückwärtskompatibilität zu den bisherigen BITV-Test-Anforderungen.

    Eine andere Möglichkeit wäre, als Lösung auch ein Alternativ-Stylesheet zuzulassen, dass die 200% bei Nur-Schrift-Vergrößerung ermöglicht. Dabei dürften in der Alternativdarstellung natürlich keine Funktionalitäten oder Inhalte verloren gehen und der Mechanismus zum Einstellen des Alternativ-Stylesheets müsste selbst gut zugänglich sein (insbesondere tastaturbedienbar, oben auf der Seite platziert, verständlich formuliert/gestaltet und kontrastreich). Problematisch ist dabei, dass das in den WCAG 2 eigentlich erst auf Level AAA vorgesehen ist, der BITV-Test aber voraussichtlich nur Level AA abdecken soll.

    Ich teile Deine Einschätzung, dass es angesichts der neuen Anforderungen leicht dazu kommen könnte, dass die meisten Websites wie auf Level AA vorgesehen im Standard-Layout nur noch für Komplett-Zoombarkeit auf 200% sorgen werden (mit px- oder em-Layouts) und die Nur-Text-Vergrößerung ohne Querscrollbalken per Alternativ-Stylesheet abwickeln – was natürlich nicht ideal ist (wie ich es überhaupt schade finde, dass die WCAG 2 relativ stark auf Alternativversionen setzen). Aber wenn die BITV 2 hier den WCAG 2 folgt, können wir mit dem BITV-Test leider nichts daran ändern – der kann natürlich keinen anderen Weg einschlagen als die BITV 2.

    Tja, das ist grob der aktuelle Diskussionsstand. Wie gesagt, in einigen Wochen wird der neue Prüfschrittentwurf offiziell veröffentlicht und steht dann vor dem Inkrafttreten wie immer zur Diskussion. Würde mich aber schon jetzt über Meinungen freuen!

    Viele Grüße,
    Tiffany

  3. Hallo Tiffany,

    Deine Antwort ist ja sozusagen ein eigener Beitrag. 🙂 Danke. Ich werde Deine Antwort mit meinen Positionen abgleichen und das in einem Folgeartikel durchgehen. Dank Dir vor allem für die Offenheit. Vor allem und gerade gesetzliche Vorgaben und das WCAG2 muss man so offen technisch diskutieren.

  4. Hallo Tiffany,

    Jetzt nach dem ersten Durchgang habe ich doch noch ein paar Fragen, bevor ich die dann im Folgeartikel falsch einbinde.

    Du bemerkst, dass der BITV-Test nur Level AA der WCAG2 abdecken soll, verstehe ich das richtig? Huch. 🙂
    Oder meinst Du jetzt das nur im Hinblick auf die Schriftskalierung?

    Die bisherige Orientierung auf 800 x 600 entsprach ja der bis vor kurzem gängigen, ich denke nicht, dass Du meinst, man hätte es jetzt durch die 1024 leichter oder? Schliesslich ist das dann die gleiche Ausgangsbasis für den aktuellen Standard. Und „sehr groß“ war ja auch in beiden Auflösungen die Anforderung?

    Auch die reine Textvergrößerung ist ja – ich hab das jetzt nur schnell übereinander gelegt – im IE6 und IE8 gleich gross oder? Warum sind das jetzt lockere Anforderungen als beim BTIV-Test bis dato?

    Danke, 🙂

    Sylvia

  5. Hallo Sylvia,

    sorry, dass ich urlaubsbedingt erst jetzt antworte!

    Zu Deinen Fragen:

    Die BITV-Test-Überarbeitung, die jetzt im Herbst kommt, betrifft erstmal nur ausgewählte WCAG-2-Anforderungen auf Level A und AA – und zwar nur solche, die mit der aktuell geltenden BITV 1 vereinbar sind. Ein Beispiel ist die Skalierbarkeit, die in der BITV 1 ja nur allgemein gefordert wird, ohne einen bestimmten Grad der Vergrößerung zu nennen. Es widerspricht der BITV 1 also nicht, an dieser Stelle schon jetzt – vor Inkrafttreten der BITV 2 – die viel konkreteren WCAG-2-Anforderungen zu übernehmen.

    Welche Level dann später nach Inkrafttreten der BITV 2 im BITV-Test abgedeckt werden, hängt natürlich in erster Linie von der BITV 2 selbst ab und was sie genau verlangt. Dazu kann ich deshalb im Moment noch nichts Abschließendes sagen. Unser Wunsch im Testentwicklungsteam ist es auf alle Fälle, für so viel Kontinuität wie möglich zu sorgen und den Test insgesamt nicht stark zu verschärfen. Denkbar wäre aus meiner persönlichen Sicht z.B., dass die bisherigen 100 Punkte Level AA abdecken und für Level AAA Zusatzpunkte geholt werden können. Das würde auch dazu passen, dass die WAI ja selbst nicht empfiehlt, Level AAA als allgemeingültigen Maßstab für komplette Websites heranzuziehen („It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content“, siehe http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#cc1). Aber wie gesagt, das ist im Moment alles noch offen und hängt von der BITV 2 ab.

    Dann zur Frage 800×600 bzw. 1024×768 – was ich da meinte, war: ein fluides Layout, bei dem die Spaltenbreiten in % angegeben sind und somit von der Breite des Browserfensters abhängen, hat es bei 1024×768 natürlich leichter, die Anforderung „sehr groß“ im IE bzw. 150% in FF zu erfüllen als bei 800×600 – einfach weil mehr Platz da ist und die Spalten breiter laufen können. Diese klitzekleine Vereinfachung betrifft aber eben nur solche fluiden Layouts mit Spalten, deren Breite in % angegeben ist. Für em-Layouts oder in px angegebenen Breiten spielt die Größe des Fensters natürlich keine Rolle.

    Und stimmt, „sehr groß“ ist im IE 6 genau so groß wie im IE 8 – daran ändert sich nichts. Die leichte Lockerung liegt wirklich nur im größeren Browserfenster.

    Falls das jetzt trotzdem noch unverständlich ist, hier auf die Schnelle ein konkretes Beispiel: wenn ich die Startseite von http://www.einfach-fuer-alle.de in FF in einem Fenster von 800×600 mit dem Nur-Text-Zoom auf 150% vergrößere, werden relativ viele Inhalte der linken Spalte abgeschnitten. Bei einem Fenster von 1024×768 und 150% passt es auch noch nicht ganz, aber viel viel besser – einfach weil die Spalte jetzt halt breiter ist.

    Viele Grüße,
    Tiffany

  6. Hallo Tiffany,

    ich bin ja auch säumig, wollte Deine ausführliche Antwort ja längst in einen eigenen Artikel kommentiert haben. ☺ Ah, ich dachte die BITV-Test-Überarbeitung käme Ende Juli, verstehe, das betraf dann eher den Relaunch der BIK-Seite.

    Ein interessantes Update-Vorgehen, dass ihr da gewählt habt. ☺ Aber, wenn ich das anmerken darf, es hört und fühlt sich schon etwas bruchstückhaft an. Man kann nur hoffen, das die BITV2 sich doch stark an das WCAG 2 annähert, sonst haben wir ja wirklich zu viele offene Stränge. Ich hoffe ja nun doch, das BITV2 wenigstens alle Level abdeckt, schliesslich muss sie sich schon an das AAA-Stufenschema halten oder? Da wieder eine eigene Gewichtung vorzunehmen, halte ich dann schon für arg verwirrend. Obwohl ja auch die BITV bis dato die Gewichtungen anders gebündelt hat, ja.

    Klar sollte eine gewisse Kontinuität im Testverfahren herrschen, aber wenn sich die Gesetzeslage eben wie die technische Entwicklung ändert und verschärft, müsste man auch mal die Kontinuitäten verlassen oder? Ich finde schon, wenn ich mir die technischen Dokumente des WCAG2 aktuell ansehe, dass da doch ein ganz anderer Rahmen an möglichen Lösungen angeboten wird. Das ist zum einen besser, weil man eben mehr Optionen hat, aber auch zum anderen für so ein Testverfahren arg überbordend bzw. man müsste sich dann quasi auf gewisse Optionen fokussieren.

    Du sprichst da eine interessante Frage- bzw. Problemstelle des WCAG 2 an, dass die quasi selbst nicht den Level AAA empfehlen, weil er eben schon viel abfordert. Aber das betrifft eben nur einige Punkte, vieles ist auf Level AAA gelandet, dass da dann im Vergleich nicht wirklich hingehört oder schlicht ohnehin selbstverständlicher sein sollte. Und die Formulierung entire site ist ja auch wieder interpretationswürdig, schliesslich testet der BITV-Test ja auch nicht ganze Auftritte oder? Ich denke, hier ist eher gemeint, dass bei ganzen Webauftritten Level AAA tatsächlich mitunter zu viel mehr Aufwand führen könnte. Das könnte dann aber nur spezielle Bereiche betreffen.

    Danke, ich habe mir auch schon ein Testbeispiel gemacht und die verschiedenen Vergrößerungsoptionen angesehen und das jetzt auch gut nachvollzogen. Die Vorgabe mit 200% im reinen Textzoom ist bei fast allen Seiten Ursache von Kaum- bis Unlesbarkeit. Und ich bin immer noch der Meinung, dass 800 x 600 ohnehin keine wirkliche Ausgangsbasis mehr ist und damit die leichte Lockerung des BITV-Tests eben eine neue Ausgangsbasis mit 1024 hat, nicht mehr und nicht weniger. Also kein wirklicher Vorteil nach vorne, wenn man schlicht nur die Basis nachregelt. ☺

  7. Hmmm, wenn ich das richtig verstanden habe dann dürfte unter den Diskutierenden hier die Meinung herumgeistern, dass WCAG 2.0 AA sich mit der Zoomfunktionalität moderner Browser begnügt.

    Das ist nicht richtig. Es wird in den Erläuterungen und in den Diskussionen bei der Erstellung der WCAG eindeutig darauf verwiesen, dass es hier nicht ausreicht, sich auf die Zoomfunktion dieser Browser zu beziehen. Eine Vergrößerung des Textes auf 200% ist damit doch ein recht ambitionierte Herausforderung und aus meiner Erfahrung auch die schwierigste Aufgabe konventionelle Websites auf AA zu bringen.

  8. @Michael

    eindeutig ist im WCAG 2 eher schwierig zu konstatieren. Und hier geistert auch nicht die Meinung herum, dass sich das WCAG 2 auf AA mit der Full-Zoom-Funktionalität begnügt. Aber – und darum ging es hier in der Diskussion – es lässt einen durchaus pragmatischen Spielraum erwarten, den das WCAG 2 durchaus auch argumentativ bereit stellt.

    Es war hier auch eher ein Gespräch, wie sich das in Zukunft entwickeln wird. Das WCAG 2 macht in Resize text: Understanding SC 1.4.4 zu allerst deutlich, dass es die Aufgabe des User Agents ist, die Zoombarkeit zur Verfügung zu stellen und der Entwickler in der Verantwortung steht, diese Funktionalität nicht zu untergraben:

    The scaling of content is primarily a user agent responsibility. User agents that satisfy UAAG 1.0 Checkpoint 4.1 allow users to configure text scale. The author’s responsibility is to create Web content that does not prevent the user agent from scaling the content effectively.

    Quelle: Resize text: Understanding SC 1.4.4

    Es wird für den IE6 und älteren Firefox-Browsern das wie üblich eingeschränkt, weil die ja nicth über eine volle Zoomfähigkeit verfügen:

    The author cannot rely on the user agent to satisfy this Success Criterion for HTML content if users do not have access to a user agent with zoom support. For example, if they work in a environment that requires them to use IE 6 or Firefox.

    Quelle: Resize text: Understanding SC 1.4.4

    Wir haben hier auch nicht dafür plädiert, dass man auf fluides oder elastisches Layout verzichtet. Es könnte nur sein, dass durch die Full-Zoom-Funktionalität der Browser, sich schlicht ein gewisser Pragmatismus in der Entwicklung breit machen wird. Die Frage ist ja auch, wie effektiv und nutzbar ist der Full-Page-Zoom letztlich. Das bleibt abzuwarten, da brauchen wir auch mehr Nutzerdaten.

    Das WCAG 2 gibt ja als Sufficient Techniques an erster Stelle dann wieder den User Agent an, dann folgen weitere Techiken wie nur den Text skalierbar machen und/oder auch die Behälter.

    Die Frage wird in Zukunft sein, wie sich Entwickler in den Techniken wirklich bewegen, greifen sie nach dem ersten Strohhalm oder erfüllen sie noch weitere Punkte. Sichern sie quasi die Skalierbarkeit noch weiterhin ab. Allein die Frage, wird es in Zukunft noch elastische Layouts geben, ist schon interessant zu diskutieren. Mehr haben Tiffany und ich hier nicht gemacht.

  9. […] sprungmarker» Die Barrierefreiheit heranzoomen: ein Ausblick | Sylvia Egger […]

Schreibe einen Kommentar

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