Barrierefreies Webdesign

[cws]

Ich traue mich mit der Frage mal ins Proforum, wo ich ja nicht hingehöre, trotzdem:

Es gibt eine Vielzahl von Anleitungen zum Erstellen von barrierefreien Websites.
Der wichtigste Link auf Deutsch ist sicher

http://www.einfach-fuer-alle.de/
und
http://www.einfach-fuer-alle.de/award2005/kriterien/

Ich habe allerdings den Eindruck, dass die Trauben dabei sehr hoch hängen, sodass viele Webdesigner aufgeben.

Meine Fragen dazu:

Warum wird das Problem mit Gewalt auf der Seite der Webdesigner angesiedelt?

Warum sieht niemand das Problem auf der Seite der Browser?

Sollte es nicht die Aufgabe eines Browsers z.B. für Sehbehinderte sein, dass er validen Code entsprechend umsetzt?

Nicht dass mich jemand missversteht, es geht mir nicht darum Barrierefreiheit auf andere abzuschieben, aber manchmal denke ich, dass die Diskussion in die falsche Richtung geht. Das es, so wie es läuft, mehr Probleme und damit Widerstände als Lösungsversuche erzeugt.

Was mir auch fehlt ist ein Validator, der wenigstens den Code nach einfachen Kriterien bewertet, ohne gleich eine 100% Lösung aufzurufen, oder mich auf verschiedene Vorschriften und ein unendliches Gewirr an Ratschlägen zu verweisen.

Klärt mich bitte auf, wenn ich das Problem nicht begriffen habe.

 

[stk]

Moin,

erstmal ist es natürlich an den Seitenerstellern für barrierefreien Code zu sorgen. Mit Seitenersteller meine ich sowohl die Webdesigner und -progger als auch die Tools, die ihnen dabei helfen sollen.

Schwierig dabei ist, das die Kriterien für Barrierefreiheit nicht durch ein hartes 0 oder 1 Raster passen. Leicht nachzuvollziehen an den div. Tools die Barrierefreiheit "messen". Ein Teil kann klar mit "vorhanden/erfüllt" oder eben nicht geprüft werden, ein sehr viel größerer Teil besteht aus Hinweisen was zu tun oder zu lassen ist. Um wieviel schwerer mag die Codeerstellung sein, wenn schon die Codeprüfung nicht so einfach maschinell machbar ist.

Browser haben in dem Spiel eigentlich keine Rolle. Was die mit validem, barrierefreien Code machen, ist eine völlig separate Veranstaltung. Nicht immer von Glanz umstellt. Barrierefreiheit ist zu vielschichtig als das ein einziger Browser alles Ansprüche (neben vielen anderer aller Nutzer) zuverlässig abdecken könnte.

Barrierefreie Webseiten unterliegt darüberhinaus dem gleichen Kriterium wie allen andere Webseiten: "… und immer an den Leser denken!" Anderrs gesagt: es gibt durchaus Anwendungsfälle, wo auf Barrierefreiheit ebenso gut verzichtet werden kann. Ein praktisches Beispiel: wir haben mal die Seiten von www.transalp.de nach WAI Stufe 1 (oder sogar 2?) barrierefrei umgemodelt. Die letzte Konsequenz bis zur Stufe 3 zu gehen haben wir uns verkniffen. Die Wahrscheinlichkeit auf einen blinden und/oder motorisch Schwerstbehinderten zu treffen der sich für's Motorradfahren im Allgemeinen, die Technik und die Touren der Transalp im Besonderen interesseirt erschien uns als zu klein .

Ein Paradoxon kommt dazu: W3C-Code-Validität und Barrierefreiheit nach WAI (einer W3C-"Abteilung") schliessen sich - zumindest an einer Ecke - gegenseitig aus. Während die WAI eine Sprachkennzeichnung mit <html lang="de"> während genau dieses Konstrukt nach xHTML 1.1 nicht zulässig ist.

Keine ganz leichte Kost die Du an- und aufgerührt hast.

Gruß Stefan

 

[cws]

... Keine ganz leichte Kost die Du an- und aufgerührt hast.

Gruß Stefan

Das ist ja mein Problem.

Es fängt bei dem Bobby-Logo an.
Bobby.org war ja früher die relevante Instanz, aber die sind weg?
http://www.watchfire.com ist auch keine ganz einfache Kost und es fehlt mir bei denen auch der klare Hinweis, "Sie dürfen das Logo xy in ihre Seite einbinden", wie es bei den w3c Validatoren der Fall ist, wie es bobby.org früher auch anbot.
Auch http://www.contentquality.com/ kommt mit für mich nicht mit wirklich klaren Aussagen rüber.

Anders formuliert, es fehlt ein Stück die Belohnung für die Bemühungen des Webdesigners, und der griffige Beweis für den Auftraggeber. Gerade das macht den Anreiz kleiner, sich um barrierefreies Design zu bemühen.

Es gibt ja quasi "amtliche" Gütesiegel, ich finde die deutsche Adresse leider nicht mehr, die dann aber kostenpflichtig sind.

Das ganze empfinde ich als extrem kontraproduktiv. Auch die Aktion Mensch, auf deren Fahnen das Projekt ja steht, führt mich eher in die Richtung lass es, das verstehst du sowieso nicht.

Ich fühle mich von den Propagendisten der Barrierefreiheit allein gelassen.

 

[stk]

Moin,

Der Bobby scheint in der Tat tot zu sein. Ich kriege auch nur noch einen Forward auf das - wie ich finde bessere - WebXACT: http://webxact.watchfire.com/ Die Einbindung von WebXACT ist geregelt: http://webxact3.watchfire.com/themes/standard-en-us/formcode.htm

Was beiden gemeinsam ist - sein muß - ist die o.g. Tatsache das nur einzelne Punkte mit einfachen Ja/Nein Regeln zu prüfen sind und sehr viele andere Punkte immer noch den manuellen Blick benötigen um zu sehen ob es die Kriterien der Barrierefreiheit erfüllt. Beispiel: eine Maschine kann nicht entscheiden ob eine verwendete Tabelle tatsächlich für tabellarische Inhalte verwandt wurde oder ob damit ein Layout aufgezogen wurde. Das erstere ist auch für barrierefreie Seiten korrekt (wenn bestimmte Dinge beachtet werden, die i.d.R. nie beachtet werden ), das zweite eine Todsünde - auch dann wenn die Regeln für Tabellen die Barrierefreiheit aufstellt korrekt umgesetzt werden. Oder: der Inhalt einer Grafik kann schmückendes Beiwerk sein oder elementare Informationen enthalten ohne die die Webseite nicht oder nur eingeschränkt benutzbar ist. Im ersten Fall kann ich jeden Mist in den Alt-Text reinschreiben, im zweiten Fall muß ich den Inhalt den Regeln der Barrierefreiheit unterwerfen. Robots können nur auswerten, dass dort eine Grafik ist, nicht aber was sie darstellt.

Bei der vielen, notwendigen Handarbeit - da bin ich ganz bei Dir - ist so ein "Gütesiegel", das man sich auf seine Seite pappen darf schon ein Mindestmaß der Anerkennung. Eine "Instanz" für .de wäre auch noch der Biene-Award und die BITV, die allerdings im wesentlichen auf den WAI-Regeln aufbaut. Das würde ich bestenfalls als "Übersetzungshilfe" begreifen.

Als ein wichtiges Thema in Sachen Barrierefreiheit empfinde ich (hab ich hier glaube ich so auch schon mal postuliert), das wir "Normalos" gar keinen Sinn für Barrieren haben. Barriere ist nicht, wenn's in der Verordnung oder im Regelwerk steht, sondern wenn eine bestimmte Person damit nicht klar kommt. Und das weißt Du i.d.R. immer erst dann wenn genau diese Person draufgeschaut hat. Genau das liefert die Nachtflug-Mailingliste. Wenn eine Seite ernsthaft Barrierefrei sein soll, dann würde ich sie (nachdem alle WebXACT u.ä. Sachen geprüft sind) dort zur Endkontrolle einwerfen.

Gruß Stefan

 

[cws]

Bei der Priority 1 erhalte ich zwar ein Häckchen (0 Errors/0 Instances), aber auch Probleme bei den "Manual Checkpoints". logisch, z.B. "einfache Sprache" kann keine Maschine prüfen. Also kommt der Hinweis:

This page does not comply with all of the automatic and manual checkpoints of the W3C Web Content Accessibility Guidelines, and requires repairs and manual verification.

Darf ich mir nun dieses Banner gönnen oder darf ich nicht, da fehlt mir die klare Aussage. Es sieht für mich etwas beliebig aus, eher nach "setze es ein, dann kann jeder selber sehen". Das ist keine schlechte Idee, nur kann niemand was mit den Ergebnissen anfangen. Es hat wohl keinen "Bestätigungscharacter", was nach dem von dir zu den "weichen" Kriterien ja gesagten eigentlich auch nicht geht.

Die Nachtflug-Mailingliste ist ja mal wirklich was handfestes, wenn es um eine praxisnahe Beurteilung geht.

 

[pepi]

@stk
Ist in XHTML 1.1 die Sprachkennzeichnung aufgrund der XML Deklaration nicht als xml:lang anzugeben? Ob sie allerdings ins eröffnende HTML oder BODY Tag gehört müßte ich auch nachsehen. In einem P kann man sie jedenfalls jederzeit innert des Inhaltes anwenden.


Meiner Ansicht nach gibt es beim "WebDesign" einige grundlegende Probleme die sowohl technisch als auch Marktwirtschaftlich begründet sind.

Die HTML Qualität im Internet ist global gesprochen "unter aller Sau". Der Google Code Report 2005 spricht Bände. So dicke, daß einem schlecht werden mag.


GUI Webeditoren wie GoLive, Dreamweaver und Frontpage erzeugen "HTML"-Code der mit HTML außer der Bezeichnung oft nicht viel zu tun hat. Damit ist viel Code im Netz weder valide und damit implizit auch nicht barrierefrei.
Viele (selbsternannte) "Profis" setzen diese Tools ein.
Jeder informatik Student der sich die EDU Lizenz von so einem Tool auf der Uni holt ist automatisch ein Profi. Immerhin studiert der das ja, oder? Ein wirklicher Profi verwendet sowas maximal fürs Rapid Prototyping. Neuere Tools wie Nvu sind bei vielen in der "Branche" verschrien weil was nix kostet auch nix wert sein kann. Außerdem verbieten diese Dinger Designs zu erstellen die nicht valide sind, was den Schöpfern ein Dorn im Auge ist.

Die Auftraggeber sind zu 99,9% schrecklich ahnungslos was das Medium und gerechte Aufbereitung von Inhalten angeht. Jeder hat das schonmal gehört. "Ich möchte eine Homepage. Eh nur ganz was einfaches." Der Rest ist ein Backend für 20.000 Euro.

Auftraggeber können zwischen wirklich gutem (validem XHTML, CSS) und generiertem Code aus der Dose nicht unterscheiden. Nehmen daher den studierten Studenten weil der das für 10€ die Stunde macht. Dementsprechend ist das Ergebnis. Das Fachwissen und die Erfahrung eines echten Profis kosten nunmal Geld.

Die Welt hat die Konzepte vom Tim Berners Lee nicht verstanden. Dort stand nämlich nie etwas von graphischem/optischem Medium, sehr wohl aber von Barrierefreiheit!

Die Browser der letzten 10 Jahre waren fürchterlich in ihrer Standardunterstützung und Interpretation. Die Browser von Microsoft werden das wohl auch noch die nächsten 10 Jahre sein. (IE 7 hat noch immer ein broken CSS1 box-model! CSS 1 ist Draft 1993 und Spec von 1996)

Viele Werbeagenturen aus dem Printbereich machen jetzt auch mit Web. Diese Leute wenden dementsprechend Ihr Wissen um Layout und Design auf WebDesign an. Dabei wird leider vollständig ignoriert, daß dieses Wissen im Web zu großen Teilen keine Gültigkeit hat. Diesem Medium geradezu gegenläufig ist.
Wenn man von einem Printgrafiker ein Layout haben möchte, ist wohl die erste Frage die kommt "Wie groß soll es sein?". Im Sinne von, wie groß ist mein Ausgabemedium, meine Leinwand, mein Papier. Die einzige korrekte Antwort fürs Web lautet "Du weist es nicht und es ist nichtmal sicher ob Du überhaupt eine Leinwand hast.". Damit ist dieses Vorhaben bereits gescheitert. Alles was dann noch an Dialog oder gar Design kommt ist nicht mehr Mediengerecht.



Und damit ich mich jetzt nicht wieder über das ganze Thema aufregen muß...
Eine Satire zum Thema Accessibility: Der Suchmaschinen-Robot und der Webdesigner

Gruß Pepi
PS: Sorry, ist mehr ein Rant geworden. Ich hoffe, daß trotzdem das eine oder andere Thema wiedererkannt wurde.

 

[tjp]

Meine Fragen dazu:

Warum wird das Problem mit Gewalt auf der Seite der Webdesigner angesiedelt?

Warum sieht niemand das Problem auf der Seite der Browser?

Sollte es nicht die Aufgabe eines Browsers z.B. für Sehbehinderte sein, dass er validen Code entsprechend umsetzt?

Das Problem ist, daß viele Webseiten keine sinnvolle Struktur enthalten. Wir haben aber bisher keine KIs, so daß es unmöglich ist die nicht vorhandene Struktur maschinell zu erzeugen. Aus diesem Grund kann der Webbrowser nicht mehr nachträglich etwas erkennen was nicht vorhanden ist.

Das Problem ist relativ leicht zu beschreiben. Die meisten Webseiten werden von Menschen designt, die aus der klassischen Layoutschule kommen. Leider haben diese Personen enorme Probleme in Strukturen zu denken und sie viel zu sehr an optischen Aussehen verhaftet. SGML hatte schon sehr früh den Gedanken von strukturierten Dokumenten unterstützt, nur so gut wie niemand hat mit SGML gearbeitet. SGML trennt Strukturendefinition, Styles und strukturierte Inhalte konsequent voneinander. Bekannter wurde der Ansatz von SGML mit XML, einer Abwandlung von SGML.

Der Webdesigner ist nun dafür veranwortlich, daß die notwendigen Strukturen in den Webseiten vorhanden sind, ist das nicht der Fall kann der Webbrowser an diesem Manko nichts mehr ändern.

Ein Beispiel mit dem es vielleicht leichter verständlich wird: ein Fachbuch.
An Strukturen existieren so Dinge wie:
der Titel, die Autoren, der Verlag, Kapitelüberschriften, weitere Gliederungsebenen, Absätze, diverse Verzeichnisse, mathematische Strukturen (oder andere fachspezifische Strukturen), ... Wichtig zum Verfassen des Buches ist nur der strukturierte Inhalt den man bezogen auf eine Strukturdefinition schreibt. Danach kann man eine oder mehrere Styles definieren, mit denen man das Aussehen des Buches erst nachträglich festlegt. Wichtig ist dabei, daß man den Inhalt auf gar keinen Fall mehr anfaßt. WYSIWYG ist zum Verfassen von strukturierten Dokumenten eher hinderlich, weil es mal wieder eine feste Verbindung von Dokument und Aussehen suggeriert, die es eben nicht geben soll.

Mit diesem Problem sieht man sich als Techniker regelmäßig konfrontiert. Die meisten Menschen achten nur darauf wie etwas aussieht, aber nicht wie es strukturiert ist. Diese Personen schreiben Texte mit einer Textverarbeitung vollkommen unstrukturiert, da werden keine Styles verwendet sondern feste Formatierungsanweisungen mitten in den Inhalt reingeschoben. Damit sind diese Dokumente vollkommen wertlos, wenn man den Inhalt maschinell aufberarbeiten will. Zum Beispiel kann niemand erkennen ob <Times,12pt,bold>Dies ist ein Text</Times,12pt,bold> nun eine Überschrift sein soll, eine Hervorhebung in einem Fließtext o.ä. Dagegen <Überschrift Ebene1>Dies ist ein Text</Überschrift Ebene1> ist von einem Computer leicht zu erkennen, da in der betreffenden Strukturdefinition drin steht, daß es so etwas wie eine "Überschrift Ebene1" gibt. Wenn man also nur irgend welche Formatierungen in einem Dokument hat, dann wird für den Computer daraus ein Einheitsbrei aus dem er keinerlei Bedeutung der einzelnen Begriffe mehr ziehen kann. Das ist genauso, als ob Du den Text in einem monotonen Singsang herunternuschelst. Da verstünde auch kaum jemand mehr etwas.

Ok, ich programmiere und habe eine technisch, naturwissenschaftliche Vorbildung, so daß ich das anders wahrnehme, aber wenn ihr wirklich wollt, daß Eure Werke besser werden müßt ihr Euch mit dem Thema mehr auseinandersetzen.

Ich habe schon Parser geschrieben, um aus Textdokumenten in speziellen Formaten wieder Strukturen zu erzeugen. Dabei ging es u.a. um die Verarbeitung von E-Mails, und ich brauchte mich noch nicht einmal mit den Inhalten der E-Mails herumschlagen, die durften roh abgespeichert werden. Trotzdem war der Ärger groß, da es massenweise unterschiedliche Auffassungen von der Interpretation der betreffenden RFCs gab. Was nicht an Struktur da ist kann man nachher nicht mehr erzeugen und so geht definitiv Information verloren.

 

[cws]

Das spricht dann sehr deutlich für stks Forderung nach css und nochmal css.
Dadurch enstehen ja zwangsweise Strukturen. andererseits müsste dann wohl auch eine Verbindlichkeit her, wenn es um die Verwendung der Tags geht. Also Überschriften immer mit <h1,2,3 ...>, die css-Elemente immer in einer Reihenfolge die im Textbrowser einen Sinn ergibt. Das scheinen mir aber realisierbare Herausforderungen.

In Opera gibt es ja so etwas wie eine Textansicht, ich versuche diese als Anhaltspunkt zu nehmen, um eine Verständlichkeit der Seite auch ohne "Volldarstellung" zu prüfen.

Na mal sehen, wie weit ich komme. stks Tipp mit der Nachtflugliste ist ja eine gute Möglichkeit, sich ein paar verdiente Schellen einzufangen.

 

[tjp]

Eine Satire zum Thema Accessibility: Der Suchmaschinen-Robot und der Webdesigner

Köstlich! Das ist eher Realsatire, das Gespräch findet so ähnlich regelmäßig zwischen echten Personen statt.

 

[tjp]

Das spricht dann sehr deutlich für stks Forderung nach css und nochmal css.
Dadurch enstehen ja zwangsweise Strukturen.

Nein, nur dann wenn man das Werkzeug bestimmungsgemäß verwendet. Ich habe leider schon zu viele Negativbeispiele gesehen.

andererseits müsste dann wohl auch eine Verbindlichkeit her, wenn es um die Verwendung der Tags geht. Also Überschriften immer mit <h1,2,3 ...>, die css-Elemente immer in einer Reihenfolge die im Textbrowser einen Sinn ergibt. Das scheinen mir aber realisierbare Herausforderungen.

Ja, das ist eine notwendige Bedingung. Man darf Tags nur in ihrem angedachten Sinn verwenden und sie niemals für etwas anderes mißbrauchen. Dazu kommt, daß man die Plausibilität der Tags, d.h. ihre Abhängigkeit voneinander, beachten muß. Die XML DTDs definieren dies zwar, aber die meisten XML-Editoren unterstützen kein DTD konformes Schreiben von XML-Dokumenten.

Ich kenne zwar einige brauchbare XML-Editoren, diese sind aber für das Verfassen von technischer Dokumentation und entsprechend teuer, mehrere Tausend Euro sind da die Regel und nicht die Ausnahme.

Ein weiterer interessanter Hinweis ist das MVC Pattern (Wikipedia Link), Apples Cocoa Dokumentation MVC, diese erklären sehr gut wie im Software Design Struktur, Aussehen und Steuerung voneinander getrennt wird. Zumindest den Grundgedanken dieses Patterns solltest Du verstehen, das würde Dein Verständnis für die Problematik erhöhen. Ich hoffe das MVC ist jetzt kein Overkill, aber bestimmte Patterns sind als Metastruktur enorm wichtig, da sie immer wieder in verschiedenen Variationen auftauchen. Und speziell das MVC für das Webdesign mit dynamischen Inhalten von großer Bedetung ist, wenn man sauber die Bestandteile trennen will.

 

[cws]

... daß erklärt sehr gut wie im Software Design Struktur, Aussehen und Steuerung voneinander getrennt wird. ...

Die Idee trifft sich ja ein Stück weit mit der Realität, wie sie sich mir darstellt.
Allerdings auf niedrigem Anfängerniveau.
Grundsätzlich findet sich das in den Stukturen von Typo3, das ich gerade versuche zu verstehen wieder, ebenso wie ich mit css eher ein Anfänger bin.

Aber die Aufteilung in die Elemente
Content, Designvorlage und Stylesheet scheint mir dem System zu entsprechen.
Desingvorlage ist die Struktur des HTML-Dokuments (im Prinzip).

Die Verwaltung dieser Elemente erfolgt unabhängig voneinander.

Die Diskussion scheint mir dann insgesamt doch in eine Metaebene zu gehen, die sich vom realen HTML-Code ein Stück entfernt, auch wenn sie hilft die Stukturen zu optimieren und die Probleme zu verstehen.

Es ist dann in der realen Webwelt, die man erlebt, eher selten wiederzufinden.
Dort sind es dann die Kleinigkeiten und die eigene Inkompetenz, die mir das Leben erschweren. Letztlich kann ich die Werkzeuge nicht selbst beeinflussen und bin auf das, was sie bieten und meine Fähigkeiten sie zu bedienen, begrenzt.

Ich bin eben kein Profi, eher ein Dilletant, der in seine Aufgabe hineinwächst.