Artikel

zeldman.com: Redesign mit barrierefreien Abstrichen

Last modified: Oktober 12, 2014

Jeffrey Zeldman hat seine Seite einem Redesign unterzogen, das in seiner Schlichtheit geteilte Aufnahme gefunden hat. Aber hier geht es nicht darum, ob uns das Design gefällt, sondern um die Barrierefreiheit der Seite.

Zeldman als Webstandards-Guru setzt auf Webstandards und man möge meinen, die Seite würde dann auch barrierefrei sein. Das ist jedoch ein durchaus gängiges Missverständnis. Natürlich tragen Webstandards dazu bei, eine Seite barrierefrei zu machen, aber es reicht nicht. Sehen wir uns doch die barrierefreien Knackpunkte der Webseite an:

Update: Punkt eins Skalierbarkeit hat inTwitter gleich Kommentarstürme ausgelöst. :) Ich werfe Zeldman nicht vor, dass er seine gesamte Seite in einem fixen Layout realisiert. Die Frage dabei ist doch, ist das die Zukunft trotz oder weil des allumfassenden Browser-Zooms? Ich sehe diesen Relaunch, der ja nicht für den barrierefreien Bereich steht, durchaus auch als Signal.Zeldman selbst beschreibt den Relaunch ja als retro: It’s so retro it’s nowtro. Because old is the new new. Die Frage darf man stellen, ist dieses Retro-Vorgehen, wieder auf ein fixes Layout zurückzugehen, tatsächlich das Neue. Wird es für die Barrierefreiheit hinreichen, wird der Browser-Zoom Standard und auch richtig und hinreichend genutzt werden.

Fixes Layout

Ja, wir leben nun in Browser-Zeiten, in denen Browser alles und jedes vergrößern mit Hilfe der eingebauten Zoom-Funktion. Deswegen erwartet man ja gerade wieder fixe, statische Layouts. Zeldmans Seite ist ein fixes Pixel-Layout und nicht mal der Text ist skalierbar, bis auf die Überschriften des rechten Seitenbereichs, die mit Hilfe von SMALL skalierbar werden.

Ist es nicht schon seit Jahren Standard, wenigstens den Text skalierbar zu machen? Abgesehen davon, dass bei einem derart einfachem Layout es nicht sonderlich viel Aufwand gewesen wäre, die beiden Spalten skalierbar zu machen. Irgendwie sehr überraschend, ich halte das schon für einen Rückschritt.

Update: Das scheint auf Unverständnis zu stossen. Wir habe noch Defacto-Standards (BITV). Das fordert noch, dass die Schrift ohne browserinterne Zoom-Funktion skalierbar ist. Freilich setzt das WCAG 2 bereits auf die Zoom-Funktion der neueren Browser. Da diese Funktion aber noch neu ist, wir nicht wissen, ob das die Zukunft sein wird und es noch zu wenig reale Daten gibt, ob für die Barrierefreiheit diese Funktion hinreichend ist, schlage ich immer noch die minimale Vergrösserbarkeit mit Hilfe von relativen Werten vor.

Überschriften

Zeldman.com - Hierarchie der Überschriften

Abbildung 1:Screenshot Überschriftenhierarchie zeldman.com

Die Überschriften-Hierarchie ist soweit ganz konsistent, das Datum der Artikel jeweils mit einer eigenen Überschrift zu versehen, halte ich für überstrukturiert. Ohne wäre das viel klarer und kompakter. Merkwürdigerweise sind auch nicht die Überschriften des Artikel verlinkt, sondern das Datum. Da das Datum aber eine Hierarchieebene unterhalb der eigentlichen Artikelüberschrift sitzt, erhält man einen falschen Eindruck von der Abfolge. Ich spreche jetzt noch gar nicht von einem Screenreader-Nutzer, der sich in der Orientierung auf eine Überschriften-Hierarchie stützt. Das Datum ist auch der einzige Weg, um zum ganzen Artikel zu gelangen, ein Mehr-Link wird bis dato nicht genutzt.

Was völlig fehlt, ist eine strukturelle Navigation oder Skip-Links. Die Überschriften-Hierarchie erstreckt sich nur auf den tatsächlichen Inhalt, es gibt keine versteckten Überschriften, die wichtige Bereiche der Webseite kennzeichnen wie den üppigen Footer-Bereich oder die Seitenleiste. Ein Skip-Link in den inhaltlich eigenständigen Footer-Bereich wäre durchaus sinnvoll. Und auch ein Link wieder nach oben wäre bei diesen langen Kommentarseiten durchaus von Vorteil. Mehr Skip-Links sind wohl nicht notwendig, weil die Seite auch auf eine Hauptnavigation verzichtet. Wie üblich in Blogsystemen, stapeln sich im Seitenbereich dann unterschiedliche Pseudo-Navigationsbereiche.

Tastaturnavigation

zeldman.com kein Tastaturfokus

Abbildung 2:Screenshot Tastaturnavigation zeldman.com

Wie Sie sehen anhand des Screenshots, sehen Sie nichts. Für Links wird a:focus nicht definiert, daher ist kein Fokus sichtbar. Besonders bei den langen Kommentarseiten, macht das keinen Spaß. Man weiß nie, wo man gerade ist. Und noch vor ein paar Tagen dachte ich mir, so was macht keiner mehr: Es wird sogar für den Fokuszustand explizit verhindert, dass der Default-Fokus greift mit outline: 0;. Immerhin wurde marginal der aktive Linkzustand per CSS markiert.

Der YouTube-Player im Artikel weiter unten wird per Tastatur nicht erreicht. Gut, über dem Player ist noch ein alternativer Link zum Video. Der Styleswitcher am Ende der Seite, der zwischen den Layoutoptionen orange und weiß wechseln lässt, ist dann leider für Tastaturnutzer ein Blocker. Der Wechsel wurde auch für onkeypress angelegt, leider wird nun erwartet, dass man mit der Tastatur einen Wechsel vornimmt. Man kann zwar jetzt das Layout wechseln, aber man kommt mit der Tastatur nicht mehr weiter.

Farben

Die orange Farbgebung hat ja eher Diskussionen ausgelöst, darum geht es uns hier nur bedingt. Wichtige Stati auf einer Webseite sollen nicht nur durch Farbe erkennbar sein. Leider wurde darauf auch nicht wirklich Wert gelegt. Der aktuell angewählte Punkt ist im Auftritt nicht gekennzeichnet. Klickt man etwa auf About, wird der aktive Punkt im Seitenbereich nicht gekennzeichnet. Ich weiß, dass das in Blogsystemen etwas schwierig ist zu realisieren, weil oftmals keine aktiven Zustände durch Klassen gekennzeichnet werden. Aber es lässt sich realisieren. Man hätte dann wenigstens den besuchten Link markieren können per CSS.

Gut, nicht alle Kontraste validieren, aber im Gegensatz zur Vorversion ist da ein ziemlicher Sprung nach vorne gemacht worden.

Fazit

Von einem Webstandards-Guru wie Zeldman erwarte ich schon, dass im Ansatz auf Barrierefreiheit geachtet wird. Nicht mal Schrift skalierbar zu machen – obwohl wir alle das seit Jahren praktizieren – und für Tastaturnutzer den Default-Fokus extra zu deaktivieren, halte ich dann doch für eine merkwürdige Strategie. Meine Vermutung ist, dass Designansprüche wieder die Ursache sind. Und wenn man zusätzlich bedenkt, wie einfach und verschlankt der ganze Auftritt nun daher kommt, hätte man im Grunde solche Punkte auch noch in den Relaunch mit integrieren können.

24 Gedanken zu “zeldman.com: Redesign mit barrierefreien Abstrichen

  1. Das outline: 0 kann ich, glaube ich, leicht erklären — er hat den Kommentar in Meyer’s reset.css überlesen oder vergessen ;-) (Was beides schon schwach ist, ja.)

    Spricht eigentlich aus Deiner Sicht etwas dagegen, :hover und :focus gleichzusetzen? Sehr viel laienhafter als Du in dem Bereich würde ich annehmen, man braucht entweder das eine oder das andere — oder?

  2. Ich kann nicht erkennen, welche Designansprüche es nötig machen könnten, Schrift in px anstatt in em auszuzeichnen. Wenn man gelernt hat, damit umzugehen, macht es nicht mal nennenswert mehr Mühe. Daher interpretiere ich die konsequente Auszeichnung in px eher als programmatisch-normativen Blick nach vorne: Da die modernen Browser auch mit px umgehen können, möchte Zeldman vielleicht die em-Krücken demonstrativ abwerfen. So gesehen – warum eigentlich nicht? Der Firefox skaliert den Text jedenfalls wunderbar (Nur-Text-Zoom-Stellung).

    Für manche anderen der genannten Punkte habe ich allerdings deutlich weniger Verständnis.

  3. @Matthias Mees

    ah – ach deswegen stand über dem outline noch der Kommentar, dass man doch auf den Fokus achten sollten. ;) Sehr schön.

    Nein, man braucht beides. Der Tastaturnutzer braucht den Fokus, der herkömmliche Nutzer den Hover. Je nach Zugang. Auch auf den aktiven Zustand sollte man nicht vergessen.

    Also immer alle Zustände definieren. Vom Aussehen her ist sicherlich der Fokuszustand deutlicher zu designen. Gemeinhin wird ja der Hover-Zustand eher dezent eingesetzt. Interessanterweise in barrierefreien Projekten wird da gerne noch mal zugelegt, da sieht dieser Zustand auch auffälliger aus.

    Der Fokus sollte wirklich gut erkennbar sein, eine Variante, die ich oft einsetze, einfach den normalen Linkzustand zu invertieren, also Vorder- und Hintergrundfarbe auszutauschen.

  4. @UschaSu

    Mit Designansprüchen meinte ich eher das herkömmliche Vorurteil, dass nur pixelgenaues Layout (fixes Layout) auch wirklich so sitzt, wie es die Designervorgabe wünscht. Sie haben vollkommen recht, dass das alles auch mit em kein Problem darstellt.

    Andererseits war mein Einwand, dass bei einem derart einfachen Layout man wirklich mit em arbeiten kann. Das geht da wirklich schnell.

    Sieht man sich das Vorgängerlayout an, findet man eine noch buntere Mischung zwischen fixem Layout und Schrift mal in Pixel, in em und in Prozenten. Da scheint Zeldman schon immer ein wenig bunt umgegangen zu sein.

    Wie ich in den nachträglichen Erläuterungen ausgeführt habe, kann ich es durchaus verstehen, wenn man durch die neue Browser-Zoom-Funktion wieder auf fixes Layout umsteigt. Die Frage für die Barrierefreiheit – und die darf und muss man stellen – reicht uns das für die Zukunft. Wir müssen auf konkrete Ergebnisse von Nutzern warten, ob ihnen dieses fixe Layout ausreicht.

  5. Hi Sylvia,

    Du hast vollkommen Recht mit Deinen Hinweisen auf fehlende Skalierbarkeit, ich finde trotz “Retro” sollte das mittlerweile echt zum Standard gehören. Da gibt es für mich auch keine Entschuldigung, es ist einfach (für mich) die absolute Grundvoraussetzung, um überhaupt von Barrierearm (frei) und Webstandards sprechen zu können.

    Schrift in px auszuzeichnen ist einfach, hmmh, – unprofessionell und laienhaft.

    Das allerschlimmste für mich jedoch ist die Tatsache, dass er es besser weiß.

    Gruß, Andreas

  6. @Adreas Hecht,

    Naja, jahrelang haben wir ja nur in Pixel gearbeitet – da war das Standard. Mittlerweile – so dachte ich jedenfalls, aber da habe ich mich wohl geirrt – ist es das Arbeiten mit em Standard.

    Wie gesagt, ich werde da noch einen eigenen Artikel zu machen, bis dato ist nicht klar, ob wir auf Pixel wieder zurückwechseln können oder sollen. Das wird die Zukunft und die Nutzer zeigen.

    Ja – ich denke, Zeldman weiss das alles, aber sein Anspruch ist wohl auch nicht Barrierefreiheit.

  7. Also, mein Anspruch ist auch nicht Barrierefreiheit, weil ich leider (noch) viel zu wenig Ahnung vom Thema habe.

    Mein Anspruch ist gute Usability und da gehört ein optimales Zoomverhalten für mich einfach dazu. Besonders, seit ich diesen Artikel gelesen habe: http://www.rorkvell.de/news/2009/Webdesign_th9-tw__.html.de.

    Und so lange wie ich meine Layout zoomen kann wie ich will, leiste ich meinen Beitrag für gute Benutzbarkeit und auch für Zugänglichkeit.

  8. @Andreas Hecht

    Genau, warum wird das jetzt nur für den barrierefreien Aspekt diskutiert? Gilt das in gleicher Weise auch für die Usability – im Grunde auch so.

    Das ist so ne Sache mit der Barrierefreiheit, die wird immer gerne in so ein Eck geschoben, als würden sämtliche Fragen durch diesen Aspekt erst virulent.

    Ich schreibe grade an einem Arikel zu dieser Zoom -Fähigkeit.

  9. Pingback: Kurz und gut XVIII Linktipps  miradlo bloggt  

  10. Schrift in px auszuzeichnen ist einfach, hmmh, – unprofessionell und laienhaft.

    Warum? Pixel ist auch eine relative Einheit. Und warum sollte ich als Webworker mit irgendwelchen Krücken (em) einen Zoom simulieren, wenn es der Browser viel besser kann?

  11. Ausgerechnet die Seite von Zoe Mickley Gillenwater ist imho ein sehr schlechtes Beispiel, wie man es nicht machen sollte.

    Der Inhalt ist auf meinem 24″-Monitor zu breit … mehr als 150 Zeichen pro Zeile, das ist zu viel des Guten und ich muss irgendwelche “Hilfsgriffe” bemühen, sprich mein Fenster verkleinern um den Artikel einigermaßen gut lesen zu können.

    This comment was originally posted on sprungmarker » Sylvia Egger

  12. @Perun,

    ich habe ja nur den inhaltlichen Zusammenhang von Gillenwater empfohlen, weil hier doch etliche Argumente und Problemstellen aufgezeigt werden. Ob die Seite ein Vorbild ist, sei dahingestellt.

    Ja – klar, das ist das Problem des fluiden Layouts, dass es eben, wenn keine max-width integriert wird, halt immer den ganzen Viewport ausfüllt. Die Seite von Gillenwater arbeitet auch noch mit einer Mischform zwischen fluid und elastisch (die Aussenbehälter in Prozenten und wenns kleinteiliger wird entweder gar nichts oder em).

    This comment was originally posted on sprungmarker » Sylvia Egger

  13. @Perun,

    ich habe ja nur den inhaltlichen Zusammenhang von Gillenwater empfohlen, weil hier doch etliche Argumente und Problemstellen aufgezeigt werden. Ob die Seite ein Vorbild ist, sei dahingestellt.

    Ja – klar, das ist das Problem des fluiden Layouts, dass es eben, wenn keine max-width integriert wird, halt immer den ganzen Viewport ausfüllt. Die Seite von Gillenwater arbeitet auch noch mit einer Mischform zwischen fluid und elastisch (die Aussenbehälter in Prozenten und wenns kleinteiliger wird entweder gar nichts oder em).

    This comment was originally posted on sprungmarker » Sylvia Egger

  14. @Perun:

    Du zitierst nicht mich hier. :)

    Ja, Pixel ist eine relative Einheit, aber bis vor kurzem hat das den Browser nicht wirklich interessiert. Jetzt durch die ganzen Zoom-Aufsätze kommt das Relative endlich zur Geltung – gut so.

    Die Diskussion, ob man nun ganz vom elastischen Layout weggehen wird, ist ja eher akademisch, weil ich davon ausgehe, dass das eher verschwinden wird. Ich habe mich ja an anderer Stelle etwas ausführlicher nun mit den Problemen des fixen Layouts und der Barrierefreiheit beschäftigt.

  15. Hallo Sylvia,

    ich habe mit dem Zitat:

    Schrift in px auszuzeichnen ist einfach, hmmh, – unprofessionell und laienhaft.

    den Andreas zitiert bzw. an ihn die Frage gerichtet. Man kann über px vs. em diskutieren, aber die Keule der Unprofessionalität an jemanden zu richten der Pixel als Einheit einsetzt … ich weiß nicht ob uns das weiter bringt.

  16. Hallo Sylvia,

    mit dem Hinweis auf die Problematik bei Gillenwaters Seite wollte ich vielmehr darauf hinweisen, dass man bei aller Liebe zu flexiblen, fludien etc. Layouts die max. Breite des lesbaren Inhalts nicht außer Acht lassen darf.

    22″er, 24″er und noch größere Monitore werden sich immer mehr und mehr ausbreiten. Ich persönlich finde es weniger störend bei einem fixen Layout u. U. horizontal zu scrollen. Es ist immerhin komfortabler, als bei einem nicht-fixen Layout ohne max-width das Browser-Fenster zu verkleinern – und damit einen Teil der Bedienfläche zu verlieren – um den Inhalt anständig lesen zu können.

    Grüße

    This comment was originally posted on sprungmarker » Sylvia Egger

  17. Hallo Vladimir,

    war mir klar, konnte ja schlecht für den Andreas antworten.

    Ja, sehe ich genauso. Bringt uns natürlich überhaupt nicht weiter. Auch Dispute, auch Pixel muss man machen können, nicht. Schliesslich definieren Standards und Nutzerprobleme die Richtung. Und da das Voll-Zoomen halt noch neu ist, muss man sehen, welche Probleme auftreten können und welcher Layouttyp sich da am besten eignet.

  18. Hallo Vladimir,

    ah, verstehe. :) Genau, das habe ich nicht mehr angeführt, weil es für die Barrierefreiheit nur bedingt in Betracht kommt. Da ist bei entsprechend großer Vergrößerung leider das horizontale Scrollen sehr mühsam, weil fast zweidrittel der Seite verschwinden aus dem Fenster und man schlicht den Überblick verliert. Insofern ist dann ein fluides Layout besser, weil es sich eben an den Viewport immer anpasst.

    Ansonsten stimme ich Dir zu, dass ein max-width unbedingt zu bevorzugen ist.

    This comment was originally posted on sprungmarker » Sylvia Egger

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

    This comment was originally posted on sprungmarker » Sylvia Egger

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

    This comment was originally posted on sprungmarker » Sylvia Egger

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert mit dem Hinweis "(Pflicht)".

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>