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.
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!
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.
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?
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.
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. ☺
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.
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.
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.
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.
Ein wenig in die barrierefreie Glaskugel geschaut: Die Barrierefreiheit heranzoomen: ein Ausblick http://url.ie/1vik
This comment was originally posted on Twitter
“Die Barrierefreiheit heranzoomen: ein Ausblick” – http://url.ie/1vik (thx @sprungmarkers)
This comment was originally posted on Twitter
RT @sprungmarkers Ein wenig in die barrierefreie Glaskugel geschaut: Die Barrierefreiheit heranzoomen: ein Ausblick http://url.ie/1vik
This comment was originally posted on Twitter
@leolezner nee, denk ich nur bedingt – elastische wird’s weniger geben, eher noch fluide http://url.ie/1wj5
This comment was originally posted on Twitter
Pingback: Bithalter Webzeuglinks 017′09 | Webzeugkoffer Webdesign
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
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.
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
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
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. ☺
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.
@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:
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:
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.