sprungmarker testet

Barrierefreiheit: Je exotischer die Anforderungen, desto besser :)

Für mich immer wieder lustig zu beobachten: Jemand – Gerrit von Aaken – ist verwirrt in Sachen barrierefreies Webdesign und notiert diese Unsicherheit: Zugänglichkeit im Webdesign – es bleibt schwierig! Das wäre ja in Summe durchaus ok, wenn nicht ähnliche argumentative Unschärfe nicht schon in Gelsenkirchen geherrscht hätte.

Damit hat man es mit einer Folgediskussion zu tun, die zwar immer noch eine Unsicherheit ausdrückt, aber – meiner Meinung nach – langsam beginnt, Linien fest machen zu wollen. Daher ist es nur richtig, dass die Kommentare – besonders aus dem barrierefreiem Fachgebiet – entsprechend häufig und harsch ausgefallen sind. Also noch einmal von vorne – die Argumente ein wenig ordnend:

Methode 1: Verbreiterung

Natürlich wir können im Namen der Barrierefreiheit jedes beliebige Fähnchen mit aufziehen, dann hat man nur das bekannte Problem der Beliebigkeit. Argumentative oder konzeptionelle Unschärfe kann den wie auch immer kreativen Prozess befördern, wenn jedoch Barrierefreiheit, sagen wir mal jetzt ganz unketzerisch im Sinne des BITVs, angestrebt werden soll, dann nutzt Verbreiterung nicht mehr viel. Dann gilt es ganz konkret umzusetzen und zu fokussieren.

Der Artikel spricht zwar immer wieder von barrierefreiem Webdesign, zieht sich aber bei der geringsten Problemstellung auf andere allgemeinere Begrifflichkeiten wie Usability oder Zugänglichkeit zurück.

Abgesehen davon, dass man Zugänglichkeit schlicht aus dem englischen Begriff Accessibility übertragen verstehen könnte – was wieder auf den Begriff der Barrierefreiheit rückführen würde, ist der Begriff Barrierefreiheit schlicht ein gesetzlich vor- und festgeschriebener Begriff, der seit Jahren (!) völlig gängig in der Arbeit mit barrierefreien Webseiten ist.

Die angebliche Diskriminierung durch Barriere im Begriff Barrierefreiheit halte ich für völlig überzogen – wie steht es dabei mit zugänglich in Zugänglichkeit – und wurde in dieser Form in Gelsenkirchen nicht wirklich zur Diskussion gestellt. Dass es sich in den meisten Fällen schlicht und ergreifend um Diskriminierung handelt, wenn ein Nutzer vor Barrieren auf Webseiten steht, das wird dann gerne ausgeblendet. Entweder weiß man darüber zu wenig oder man müsste aktiv werden. Beides ist dann wohl zu anstrengend.

Dann führt man lieber schöne, breit angelegte Scheindiskussion zu Barrieren auf iPhones, alten Laptops oder anderen Alternativen, weil man sich da auskennt und das schon erlebt hat.

Methode 2: Begriffs-Verwirrung stiften

Es mag ja sein, dass es diese Begriffe für verschiedene Behinderungen und Beeinträchtigungen auch tatsächlich gibt. Aber in einem Artikel, der zwischen iPhone und Vollblindheit wechselt, stößt mir das dann schon ein wenig auf. Da werden die Vollblinden, die nichts mehr wirklich tangiert – wahrscheinlich auch keine Webseiten 😉 – eingebaut, die Geburtsblinden, die jeden Trick raushaben sollen, angesprochen und wohl diverse andere Exoten, auf die man sich nicht mehr namentlich beziehen kann und mag.

Und unter uns barrierefreien Optimierern: Mir ist der arme iPhone-Nutzer in erster Linie mal zweitrangig, desgleichen der bedauernswerte Nutzer mit einem überdimensionalen Bildschirm, dem alle Webseiten wie Zwerge vorkommen mögen. Das sind alles Nutzergruppen, die sich nicht vergleichen lassen. Es ist schön und fein, wenn ein elastisch gebautes Layout auch die Riesen-Monitor-Nutzer zufrieden stellt, aber das ist nur ein Seiteneffekt. Sorry, wenn jemand barrierefreie Seiten optimiert, dreht man den Spieß schlicht mal um. In erster Linie wird für spezielle Nutzer mit Behinderung und Beeinträchtigungen optimiert und wenn das für andere auch Ergebnisse zeitigt, wunderbar. Meisthin wird es das ohnehin, aber es ist mir wichtig, in der Barrierefreiheit nicht immer das Deadend zu sehen, sondern schlicht eine andere Herangehensweise. Das hat nichts mit Exotik zu tun – so endet ja die meiste Diskussion in diesem Bereich -, sondern schlicht mit Tatsachen, Problemen und Lösungen, die mal besser mal schlechter helfen und funktionieren.

Methode 3: Gadgets rausgreifen

Es freut mich dann immer besonders, wenn auf die neuralgischen Punkten der barrierefreien Optimierung gezielt wird. Sobald einige Gadgets oder Hilfsmittel irgendwie in den Mainstream wandern, werden sie auch gleich wieder abgekanzelt. Das trifft derzeit am stärksten Styleswitcher, Textzoom-Hilfen und Kontrastregler. Dieser Disput wurde ja auch schon in Gelsenkirchen geführt. Vielleicht sollte man, wenn man in diesen Dingen verwirrt ist, schlicht einfach mal interpretative Gesetzestexte wie bei der BIK lesen, die durchaus ganz klare Stellungnahmen zu diesen Hilfsmitteln bieten. Auf die Frage eines Nutzers, ob man nicht auf die allgemeine Vergrößerbarkeit der Schrift verzichten könne, dafür würde man ja diesen Textzoomer sichtbar auf der Seite anbieten, fällt die Antwort ganz erwartet aus: Man kann gerne so eine zusätzliche Sache anbieten, aber grundsätzlich muss es dem Nutzer möglich sein, die Schrift zu vergrößern.

Des weiteren sind das ja ohnehin immer nur Designdiskussionen, die hier geführt werden. In den selteneren Fällen greift man wirklich auf weitere Stylesheets (z. B. bei Kontrasthilfen mitunter schon) zurück, sondern stellt das im Default-Stylesheet durchaus schon zur Verfügung und der Switcher ist dann die sichtbare Manifestation dessen. Ob das Gadget dann ins Design passt oder des Guten mitunter zuviel gemacht wird, sei dahingestellt. Das muss man im Einzelfall dann testen und abwägen.

Mir scheint aber auch symptomatisch, dass man immer über die sichtbaren Gadgets diskutiert, weit weniger aber über unsichtbaren Optimierungen, die im Grunde eine barrierefreie Seite ausmachen (semantische Struktur und Auszeichnung, Sprunglinks, semantische Hierarchie und Erreichbarkeit aller Bereiche auf der Webseite, Optimierung einer Tastaturnavigation etc. pp – das hier ist jetzt nicht völlständig :)).

Auch die plötzliche Verlagerung der barrierefreien Optimierung auf das Default-Stylesheet scheint mir eine überzogene Wendung. Wenn man ein Stylesheet so aufgeräumt und sinnvoll strukturiert, dass etwa Farben in einem Block definiert werden, kann man mit geringem Aufwand diese Farben auch für andere Nutzer und Farben/ Kontraste optimieren. Diese minimalen Blöcke blähen ein Stylesheet wahrlich dann nicht auf. Schriftgrößen im Default-Stylesheet mit EM-Werten zu gestalten, halte ich ohnehin für Standard – wo ist hier der unmäßige Aufwand?

Methode 4: Wir leben in einer Überforderung

Das hörte man ja auch schon in Gelsenkirchen immer wieder: was kann man heute bloß machen, alles ist so kompliziert. Ach je! Anstatt einfach mal tatsächlich sein Halbwissen und Unsicherheit abzulegen, indem man sich intensiver mit dem Thema Barrierefreiheit befasst, spricht man lieber davon, wie verwirrend doch alles ist. Und – das ist dann der Clou und Kniff an dieser Argumentation – deswegen machen wir einfach alles so einfach wie möglich. Der Geburtsblinde wird sich schon zu helfen wissen, der ist ja Experte. Der betroffene Nutzer wird sich schon melden, wenn er mal wieder vor einer Barriere steht (hoffentlich funktioniert dann das Kontaktformular!). Und vom lernbehinderten Nutzer weiß man eh schon rein gar nichts. 😉 Das ist genau die Technik, wie man gar nicht weiter kommt.

Anstatt sich einfach mal eine Zielgruppe genauer vorzunehmen. Dann die nächste! Und – meine Güte – so sehr unterscheiden sich die grundsätzlichen Optimierungen nicht. Natürlich gibt es immer Spezialfälle, aber gibt es die nicht sonst auch (IE 6;)).

Fazit: So kann es nicht weiter gehen!

Im Grunde fehlt eine wirklich ehrliche Nachbesprechung in diesem Bereich, auch in der Nachschau auf Gelsenkirchen. Wenn wir da weiter machen, wo dieser Artikel uns entlässt – Ich bastele auf meine Weise weiter am zugänglichen Web (Quelle: Zugänglichkeit im Webdesign – es bleibt schwierig!) – dann können wir langsam damit aufhören. Denn dieser Artikel suggeriert – obwohl er im Grund nur die Verwirrung und Unsicherheit des Autors spiegelt -, dass es ein heilloses Unterfangen und Procedere ist, barrierefreies Webdesign durchzusetzen.

Das ist jedoch – und da möge man mir meine rüden Worte verzeihen – blühender Unsinn! Gerade barrierefreies Webdesign ist mittlerweile ein gestandener und verstandener Prozess. Und es ist unsinnig, hinter all die Erkenntnisse und Ergebnisse ständig wieder zurückgehen zu wollen, weil man etwa Styleswitcher nicht genug passend findet. 😉 Haben wir nicht wichtigeres vor?

Hinweis

Es ist wunderbar, viele Kommentare zu erhalten. 🙂 Aufgrund der Dichte in den Argumenten, werde ich sie nach und nach beantworten.

31 Antworten auf “Barrierefreiheit: Je exotischer die Anforderungen, desto besser :)”

  1. Hallo Sylvia,

    BF-Zoff in Bloggersdorf – und Du hast eine sehr schöne Zusammenfassung dazu erarbeitet. Ja, es bleibt schwierig – nur ganz anders, als der erwähnte Text uns erzählen will.

  2. Vielen Dank. Der Artikel trifft sehr gut die Probleme. Manchmal denke ich mir, dass es schade ist wie sich Webdesigner ihre Arbeit komplizierter reden als sie eigenenich ist. Weder WCAG1 noch 2 sind so umfangreich,dass man nicht einen guten Einstieg ins Thema bekommen könnte.

    Übrigens konnte ich diesen Kommentar problemlos mit meinen iPod Touch schreiben. Ohne Anpassung. Hilfreich ist es eigentlich nur eine logische Tab-Reihenfolge, weil man dann schön von einem Feld zum anderen springen kann.

  3. Du bringst es wirklich wunderbar auf den Punkt.

    Am meisten hilft mir den Dialog mit den betroffenen Usern zu suchen. Welche erleuchtenden Erkentnisse da hervorgehen ist unbezahlbar.

    Den Begriff Barrierefreie Webseiten möchte ich auf keinen Fall als altmodisch sehen, denn da gehts ja erst langsam los. Das die dementsprechenden Optimierungen in den Alltag eines jeden Webdesigner fliessen, bleibt zu hoffen.

  4. Das macht mich ja glücklich, dass ich mit meinem putzigen Artikel zur allgemeinen Erheiterung unter den Barrierefreiheits-Profis beitragen konnte! Ich habe dennoch ein wenig das Gefühl, dass jeder seine eigene Sichtweise auf den Text anwendet, und das herausliest, was er/sie herauslesen möchte. Sei’s drum.

    Mir ging es im Wesentlichen um die Problematik der _visuellen_ Barrierefreiheit. Aus der Quellcode-Sicht gibt es meines Erachtens nämlich kaum Probleme, hier lassen sich relativ klare Regeln aufstellen, die man befolgen kann.

    Doch da ich als Designer eben auch den visuellen Teil einer Website zu verantworten habe, stoße ich auf Unklarheiten. Vielleicht ist das alles nur Ignoranz! Deshalb hier ein kleines Quiz, was ich mir heute morgen im Auto ausgedacht habe. Stellt Euch vor, Ihr seid Webdesigner und müsst für eine Gemeinde eine barrierefreie Website umsetzen.

    1) Die Gemeinde hat als Logofarbe in allen Broschüren und Briefbögen ein mittelhelles Blau, welches Ihr natürlich auch im Pixel-Entwurf als RGB-Wert verwendet. Der Kontrast-Checker sagt aber, dass dieses Blau einen zu geringen Kontrast mit Weiß, und auch mit Schwarz hat. Was tun?

    a) Eigenmächtig das Corporate Design und das Logo ändern und das Blau deutlich dunkler machen.
    b) Das Blau so lassen und ein alternatives Hochkontrast-Stylesheet ins Auge fassen, das per JavaScript-Styleswitcher eingebunden wird.
    c) Das Blau so lassen und darauf vertrauen, dass sehbehinderte User sowieso systemweit mit Hochkontrast unterwegs sind.

    2) Die Fließtext-Schrift ist im Default-Zustand auf 12 Pixel, Arial angelegt. Bei den ersten Usertests beschweren sich einige ältere Mitbürger, die sich vor kurzem einen neuen Laptop mit 140ppi-Bildschirm gekauft haben, dass die Schrift so winzig sei. Wie reagiert man korrekt?

    a) Man ändert die Schriftgröße generell auf 16 Pixel (=100%) und stört sich nicht weiter an der Klobigkeit, die das gesamte Design nun besitzt.
    b) Man baut zusätzlich zum Hochkontrast-Styleswitcher noch einen Textzoom-Button ein, den man schön auffällig ganz oben link platziert.
    c) Man verfasst einen freundlichen Hilfetext auf der Website, in dem man erläutert, wie man mit jedem modernen Browser die Schriftgröße skalieren kann.

    3) Das Seitenlayout ist so aufgebaut, dass es auch unter 800×600 Pixeln im Viewport noch ohne zu scrollen benutzbar ist. Viele Bürger beschweren sich jetzt aber, dass das Layout auf ihren Bildschirmen so seltsam langgezogen ist und die Zeilen zu lang zum Lesen sind. Es stellt sich heraus: 50 Prozent der Bürger surfen mit 1280Pixel Breite oder höher.

    a) Ich mache ein fixes Layout auf 1024er Breite und nehme bei 2% der User einen Scrollbalken in Kauf
    b) Ich begrenze die Breite per max-width auf 1024 Pixel und nehme bei vielen Usern „verschenkten Platz“ in Kauf
    c) Ich verweise per Hilfetext auf den Textzoom oder mache das gleich per JavaScript: Viewport ausmessen = Ausgangsschriftgrad anpassen.

    Also, was meint Ihr? Ist das sehr praxisfern? Wie würdet Ihr handeln? Keine Ausreden („Kommt drauf an!“), sondern klare Antworten! Ich bekomme viel zu wenig handfeste Handlungsanweisungen über die visuellen Aspekte der Barrierefreiheit. (Ab heute ist das Wort Zugänglichkeit bei mir tabu. Es heißt ab jetzt wieder Barrierefreiheit, habe ich gelernt.)

  5. Mal ganz losgelöst von der Diskussion darüber, ob man den Begriff „Barrierefreiheit“ oder lieber „Zugänglichkeit“ verwenden möchte und welche Konnotationen die jeweiligen Begriffe tragen…Selbstverständlich sollten und müssen diese Begriffe diskutiert werden.

    Der Begriff „Barrierefreiheit“ hat sich durch seine Verwendung in den Gesetzestext ‚etabliert‘. Gleiches gilt für den Begriff „Zugänglichkeit“ nicht.

    Bei aller Unsicherheit über die Datenbasis kann man dies z.B. über google trends sehen. Im Unterschied zum Begriff „Barrierefreiheit“ liefert eine Abfrage des Begriffs „Zugänglichkeit“ nur: „Your terms – zugänglichkeit – do not have enough search volume to show graphs.“

    Was also tun, um das Thema insgesamt voranzubringen? Brauchen wir – zumindest zur Zeit – mehr Pragmatismus in der öffentlichen Darstellung, auch wenn wir dafür einen evtl. ‚ungeliebten‘ Begriff verwenden müssen ?

  6. Hi Gerrit, grundsätzlich nette Quiz-Idee, aber:

    Antwort 2a beinhaltet schon mal Deine Wertung („Klobigkeit“). Und wieso ist bei Frage 3 das Seitenlayout so aufgebaut, dass es unter 800 x 600 und ohne zu scrollen nutzbar ist? Welche BF-Seite einer Kommune hat sowas?

    Ich habe auch eine Frage: warum stellst Du dein Quiz eigentlich hier rein, und nicht bei Dir? 😉

    Tatsächlich ist das nicht wirklich so praxisnah, aber Gerrit: mich verunsichert das Thema BF auch immer wieder. Ich hatte das Blau-Problem zum Beispiel bei eine kommunalen Website, die ich möglichst barrierefrei umsetzen wollte. Es gibt da eben eine intensive Beschäftigung mit Problemen, die marginal erscheinen.
    Dabei geht es eben immer um die Suche nach Möglichkeiten, diese Probleme wie fehlenden Kontrast zu minimieren. Dir ist bestimmt klar, dass da natürlich nicht eine konstruierte Multiple-choice-Lösung reicht, die man sich mal eben im Auto überlegen kann.

    Ist es vielleicht egal, wenn das Corporate Design und das Logo der Gemeinde (da nennt man das Logo nicht immer, aber meistens „Wappen“) geändert wird, weil der Stadtvertretung das Blau eh nicht gefällt? Kann man nicht auch eine Farben ergänzen, auch für Navi oder andere Seitenbereiche, ohne das das Blau in den Hintergrund tritt? Muss ja nicht nur weiss oder schwarz auf Blau sein, kann ja auch ein fetter 20-Pixel-Border um den Wrapper geben, bzw. einen blauen Seitenhintergrund, oder?

    Du bist selbst ein Designer, und wie überall geht es doch darum, zunächst die richtigen Fragen zu stellen. Ist die Anforderung Barrierefreiheit, wirst du mit den richtigen Fragen auch die richtigen Antworten finden.

    Und deshalb würde ich persönlich sagen: es kommt eben doch immer darauf an.

    Nur meine 2,2 Cent.

  7. Gerrit ich war gar nicht erheitert über deinen Artikel, wurde ebenso falsch verstanden. Ganz im Gegenteil er hat mich sehr zum Nachdenken gebracht. In einigen Punkten hast du sicher recht, die goldenen Regeln werden nicht so einfach auf einem Tableau serviert.

    Sowie du schreibst zum Beispiel: hohe Kontraste sind auch nicht das gelbe vom Ei, es gibt Sehbehinderungen die das nicht vertragen.

    Zumindest die Grundregeln sollten eingehalten werden (und ich meine nicht den validen code), semantischer aufbau, sprungmarker, textierung, tabbing.

  8. [quote comment=“1234″]Das macht mich ja glücklich, dass ich mit meinem putzigen Artikel zur allgemeinen Erheiterung unter den Barrierefreiheits-Profis beitragen konnte! Ich habe dennoch ein wenig das Gefühl, dass jeder seine eigene Sichtweise auf den Text anwendet, und das herausliest, was er/sie herauslesen möchte. Sei’s drum.[/quote]

    Sorry, aber dein Text war einfach zu verworren als das klar deine Sichtweise herausgekommen wäre. Du sagst ja selbst, dass du dir beim Verfassen nicht sicher warst.

    [quote comment=“1234″]Stellt Euch vor, Ihr seid Webdesigner und müsst für eine Gemeinde eine barrierefreie Website umsetzen.[/quote]

    Ich versuch’s.

    [quote comment=“1234″]1) Die Gemeinde hat als Logofarbe in allen Broschüren und Briefbögen ein mittelhelles Blau, welches Ihr natürlich auch im Pixel-Entwurf als RGB-Wert verwendet. Der Kontrast-Checker sagt aber, dass dieses Blau einen zu geringen Kontrast mit Weiß, und auch mit Schwarz hat. Was tun?[/quote]

    d) (Ich gehe eigentlich davon aus, dass ein 3:1-Helligkeitskontrast von fast jeder Farbe zu entweder schwarz oder weiß geben sollte, bin aber gerade zu faul das zu überprüfen.) Ich würde erst einmal abklären wie wichtig das Logo wirklich ist. Ist es nur dekorative Information wie es für mich ein Wappen bsp. darstellt, dann darf es gerne aus dem Kontrastschema rausfallen. Ist es allerdings beispielsw. der Name der Gemeinde, dann sind das essentielle Informationen. Ich würde mit den Beteiligten abklären ob man etwas gegen diesen schwachen Kontrast tun kann, vielleicht indem man eine feine Outline um den Text zieht, die ihn besser von der weißen Hintergrundfarbe hervor scheinen lässt. Wenn auch das nicht gewünscht wird, dann ist es wichtig ob der Name der Gemeinde auch noch aus anderen Quellen hervorgeht, beispielsweise aus dem title oder einer Brotkrumennavigation. In diesem Fall würde ich die Version nehmen, die am meisten Kontrast besitzt (also entweder schwarz oder weiß im Hintergrund) und es sich darauf beruhen lassen. Wenn diese Anhaltspunkte nicht da sind, dann kommt man um ein Hochkontrast-Stylesheet wohl nicht herum.

    (Ja, das ist die lange Version von „Kommt darauf an“, aber du wolltest es ja so.)

    [quote comment=“1234″]2) Die Fließtext-Schrift ist im Default-Zustand auf 12 Pixel, Arial angelegt. Bei den ersten Usertests beschweren sich einige ältere Mitbürger, die sich vor kurzem einen neuen Laptop mit 140ppi-Bildschirm gekauft haben, dass die Schrift so winzig sei. Wie reagiert man korrekt?[/quote]

    b) ohne den Hochkontrast-Switcher (was soll die Verknüpfung der beiden Quizfragen?) *und* c). Bei der ersten Änderung der Schriftgröße würde ich einen Hilfetext einblenden, der kurz und knapp darauf aufmerksam macht, dass man das auch per Browser machen kann, falls einem die Schrift auf anderen Seiten, die diese Funktion nicht haben, auch zu klein ist.

    [quote comment=“1234″]3) Das Seitenlayout ist so aufgebaut, dass es auch unter 800×600 Pixeln im Viewport noch ohne zu scrollen benutzbar ist. Viele Bürger beschweren sich jetzt aber, dass das Layout auf ihren Bildschirmen so seltsam langgezogen ist und die Zeilen zu lang zum Lesen sind. Es stellt sich heraus: 50 Prozent der Bürger surfen mit 1280Pixel Breite oder höher.

    a) Ich mache ein fixes Layout auf 1024er Breite und nehme bei 2% der User einen Scrollbalken in Kauf
    b) Ich begrenze die Breite per max-width auf 1024 Pixel und nehme bei vielen Usern „verschenkten Platz“ in Kauf
    c) Ich verweise per Hilfetext auf den Textzoom oder mache das gleich per JavaScript: Viewport ausmessen = Ausgangsschriftgrad anpassen.[/quote]

    ? Ist es jetzt ein Problem, dass die Zeilen zu lang sind (Frage) oder, dass so viel Platz verschenkt wird (Antwort b)?

    Ich versuche mit meinem Peugeot 106 ja auch nicht einen 4 Meter langen Wandschrank zu transportieren. Gott sei dank ist aber eine Webseite flexibler als mein altes Auto. so kann man sie bis zu einer gewissen breite Fluid laufen lassen, das müssen ja nicht 1024 Pixel sein, das können auch 1200 Pixel oder gar 1400 Pixel sein. Natürlich kommt es auf die Lesbarkeit des designs an. Aber verschenkt ist links und rechts nichts, wenn der Text damit leichter lesbar wird/bleibt. (ich tendiere zu b, aber ohne die Wertung mit dem verschenkten Platz).

    [quote comment=“1234″]Ich bekomme viel zu wenig handfeste Handlungsanweisungen über die visuellen Aspekte der Barrierefreiheit.[/quote]

    Weil es eben doch oftmals „darauf ankommt“ und es keine klaren Regeln gibt. Deshalb sind die W3C-Richtlinien eben keine Regeln. Es kommt immer auch auf den Kontext an in dem die Elemente der Seite stehen.

  9. @Sylvia: sehr feiner Artikel!

    @GvA: Logo ist in der Regel keine wesentliche Information, da die eigentliche Info (»Wessen Seite ist das?«) idR nochmal woanders in Textform vorhanden ist. Also kann das Logo x-beliebige Farben verwenden.

    Aber: wenn das Logo laut Styleguide derart schwache Kontraste hat, dann hat die hypothetische Gemeinde das Problem nicht nur im Web, sondern auch im Print. Nun im Web an den Symptomen rumdoktern zu wollen ist der falsche Ansatz, da gehört ganz einfach der Styleguide geändert, weil es eben auch andere Medien betrifft.

    Zur Frage »Wie reagiert man korrekt?« beim Thema Schriftgrößen: man reagiert korrekt, indem man gar nicht reagiert. Es gibt keine optimale Schriftgröße, die alle Benutzer zufiredenstellt und es ist auch nicht Aufgabe einer jeden Website, dem Nutzer die Bedienung seines Browsers zu erklären – da müssen die schon selbst drauf kommen.

  10. Ich beginne mal dort, wo ich Verständnisprobleme habe. Kerstin Probieschs Anmerkung, dass Google Trends für den Begriff Barrierefreiheit durchaus einen Trend auswirft (für Deutschland, Österreich und die Schweiz ;)), aber für Zugänglichkeit nichts, steht für mich jetzt ein wenig im Raum.

    Was schließen wir nun daraus? Geht es jetzt darum den Begriff der Zugänglichkeit zu favorisieren? Und warum das dann im Gegenzug zu einem bereits einigermassen etablierten?

  11. Bevor ich auf die Details – die Quiz-Geschichte von Gerrit (darf ich duzen :)) – eingehe, ein paar grundsätzliche Antworten.

    Ich antworte zwar auf den BF-Zoff (Nils Pooker) und auf den putzigen Artikel von Gerrit, wie er ihn selbst relativiert, aber ich setze mich durchaus mit einer Tendenz auseinander, die mir in Gelsenkirchen schon aufgefallen ist und nicht nur Gerrit betraf, auch Markus Angermeier ging in seinen Argumenten gerne lieber wieder auf alternative Oberflächen wie iPhone zurück. Es mag sein, dass ich diese Dispute und Argumente – so sehr sie von den einzelnen dann im Nachhinein verniedlicht werden -, derzeit überbewerte. Eine Tendenz lässt sich für mich im Blick auf barrierefreies Webdesign sehr wohl ausmachen. Und die habe ich kritisch kommentiert. Der Gemeinplatz, dass jeder auch sich selbst mitliest, erfreut die Sprachwissenschaft, entwertet jedoch auch jeden kritischen Kommentar. 😉

    Gerrit hat durchaus so was wie Meinungshoheit für einen bestimmten Bereich und das kann man auch an den erfreuten Kommentaren von Lesern ablesen, die sich bis dato wenig mit dem Thema Barrierefreiheit beschäftigt haben. Das Problem ist dabei nur, dass diese Leser vieles einfach so mitnehmen und es nicht weiter hinterfragen, auch wenn Gerrit sich durchaus selbstkritisch am Schluss seines Artikels fragt, wieviel er dann letztendlich darüber wisse.

    Ich mag die Leserschaft unterschätzen, mag sein. 🙂

    So nett es ist, Detailfragen – die auch noch beantworten werde 🙂 (Testumgebung on) – als Quizantworten zu sammeln, geht auch das an den grundsäztlichen Antworten vorbei.

    Noch weit bevor der Kunde mir ein nicht kontrastreiches Logo in die Hand drückt, muss der barrierefreie Abstimmungsprozess mit dem Kunden beginnen. Schon vorab muss dem Kunden klar sein, dass seine Webseite nicht wie seine Printwerbung aussehen kann und dass er auch noch die gesamte Gestaltung überdenken muss (Farben, Schriften etc.). Das Logo wäre dann nur ein Element.

    Ich persönlich kenne diese Problematik durchaus sehr gut. 🙂 Und ich wünschte mir auch, dass dieser Prozess mit dem Kunden eben dann doch ganzheitlicher ablaufen würde. Insofern verstehe ich Gerrits Quizz-Dilemma nur zu gut.

  12. Damit wir uns nicht falsch verstehen – ich habe meinen Artikel nicht verniedlicht, sondern eher ironisch darauf aufmerksam gemacht, dass die BF-Experten ihn offenbar als niedlich angesehen haben. Passt aber schon – kamen ja schließlich doch eine Menge an Reaktionen und Diskussionen auf. Was dann im Endeffekt wieder zeigt, dass es sooo unnütz nicht gewesen sein kann, mal meine gesammelten Gedanken in Worte zu gießen – ganz befreit von den (künstlich) definierten Grenzen zwischen Barrierefreiheit, Usability und techn. Zugänglichkeit.

  13. Quizzfrage 1: kontrastarmes Logo

    Hier muss ich Tomas Caspers zustimmen, bei der Kontrastierung von Vorder- und Hintergrund geht es um die ganze Webseite (da haben wir sie wieder die Ganzheitlichkeit), nicht um das einzelne Logo. Bei Grafiken ist nur wichtig, dass sie Inhalt im Alt-Attribut haben und dass die nicht transparent sind. Denn das franst mitunter ins Unlesbare aus, sobald der Nutzer die Hintergrundfarbe individuell anpasst.

    Bei der Kontrastierung geht es um Lesbarkeit und davon sind hauptsächlich Textelemente betroffen. Wenn man natürlich alles in Schriftgrafik macht, dann wären die auch mitbetroffen. Aber das sollte man ja ohnehin nicht. 😉 Das kann man ja alles auf einer Webseite ganz einfach testen, in dem man die Farben ändert (Hinter- und Vordergrundfarbe, in Opera alternative Styles einstellt) und nachsieht, ob das Logo noch lesbar ist. Liegt es transparent auf dem Hintergrund, ist es bei gleicher Farbe und Hintergrundfarbe irgendwann dann verschwunden. 🙂

    Die Fragestellung, was macht man insgesamt mit einem kontrastarmen CI. Nunja. 🙂 Entweder man hat die Möglichkeit, mit dem Kunden eine annähernd CI-konforme Lösung zu finden, oder man greift tatsächlich auf alternative Stylesheets (die im übrigen mit dem vernachlässigten ALTERNATE STYLESHEET auch im Browser selbst abrufbar sind – man könnte daher auch auf diese Styleswitcher durchaus verzichten) zurück. Wie schon öfter erwähnt, für eine barrierefreie Zertifizierung ist so was sehr wichtig, aber in der Praxis ist auch eine gute Annäherung schon ein großer Schritt. Einfach die Seite immer wieder mit Alternativen testen, dann kriegt man mit der Zeit eine ungefähre Einschätzung, was geht und was dann eher nicht. 🙂

  14. Quizfrage 2: Fliesstext auf 12 Pixel

    Ich dachte, diese Frage hätte ich eigentlich schon beantwortet. Es ist doch Standard, die Schrift mit EM-Werten zu erstellen. Damit kommt man nicht mehr in die Verlegenheit, dem Nutzer eine Hilfe an die Seite geben zu müssen, weil der Fliesstext immer skalierbar ist. Ob man dann noch einen offiziellen Schriftzoomer mit draufsetzt, ist dann eine individuelle Entscheidung. Grundsätzlich ist aber alles vorbereitet.

    Wie wir in Zukunft damit umgehen, dass Browser nun den Zoom der ganzen Webseite quasi schon integriert haben, wird sich zeigen. Die Diskussion läuft ja schon, ob EM-Layout dann noch nötig sein wird. Das ist aber eine weitere unsichere Baustelle. Derzeit würde ich aber immer noch auf EM setzen wollen.

    Eine Frage, die sich an diese Frage anschliesst ist, ob man EM für flexible Layouts noch weiterhin einsetzen wird, oder dann doch auf die Zoom-Funktion der Browser aufsetzt.

  15. Quizfrage 3: Flexibles Layout

    In dieser Frage steckt für mich zu sehr dahinter, ach ein flexibles Layout sieht ja auf grossen Monitoren aus wie ein Kaugummi. Das passt mir nicht.

    Hm – aus meiner Erfahrung muss ich sagen, dass der Kunde eigentlich immer eine ganz genaue Vorstellung davon hat, wie breit sein Layout laufen soll. Er sagt auch ganz konkret, wenn er ein flexibles Layout haben will, das quasi nach oben offen ist. Weil – flexibles Layout kostet. 🙂

    Okay, das war jetzt eine wirtschaftliche Antwort. Ich denke, die Antwort von Eric kommt ganz gut hin. Im seltensten Fall wird man Layouts machen, die jede mögliche Auflösung nach oben zulassen. Man wird das Layout auf den statistischen Fall nach oben begrenzen. Aber nach unten ist dann eben noch sehr viel möglich.

    Grundsätzlich muss man jedoch sagen, dass flexible Layouts nach unten irgendwann schwierig werden, wenn eine Webseite viele Bilder hat. Denn Bilder müssen dann ja auch mitskalieren nach oben und nach unten. Was selten wirklich noch aussieht.

    Es geht dabei darum, dass man nicht unendlich scrollen und nicht ständig hin und her springen muss im Lesen. Ein Scrollbalken soll bei niedrigen Auflösungen vermieden werden und Elemente sollten sich nicht so überlagern, dass der Inhalt nicht mehr lesbar ist.

  16. Gerrit:

    Ich hoffe, dass wir uns nicht falsch verstehen. Aber putzig hatte ich nicht noch eine ironische Drehung weiter gelesen, wie Du das wohl jetzt meinst. Gut – dann muss ich wohl das nächste Mal noch einen doppelten Boden mehr einziehen.

    Was nicht stimmt ist, dass die barrierefreien Experten – wie Du sie nennst -, deinen Artikel als niedlich sehen. Wenn dem so wäre, würde man nicht so kritisch darauf eingehen.

    Und klar ist es immer gut, wenn Artikel Dispute und Kritik herausfordern, aber diese Reaktionen beweisen nicht unbedingt, dass dadurch Unschärfe – vor allem nicht in einem ohnehin eher schwierig nach aussen zu kommunizierenden Bereich wie der Barrierefreiheit – willkommen ist. 😉

  17. Ein zentrales Argument für Barrierefreiheit ist, dass Design und Barrierefreiheit zusammengehen. Ist das immer so? Ich glaube nicht. Auch wenn hier sicher Argumente von der Designerfraktion relativiert werden können, bleibt der Aufwand für eine umfassende Prüfung, die zu Abstrichen am Design führen können.

    Semantische Auszeichnung ist Sache der Umsetzer und der Programmtechnik und hat nichts mit Design zu tun. Darum dürfen diese beiden Themen nicht vermischt werden. Es gibt da einen Aufwand in Schulung und Programmierung, der größtenteils noch vor uns liegt. Auch das positiv genannte WordPress produziert redundante titles und baut dann auch noch den HTML-Code mit ein.
    Auf der Codebasis ist die Sache soweit klar, da stimme ich Gerrit zu, abgesehen von marginalen Differenzen (ja, ob eine Barrierefreiheit 100% valide sein muss sehe ich als marginal an).

    Alles was dann noch mit Javascript zu tun hat ist nochmal ein Thema für sich.

    Und viel zu wenig höre ich vom einfachen Text, ein wesentlicher Bestandteil der Barrierefreiheit! Das Texten kann einem die Technik genauso wenig abnehmen wie das Design. Im Design gibt es immerhin noch den Vorteil diverser Prüfwerkzeuge.

    @Silvia, es gibt Unklarheiten. Wenn die Zielgruppe iPod-User mit Riesenzweitbildschirm sind, dann sind sie nicht egal. Und wenn die Zielgruppe auf viele bunte Grafiken anspricht, die einen in die Kontrastzwickmühle bringen würden, auch nicht.

    Mit einem Kunden, der Barrierefreiheit bestellt hat, kann man sicher noch darüber reden, dass nicht alle seine Ideen so oder garnicht umgesetzt werden können. Und wenn für eine öffentliche Seite gesetzlich noch keine Barrierefreiheit vorgeschrieben ist, bleibt immer noch das Argument, dass der nachträgliche Umbau mehr kostet als es sofort zu machen, und auch andere Argumente wie Fairness, die dort durchaus aufgenommen werden.

    Und die anderen? Ich will da keine Gesetze für Websites. Ich will ein Umdenken erreichen, mit klaren, ehrlichen Aussagen: Barrierefreies Design kostet meisten mehr, Autoren müssen geschult werden und bei der Software muss sind vielleicht wirklich hohe Kosten zu erwarten, wenn das CMS ausgetauscht werden muss.
    Und wenn die Seite dann einigermaßen barrierefrei ist, kann man damit nicht werben, weil man dann von den Standardistas auseinander genommen wird – zu Recht, denn Barrierefreiheit sollte aus anderen Gründen umgesetzt werden als für Werbeeffekte.

    Klar ist, es lohnt sich langfristig, Barrierefreiheit zu praktizieren, und genauso muss die Barrierefreiheit auch in den Weballtag einfließen. Mit der Brechstange ist da sicher nichts zu machen. Das pochen auf validen Code und Aussagen wie Sorry, wenn jemand barrierefreie Seiten optimiert, dreht man den Spieß schlicht mal um sind dabei nicht besonders hilfreich.

  18. Das wird hier ja ein richtiger Kommentar-Evergreen. 🙂

    @Harald 🙂 (Tee?)
    Richtig: Der Ausgangspunkt für die Diskussion hier ist barrierefreies Webdesign und der Artikel von Gerrit. Bei Gerrit ging es jedoch auch um eine Begriffsverschiebung hin zu Zugänglichkeit, was für mich tatsächlich noch eine andere Valenz hat als Barrierefreiheit.

    Und deswegen habe ich mich nicht nur auf die Designfragen in meiner Antwort bezogen, sondern auf das gesamte Feld der barrierefreien Umsetzung. Es ging mir darum, nicht an einzelnen äußeren Effekten wie Styleswitcher oder Kontrastregler Designfragen zu klären, sondern die Fragen beginnen eben nicht mit diesem Gadgets, sondern die werden im Code bereits realisiert. Mir ging es, diesen Ausseneffekt der Diskussion wieder auf die konkrete Umsetzung (den Quellcode) rückzuführen.

    Ob Semantische Auszeichnung auch eine Designfrage ist, nun da liessen sich sicherlich noch Beispiele finden (die werden ja vom Browser durchaus auch optisch hervorgehoben). 🙂

    Zu WordPress: von Haus aus ist WordPress schlicht wie viele Blogsystem semantisch sehr gut vorbereitet und die Standardthemes bieten auch validen Code. Das hat alles noch nicht wirklich mit Barrierefreiheit insgesamt zu tun, aber es ist ein guter Startpunkt. Vor allem gibt es gute Plugins, die dabei unterstützen.

    Es hätte dann doch zu weit geführt, auch noch die Textbarriere mit zu berücksichtigen. Aber da hast Du natürlich recht damit.

    Zu Deiner konkreten Unklarheitsfrage: Ich spreche hier aus einer idealen sprungmarker-Position heraus. Das ist mir vollkommen klar – ich schaffe und spreche hier von idealen Verhältnissen. Dazu gibt es diesen Blog, um von den idealen Bedingungen zu sprechen. Aber im realen Arbeitsleben kämpfe ich genauso mit den von Dir erwähnten Problemen. Nur eine Einschränkung gibt es bei mir nicht: Wenn ich ein barrierefreies Projekt auf dem Tisch habe, dann blende ich den iPod-User wirklich aus. Das ist nicht mein Kunde, um es mal salopp zu sagen. Das hat nichts mit Ausschlussmechanismen zu tun.
    Umgekehrt würde jeder andere Entwickler, wenn er eine Seite für einen iPod optimiert, nicht auf die Barrierefreiheit achten müssen. Dass sich durch gewisse Semantik und entsprechend erarbeitete Vorlagen für viele Optimierungen einiges auf den Weg insgesamt bringen lässt, ist mir auch klar und ist ja tägliche Praxis.

    Klar, wollen wir alle ein Umdenken erreichen. Aber ich finde auch gut, dass es Gesetze und feste Rahmenbedingungen gibt, wenn man so will sind das dann auch Standards. Und – ganz ehrlich, wenn es das BITV nicht gegeben hätte, wären die meisten kommunalen Webseiten heute noch nicht barrierefrei.

    Die Kostenfrage klärt sich mittlerweile schon besser, die Kunden wollen etwa auch für eine Redakteurschulung zahlen.

    Warum soll man bei einer guten umgesetzten barrierefreien Seite von den Webstandards-Kundigen auseinandergenommen werden. Wenn Du Dir die aktuellen von der BIK zertifizierten Webseiten ansiehst. auch die Agenturseiten, sind die durchaus grafisch ansprechend gemacht – auch die Portale -, und die Seiten sind vollkommen valide und gut semantisch durchstrukturiert? Das ist für mich jetzt kein Widerspruch.

    Das mit dem Spiess umdrehen meinte ich nicht brechstangenhaft. Ich meinte damit, ähnlich wie das iPod-Beispiel, dass der Fokus für eine barrierefreie Webseite eben auf der Barrierefreiheit liegt. Das ist das primäre Ziel. Welche anderen Probleme und Freuden damit noch gelöste und erzeugt werden können, ist mir dann zweitrangig. Es ging mir auch darum, endlich das Erarbeiten einer barrierefreien Webseite als Ziel an sich zu definieren und nicht als quasi Spoiler, den man dann noch draufsetzt. 🙂

  19. [quote comment=““]@Harald 🙂 (Tee?)[/quote]

    Hab ich gerade 🙂 Zu Gesetzen: ich will schon Gesetze für Auftritte staatlicher Einrichtungen wie Behörden, Gemeinden und Regierungen. Für mich klang durch, dass auch für große eCommerce- und andere Portale Vorschriften gelten sollen. Das lehne ich ab.

    Dass semantische Auszeichnung auch Auswirkung auf das Layout hat stimmt wohl, doch die kann man mit CSS austricksen. Eine klare Trennung zwischen den von mir genannten Bereichen gibt Webentwicklern die Möglichkeit, auch ohne das große Gesamtziel einen Teil Barrierefreiheit mit einfließen zu lassen.

    Ich finde es toll, dass das Thema wieder hochgekocht ist!

  20. [quote comment=“1263″]Ich glaube nicht. Auch wenn hier sicher Argumente von der Designerfraktion relativiert werden können, bleibt der Aufwand für eine umfassende Prüfung, die zu Abstrichen am Design führen können.[/quote]

    Abstriche am Design eher nicht, vielmehr an der Dekoration. Oder man verzichtet auf eine umfassende Überprüfung der visuellen Elemente nachträglich und geht mit gesundem Menschenverstand™ an die Sache heran. Das hilft ungemein, gerade wenn es um Kontraste geht.

    [quote comment=“1263″]Wenn die Zielgruppe iPod-User mit Riesenzweitbildschirm sind, dann sind sie nicht egal. Und wenn die Zielgruppe auf viele bunte Grafiken anspricht, die einen in die Kontrastzwickmühle bringen würden, auch nicht.[/quote]

    Ich will sehen, wie du ein Webdesign machst, dass sowohl auf einem iPod touch/iPhone als auch auf einem „Riesenzweitbildschirm“ funktioniert. Das sind unterschiedliche Szenarien und auch, wenn der iPod-Safari es unheimlich leicht und bequem macht „normale“ Webseiten anzuschauen, so ist nicht jedes Design in jeder Auflösung dafür optimal geeignet. Man würde dem iPod also ohnehin ein eigenes Stylesheet zuweisen wollen. Mit Barrierefreiheit hat das alles aber nichts zu tun.

    Zur „Kontrastzwickmühle“: Die Zielgruppe kann noch so sehr auf Low-Contrast stehen, wenn die Grafiken rote Schrift auf grünem Grund haben, dann können es >5% der Männer nicht lesen. Das kann man umgehen. Es gibt genug bunte Farben, die einen hohen Kontrast haben. Und wenn es anders nicht geht, dann muss man eben ein Hochkontrast-Stylesheet einbinden.

    [quote comment=“1263″]Mit einem Kunden, der Barrierefreiheit bestellt hat[/quote]

    Ich frage mich bei solchen Annahmen immer, ob man auch in der Werkstatt dem Automechaniker sagt, dass er auch die Bremsen ja richtig einbauen soll und dass man gerne *funktionierende* Bremsen hätte. Nein? Vielleicht sollte qualitativ hochwertiges Webdesign auch Standard werden.

    [quote comment=“1263″]Und die anderen? Ich will da keine Gesetze für Websites. Ich will ein Umdenken erreichen, mit klaren, ehrlichen Aussagen[/quote]

    Das versucht die Anti-Raucher-Lobby schon seit Jahren. Letztlich braucht es einen gewissen Zwang, beim Rauchen kommt der u.a. über den Preis. Schlechtes Webdesign muss mehr kosten als gutes. Und das erreicht man anscheinend nur über Bestrafungen.

    [quote comment=“1263″]Und wenn die Seite dann einigermaßen barrierefrei ist, kann man damit nicht werben, weil man dann von den Standardistas auseinander genommen wird – zu Recht, denn Barrierefreiheit sollte aus anderen Gründen umgesetzt werden als für Werbeeffekte.[/quote]

    Das verstehe ich nicht 🙂 Mir ist es wurscht aus welchem Grund eine Seite barrierefrei ist. Das Ziel ist das Ziel.

  21. @Harald

    Zur Gesetzgebung: Warum sollte man das nur auf Kommunen beschränken. Vor allem – wenn man Barrierefreiheit allgemein durchgesetzt haben möchte, sollte das Gesetz dahingehend erweiterbar sein. Aber keine Angst, auch das neue BITV, das im Sommer kommen soll, hat sich gegen diese Erweiterung ausgesprochen.

    Zur semantischen Auszeichnung: Warum sollte man mit CSS die vom Browser angezeigte Auszeichnung austricksen wollen? Bei logischen Auszeichnungen entscheidet die Ausgabe (Bsp. Browser), wie etwa EM– oder STRONG-Elemente dargestellt werden. Man gibt der Ausgabe damit quasi immer schon eine Formatvorlage mit. Mit CSS sollte man das nicht überschreiben, nur verstärken. 🙂

    Das Thema Barrierefreiheit scheint immer wieder virulent zu sein. Ich würde mir nur manchmal wünschen, wir kämen einen Schritt weiter damit.

  22. [quote comment=“1267″]Schlechtes Webdesign muss mehr kosten als gutes. Und das erreicht man anscheinend nur über Bestrafungen..[/quote]

    Das tut es ja auch meisthin, weil es im Nachbearbeiten (Schluddrigkeiten, keine externen und internen Standards eingehalten, ständiges Debuggen statt elegante Nachpflege und so weiter) dann die Kosten hochzieht. 🙂

    Aber grundsätzlich ein guter Ansatz, werde das beim nächsten Meeting vorschlagen. Mal sehen wie groß die Preisspanne dann zwischen beiden Posten werden kann. 😉

  23. [quote comment=“1267″]Letztlich braucht es einen gewissen Zwang, beim Rauchen kommt der u.a. über den Preis.[/quote]

    Ich, bisher hatte ich schon recht positive Resonanz, der Wunsch ist bei den Programmierern und Designern, die ich kenne, schon da. Die Barrieren sind da eher die Pixelschubserprogramme und der IE.

    [quote comment=“1267″]… wenn die Grafiken rote Schrift auf grünem Grund haben[/quote]

    Sieht sowieso nicht schön aus 🙂

    [quote comment=“1267″]ob man auch in der Werkstatt dem Automechaniker sagt, dass er auch die Bremsen ja richtig einbauen soll und dass man gerne *funktionierende* Bremsen hätte.[/quote]

    Immer diese Autovergleiche. Mit einem riesigen Sport Utility Vehicle komme ich auch nicht durch alle Innenstädte. Mir wäre so ein Auto peinlich, aber wie man sieht finden sie viele gut. Da hab ich mir jetzt allerdings eine Falle gestellt: die werden auch durch die Gesetzgebung teurer.

    Das Problem sehe ich halt bei der Grenzziehung. Sicher kann man Portalen, mit denen viel Geld verdient wird, zumuten, barrierefrei aufzutreten. Aber was ist mit den vielen Neueinsteigern und Auftritten kleiner Firmen? Und auf welcher Grundlage soll das eingeklagt werden? Wenn mangelnde Barrierefreiheit abgemahnt werden kann, verlieren wir viel von dem positiven Image, was wir in den letzten Jahren aufgebaut haben.

  24. Wir sollten endlich aufhören uns so wichtig zu nehmen und den Nutzern wieder mehr zutrauen. Sie haben seit jeher die Möglichkeit die Dokumente nach ihren höchst individuellen Vorlieben und Bedürfnissen anzupassen. Unsere Hilfe benötigen sie nicht.

  25. @Gerhard

    Die Frage, die zuerst zu stellen ist, wer sind wir? Dem Nutzer vertrauen ist das eine, das andere barrierefreie Webseiten zu erstellen für möglichst viele Nutzer. Auch damit ist dem Nutzer weiterhin einiges zuzutrauen. Ich denke, Du müsstest schon etwas genauer werden in Deinen Argumenten. So ist das nur unscharf und wenig erhellend für die aktuelle Diskussion.

  26. @Harald

    ad. Pixelschubserei: Klar, bei einem elastischen Layout wird es weit schwieriger, pixelgenau zu arbeiten. Aber wenn man auch Grafiken mit EM-Werten versieht, dann geht das schon. Ist halt mehr Arbeit. 🙂
    Und der IE ist an sich kein Hindernis.

    Warum wir eine barrierefreie Seite als monströs angesehehen? Welche guten barrierefreien Seite sieht man das an?

    Wer klagt denn hier in Deutschlande, Harald? Man sollte nicht immer solche Szenarien entwerfen. Wie gesagt, das neue BITV sieht das gesetzlich für die Privatwirtschaft nicht vor. Also wovor und warum auch zittern? 🙂

  27. [quote comment=“1277″]Klar, bei einem elastischen Layout wird es weit schwieriger, pixelgenau zu arbeiten. Aber wenn man auch Grafiken mit EM-Werten versieht, dann geht das schon. Ist halt mehr Arbeit. :)[/quote]
    Aber warum sollte man das tun? Findest du es sinnvoll die Möglichkeit den Schriftgrad zu verändern einfach als Zoomfunktion zu missbrauchen? Eine Änderung des Schriftgrades beeinflusst schließlich üblicherweise auch die Anzahl der in einer Zeile dargestellten Zeichen und verbessert so auch die Lesbarkeit von Texten.

  28. @Gerhard
    bitte – die Diskussion hatten wir schon hier im Kommentarbereich. Von Missbrauch kann keine Rede sein zum einen. Und zum anderen ist die Zoomfunktion noch nicht in allen aktuellen Browsern gängig. Das muss man abwarten. Ich sprach bereits davon, dass es derzeit Diskussionen gibt, ob ein durchgängiges EM-Layout in Zukunft sich weiter durchsetzen wird.
    Das mit der Lesbarkeit müsstest Du noch weiter ausführen. Wenn Du meinst, ein elastisches Layout, das nach oben offen bleibt, gefährde bei einer hohen Auflösung die Lesbarkeit, dazu habe ich auch bereits hier kommentiert.

  29. [quote comment=“1289″]bitte – die Diskussion hatten wir schon hier im Kommentarbereich. Von Missbrauch kann keine Rede sein zum einen. Und zum anderen ist die Zoomfunktion noch nicht in allen aktuellen Browsern gängig. Das muss man abwarten. Ich sprach bereits davon, dass es derzeit Diskussionen gibt, ob ein durchgängiges EM-Layout in Zukunft sich weiter durchsetzen wird.[/quote]
    Ja? Hab‘ ich überlesen. Entschuldige bitte.

    [quote comment=“1289″]Das mit der Lesbarkeit müsstest Du noch weiter ausführen. Wenn Du meinst, ein elastisches Layout, das nach oben offen bleibt, gefährde bei einer hohen Auflösung die Lesbarkeit, dazu habe ich auch bereits hier kommentiert.[/quote]
    Mit einer Änderung des Schriftgrades lässt sich bei den meisten Websites nicht nur die Größe der Zeichen sondern auch die Anzahl der in einer Zeile dargestellten Zeichen beeinflussen. Und das ist auch gut so.

  30. […] public links >> barrierefreiheit Barrierefreiheit: Je exotischer die Anforderungen, desto besser 🙂 Saved by vingon15 on Wed 01-10-2008 Online-Shops: Warum Barrierefreiheit immer wichtiger wird […]

Schreibe einen Kommentar

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