1. Webseiten müssen ohne Farbe lesbar sein und individuelle Farbeinstellungen erlauben.
2. Gebraucht wird das in der Praxis von manchen BenutzerInnen mit Sehbehinderung, die eigene Einstellungen für den Bildschirm
   wählen, weil sie z.B. sehr blendempfindlich sind.
3. Durch das Ausschalten der Farbangaben werden auch Hintergrundbilder ausgeblendet (siehe Bilder), d.h. wichtige Information darf nicht in Hintergrundbildern ohne Textalternative, die beim Wegschalten sichtbar wird (!) gegeben werden.
4. Farben sollen im CSS, nicht im HTML definiert sein, und zwar jeweils Vorder- und Hintergrundfarbe.

Farbe als Unterscheidungsmerkmal

1. Farbe darf nicht alleiniges Unterscheidungsmerkmal sein.
2. Links im Fließtext sollen auch unterstrichen oder fettgedruckt sein, nicht nur andersfarbig.
3. Pflichtfeldkennzeichnung in Formularen nicht nur mit Farbe, sondern z.B. auch mit einem * oder fettgedruckt.
4. Fehlermarkierung in Formularen nicht nur mit Farbe, sondern z.b. auch durch Umrahmung des Inputfeldes.
5. In Diagrammen oder Grafiken sollen bedeutungsunterscheidende Farben durch Muster oder Text ergänzt werden.

Gestörte Farbwahrnehmung

1. Rot-Grün Blindheit (Deuteranope oder Protanope) ist häufig und verursacht die Wahrnehmung einer beige-braunen Mischfarbe bei Rot oder Grüntönen.
2. Wenn auch die Farbhelligkeit ähnlich ist, können Rot- und Grüntöne gar nicht unterschieden werden.
3. Rotschwäche führt zur Wahrnehmung von rot als grau oder schwarz.
4. Selten ist eine Blau / Gelb Schwäche (Tritanope, orange wird dann z.B. rosa wahrgenommen, dunkelblau gräulich).
5. Es geht aber nicht um Vermeidung gewisser Farben als Designelement, sondern um Wahrung von inhaltlichen Bedeutungsunterschieden!

Farbkontraste

1. Komplementäre Farben für Hintergrund und Vordergrund flimmern und sind für Normalsichtige schwer lesbar.
2. Zu geringe Kontraste – zu geringe Unterschiede in der Farbhelligkeit und im Farbton von Text und Hintergrund machen Text schwer lesbar.
3. Laut WCAG 2.0 (Level AA) ist ein Kontrastverhältnis (contrast ratio – Messwert für den Helligkeitsunterschied) von 5:1 zwischen Text und Hintergrund nötig, bei großer Schrift (18pt oder fettgedruckt 14pt) genügt auch ein Kontrastverhältnis von 3:1 (die Kontrastscala reicht bis zu 21:1). Zur Erreichung von Level AAA ist Kontrastverhältnis von 7:1 nötig, für größeren Text 5:1.
4. Manche Menschen mit Sehbehinderung bevorzugen sehr starke Kontraste und bei Blendemfindlichkeit dunklen Hintergrund (z.b. weiß auf schwarz, weiß auf blau, gelb auf blau).
5. Das kann im Betriebsystem oder Browser eingestellt werden oder – vermutlich komfortabler – durch Zoomprogramme (wie Zoomtext oder Magic).
6. Die Auswahlmöglichkeit von invertierter Farbdarstellung auf Webseiten (durch zusätzliche Stylesheets) ist ein nettes Feature für eine bestimmte Zielgruppe, das Engagement für die Sache demonstriert, aber nicht wirklich notwendig.

Testen

1. Testen kann man Darstellung ohne Farbe im Firefox unter Extras / Einstellungen / Inhalt,
   Im IE unter Extras / Internetoptionen / Eingabehilfen.
2. Den Kontrastmodus unter Windows erreicht man schnell mittels Tastenkombination: linke Umschalttaste + linke Alttaste + Druck.
3. Für schnelles Testen ist auch Opera gut, hier gibt es einige vordefinierte Farboptionen.
4. Die Darstellung einer Seite bei Farbenblindheit kann man testen unter http://vischeck.com/.
5. Farbkontraste einer Webseite testen kann man gut mit der Firefox Extension Colour Contrast Analyser von juicystudio.
6. Einzelne Farbkombinationen analysiert der Luminosity Contrast Ratio Analyser.

aktualisiert: 18.7. 2007

Layouttabellen

1. Professionelle WebdesignerInnen kommen mittlerweile ohne Tabellen fürs Layout aus.
2. Sie schwören auf reine CSS Layouts und halten Tabellenlayouts für veraltet und unprofessionell.
3. Die Vorteile sind größere semantische Korrektheit, weniger und übersichtlicherer Quellcode und flexiblere Ausgabemöglichkeiten.
4. Tabellenlayouts sind zugegebenermaßen, wenn mans gewöhnt ist, schneller und einfacher als komplexe CSS Layouts, innerhalb von float Layouts sind Layouttabellen manchmal auch sicherer und einfacher als weitere float Konstruktionen.
5. Tabellen werden auch bei HTML Newslettern noch angeraten, weil die gängigen E-Mail Programme sehr unterschiedliche CSS Unterstützung haben.
6. Layouttabellen sind zugänglich mit Screen-Readern und anderen assistiven Technologien, wenn sie linear, d.h Zeile für Zeile, Zelle für Zelle lesbar sind.
7. Das kann man z.b. überprüfen mit dem Webformator, mit der Webdeveloper Toolbar im Firefox oder im Opera unter Seitendarstellung / Tabellen deaktivieren.
8. Layouttabellen sind in den WCAG 1.0 und auch in WCAG 2.0 nicht verboten, werden aber für neue Webseiten nicht empfohlen.
9. Probleme bereiten Layouttabellen Screen-Reader Usern, wenn sie sehr verschachtelt sind,
10. …wenn es innerhalb der Tabellen keinen ansteuerbaren Markup gibt (wie Absätze, Überschriften, Listen),
11. …wenn es zusätzlich komplexe Datentabellen gibt.
12. Laut einem Kommentar in der WCAG 2.0 Entwurfsversion (Kommentar LC-674) dürften Layouttabellen nicht mehr als 4 Ebenen verschachtelt sein (finde ich kurios) und nicht mehr als 4 Zeilen oder 4 Spalten haben. Eine offizielle Empfehlung gibt es dazu nicht, weil die Verwendung von Layouttabellen nicht mehr gefördert werden soll.
13. Layouttabellen dürfen keine Strukturelemente für Datentabellen enthalten (wie th, caption, headers, scope, summary)
14. Die Barrierefreiheit von Content Management Systemen misst sich u.a. auch am standardkonformen Output ohne Tabellen.
15. Blog Systeme wie WordPress sind hier Vorreiter.
16. Bei Typo3 ermöglicht die Extension “CSS styled Content” die tabellenlose Einbindung von Bildern, teilweise sind auch Anpassungen in Extension Templates (z.B. für News oder Suche) oder durch Überschreiben vom Standardcode in Typoscript nötig.
17. Die Einbindung einzelner Module mittels Tabellen in Joomla kann durch Änderungen im Core-Code oder mithilfe des “tJ Accessibility Patches” korrigiert werden.

Datentabellen

1. Datentabellen benötigen zumindestens table headers (th).
2. Wenn Datentabellen umfangreich und komplexer sind, brauchen sie auch thead, tfoot, tbody, col, colgroup und die Attribute für Tabellenzellen scope oder headers.
3. Wenn nicht aus dem Kontext bereits ganz klar ist, was sie beinhalten, auch caption und summary.
4. Screen-Reader haben einen Tabellenlesemodus, der diese Strukturinformationen ausliest.
5. Durch scope oder headers mit id wird eine exakte Zuordnung von Spalten- und Zeilenüberschriften zu einzelnen Inhaltszellen gegeben (das ist wichtig, um den Überblick zu bewahren, weil eine Braille-Zeile nur eine geringe Anzahl von Zeichen auf einmal darstellt).
6. Beispiele für Datentabellen gibt es auf der W3C Seite.

Allgemeines

1. Tabellen sollen keine fixen Größenwerte im HTML Code beinhalten.
2. Fixe Größenangaben – besonders im HTML Code – sind schlecht für User mit Sehbehinderung, die sich ihre Bildschirmanzeige umstellen, z.b. auf Kontrastmodus mit schwarzem Hintergrund und größerer Schrift.
3. Ausprobieren kann man das unter Windows u.a. unter Systemsteuerung / Eingabehilfen / Anzeige.

1. Formularfelder brauchen labels, komplexere Formulare auch fieldset und legend.
2. Labels sollen vor dem Formularfeld stehen.
3. Positionierung von Text und Formularfeldern mit CSS float in label, p oder div, möglichst nicht mit Layouttabellen.
4. Jedes Formular (auch ein einfaches Suchfeld) braucht einen Submitbutton.
5. Kennzeichnung von Pflichtfeldern vor dem Formularfeld.
6. Definition von Pflichtfeldkennzeichnung vor dem Formular.
7. Pflichtfelder und Fehler nicht allein durch Farbe kennzeichnen (sondern auch mit Symbol, Fettdruck etc.)
8. Fehlermeldungen idealerweise gesammelt vor dem Formular mit Verlinkung zum jeweils fehlerhaften Inputfeld.
9. Zusätzliche optische Kennzeichnung des fehlerhaft gefüllten Inputfelds.
10. Vorbelegung von Formularfeldern wird nicht mehr für nötig befunden, wenn man sie macht, muss sie bei Focus gelöscht werden.
11. Formulare müssen tastaturbedienbar sein (mit Tabulator, Eingabe-, Leertaste)
12. Tabindex ist im Normalfall nicht nötig, lineare Tabreihenfolge muss gegeben sein.
13. Vorsicht beim onchange Event-Handler (siehe Javascript)
14. Formulare sollen sich ohne Javascript absenden lassen.
15. Grafische Captchas sind nicht screenreadertauglich.
16. Bei Eingabe wichtiger Daten, bei Finanztransaktionen…. ist vor Abschicken eine Zusammenfassung und Korrekturmöglichkeit der Daten notwendig.

1. Webseiten müssen ohne Stylesheets gelesen werden können.
2. Prüfen kann man das leicht durch Wegschalten des CSS im Firefox (Ansicht / Webseitenstil) oder mit der Webdeveloper Toolbar.
3. Idealerweise bleibt eine lineare HTML Version übrig (keine Layouttabellen).
4. Keine Formatangaben (z.b. font, bgcolor, b, i, Hintergrund, Schriftfarbe…) im HTML, möglichst keine Inline Styles, sondern externe Stylesheets.
5. Vorsicht bei Wysiwyg Editoren in CMS! Unerlaubte Formatierungsmöglichkeiten für RedakteurInnen ausblenden.
6. Vorsicht bei Image Replacement Techniken (siehe Bilder).
7. Linkmarkierung für mouseover a:hover auch für TastaturbenutzerInnen sichtbar machen mit a:focus, a:active.
8. Jeweils Hintergrund und Vordergrundfarben definieren.
9. Für media aural und handheld gibt es noch zu wenig bzw. sehr unterschiedliche Unterstützung.
10. Ein print.css, das die Navigation ausblendet, sollte selbstverständlich sein.
11. Styleswitcher: Verschiedene CSS auf Webseiten zur Auswahl – z.B. Farb-, Kontrastvarianten – sind nette Features, UserInnen, die sie wirklich brauchen, verwenden aber vermutlich Zoomsoftware (die Seiten auch mit Farbfiltern versehen kann) oder individuelle Benutzereinstellungen, weil sie Farb- oder Kontrastanpassungen im normalen Computeralltag auch benötigen.
12. Manche UserInnen mit starker Sehbehinderung schätzen eigens für sie gestaltete einspaltige Versionen mit größerer Schrift und nicht blendendem Hintergrund, die sich sehr groß skalieren lassen. Andere wiederum bevorzugen die “normale” grafische Version zur Gesamtorientierung und scrollen lieber quer beim Zoomen.
13. Screenreader interpretieren CSS auch. Mit display:none oder visibility:hidden versteckte Teile zeigen auch Screenreader nicht. Für Navigationsunterstützung (Sprungmarken, unsichtbare Headlines) gibts derzeit nur die alle ProgrammiererInnen schmerzende Lösung, sie mit Minuswerten außerhalb des Bildschirms zu positionieren.
14. Info auf der W3C Seite: Accessibility Features von CSS.

1. Frames sind veraltet, kein Profi braucht sie mehr, viele Gründe sprechen gegen sie, sie sind aber im Prinzip nicht unzugänglich.
2. d.h. 3 Frames auf einer Seite sind theoretisch zugänglich, 17 verschachtelte Frames nicht.
3. Iframes sind erlaubt.
4. Frames, auch Iframes brauchen title und noframes Section.
5. title ist wichtig für ScreenreaderbenutzerInnen, Virgo (mit Webformator) zeigt alle Frames auf einer Seite, Jaws, IBM Homepagereader immer nur einen Frame auf einmal.
6. Manche blinde UserInnen schätzen Frames sogar, weil sie eine Seite in mehrere überschaubareTeile aufsplitten.
7. Schriftvergrößerung muss möglich sein, ohne dass Inhalte verschwinden.

1. Sprachauszeichnung von fremdsprachigen Begriffen macht man mit dem Attribut lang und xml:lang in umgebendem HTML Element (span, div, h1…, p, a etc.)
2. Gebraucht wird das für richtiges Vorlesen durch die synthetische Sprachausgabe von Screenreadern oder Zoomsoftware.
3. In HTML lang, in XHTML lang + xml:lang Attribute
4. Betrifft laut WCAG 1.0 strenggenommen auch gebräuchliche Wörter wie Home, Webdesign, Email
5. Hybride (z.B. downloaden) und zusammengesetzte Wörter nicht kennzeichnen, sie sind so nicht im fremdsprachigen Wörterbuch der Sprachausgabe enthalten. Site Map müsste auseinandergeschrieben werden, wie im Englischen üblich.
6. die Sprachausgabe des Screenreaders macht eine kurze Pause vor dem Umschalten der Sprache (bei automatischer Spracherkennung, die auch ausgeschalten werden kann). Manche BenutzerInnen stört das, sie lassen sich deshalb lieber alles auf deutsch und fehlerhaft vorlesen.
7. In der Entwurfsfassung der WCAG 2.0 ist Sprachauszeichnung kein Level A Kriterium mehr und nur noch für Phrasen, nicht mehr für einzelne gebräuchliche Fremdwörter vorgeschrieben.
8. In Typo3 gibts eine Extension, die auch für Sprachauszeichnung verwendet werden kann, in WordPress bislang kein offizielles Plugin, aber individuelle Lösungen.
9. Bisheriges AAA Kriterium: Machen Sie die vorherrschende natürliche Sprache des Dokuments kenntlich, wird zukünftig A Level: das heißt lang und xml:lang Attribut im html tag.

1. Wichtige Funktionen einer Seite müssen laut WCAG 1.0 (Level A) ohne Javascript bedienbar sein.
2. Formuare müssen sich absenden lassen, wenn Fehlercheck via Javascript nicht funktioniert, Fehlerabfrage also besser auch serverseitig.
3. Browserabfragen dürfen nicht das Aufrufen der Seite verhindern, wenn Javascript abgeschalten ist.
4. Menüs sollen nicht javascriptabhängig sein.
5. Seiteninhalte sollten nicht on the fly erstellt werden.
6. “javascript:…” soll bei wichtigen Funktionen nicht als Ziel (href) eines Links verwendet werden.
7. Moderne Screenreader interpretieren Javascript, allerdings nicht vollständig, komplexere Scripts müssen getestet werden.
8. In den WCAG 2.0 gilt Javascript grundsätzlich als zugänglich programmierbar.
9. Abgeschaltenes Javascript ist damit ein Sicherheitsthema, kein Accessibilitythema mehr.
10. Zugänglich heißt: Javascriptfunktionen müssen auch mit der Tastatur bedienbar sein.
11. Event-Handler sollen also (für mehr als rein grafische Effekte) nicht mausabhängig sein (wie z.B. onmouseover, onmouseout).
12. Logische Event-Handler (auch tastaturbedienbar) sind onfocus, onblur, onsubmit, onselect.
13. onclick ist nur bei Links tastaturbedienbar.
14. Vorsicht beim onchange Event-Handler: onchange (z.B. zum Aufrufen neuer Seiten bei Auswahllisten) ist im Firefox tastaturbedienbar, im Internet Explorer (und damit auch mit gängigen Screenreadern) im Normalfall nicht, dort kann es nur mit der Maus bedient werden, weil mit Tastatur sofort beim ersten Eintragwechsel der Befehl ausgeführt wird.
15. Mit der Tastenkombination alt + Pfeil nach unten sind Auswahllisten aufklappbar, onchange also auch im IE tastaturbedienbar. Diese Tastenkombination ist aber den meisten UserInnen nicht bekannt.
16. Mit dem Webformator ist onchange auch bedienbar.
17. Zugänglich heißt weiters: Die UserInnen müssen die Kontrolle über Änderungen haben.
18. Ajax Lösungen, wo Seiteninhalte verändert werden, ohne dass die Seite neu geladen wird, sind nach derzeitigem Stand der Technik und Hilfsmittelunterstützung nicht screenreadertauglich
19. Für Ajax gibt es bislang nur Fallbacklösungen und unzureichende Hackversuche, um Seiten für Screenreader neu zu laden bei Datenänderung bzw. die nötige Information diesbezüglich zu liefern
20. Eine lesenswertes Tutorial zu barrierefreiem Javascript: http://ichwill.net

aktualisiert am 18.7. 2007

Textalternativen

1. alt Attribut bei Bildern ist allgemeiner Webstandard, Screen-Reader BenutzerInnen brauchen den Alternativtext.
2. Screen-Reader kündigen beim Vorlesen Bilder an mit: Grafik (im strukturierten Modus zeigt es auch die Braille Zeile an??).
3. Inhaltlich wichtige Bilder mit Beschreibung, so kurz und aussagekräftig wie möglich.
4. Keine redundante Information (z.b. gleiche Info in alt und title und Bildunterschrift oder alt=“Bild:Beschreibung vom Bild“).
5. Ausblendung des ev. störenden Tooltipps bei mouseover im Internet Explorer erreicht man durch leeren title=”".
6. Verlinkte Bilder benötigen unbedingt alt Attribut mit Angabe des Linkziels. Ziel des Links soll zuerst im alt stehen, ev. zusätzlich Bildinfo.
7. title Attribut ist by default ausgeschalten in Screen-Readern, deshalb keine zentral wichtige Info in title.
8. Verstecken von © Angaben im alt ist eine missbräuchliche Verwendung, es genügt nicht dem Copyright und nützt Screen-Reader BenutzerInnen nichts.
9. Platzhalterbilder (spacer.gifs, wenn man sie noch nötig hat…) und ev. auch inhaltlich unwichtige Bilder mit leerem alt=““, damit sie von Screen-Readern ignoriert werden können.
10. Inhaltlich nicht wichtige Icons neben Textlinks und grafische Listenpunkte besser im CSS definieren, ansonsten mit leerem alt=”"

Optimierung für Menschen mit Sehschwächen

1. Textgrafiken wenn möglich vermeiden, weil sie beim Zoomen schlecht lesbar sind.
2. Text in Grafikform muss zumindestens groß und gut lesbar sein und sollte ein alt Attribut haben.
3. Vorsicht bei Image Replacement Techniken (d.h. Auslagerung von Bildern als Hintergrundbilder ins CSS + verstecktem Text). Verstecken von Text mit display:none ist nicht screen-reader-tauglich. Für Screen-Reader kann die Textinformation gegeben werden, in dem man sie außerhalb des Viewports positioniert (z.B. left:-1000px;) und damit grafisch versteckt.

   Menschen mit Sehbehinderungen, die nicht Zoomsoftware verwenden, sondern die Benutzereinstellungen im Browser verändern (z.b. den Kontrastmodus von Windows verwenden oder Farbinformationen wegschalten – unter Extras / Internetoptionen / Eingabehilfen) schalten damit Hintergrundbilder aus. Sie verlieren durch das aus dem Sichtfeldschieben des Textes jede Information.

   Text sollte für diese Zielgruppe besser unterhalb des Hintergrundbildes versteckt werden, in gleicher Farbe wie Hintergrund (gibt Validierungsfehler) oder außerhalb des zugehörigen Containers.

4. Textgrafiken besser nicht mit transparentem Hintergrund abspeichern, bzw. kontrollieren, ob man sie im Kontrastmodus (z.b. auf schwarzem Hintergrund) noch lesen kann.
   Kontrastmodus testen kann man mit Windows unter Systemsteuerung / Eingabehilfen / Anzeige. Im Opera auch sehr gut im Benutzermodus.

Optimierung für Menschen mit motorischen Einschränkungen

1. Verlinkte Bilder / Icons sollten groß genug sein, ev. transparenten Rahmen rundherum lassen, damit die Klickfläche größer wird.