Webstandards
Eine Fachpräsentation von Philipp Hauer im Fachbereich Informatik. Gehalten am Richard-Wossidlo-Gymnasium am 06.03.2007 und am 17.03.2007. ©
Inhaltsangabe
- Einleitung
- Webstandards
- Barrierenfreiheit
- Wertung der Webstandards
- Anhang (Erklärung des Verfassers, Abbildungsverzeichnis, Quellen)
Einleitung
Schauen Sie sich folgende Bilder an. In allen wird ein und die selbe Internetseite dargestellt, nur mit anderen Browsern, Betriebssystemen oder Auflösungen.
Firefox  |
Opera |
|---|---|
 |
 |
| Eine bestimmte Internetseite im Browser Firefox unterm Betriebssystem (OS) Windows xp bei einer Auslösung von 1280 x 1024 px. | Die selbe Seite im Browser Opera bei gleicher Auflösung und Betriebssystem. |
Netscape |
Safari   |
 |
 |
| Wieder Windows xp, nur diesmal im Browser Netscape bei einer Auflösung von 1024 x 768 px. | Nun anderes Betriebssystem: Apple Macintosh (Mac OS X 10). Browser: Safari; Auslösung: 1280 x 800 px (Widescreen); auf einem MacBook (Notebook) |
Konqueror   |
|
 |
|
| Schließlich die Site unter Linux Ubuntu im Browser Konqueror bei einer kleineren (< 1024 x 768 px) Auflösung. |
Was fällt auf?
Nichts. Und der Grund, warum diese Internetseite unabhängig von Browser, Betriebssystem oder Auflösung immer gleich dargestellt wird, ist gleichzeitig Gegenstand dieser Fachpräsentation:
Webstandards.
"To lead the World Wide Web to its full potential by developing protocols and guidelines that ensure long-term growth for the Web."
W3C, The Mission
Warum Webstandards?
Das Ziel von Webstandards ist das Zugänglichmachen einer Site für eine größtmögliche Anzahl von Benutzer mit größtmöglicher Anzahl von Browsern unter verschiedenen Plattformen; also das Verwirklichen von Massenkompatiblität: Eine Internetseite soll von möglichst vielen webfähigen Endgeräten und damit Menschen nutzbar sein.
Ein weiterer Vorteil ist die Aufwärtskompatiblität einer Site im Browser. Ist diese standardkonform, wird sie auch in zukünftigen Browserversionen korrekt dargestellt. Es ist keine überarbeitung nötig, nur weil eine neue Browserversion erschienen ist. Eine lange Lebensdauer ist die direkte Konsequenz aus diesem Sachverhalt.
Suchmaschinen- und Wartungsfreundlichkeit sind 2 weitere positive Nebeneffekte, die bei der Nutzung von Standards entstehen.
W3C
Das W3C (World Wide Web Consortium) ist das Gremium zur Standardisierung der WWW betreffenden Techniken. Gründer und Vorsitzender ist kein geringerer als Tim Berners-Lee, der Erfinder des WWW. Dieses Konsortium gibt sog. Empfehlungen aus, welche sich wie folgt charakterisieren lassen:
- Die Empfehlungen des W3C haben keine gesetzlich Gültigkeit; sind aber dennoch von hoher Verbindlichkeit. Das W3C ist keine zwischenstaatlich anerkannte Organisation wie die ISO und ist daher nicht berechtigt gesetzlich bindende Standards auszugeben. Daher redet die W3C selber auch von "Empfehlungen" statt von "Standards".
- Sie können jedoch als Quasistandards betrachtet werden.
- Die Empfehlungen sind weiterhin plattformunabhängig, was bedeutet dass die Standards gleich umsetzbar und nutzbar sind, egal welches Betriebssystem, Browser, Auslösung etc. genutzt wird (siehe Einleitung).
- Weiter sind sie patentfrei (jeder kann sie nutzen) und unparteiisch (sie bevorteilen keine Organisation, Firma oder Institution).
Nun eine Übersicht über alle bisherigen "Recommendations" des W3C:
| WCAG | XHTML | SMIL | OWL |
| XML | XML Schema | DOM | XSL |
| XSLT | RSS | CSS | XPointer |
| HTML | PNG | SVG | RDF |
| XLink | VoiceXML | XPath | XQuery |
| MathML | XForms |
Salopp gesagt, legt das W3C mit seinem Empfehlungen fest, welche Techniken, Methoden, Funktionen, Befehle, Schreibweisen etc. (im Quellcode) gültig sind und welche es nicht sind. Das mag sich im ersten Moment anmaßend anhören, bringt aber viele Vorteile, wie ich jetzt darlegen möchte:
Bedeutung
Man kann Webstandards als kleinsten gemeinsamen Nenner, oder besser als Konsens, zwischen den verschiedenen Browsern und dem Webdesigner betrachten.
Der Webdesigner auf der einen Seite hat die Gewissheit, dass seine Internetseite in allen Browsern korrekt dargestellt wird, solange er sich im Rahmen der Webstandards bewegt. Vorraussetzung dafür ist jedoch, dass auch die Browser standardskonform interpretieren/parsen. Natürlich steht es ihm frei beispielsweise HTML-Befehle zunutzen, die nicht in der HMTL 4.01-Spezifikation des W3C enthalten sind. Dieser mag auch in vielen Browsern trotzdem funktionieren, jedoch hat er nicht die Endgewissheit, da es immer noch Browser geben kann oder geben wird, die diesen Befehl nicht unterstützen. Eine Massenkompatibilität wäre damit nicht mehr gewährleistet.
Der Browser auf der anderen Seite ist gezwungen, einen festen Fundus an Code, Techniken, Befehlen etc. zu unterstützen, um standardkonform zu sein, was heutzutage eine wichtige Vorraussetzung ist, um sich auf dem Browsermarkt zu behaupten, da der Trend ganz klar zu standardkonformen Browsern und Webdesign geht.
So weit die idealisierte Theorie. In der Praxis sieht es natürlich anders aus. Denn das ganze klappt nicht, solange es einen weit verbreiteten Browser gibt, der die Standards nicht erfüllt. Die Rede ist natürlich von Microsofts Internet Explorer. Dieser ist nicht so weit verbreitet, weil er ein guter Browser ist, sondern weil er mit Windows ausgeliefert wird. Der Internet Explorer (IE) bildet bei so ziemlich allem, was soeben dargestellt wurde, die Ausnahme. Wegen des Internet Explorers ist der Webdesigner gezwungen, so genannte Browserweichen zustellen (z. B. Conditional Comments), also Befehle zu geben, die nur der Internet Explorer versteht, um dessen Standardinkonformität zu kompensieren.
Webstandards in der Praxis
Für Webdesigner gibt es Validatoren (engl. valid für gültig), z. B. für (X)HTML oder CSS. Dort kann er seinen geschriebenen Seitenquellcode auf W3C-Standardkonformität überprüfen.
In einem Validator kann der Webdesigner die Adresse seines Dokumentes eingeben, dass er validieren (auf Gültigkeit prüfen) möchte. Im Beispiel rechts ist das Dokument nicht valid aufgrund von 4 Fehlern. So wurde der marquee-Befehl verwendet, welcher aber nicht in der HTML 4.01-Spezifikation des W3C enthalten und damit ungültig ist. Weiterhin wurde das background-Attribut dort verwendet, wo es nicht zulässig ist: nämlich im td-Tag. Beseitigt der Webdesigner diese Fehler ist sein Dokument standardkonform.
Für Browser gibt es den Acid2-Test, bei dem geprüft wird, ob der Browser einen bestimmten Quellcode (größtenteils CSS) entsprechend dem Standards interpretiert und ob er mit fehlerhaften Quellcode korrekt umgeht. Besteht der Browser den Test wird das Smilie wie links dargestellt. Der Name des Tests leitet sich vom englischen Wort für scharf, bissig, beißend ab. Der Test trägt den Namen nicht zur Unrecht, da er faktisch die Browserspreu vom -weisen trennt. Bis dato (10.09.2008) haben nur 6 Browser von ca. 113 diesen Test bestanden.
Browser im Acid2-Test
Nun einige Beispiele zur Veranschaulichung (für den Screenshot vom Browser auf das Bild klicken):
| Firefox 2.0.0.1 |
Firefox 3.0 |
|---|---|
Der Mozilla Firefox (Version 2.0.0.1), hier unter Windows, bestand den Test noch nicht. Wie aber gut zu erkennen ist, ist das dargestellte Gebilde einem Smilie bereits sehr ähnlich. Grundsätzlich war der Firefox jedoch bereits in der 2er Version ein sehr standardkonformer Browser, der Webdesignern kaum Schwierigkeiten bereitete. |
Die Version 3.0 (Release: 17. Juni 2008) des Mozilla Firefox bestand dann endlich den Acid2-Test. |
| Opera 9.02 |
Navigator 7.1 |
|
Der Opera (Version 9.02) besteht den Test seit der Version 9, die im März 2006 erschien. Sehr lange Zeit war er der einzige Browser für Windows, der den Test bestand. |
Netscape (Version 7.1, unter Windows) besteht den Test, genau wie sein Nachfolger, nicht. |
| Netscape 8.1 |
Internet Explorer 5.01 |
|
Netscape (Version 8.1, unter Windows) besteht den Test ebenfalls nicht. Das entstandene Gebilde ist dem aus dem Firefox sehr ähnlich. Was daran liegt, dass beide dieselbe Rendering-Engine nutzen (Mozilla ist aus Netscape hervorgegangen).
|
Nun einen kleinen überblick über die Entwicklung des Internet Explorers.
|
| Internet Explorer 6 |
Internet Explorer 7.0.5 |
|
Version 6, die Version die ganze 5 Jahre lange die aktuelle Version des Internet Explorers war, fällt kläglich durch den Test. Und eben diese Browserversion hat jahrelang den Webdesignern das Leben schwer gemacht, da ständig Browserweichen gestellt werden mussten aufgrund der miserablen Unterstützung des CSS-Standards. Als Version 6 2001 herauskam, war die CSS 2.0-Empfehlung bereits 3 Jahre alt... Doch dazu später mehr. |
Mit Version 7 hat Microsoft dann einen ersten Schritt in Richtung Standardskompatiblität gemacht. Auch wenn sich das Ergebnis des Acid2-Testes im Vergleich zur 6er Version kaum gebessert hat. Dazu muss man einräumen, dass der Acid2-Test doch immer noch ein theoretischer Test ist. In der Praxis hat es sich gebessert. Ein erster Schritt wurde getan, der aber lange noch nicht ausreicht.
|
| Safari 2.0.4 |
Konqueror 3.5 |
|
Der erste Browser, der den Acid2-Test überhaupt bestand (seit April 2005), war der Safari unter Macintosh von Apple. |
Kurz darauf bestand auch der Konqueror unter Linux (hier Ubuntu) ab Version 3.5 den Test. |
Der Acid2-Test ist über folgenden Link zu erreichen: Acid2-Test auf Webstandards.org.
Update: Seit März 2008 gab das WaSP nun den Nachfolger des Acid2-Tests heraus: Der Acid3-Test. Dieser beschränkt sich nicht nur auf CSS, sondern prüft auch die Kompatibilität mit der DOM-Manipulation, SVG und die Einbindung von Webfonts. Bis jetzt gelang es noch keinen Browser diesen Test zubestehen.
Barrierenfreiheit
WCAG
Was WCAG ist, sagt schon ihr Name: Web Content Accessiblity Guidelines; also Richtlinien, wie man den Inhalt einer Internetseite zugänglich, - mit anderen Worten - barrierenfrei gestaltet. Sie wurde durch die Web Accessiblity Initiative (WAI), einer Arbeitgruppe der W3C, entwickelt. Im Mai 1999 wurde schließlich die bis heute aktuelle Version WCAG 1.0 verabschiedet. WCAG 2.0 ist seit April 2006 im Working-Draft-Status (der ersten von insgesamt fünf Phasen).
Was ist Barrierenfreiheit?
Nun bleibt zu klären, was eigentlich barrierenfrei bedeutet. Barrierenfreiheit beschreibt die uneingeschränkte Nutzung von Websites unabhängig von körperlichen oder technischen Möglichkeiten. Es gibt eine Reihe von körperlichen Barrieren im Internet:
Die technischen Barrieren lassen sich unter der Problematik der Mannigfaltigkeit der Ausgabegeräte und Plattformen zusammenfassen.
Barriere Sehstörung
Problem:
- Kleine Schriften und Bilder sind schlecht lesbar.
- Es kann zur Blendwirkung durch helle Flächen kommen. Z. B. kann ein komplett weißer Hintergrund manche Menschen blenden.
- Bei Farbblindheit gehen die Farbinformationen verloren.
- Bei Schriftvergrößerung* passt der Inhalt nicht mehr auf die Site. Das Design wird dabei oft auseinander gerissen und horizontales Scrollen wird nötig.
Abhilfe:
- Sehgestörte Menschen nutzen oft Vergrößerungssoftware oder
- große Monitore auf denen sie eine kleine Auflösungen fahren.
Aber viel wichtiger sind die Anforderungen, die diese Barriere an das Design einer Internetseite stellt,
-
allen voran an die Schrift:
- Die Schrift sollte groß und skalierbar sein. Dazu ist ein flexibles Design nötig, dass sich an die Größe des Inhaltsbereichs, der Fenstergröße und der Auflösung anpasst. Pixelgenaues Design ist nicht barrierenfrei.
- Schriftgrafiken sollten vermieden werden, da sie i. d. R. nicht mit der Schrift vergrößert werden können.*
- Starke Kontraste und
- klare, schnörkellose Fonts (= Schriftarten; im Internet haben sich serifenlose etabliert) erhöhen die Lesbarkeit enorm; genauso wie der
- Verzicht auf blinkende oder animierte Texte.
- Eine individuelle Farbeinstellung sollte gewährleistet bleiben. Der User sollte letztendlich über die Farbgebung von Schrift und Hintergrund entscheiden können, um sie seinen Wünschen anzupassen.
- Statt farbig sollte physisch markiert werden. Beispiel: Manche Webdesigner nutzen zur Hervorhebung eines Wortes einfach eine andere Farbe. Sieht sich nun ein Farbblinder diese Seite an, geht ihm diese Information verloren. Daher sollte physisch, also fett oder kursiv markiert werden.
Vermeidung von Captchas. Captchas sind Turing-Tests, bei denen man sich als Mensch identifizieren muss. Oft wird man, z. B. beim Eintrag in ein Gästebuch, gebeten, Zeichen von einem Bild abzutippen. Diese Funktion dient dem Spamschutz, damit nicht ein Spambot immer und immer wieder ein Eintrag macht. Manchmal fällt es schon einem Nichtsehgestörten schwer die Ziffern zu erkennen; was soll denn erst ein sehbehinderter Menschen daraus lesen? Daher sollte man Alternativen zu Captchas anbieten, wie akustische Captchas oder Rechencaptachas, bei dem man 2 Zahlen addieren muss (siehe Wikipedia).
Zusammenfassend folgende Negativbeispiele*:
|
In diesem Beispiel wurde pixelgenau designt: der Inhaltbereich und die Navigationspunkte haben eine feste Größe. Weiterhin ist die Farbe der 2ten überschrift schlecht gewählt: grau auf weißem Hintergrund ist schlichtweg unleserlich; genau wie der sinnfreie Lauftext darüber. Schließlich wurde die Textgröße des Inhalts tendenziell zu klein gewählt, so dass man gewillt ist, die Schriftvergrößerungsfunktion* des Browsers zu nutzen (Strg und + bzw -; Ansicht > Schriftgröße/Textgröße). Tut man dies mehrmals, sieht sie Site, wie rechts dargestellt aus. |
Das pixelgenaue Design wurde förmlich gesprengt und auseinander gerissen. Es kommt zur überlagerung von Texten, da bestimmte Elemente absolut positioniert wurden. Außerdem fallen die einzelnen Navigationspunkte aus den dafür vorgesehenen Rahmen. Aber den Inhaltstext kann man jetzt besser lesen... |
|
Nun ein Beispiel zu den Schriftgrafiken. Im Beispiel sind die Navigationspunkte mit Schriftgrafiken (eigentlich mit Flash, aber damit verhält es sich hier genauso) umgesetzt, wodurch eine Schriftart genutzt werden konnte, unabhängig von den installierten Font des Betrachters. Diese Schrift ist sehr gedrungen, klein und unleserlich. Wieder ist man geneigt zur Schriftskalierung* zu greifen. |
Davon abgesehen, dass wieder das Design um ein "komisches Etwas" rechts erweitert wird, lassen sich die Navigationspunkte nicht mit vergrößern. Sie bleiben unleserlich und damit eine Barriere. |
Hier nun die bekannten Logos von Google und ebay, wie sie ein Rot-Grün-, ein Blau-Gelb- und ein komplett Farbblinder sehen würde:
| Normal: |  |
 |
|---|---|---|
| Rot/Grün-Blindheit: |  |
 |
| Blau/Gelb-Blindheit: |  |
 |
| Farbblindheit: |  |
 |
Das gleiche, aber nun an einer kompletten Internetpräsenz. Man beachte besonders die Veränderung an der Fotografie.
| Normal: | Blau/Gelb-Blindheit: | Farbblindheit: |
|---|---|---|
 |
 |
 |
Es fällt auf, wie stark die ursprünglichen Farbinformationen verfälscht oder gar verloren gehen.
Barriere Blindheit
Problem: Keine visuelle Wahrnehmung. Das bedeutet konkret:
- Blinde können generell, ob nun mit oder ohne Hilfsmittel, keine Bilder wahrnehmen
- Text am Monitor können sie nicht erkennen.
Abhilfe: Blinde nutzen sog. Screenreader. Das sind Bildschirmausleseprogramme, die den dargestellten Text erfassen und ausgeben können. Diese Screenreader können keine Bilder, Animationen, Videos, Flash-, Javascript-, Java-Applikation oder CSS erkennen und umsetzten, sondern nur reinen Text. Es gibt 2 Möglichkeiten der Ausgabe:
- Der Text wird in einer Braille-Zeile in Blindenschrift ausgeben.
- Automatische Sprachausgabe. Der Text wird dem Blinden vorgelesen.
Anforderung:
- Die Site sollte über eine sinnvolle Struktur und Gliederung verfügen. Man sollte mit überschrifthierarchien (h1, h2, h3...), Absätzen, Listen u. s. w. arbeiten. Dabei ist der semantisch korrekte Einsatz der strukturierenden HTML-Tag notwendig. Will man eine überschrift setzten, sollte man auch das dafür vorgesehene h1-Tag verwenden, und nicht eine div-box mittel CSS-Formatierung wie ein überschrift aussehen lassen. Screenreader erkennen nämlich kein CSS und für diesen würde diese Textzeile wie ganz normaler Text aussehen und nicht wie eine überschrift. Merke: Screenreader unterstützen kein CSS, wohl aber HTML.
- Des Weiteren sollten aussagekräftige Alt-Attribute für Bilder, Videos, Animationen und Hyperlinks gesetzt werden. Dieser Text wird dargestellt, wenn beispielsweise das Bild nicht dargestellt werden kann - also bei Screenreadern immer. Präsentationsgrafiken sollten ein leeres Alt-Attribute (alt=""; nicht gar keins!) besitzen; Grafiken mit informativen Wert dagegen schon. Auch sind Schriftgrafiken in den meisten Fällen entbehrlich, da sie durch Screenreader einfach nicht dargestellt werden und damit von Blinden nicht erfasst werden können. Wenn man sie schon nutzt, dann mit einem entsprechendem Alt-Attribut.
- Durch Trennung von Inhalt und Design (nähere Erklärung siehe Plattform) hat der Screenreader eine entschlankte Datei mit nichts anderem als dem Inhalt zu parsen und auszugeben.
-
Schließlich sind die Meta-Informationen, die Informationen, die jedem *.html-Dokument mitgegeben werden, aber nicht dargestellt werden, ebenso wichtig. Durch sie erfährt der Screenreader z. B., welche Sprache nun folgt (
<html lang="de">oder Open Graph Metadaten).
Es gilt folgende Regel: Ist eine Internetseite in einem Textbrowser "zumutbar" und "browsbar" ist sie es auch für Blinde mit Screenreadern. Textbrowser unterstützen genau wie Screenreader weder CSS noch Bilder, Javascript, Java oder Flash. Zur Veranschaulichung nun zwei Seiten im Textbrowser:
|
Kennen sie diese Site? Mit Sicherheit, nur haben sie Google noch nie in einem Textbrowser betrachtet: ganz ohne CSS, Bilder & Co. Statt dem Bild wurde der Alt-Text "Google" angezeigt. |
Hier ist eben das Dokument, was sie gerade betrachten im Textbrowser dargestellt. Man sieht sehr gut, wie wichtig, das Strukturieren des Inhalts mittels HTML-Tags ist. Im Screenshot sind sowohl nummerierte als auch ungeordnete Listen, überschriften, Absätze, Links etc. zu sehen. Diese und nur diese Informationen erhält somit auch ein Screenreader und gibt sie an dem blinden Nutzer weiter. |
Die Screenshot wurden im bekannten Textbrowser Lynx gemacht. Für den Fall, dass Sie sich selber an diesem Browser versuchen wollen, haben ich ihn zum Download bereitgestellt: Download Lynx (586 KB).
Barriere motorische Störungen
Problem:
- Genaue Mausbewegungen und -klicks sind nur schwer auszuführen (z. B. bei spastischen Anfällen)
- Kleine Schaltflächen sind bei eingeschränkter Feinmotorik schwierig "zutreffen".
- Javascript- und Flash-Funktionen bereiten gerade solchen Menschen große Probleme. So wird gerade Flash sehr animationslästig und interaktivempfindlich genutzt. Motorisch behinderte Menschen haben mit solchen Sites große Probleme.
Abhilfe:
- Bei stark eingeschränkter Feinmotorik (z. B. bei Spastik) wird eine Navigation per Maus unmöglich. Stattdessen wird die Tastatur zum Navigieren genutzt. Dabei springt man mittel der Tabulator-Taste von Link zu Link und bestätigt diesen mit Enter.
- Spezialtastaturen und -mäuse werden auch genutzt, um Sites trotz eingeschränkter Motorik nutzen zu können.
Anforderung:
- Logische Tabulatoren-Reihenfolge. Die Reihenfolge, in der von Link zu Link gesprungen wird, sollte logisch und plausibel sein.
- Für Menschen mit geringeren motorischen Einschränkungen, die trotzdem noch eine Maus nutzen, sollten größere Schaltflächen genutzt werden. Solche sind einfach "besser zu treffen".
- Sofern Pullout-Navigationen genutzt werden sollten diese zeitverzögert sein, damit sich der Nutzer erlauben kann, auch mal vom Fenster "abzurutschen".
- Aus dem beiden eben genannten Gründen sollte auch auf unnötige Javascript-, Flash- oder Java-Spielerei verzichtet werden.
- Die Nutzung des Doppelklicks sollte nie verlangt werden.
Barriere Gehörlosigkeit
Problem:
- Keine akustische Wahrnehmung
Anforderung:
- Keine akustischen Informationen verwenden. Natürlich kann man auch weiterhin Musik oder Töne nutzen, diese sollten jedoch keinen Informationsgehalt haben, sodass durch das Nichthören dieser keine Nachteile entstehen.
- Videos in Gebärdensprache anbieten...
- Texte und Bilder verwenden um Informationen zu vermitteln.
Generell treffen Gehörlose im Internet jedoch auf wenige Barrieren, da das WWW einfach ein größtenteils visuell wahrgenommenes Medium ist.
Barriere kognitive Behinderung
Problem:
- Verstehen von langen, umständlich formulierten Texten (Schachtelsätze etc.).
- Komplexe Navigationen
Anforderung:
- Website in "leichter" und richtiger Sprache gestalten. Praktisch bedeutet dass u. a.: im Aktiv statt passiv zu schreiben, Groß- und Kleinschreibung beachten, unnötige Füll-, Fremdwörter, Abkürzungen oder Akronyme vermeiden, um das Lesen so angenehm wie möglich zu machen.
- Plausible Navigationen. Dazu einige Beispiele zur Illustration:
Barriere Plattform
Problem:
- Abhängigkeit der Darstellung von der Plattform. Die Erscheinung einer Site variiert je nach verwendeter Hard- und Software. Also konkret: welcher Monitor genutzt wird, welche Auslösung gefahren wird, ob man mit Handy oder PDA ins Internet geht, welches Betriebssystem genutzt wird, welche Farbpalette dort installiert ist, - natürlich - welchen Browser man nutzt, welche Plugins dort installiert sind (z. B. Flash-Plugin) und schließlich welche Browserversion verwendet wird. Geh ich mit einer veralteten Version ins WWW oder mit der brandaktuellen? Die Darstellung hängt wesentlich von diesen Faktoren hab.
- Ein weiteres "Problem" ist, dass mobile Geräte häufig kein CSS unterstützen, da auf den kleinen Displays einfach nicht genug Platz vorhanden ist.
-
Trennung von Inhalt und Design
- HTML, gerade zur Anfangszeit des WWW oft zur Formatierung zweckentfremdet, dient allein der Strukturierung des Inhalts. Folglich steht in der *.html-Datei nur der strukturierte Inhalt: Man bestimmt, welche Bereiche Inhalt und Navigation sind, was der erste Navigationspunkt ist, die überschriften, der erste Absatz im Inhalt, der zweite, dort eine Liste u. s. w.; man verleiht seinen Inhalten Struktur.
- Mit CSS schließlich erfolgt das Designen, Layouten, Positionieren der HTML-Elemente und das Einbinden der Präsentionsgrafiken, also Grafiken, die keinen informativen Wert haben, sondern einfach nur gut aussehen sollen.
Außerdem können mobile Geräte wesentlich schneller arbeiten. Da sie kein CSS interpretieren, wird nur der reine Inhalt geladen, was zu kurzen Ladezeiten führt.
Bei Designänderungen schließlich ist es nur nötig, die eine *.css-Datei zu modifizieren. Stehen so Änderungen an, muss nicht jede *.html-Inhaltsdatei einzelnd geöffnet und editiert werden, sondern nur die *.css-Datei und schon sind die Veränderungen auf allen Dokumenten übernommen. - Weiterhin ist ein flexibles Layout (siehe Sehbehinderung) nötig, welches sich an Fenstergröße des Browsers und damit auch an die gefahrende Auflösung anpasst. Auch für Menschen, die eine Auflösung von 800 x 600 fahren, sollten die Site nutzen können.
- Cross-Browser-Kompatiblität bedeutet, dass eine Seite in allen gängigen Browsern korrekt dargestellt wird und nutzbar ist. Würden die Webstandards so umgesetzt, wie es die Theorie fordert, bräuchte man das eigentlich nicht: Man würde seine Site standardkonform gestalten und schon funktioniert sie in allen Browsern. Welch schöner Traum. Es ist jedoch notwendig für den standardinkompatiblen Internet Explorer Browserweichen (z. B. Conditional Comments) zu stellen, was natürlich mit einem erheblichen Mehraufwand an Zeit und damit Kosten verwunden ist. Das ist leider nötig, weil er (noch...) der am stärksten verbreitete Browser ist.
Umsetzung der Barrierenfreiheit
Die Umsetzung der Barrierenfreiheit variiert extrem stark; je nach verantwortlichen Webdesigner und/oder Institution. So gibt es in den Weiten des WWW sowohl sehr barrierenarme Seiten aber auch Sites, die eine einzige Barriere darstellen:
Z. B. sind Flashsites i. d. R. extrem barrierenvoll. Es gibt zwar seit einigen Jahren sog. accessiblity-classes, mit dem eine Flashsite auch für Screenreader zugänglich werden, die jedoch nur sehr selten genutzt werden. Was nützt die tollste Erweiterung, wenn sie zu selten genutzt wird?
Interessant ist auch, dass Webpräsenzen des Bundes barrierenfrei sein müssen. Dies wurde mit dem Behindertengleichstellungsgesetz (BGG) vom Mai 2002 gesetzlich festgelegt. So muss die Website vom Arbeitsamt barrierenfrei sein, damit auch behinderte Menschen sie nutzten können. Aus exakt dem gleichem Grund, sind vor öffentlichen Gebäuden auch Auffahren für Rollstühle: Die Gebäude müssen auch barrierenfrei sein. Analoges gilt für Internetseiten des Bundes.
"Niemand darf wegen seiner Behinderung benachteiligt werden."
Grundgesetz der Bundesrepublik Deutschland, Art. 3.3; Änderung vom Juni 1996.
Würde man diesen Absatz genau nehmen, wäre man genötigt festzustellen, dass Tag für Tag im Internet millionenmal allein in Deutschland gegen unser Grundgesetz verstoßen wird, da es unzählige Sites gibt, die behinderte Menschen nicht nutzen können. Natürlich wird dafür niemand belangt...
Häufig dreht es sich beim Thema Barrierenfreiheit beim Webdesigner um Fragen wie: "Wer macht denn das schon? Behinderte sind doch eh die Minderheit. Der Aufwand ist doch viel zu groß. ". So ist der Otto-Normal-Webdesigner froh, wenn er ein Captcha in sein Gästebuch integriert bekommt - nun soll es auch noch Alternativen dafür anbieten? Autoren von sehr zeitaufwendigen Flashseiten haben verständlicherweise nach Fertigstellung nicht mehr die Muße noch eine HTML-CSS-Version zu erstellen. Oder: Wer bietet denn schon ein Video alternativ in Gebärdensprache an? Man stelle sich das mal vor: youTube, MyVideo - dort sieht man so etwas nicht. Ich habe so etwas generell noch nie im Internet gesehen. Sie?
Und spätestens dann ist selbst der Barrierenfreiheitsympatisant an einen Punkt angekommen, wo er sagt: "Bis hier und nicht weiter". Generell ist Barrierenfreiheit etwas großartiges und wichtiges, da es viele Vorteile bringt und die eh schon von der Gesellschaft Benachteiligten die Möglichkeit gibt, das Medium Internet zu nutzen. Jedoch stehen irgendwann Kosten und Nutzen in keinem Verhältnis mehr.
Auch gilt es die Utopie von Barrierenfreiheit aufzudecken: Niemals kann ein behinderter Mensch eine Internetseite genauso, im gleichem Maße, komfortabel nutzen wie eine nichtbehinderter. Daher sollte man lieber von Barrierenarmut reden. Barrierenfreiheit ist unerreichbar - wenn auch erstrebenswert.
Wertung der Webstandards
Generell sind Webstandards eine großartige und nötige Sache, da sie das WWW standardisieren, weiter entwickeln und verbessern. Aber es gibt auch Kritikpunkte, die sich durch folgende Erscheinungsdaten veranschaulichen und belegen lassen:
| Erscheinungsdaten (Releases) | |||
|---|---|---|---|
| W3C-Standards | CSS 2.0 | 1998 | |
| WCAG 1.0 | 1999 | ||
| HTML 4.01 | 1999 | ||
| IE 6 | 2001 | Internet Explorer Version | |
| IE 7 | 2006 | ||
WCAG 1.0 und HTML 4.01, die aktuellen Versionen, sind mittlerweile ganze 8, CSS 2.0 sogar 9 Jahre alt. Das zeigt sehr gut, wie langsam das W3C in der Ausarbeitung seiner Standards ist. Und das bei einem so rasend schnell wachsenden Medium wie dem Internet, verlieren diese sehr schnell an Aktualität und werden nicht mehr zeitgemäß.
Und wenn dann doch einmal ein Standard herausgebracht wird, dauert die praktische Umsetzung und Nutzbarkeit (durch den Webdesigner) sehr lange, da die Standards erst von den Browsern unterstützt werden müssen, da das die Vorraussetzung ist, um damit als Webdesigner arbeiten zu können. Doch einmal konkret: Als der Internet Explorer 6 2001 erschien, war CSS 2.0 bereits 3 Jahre alt und eine Standardkonformität war faktisch nicht vorhanden (siehe Acid2-Test). Das demonstriert, wie wenig Bedeutung Microsoft Webstandards beigemessen hat. Doch gerade als weit verbreitester Browser hätte Microsofts Internet Explorer eigentlich die Verantwortung, Webstandards zu unterstützen um das WWW weiter zu entwickeln. Das war und ist nicht der Fall. So musste und muss der Webdesigner auf vieles Verzichten um eine Site im Internet Explorer zum Laufen zu bringen (Browserweichen etc.). Auf diese Weise lähmte der Internet Explorer die Entwicklung und Standardisierung des WWW.
Doch der Trend geht zu Standardkonformität. Das zeigt sich spätestens am steigenden Markverlust des Internet Explorer an der Browserlandschaft, was Microsoft u. a. dann zum Einlenken brachte. So erschien Ende 2006 der Internet Explorer 7, der einen ersten Schritt (nicht mehr!) in Richtung Standardskompatibilität machte.
Einen 1. Schritt nach 8 Jahren CSS 2.0...
Barrierenfreie und standardkonforme Sites bringen gleichzeitig viele weitere Vorteile:
- Sie sind suchmaschinenfreundlicher, d. h. sie werden leichter und besser durch Suchmaschinen gefunden
- Barrierenfreie Sites sind gleichzeitig benutzerfreundlich. Erhöht man beispielsweise die Lesbarkeit durch korrekte Schrift- und Farbwahl tut man gleichzeitig auch nichtbehinderten Menschen einen Gefallen.
- Sie sind wartungsfreundlicher und flexibler vor allem durch die Trennung von Inhalt und Layout.
- Bedingt durch die Aufwärtskompatiblität sind standardkonforme Sites auch zukunftssicher.
- Das alles zusammen macht eine konforme Internetpräsenz kostenschonend, was heutzutage kein unerheblicher Faktor ist.
Wir sehen also, dass die Vorteile für den Webdesigner selber überwiegen. Barrierenfreies Webdesign ist also keine allenige Frage der Barmherzigkeit, Solidarität oder Nächstenliebe. Da kann man folglich nicht verstehen, warum Webstandards nicht flächendeckend von Webdesignern umgesetzt werden. Ob das nun aus Faulheit, Gleichgültigkeit oder Ignoranz geschieht, vermag ich nicht zu sagen.
Nichtsdestotrotz bin ich ein großer Sympatisant von Webstandards, da sie das World Wide Web zu einem besseren, menschen- und massenfreundlicheren Ort machen. Sie trugen wesentlich zu Popularität des WWW bei, z. B. durch die Entwicklung von CSS, wodurch das Internet wesentlich grafischer und anschaulicher wurde. Die Zahl der Internetanschlüsse in Deutschland nimmt stetig zu und man könnte sagen: Der Erfolg gibt Recht.
Man kann froh sein, dass der Trend zu standardkonformen Browsern und Webdesign geht. Doch die Umsetzung klappt nur, wenn sowohl Browser als auch Webdesigner diese umsetzten - das was heute noch nicht in dem Maße der Fall ist, wie man sich es wünschen würde. Nur dann kann das WWW wachsen und sein "full potential" entfalten.
Damit solche Bilder der Vergangenheit angehören:
| Internet Explorer 6 ohne Browserweichen |
Internet Explorer 6 mit Browserweichen |
|---|---|
|
Das Eingangsbeispiel im Internet Explorer 6 ohne jegliche Browserweichen. Obwohl die Site W3C-Standardkonform ist, wird sie schlicht weg falsch und unästhetisch dargestellt. Und das ist noch ein erträgliches Beispiel. |
Und so ist es nötig Browserweichen zu stellen, um eine Darstellung im IE6 zu ermöglichen... |
"To lead the World Wide Web to its full potential by developing protocols and guidelines that ensure long-term growth for the Web."
W3C, The Mission
Anmerkungen:
* Schriftvergrößerung ist einer Funktion, die fast alle modernen Browser beherrschen. Es gibt 2 Varianten davon: Bei der einen wird nur die Schrift vergrößert (Firefox 2.x, Netscape), was zu den genannten Problemen führen kann und bei der anderen (Internet Explorer 7, Opera, Firefox 3+) wird einfach in die Site hineingezoomt, sodass auch Bilder größer erscheinen.