Der Internetauftritt der Bahnhofsmission hat mich einige Tage beschäftigt. Anlass war die Klage meiner taubblinden Bekannten Marina Pompe, die wegen gravierender Mängel der Website der Bahnhofsmission nicht an dringend benötigte Informationen kam. Siehe M. Pompes Artikel dazu auf www.tbl-welt.de. Die Leitung der Bahnhofsmission stellte sich leider taub für die begründeten Anliegen ihrer eigenen Klientel. Eine ganze Reihe von E-Mails blieb unbeantwortet und unbearbeitet. Sogar eine Mängelanzeige des AbI-Projekts wurde schlicht ignoriert.
Mit so viel Ignoranz konnte und wollte ich mich nicht zufrieden geben. Ich wollte meiner taubblinden Bekannten bei Ihrem Bemühen helfen, sich ein klein wenig Selbständigkeit zurück zu erobern.

Offener Brief

Ich griff zu einer Maßnahme, die mir nicht leicht fiel: Ein offener Brief an die Leitung der Bahnhofsmission (den ich in Kopie natürlich auch per E-Mail an die Adressaten schickte).
Und siehe da: plötzlich klappte es mit der Kommunikation. Herr B., einer der Angeschriebenen, antwortete. Und beklagte sich zuerst einmal über die Tatsache, dass

… Organisationen, die nicht oder (wie in unserem Fall) nicht umgehend reagieren, in Foren, Blogs etc. sehr schnell an den virtuellen Pranger gestellt [werden]

“Nicht umgehend"? Die nicht beantwortete Mängelanzeige des AbI-Projekts datiert vor dem November 2009. Auf M. Pompes und meine Mails kam über zwei Wochen keinerlei Reaktion, nicht einmal eine Eingangsbestätigung.
Nein, Herr B. Sie haben keinen Grund, sich zu beklagen. Mit Ihrer Methode, auf Anfragen und wohlmeinende Hinweise per E-Mail schlichtweg nicht zu reagieren, rechtfertigen Sie nachträglich das, was Sie selbst virtuellen Pranger nennen. Es scheint leider die einzige Möglichkeit zu sein, Bitten oder Vorschläge an Sie heranzutragen.

Flurschaden

Herr B. schrieb weiter:

… führt aber u.U. zu einem dauerhaften Flurschaden, wenn einschlägige Beiträge nicht wieder entfernt werden.

Nein, Herr B., Sie verwechseln da etwas. Der Flurschaden besteht bereits. Auf Ihrem Internetauftritt. Und die “einschlägigen Beiträge” wurden in der Absicht erstellt, diesen Flurschaden zu begrenzen.

Ein Lichtblick

Zwei von drei der konkret angesprochenen Mängel wurden inzwischen behoben. Der Aufwand für diese Nachbesserung betrug mit Sicherheit nur einen Bruchteil des Aufwands, den ich in meine Bemühungen investiert habe, mit der Bahnhofsmission in Dialog zu treten.
Bei dieser Gelegenheit gilt mein besonderer Dank Eva Papst, die mein Vorhaben mit einem eigenen Blogbeitrag und mehreren E-Mails an die Bahnhofsmission unterstützt hat.

Konferenz für Kirchliche Bahnhofsmission in Deutschland
Bundesarbeitsgemeinschaft der Katholischen Bahnhofsmissionen in Deutschland
Verband der Deutschen Evangelischen Bahnhofsmission e.V.

Herrn Christian Baron
Frau Dr. Gisela Sauter-Ackermann
Herrn Christian Bakemeier

Kopie geht per E-Mail an:
bundesgeschaeftsstelle @bahnhofsmission.de
gisela.sauter-ackermann@bahnhofsmission.de
bakemeier@diakonie.de

Sehr geehrte Damen und Herren,

vor einiger Zeit wurde ich von einer taubblinden Bekannten darauf aufmerksam gemacht, dass Ihr Internetauftritt www.bahnhofsmission.de für blinde und sehbehinderte Menschen nicht bedienbar ist. Um an die benötigten Informationen zu gelangen, hat meine Bekannte eine E-Mail an Ihre Geschäftsstelle geschickt, mit der Bitte, ihr die Adressdaten der einzelnen Bahnhofsmissionen mitzuteilen. Da die E-Mail meiner Bekannten unbeantwortet blieb, versuchte auch ich, per E-Mail an die auf Ihrer Webseite genannte Adresse Ihrer Geschäftsstelle Kontakt mit Ihnen aufzunehmen.
Auch diese E-Mail blieb ohne Antwort.

Aus diesem Grund wähle ich nun den Weg über einen offenen Brief.

Auf www.bahnhofsmission.de ist zu lesen:

Wir geben Auskünfte und unterstützen Sie bei Verständigungsschwierigkeiten.
Zum Beispiel wenn Sie gehörlos sind, schwerhörig, blind, seh- oder sprachbehindert. …

Ihr Webauftritt missachtet diesen Anspruch leider auf geradezu eklatante Weise. Insbesondere blinde oder sehbehinderte Menschen, die Webseiten mit Zusatzprogrammen lesen, können die auf Ihren Webseiten angebotenen Informationen wegen handwerklicher Fehler bei der Erstellung der Seiten nicht nutzen.

Solche Fehler können aus Unwissenheit und Unkenntnis der erforderlichen Techniken entstehen, und wären dann korrigierbar und entschuldbar. Oder sollte es sich im vorliegenden Fall nicht um Unwissenheit handeln, sondern um Desinteresse? Desinteresse für die Bedürfnisse der eigenen Klientel?
Wie anders sonst wäre folgendes zu erklären:
Das AbI-Projekt hat eine Meldestelle für erkannte Webbarrieren eingerichtet, informiert Seitenbetreiber über erkannte Barrieren, und bietet Hilfestellung zur Behebung dieser Barrieren. AbI-Projekt hat Sie auf die Barrieren aufmerksam gemacht - ohne Erfolg. Nachzulesen auf www.webbarrieren.wob11.de/annahmeverweigert.html

Gerne wäre auch ich bereit, detaillierte Hinweise auf die schlimmsten Mängel des Webauftritts zu geben, und Wege aufzuzeigen, wie die gravierendsten Schwachstellen möglichst schnell beseitigt werden könnten. Vielleicht kann meine taubblinde Bekannte dann vor Ihrer nächsten Bahnfahrt selbst die Bahnhofsmission kontaktieren, um die Assistenz der vielen freundlichen Helfer vor Ort in Anspruch nehmen zu können.

mit freundlichen Grüßen

Fritz Weisshart
webdesign weisshart
Dipl.-Ing.(FH) Fritz Weisshart & Co. GbR

Anhang:
Unter anderem auf folgenden Internetseiten wurde kürzlich über die Mängel auf Ihrer Webseite berichtet:

• Bahnhofsmission - wie zugänglich ist sie?
• Die Narren sind los - ich auch!
  Praktische Erfahrungen mit dem Webauftritt der Bahnhofsmission
• Barrieren im Web - Annahme verweigert
• Mission Bahnhofsmission
• Barrierefreiheit ist kein Spiel

Nachtrag 16.02.
Es ist sicher nicht schön, wenn man quasi an den virtuellen Pranger gestellt wird. So empfand es auch einer der Adressaten dieses offenen Briefes. Und sanktioniert gleichzeitig mit seiner Antwort, die heute eingegangen ist, sowie einer ersten Notmaßnahme, diese von mir gewählte Methode. Zwei Wochen nach dem Versand mehrerer E-Mails nicht einmal eine Empfangsbestätigung zu schicken, rechtfertigt Versuche, auf andere Art in Kontakt zu kommen. Es widerspricht jeglicher Erfahrung, nach zwei Wochen noch Antwort auf eine E-Mail zu erwarten.
Positiv: Die falschen Verlinkungen zu den Adressen der einzelnen Missionen in der Textversion (siehe Eva Papsts Blog) wurden korrigiert. Damit kann zumindest jemand, der die nichtöffentliche Adresse der Textversion kennt, nach Adressen recherchieren.
Hier noch einmal die Adresse: http://www.bahnhofsmission.de/bahn/html/home/index_text.php
Warum “nichtöffentlich"? Weil diese Adresse per CSS display:none vor ALLEN Seitenbesuchern versteckt ist. Also sowohl vor sehenden Besuchern, als auch vor blinden und sehbehinderten Usern, die auf Screen Reader angewiesen sind.

Die Bahnhofsmission hätte wirklich Grund, ihren Webauftritt barrierefrei zu gestalten. Der eigene Anspruch (Zitat):

Wir geben Auskünfte und unterstützen Sie bei Verständigungsschwierigkeiten. Zum Beispiel wenn Sie gehörlos sind, schwerhörig, blind, seh- oder sprachbehindert.

Leider ist der Internetauftritt der Bahnhofsmission ein Muster an Unzugänglichkeit. Praktisch alle Fehler, die man nur machen kann, wurden auf der Site auch umgesetzt.
Siehe dazu Eva Papsts Blog und mein eigener Beitrag

Nun muss ich feststellen, dass die Bahnhofsmission wohl auch beratungsresistent ist:
Das Aktionsbündnis für barrierefreie Informationstechnik, ein Zusammenschluss von Behindertenverbänden und Experten für barrierefreie Informationstechnik, hat eine Meldestelle für Webbarrieren eingerichtet. Und nun finde ich, dass die Bahnhofsmission von dieser Meldestelle bereits auf die Mängel hingewiesen wurde, sich aber leider beratungsresistent zeigt.
Hier die Liste beratungsresistenter Seitenbetreiber
Dass die Bahnhofsmission sich damit auf eine Stufe mit Burgerking, musicload.de, Lidl & Co. stellt, macht einfach nur traurig.

Es gibt Seiten im Web, die sollten sich nun wirklich mit dem Thema Barrierefreiheit auseinandersetzen.
Die Bahnhofsmission gehört dazu.
Zitat auf der Seite:

Wir geben Auskünfte und unterstützen Sie bei Verständigungsschwierigkeiten. Zum Beispiel wenn Sie gehörlos sind, schwerhörig, blind, seh- oder sprachbehindert.

Hier sollten also unter anderem blinde oder sehbehinderte Benutzer Hilfe finden. Zum Beispiel Kontaktadressen.

Ich habe einer blinden Bekannten die Aufgabe gestellt, auf diesen Seiten die Telefonnummer der Bahnhofsmission München zu finden. Und ich hätte gewettet, dass sie das nicht schafft. Warum ich mir da so sicher war? Nun, ich verwende zum Testen einen Screen Reader. Und ich hab’ mir die Seiten der Bahnhofsmission mit einem Screen Reader angehört. Speziell die Seite Zu Ihrer nächsten Bahnhofsmission.
Hören Sie selbst:

Download des Hörbeispiels (mp3 - 843 kB)

Hier wurde geradezu beispielhaft alles falsch gemacht, was man nur falsch machen kann: Das Navigationsmenü aus Grafiken aufgebaut. Alle Grafiken unbeschriftet (der Screen Reader liest bei jedem Navigationspunkt “index", weil er versucht, aus dem Linkziel etwas Brauchbares herauszulesen), Dann eine Image-Map, die auch nur für sehende Mausbenutzer bedienbar ist. Und so geht es weiter.

Soll ich berichten, wie die Wette mit meiner blinden Bekannten ausgegangen ist? Nein, wir haben nicht gewettet. Ich hätte das als nicht fair empfunden. Sie hatte meines Erachtens keine Chance. Aber sie hat es geschafft! Wie? Ich habe einen bösen Verdacht: Durch erzwungene Übung. Es gibt wohl so viele schlechte Seiten, dass Screen Reader Benutzer Strategien entwickeln mussten, auch damit zurecht zu kommen.

PS: Die Geschäftsstelle der Bahnhofsmission habe ich angeschrieben. Sollte ich eine Antwort erhalten, werde ich das selbstverständlich hier posten.

Sie haben Printerzeugnisse, die Sie hübsch im Internet präsentieren wollen?
dialogperfect®viewer produziert daraus ein schickes E-Paper. Auf dem Bildschirm kann man das Ergebnis anschauen, blättern, und suchen.
So richtig funktioniert das alles aber nur, wenn man die Seite mit der Maus bedienen kann, und nicht auf die Tastatur angewiesen ist. Nach dieser Vorbemerkung ist auch Folgendes verständlich:

“Ich kann auf der Seite nichts lesen. Wo eine Textsuche ist, müsste doch auch auch Text sein.” Diese Logik einer befreundeten Screen Reader Nutzerin ist zwingend. Also mache ich mich auf die Suche nach dem Text.

Ein Blick in den Quelltext der Beispielseite liefert schnell den nötigen Hinweis. JavaScript deaktivieren! dann läuft der Flash-Player nicht, und schwupps, der komplette Text ist sichtbar. Sogar mit richtigen Links zum Blättern durch das Dokument.
Eigentlich schade um die Arbeit, die mit der Konvertierung des Textes verbunden ist. Und vor allem schade um das schöne Geld. Unter 480,- € läuft das nämlich nicht. www.dialogperfect-viewer.de/358-Preise.html

Dabei könnte der Anbieter mit wenigen Zeilen Code Abhilfe schaffen. Wenn er für Accessibility sensibilisiert wäre, und sich die notwendigen Kenntnisse aneignen würde.

Nachtrag:
Weil vermutlich nicht jeder sofort sofort weiß, wie man JavaScript deaktiviert und wieder aktiviert, hier die Kurzfassung:

Firefox:
Menü - Extras - Einstellungen.
Hier deaktivieren Sie unter Inhalt bzw. Web-Features den Punkt “JavaScript aktivieren” und klicken Sie OK.

Internet Explorer:
Menü - Extras - Internetoptionen.
Hier klicken Sie unter Sicherheit auf Stufe anpassen und aktivieren dann unter Scripting - Active Scripting den Punkt “Deaktivieren". Bestätigen Sie zwei mal mit OK.

Richtig elegant, weil Domain bezogen, geht das Aktivieren und Deaktivieren von JavaScript natürlich mit der Firefox-Extension NoScript

Von einem Screen Reader Nutzer hörte ich neulich beiläufig folgende Bemerkung:

Die Google-Ergebnisse kann man jetzt endlich ordentlich lesen, seit Google die Seite mit Überschriften strukturiert hat.

Tatsächlich: Jeder einzelne Treffer ist als h3 ausgezeichnet, und damit komfortabel per Screen Reader anzuspringen.
Aber die Ergebnisseiten waren doch immer schon als nummerierte Listen aufgebaut? Und allein dadurch schon mit Screen Readern optimal zu scannen und zu navigieren?

Des Rätsels Lösung: Innerhalb jedes Listenelements ist der Link zur gefundenen Seite als h3 Überschrift ausgezeichnet. Das ist in HTML erlaubt, und macht auch semantisch Sinn. Wenn denn nach der Überschrift tatsächlich ein Kapitel folgt. Die Treffer in den Google Ergebnissen könnte man tatsächlich als einzelne Kapitel bezeichnen.

<ul>
   <li>
      <h3>Überschrift des 1. Listenpunkts</h3>
      Text des 1. Listenpunkts.
   </li>
   <li>
      <h3>Überschrift des 2. Listenpunkts</h3>
      Text des 2. Listenpunkts.
   </li>
</ul>

Ich hab’ die Technik übernommen: Für Kommentare. Z. B. in diesem Artikel. Die Kommentare sind als nummerierte Liste ausgezeichnet, und jeder Kommentar hat eine h3 Überschrift.
Semantisch korrekt, und optimal lesbar.

Das Design von Schriften bereitet bei der Gestaltung von Webseiten immer wieder Kopfschmerzen. Nur eine Handvoll Fonts sind auf allen Systemen verfügbar, und aufwendige grafische Effekte sind nahezu unmöglich, wenn man sich an CSS und HTML Standards halten will.

So die Einleitung eines Artikels, der eine inzwischen mehrere Jahre alte Technik beschreibt. Eine Technik, die hier immer noch eingesetzt wird, um die Überschriften im Style Leonardo zu generieren.

Nun mag ja in einigen Jahren @font-face embedding allgemein verfügbar sein. Bis es so weit ist halte ich die Dynatext Technik noch immer für eine der besten:
Das fallback, d. h. die Funktion ohne Javascript, ist perfekt.
Und die Barrierefreiheit ebenso.
Wirklich?
Mal in einem Screen Reader testen:

Download des Hörbeispiels (mp3 | 76 kB)

Was sagt der Screen Reader? (im Hörbeispiel ist es der NVDA)

Webdesign nach Maß - Grafik - von - Grafik - webdesign weisshart

Zugegeben. Das zweimalige Ansagen einer Grafik ist nicht schön. Aber akzeptabel. Und die Technik damit barrierefrei: Es geht keine Information verloren; und die Navigation mit dem Screen Reader funktioniert weiterhin (in diesem Fall das Anspringen von Überschriften).
Die Belästigung für Screen Reader Nutzer durch das unschöne Ansagen der Grafiken hält sich in Grenzen, da diese Technik der dynamischenTextersetzung aus Performance Gründen ohnehin nur für kürzere Textpassagen, z. B. Überschriften, einsetzbar ist.

Seit einiger Zeit schon gibt es auf manchen Seiten im Web die Möglichkeit, sich die Seite vorlesen zu lassen.
Zum Beispiel bei heise online

Dazu muss lediglich ein Grafiklink angeklickt werden.

Dass dieser Service nicht für blinde Surfer gedacht sein kann, ist offensichtlich. Wie sollte ein Blinder den Link zum Anklicken finden? Dazu braucht er erst einmal einen Screen Reader, der ihm die Seite vorliest – und wenn der Screen Reader liest, dann braucht er den Vorleseservice nicht mehr.

Wozu also der Aufwand?
Nun gut, ich habe gelernt, dass angeblich Menschen mit Leseschwäche für diese Erleichterung dankbar wären.
Ich kann das leider nicht überprüfen, aber meine persönliche Meinung ist: Man schmückt sich mit einem mehr oder weniger nutzlosen Feature, um zu demonstrieren, wie fortschrittlich man ist, wie sehr man um Barrierefreiheit bemüht ist.

Was ist aber mit der scheinbaren Zielgruppe, den blinden und sehbehinderten Surfern, die einen Screen Reader benutzen? Wehe, wenn sie versehentlich diesen Link betätigen. Dann fängt die Vorleserei an, während gleichzeitig der Screen Reader den Inhalt eines Popups vorliest, das sich beim Klick öffnet. Und das klingt dann so:

Download des Hörbeispiels (mp3 - 428 kB)

Warum schildere ich das so detailliert?
Ich suche immer noch nach einer Möglichkeit, Seiteninhalte vor Screen Readern zu verstecken. Hier wäre ein klassischer Anwendungsfall. Und ein Fall für praktizierte Gleichberechtigung. Warum soll ich Screen Reader Nutzern Inhalte präsentieren, die im besten Fall überflüssig für sie sind.

Leider kann man zwar Seiteninhalte zuverlässig vor sehenden Besuchern verstecken, aber der umgekehrte Weg scheint nicht möglich zu sein.
Oder doch? Kennt jemand eine Technik?

Kaum wusste ich, dass es Screen Reader gibt, schon sah ich mich mit der Aufgabe konfrontiert, Sprachwechsel im Markup auszuzeichnen.
Doch gemach und der Reihe nach:

Screen Reader, das sind die Programme, die blinden und stark sehbehinderten Computerbenutzern den Bildschirminhalt vorlesen. Hut ab vor der Leistung dieser Programme. Sie schaffen es, verständlich vorzulesen, wenn auch der Tonfall der synthetischen Stimmen gewöhnungsbedürftig ist.
Nun ist leicht nachzuvollziehen, dass diese Programme wissen müssen, in welcher Sprache der geneigte Hörer den Text gerne vorgelesen hätte. Geben Sie einem deutschen Erstklässler einen englischen Text zum Vorlesen, und Sie wissen, was ich meine.
Für Webseiten gilt:
Damit Screen Reader wissen, in welcher Sprache Sie vorlesen sollen, suchen sie nach dem lang-Attribut im <html> Tag.
Beispiel:
<html xmlns="http://www.w3.org/1999/xhtml” lang="de” xml:lang="de">
Screen Reader wissen nun: Die Sprache der Seite ist deutsch. So weit so gut.

Was nun, wenn auf einer Webseite anderssprachige Passagen vorkommen?
Nun, die Schulbuchweisheit sagt: Diese Passagen müssen entsprechend ausgezeichnet werden. Das sieht an einem Beispiel folgendermaßen aus:
<span lang="en” xml:lang="en">Best Practice</span>
und das Ergebnis klingt sogar, von einem Screen Reader wie z. B. Jaws vorgelesen, zumeist relativ vernünftig nach Englisch.

Leider wird Sprachauszeichnung wohl nur auf einem verschwindend geringen Anteil der Webseiten realisiert. Das haben anscheinend auch die Hersteller von Screen Readern festgestellt. Und haben ihren Programmen beigebracht, die am häufigsten auch in deutschen Texten vorkommenden englischen Ausdrücke auch ohne Sprachauszeichnung richtig auszusprechen. Was dann wohl wiederum zur Folge hat, dass genau diese Ausdrücke, mit einer an sich korrekten Sprachauszeichnung versehen, vollkommen entstellt vorgelesen werden.

Dazu kommt noch ein weiteres Problem: Der Screen Reader braucht eine merkbare Zeit, um den ausgezeichneten Sprachwechsel zu realisieren. Er legt eine hörbare, und den Lesefluss störende, Pause ein.

Mein Fazit: Ich bin inzwischen mit der Auszeichnung von Sprachwechseln sehr zurückhaltend geworden. Lieber einmal zu wenig, als einmal zu oft.

Die Geister scheiden sich daran, wie denn nun ein Link am besten geöffnet werden soll. Die einen schätzen ein neues Fenster, um die alte Ansicht nicht zu verlieren. Andere hassen das Fenstergewirr.

Eine Lösung für dieses Dilemma habe ich bereits 2006 hier beschrieben.

Nun habe ich mich entschieden, dieses Feature durchgängig auf allen Seiten anzubieten. Auf Kommentare hierzu freue ich mich.

Accesskeys sind ein — umstrittenes — Mittel, um Seiten zugänglicher zu machen für Benutzer, die keine Maus bedienen können — aus welchen Gründen auch immer.
Umstritten, weil damit Webseiten Tastenkombinationen belegen, die eventuell vom System des Besuchers vorbelegt sind. Paradebeispiel ist die Tastenkombination Alt + D. Damit wird in vielen Browsern das Dateimenü aufgerufen. Sollte nun ein Webworker genau diese Tastenkombination für einen Accesskey verwenden, dann können Tastaturnutzer das Dateimenü ihres Browsers nicht mehr erreichen. Accessibility pervertiert.
Eine gute Abhandlung zu diesem Thema gibt es bei Jens Meiert über Accesskeys
Auf meinen Seiten gibt es seit langem Accesskeys — Tastaturkürzel bei webdesign weisshart — obwohl ich immer wieder darüber nachdenke, sie ganz zu entfernen. Aus den oben zitierten Gründen.
Wie dem auch sei: Ich habe die Keys geändert, und an den britischen Accesskey-Standard angepasst. Wichtigstes Detail: Der Sprung zum Inhalt, der Skiplink, hat jetzt den Accesskey [S]. "S" für Skiplink oder Sprunglink.

Manchmal möchte man Bereiche auf einer Webseite erst bei Bedarf anzeigen, die Seite soll erst einmal übersichtlich und aufgeräumt sein. Erst nach einem Klick sollen Details gezeigt werden.
Eine barrierefreie Lösung auf Basis von JavaScript beschreibe ich in diesem Artikel
Ich freue mich auf Kommentare - direkt im Artikel! (die Kommentarfunktion hier ist gesperrt).

Skiplinks (englisch: to skip, deutsch: überspringen) sind Links, die es ermöglichen, größere Bereiche einer Webseite zu überspringen, zum Beispiel die Navigation. Skiplinks unterstützen Nutzer, die nur mit der Tastatur arbeiten, zum Beispiel blinde Menschen.
Immer öfter sieht man Skiplinks, auch auf “großen” Portalen. Gut. Leider “sieht” man diese Skiplinks aber häufig nur im Quellcode. Und dann werden Sie per CSS display:none; unsichtbar gemacht. Und leider nicht nur unsichtbar, sondern sogar total unwirksam. Sie funktionieren einfach nicht. Auch nicht mit Screen Readern, für die sie doch wohl gedacht sind.
Zwei Beispiele:
www.zdf.de und www.deutsche-rentenversicherung-bund.de
Ist die Sache mit den Skiplinks denn wirklich so schwierig?

PS: Beide Firmen wurden angeschrieben. Auf eine Antwort warte ich.

Flash Barrierefrei? Im Prinzip geht das. Nur Benutzer des Firefox Browsers bleiben außen vor.

Wieso?
Barrierefreies Flash bedeutet vor allem, dass Flashfilme mit der Tastatur bedient werden können.
Ein schönes Beispiel für einen mit der Tastatur bedienbaren Flash Film bietet Adobe selbst auf dieser Seite. Wunderbar. Alle Schaltflächen mit der Tab Taste erreichbar, und alle sauber für Screen Reader beschriftet.
Nur mit dem Firefox: Fehlanzeige. Man kommt mit der Tab Taste überall hin, nur nicht in den Flash Film.
Warum?
Weil vermutlich auch Adobe weiß, dass der Firefox den “Tab-Fokus kapert". Wenn man im Firefox mit Tab in einen Flash Film hineintabbt, dann kommt man mit der Tastatur nicht mehr aus diesem Film heraus, man bleibt quasi im Flash gefangen. Damit ist die Seite nicht mehr benutzbar.

Der übliche Ausweg ist bekannt:
In den Aufruf des Flash Objekts kommt diese Anweisung: style="-moz-user-focus:ignore;”
Damit erreicht man, dass der Firefox mit der Tastatur nicht in das Flash Objekt hineintabbt, und folglich auch der Tastaturfokus auch nicht “eingefangen” wird.
Aber natürlich ist das Flash dann mit der Tastatur auch nicht zugänglich.

Fazit:
Flash und Firefox passen nicht zusammen. Auch nicht in der jeweils neuesten Version.
Wann werden die Firefox Entwickler sich dieses Themas annehmen? Barrierefreiheit hat doch ansonsten bei Mozilla einen hohen Stellenwert.
Oder bin ich nicht auf dem aktuellen Stand?

Nachtrag:

Der Bug ist seit 2001 bei Mozilla als Bug 78414 und Bug 93149 bekannt, um nicht zu sagen berühmt.

Mein Chat ist neuerdings nicht mehr XHTML valide.
Grund: Ich setze WAI ARIA ein. Konkret: aria-live.

Was ist ARIA? Hier eine gute Einführung in ARIA

Mit aria-live erreiche ich, dass im Chat die jeweils neueste Nachricht von Screen Readern automatisch vorgelesen wird. Für blinde Chatter ein nicht zu unterschätzender Komfort. Und ein großer Schritt in Richtung weniger Barrieren für eine bestimmte Personengruppe.

Leider wird dadurch die Seite für den W3C Validator invalide. Und Validität wird allgemein als eine der Grundfesten, als “sine qua non", jeglicher Barrierefreiheit bezeichnet.

Was nun?
Auf ARIA verzichten, bis das W3C mit dem Validator nachzieht?
Mit invaliden Seiten leben?

Mal sehen, wie Andere mit dem Dilemma umgehen.

Standfest: Die Vorteile von ARIA rechtfertigen ein “nicht valide” Urteil des Validators:

www.einfach-fuer-alle.de

Wankelmütig: WordPress:

Mit der WordPress Version 2.6.3 wurde erstmals ARIA eingesetzt:
www.gefangenimnetz.de
sowie www.webdesign-in.de

aber WordPress 2.8 machte dann wieder einen Rückzieher:

Hier finde ich zwar im Template die Angaben für aria-required, aber sie werden nicht im Quelltext ausgegeben, - entweder habe ich technisch was übersehen oder es ist ein Bug - kann ich derzeit einfach nicht sagen:

Quelle:
www.texto.de

Die Ja - Aber Fraktion

ARIA ja, aber dennoch validieren. Das versuchen

www.456bereastreet.com und www.paciellogroup.com

Mein Fazit

Ich kann mich für diese, zweifellos technisch reizvollen Versuche, ARIA zu validieren, nicht erwärmen.
Ich versuche, mich der Fraktion der Standfesten anzuschließen. ARIA bringt wertvollen Zusatznutzen, und schadet niemandem. Also bleibt es. Auch wenn ARIA bisher bei W3C erst den Status working draft hat. Und auch wenn das W3C noch länger braucht, um den Validator auf den Stand der Zeit zu bringen.
Nennt man diese Haltung Pragmatismus?

Nachtrag 08.08.2009

Auch www.bik-online.info/ wird von Bauchschmerzen geplagt, und eiert rum:

Wenn Fehler bei der Validierung ausschliesslich durch den Einsatz von WAI-ARIA (Rollen, Zuständen, Eigenschaften etc.) enstehen gilt der Prüfschritt als erfüllt.

Der Einsatz von WAI-ARIA Techniken verbessert die Zugänglichkeit. Der BITV-Test bewertet die praktische Zugänglichkeit. Es wäre nicht nachvollziehbar, wenn der Einsatz von Techniken zur Verbesserung der
Zugänglichkeit im BITV-Test zu Punktabzügen führen würde.

Neuentwurf Prüfschritt 3.2.1 “Valides HTML":
testen.bitv-test.de/index.php?a=di&iid=1140

Wir sind nicht sehr glücklich mit dieser Ausnahmeregelung und hoffen, dass sich das Thema bald von selbst erledigt.

Nachtrag 10.08.2009

Ich gehöre anscheinend auch zur Fraktion der “Ja - Aber".
Ich konnte mir nicht verkneifen, das aria Attribut per Javascript ins DOM zu schreiben, damit der Validator wieder “Grün” zeigt. Asche auf mein Haupt. :-)

Der AChecker (Accessibility Checker) nach WCAG 2.0 der Universität Toronto, den ich schon länger in die Liste meiner Testwerkzeuge aufgenommen hatte, wurde rundum erneuert. Und bei der Gelegenheit änderte sich auch die Adresse in http://achecker.ca/checker/
Schade nur, dass er anscheinend nicht mehr mit einem URL Parameter aufgerufen werden kann. Das war bisher so praktisch in Verbindung mit den Web Developer Extras.

Auswahllisten (Ausklapplisten / <select>) dienen dazu, dem Anwender eine Liste mit festen Einträgen anzubieten, aus der er einen Eintrag auswählen kann. Der Text des ausgewählten Eintrags wird übertragen, wenn der Anwender das Formular abschickt.
Zum Abschicken gibt es einen eigenen Button, z. B. <input type="submit” … >
Wenn nun das Formular als einziges Element eine Auswahlliste enthält (typisches Beispiel: ein Style Switcher), dann ist es lästig, den Submit Button anzusteuern und zu betätigen.
Pfiffiger wäre es, die Auswahl mit Enter bestätigen zu können.
Hier kommt Javascript mit dem Event Handler onchange zu Hilfe.
Beispiel:

<select name="titel" size="1" onchange="this.form.submit()" >

Wunderbar.
Aber:
Versuchen Sie mal, eine solchermaßen aufgepeppte Auswahlliste im Internet Explorer ohne Maus, also nur mit der Tastatur, zu bedienen. Ich habe für Ihre Versuche ein Muster zum Testen erstellt. Dieses Muster beinhaltet konsequenterweise keinen Submit Button. (In der Praxis würde ich den jedoch sicherheitshalber belassen.)
Und was passiert da? Es gelingt bei ausschließlicher Tastaturnutzung nicht, einen der angebotenen Einträge auszuwählen, weil das Formular sofort beim Versuch, innerhalb der Auswahlliste mit den Pfeiltasten nach unten zu gehen, abgeschickt wird. Dabei wird dann immer der zweite Eintrag in der Liste “Michael Jackson” gewählt.
Es sei denn, Sie wissen, wie man das mit dem Internet Explorer macht:

1. Mit der Tab Taste den Fokus auf die Auswahlliste setzen.
2. Die Auswahlliste mit “Alt+Pfeil nach unten” öffnen.
3. Mit den Pfeiltasten (nach unten / nach oben) innerhalb der ausgeklappten Liste navigieren.
4. Enter

Und jetzt die Preisfrage: Wer wusste das?

Mir jedenfalls ist das zu riskant. Ich befürchte, zu viele Besucher mit dieser Technik auszuschließen.
Ich werde also in der praktischen Anwendung dem Internet Explorer ein Formular ausliefern ohne den onchange event handler. (Das geht ja recht zuverlässig mit conditional comments.)

Behindern gehörlose Übersetzer die Schaffung barrierefreier Webseiten?

oder

Übersetzer für DGS (deutsche Gebärdensprache) gesucht

Beim Thema Barrierefreiheit denken die meisten Webworker erst einmal an blinde Menschen. Wenn sie sich überhaupt zu diesem Thema Gedanken machen.
Dieser Ansatz ist auch gut. Wenn Webseiten so gestaltet werden, dass sie für blinde Menschen mit den entsprechenden Hilfsmitteln (Screen Reader) zugänglich sind, dann ist ein wichtiger Schritt zur Barrierefreiheit getan.

Es gibt aber noch weitere Behinderungen, die bei der Erstellung barrierefreier Webseiten berücksichtigt werden müssen. Neben Menschen mit motorischen Behinderungen ist insbesondere die Gruppe der gehörlosen Menschen zu nennen. Auf letzteren Fall möchte ich in diesem Beitrag speziell eingehen.

“Wieso sollte Gehörlosigkeit bei der Benutzung des Internet ein Problem darstellen?” werden Sie sich jetzt vielleicht fragen. “Gehörlose Menschen können doch lesen.”
Leider trifft diese Aussage nur bedingt zu. Für von Geburt gehörlose Menschen ist Deutsch eine Fremdsprache. Sie sind mit Gebärdensprache aufgewachsen. Ihr Sprachverständnis für die deutsche Schriftsprache ist in manchen Fällen auf dem Niveau der 4. Klasse.

Als Lösung bietet sich die Bereitstellung von Gebärdensprachfilmen an. Dabei werden die Inhalte der Internetseiten in Deutsche Gebärdensprache übersetzt und auf Video verfilmt. (…) So sind wichtige Informationen auch für Gehörlose barrierefrei erreichbar und nur noch einen Mausklick entfernt.

Quelle: www.dgs-filme.de/GWHomepage/barrierefreiheit.htm

Leider ist nun diese empfohlene “Bereitstellung von Gebärdensprachfilmen” ihrerseits mit einer in vielen Fällen unüberwindlichen Barriere behaftet: Die Kosten für die Erstellung entsprechender Übersetzungen sind exorbitant. Für einen mittelschweren Text mit 600 Wörtern (entsprechend ca. 1 ½ Seiten oder dem 1 ½ fachen Umfang dieses Beitrags) wurde mir von zwei Anbietern jeweils ein Preis von 1000 (tausend) Euro genannt.
Ich kann nachvollziehen, dass der Aufwand für die Erstellung von Gebärdensprachfilmen höher ist als beispielsweise die Übersetzung in eine andere Schriftsprache. Ein Schmunzeln hat mir jedoch folgender Passus in einer mit dem Angebot gelieferten Leistungsbeschreibung entlockt:

… die genaue Einstellung der Kamera, die Auswahl und Positionierung der Scheinwerfer sowie die Vorbereitung des Hintergrundes. Auch muss die Kleidung des Darstellers festgelegt werden.

Ich will nicht von Abzocke sprechen. Ich glaube auch nicht, dass hier eine gewisse Monopolstellung missbraucht wird.
Beide Angebote stammen von “Muttersprachlern", also von gehörlosen Menschen, deren Muttersprache die deutsche Gebärdensprache ist. Eine wichtige Voraussetzung für eine qualitiativ hochwertige Übersetzung.

Aber:
Mit diesen Preisen verhindern die Anbieter, also die Betroffenen selbst!, dass mehr Webseiten barrierefrei nach ihrer eigenen Definition gestaltet werden.

Ich suche weiter nach einer Möglichkeit, Gebärdensprachfilme zu Kosten anzubieten, die es auch nichtkommerziellen und nichtöffentlichen Webseitenbetreibern ermöglicht, gehörlose Seitenbesucher in ihrer Muttersprache anzureden.

Einen neuen Video Player ein, der hinsichtlich Barrierefreiheit alles in den Schatten stellt, was ich bisher im Web gesehen habe, stelle ich in diesem Artikel vor, einschließlich Demo, Beschreibung und Codeschnipseln.

Hintergrundmusik auf Webseiten ist - vorsichtig ausgedrückt - einer der beliebtesten Anfängerfehler. Im Web wird, zu Recht, nachdrücklich davor gewarnt. Diese Warnungen kann man im Wesentlichen wie folgt zusammenfassen:
Hintergrundmusik, vor allem, wenn sie ungefragt losdudelt, führt dazu, dass die meisten Besucher die Seite sofort wieder verlassen.
Eine Suche nach “Hintergrundmusik auf Webseiten” listet daher - zu Recht - hauptsächlich Seiten auf, die vor dem Einsatz von Hintergrundmusik auf Webseiten warnen.

Was aber, wenn ein Webmaster partout der Meinung ist, dass sein Fall ganz anders liegt, und dass auf seiner Seite Hintergrundmusik gerechtfertigt ist? Nun gut, dann wenigstens richtig.

Wie es richtig gemacht wird, zeige ich auf einer Demoseite
Und um die Sache zu erleichtern, gibt es dort auch gleich das komplette Script mit einer detaillierten Anleitung zum Download.

Skiplinks (englisch: to skip, deutsch: überspringen) sind Links, die es ermöglichen, größere Bereiche einer Webseite zu überspringen, zum Beispiel die Navigation. Skiplinks unterstützen Nutzer, die nur mit der Tastatur arbeiten, zum Beispiel blinde Surfer.

Ich habe einen Artikel verfasst, wie man Skiplinks richtig einbaut.
Ein besonderes Zuckerl ist eine Technik, die auch WebKIT basierten Browsern wie Safari das Springen beibringt.

Eine der besten Methoden, Webseiten auf Barrierefreiheit zu testen, ist die Verwendung eines Screen Readers.
Ich habe einen Artikel zu diesem Thema von WebAIM übersetzt.

Einige persönliche Anmerkungen zu diesem Artikel:

• Die dort beschriebenen Verfahren zur Benutzung von Jaws werden wohl nur sehr erfahrene Benutzer allesamt kennen und verwenden. Ein Webworker, der nur seine eigenen Seiten testen will, wird mit einem Bruchteil der beschriebenen Tastaturkürzel auskommen.
• Im Zweifelsfall sollte man immer den Rat eines Experten suchen. Im vorliegenden Fall ist jeder blinde Screen Reader Nutzer ein Experte.
• Last but not least: Barrierefreiheit ist nicht nur Webdesign für blinde Menschen. Es gibt viele Aspekte der Barrierefreiheit, die mit einem Screen Reader nicht getestet werden können.

Bei Robert Lender bin ich drauf gestoßen: Eine Blog-Parade zum Thema “Webseiten ohne Maus, nur mit der Tastatur bedienen - und viele Menschen sind sogar darauf angewiesen, dass Webseiten ohne Maus navigierbar und bedienbar sind.”
Dabei ist mir aufgefallen, dass ich selbst dazu schon einiges veröffentlicht habe, verstreut über viele Seiten und Blogeinträge. Eine Zusammenfassung kann daher nicht schaden:

• Rechte Maustaste ohne Maus
• Ein Script für einen online MP3 Player, der ohne Maus bedient werden kann.
• Ein mit der Tastatur bedienbarer Flash Video Player
• Dieser Blogbeitrag zum Thema Sprunglink hätte mich beinahe meinen letzten Nerv gekostet. Tomas Caspers konnte mir mit dem Hinweis auf IE hasLayout den entscheidenden Tipp geben, um meine Sprunglinks zu reparieren.

Mehr zum Thema in der aktuellen Tab-Parade von MAIN_blog.

Animated GIFs, das sind die hüpfenden Männchen, Fahnen, die kreiselnden @ usw., die man häufig, überwiegend auf privaten Seiten sieht. Oft klicke ich einfach ganz schnell weg, weil die Dinger einfach nur nerven.
Gibt es auch einen Weg, die Animation abzuschalten, um die Seite in Ruhe zu lesen?

Nichts einfacher als das: Die Esc Taste ist dein Freund.

Weil diese Frage immer wieder gestellt wird:
“Wie macht man einen Rechtsklick - zum Beispiel, um eine Datei zu speichern - wenn die rechte Maustaste nicht zur Verfügung steht, oder eine Maus nicht bedient werden kann?”

Ganz einfach:
Mit der Tab-Taste den Fokus auf den Link setzen.
Dann
- entweder mit der Applikationstaste - diese befindet sich meist links neben der rechten STRG Taste, und trägt ein Symbol, das ein Navigationsmenü darstellen soll.
- oder mit UMSCHALT+F10
das Kontextmenü öffnen.

Nach vierwöchiger Testphase kann ich sagen: meine Lösung reicht - für meine Zwecke.

Ich prüfe einfach, wie lange es dauert, bis ein Formular - in diesem Fall der Kommentar hier im Blog - abgeschickt wird. Und alles unter 10 Sekunden ist böse.

Die Technik, obwohl nicht neu, habe ich, zusammen mit anderen bekannten Techniken, noch einmal beschrieben: Techniken zur Abwehr von Kommentarspam
Ich muss gestehen, dass tatsächlich während Testphase ein einziger Spambot 15 Sekunden bis zum Abschicken wartete, und damit den Schutz aushebelte.
Ich kann damit leben. Ich muss diesen Spam-Kommentar eben manuell löschen. Zusammen mit - viel häufigeren - manuellen Spam-Einträgen folgender Art:

… bin zufällig auf diese Seite gestoßen und bin sehr überrascht was es hier alles für interessante Themen gibt. Werde jetzt öfters mal vorbeischauen.

Sollte in Zukunft maschinell produzierter Spam doch häufiger vorkommen, dann ist meine Wahl: zusätzlich Methode 2: ein verstecktes Feld, das nicht ausgefüllt werden darf.

In jedem Fall habe ich für mich eine Lösung gefunden, die niemanden belästigt, vor allem niemanden aussperrt, und dennoch die bösen Bots mit ausreichender Zuverlässigkeit aussperrt.

Gegen die plumpen Versuche, sich mittels manueller Kommentare der oben zitierten Art Backlinks zu erschleichen, hilft manuelles Löschen (zumindest der Links in den Kommentaren).
Da ich die Kommentare in meinem Blog ohnehin lese, kein größeres Problem.

Seit langem setzte ich als Schutz gegen Kommentarspam eine Rechenaufgabe ein. Mit vollem Erfolg. Kein einziger böser Bot machte sich die Mühe, 5 plus 3 auszurechnen.
Seit heute gibt es - versuchsweise - eine neue Art des Spamschutzes. Nein, kein CAPTCHA! Menschliche Besucher werden von meiner Technik nicht belästigt oder gar ausgesperrt; sie merken gar nichts von einem Spamschutz. Das Ausfüllen eines zusätzlichen Feldes ist nicht mehr erforderlich.
Ob der Schutz wirksam ist, wird sich zeigen. Aus diesem Grund werde ich die Technik auch erst nach einer maximal mehrwöchigen Testphase veröffentlichen.
Vorab sei nur so viel verraten: Ganze 6 Zeilen PHP sind hierfür erforderlich!

Sauberen, korrekten (X)HTML- und CSS-Code schreiben - ob von Hand, oder mit einem CMS-System, mit einer Blog- oder Forensoftware, ist eine Sache. Aber auch hierbei gilt: Kontrolle ist besser. Um Webseiten nach allen denkbaren Kriterien zu testen, gibt es eine Fülle von Werkzeugen, viele davon online.

Ich habe mal in meine Werkzeugkiste gegriffen, und stelle hier meine wichtigsten Tools vor.

Hoppla! Was ist denn mit dem Design passiert? Ganz einfach, webdesign weisshart beteiligt sich auch 2008 wieder am »CSS Naked Day«. Die Idee dahinter ist recht simpel: ist die Website noch benutzbar, wenn man sämtliche Formatierungen abschaltet? Verwendet die Website semantisches Markup, oder gehen ohne das Design wesentliche Informationen verloren?

Entstanden ist die Idee im Weblog von Dustin Diaz, der den »First Annual Naked Day: April 05« ausgerufen hat. Auf dieser Seite findet man auch eine lange Liste von Websites, die ebenfalls an der Aktion teilnehmen.

… wenn dir diese Ansicht nicht gefällt, dann wähle einfach aus meinem Styleswitcher einen Style aus; dann ist der Spuk vorbei, zumindest so lange, bis Du Deinen Browser neu startest. ;-)

Am 9. April ist es wieder so weit:
Meine Seiten werden einen Tag lang nackt, ohne jegliches Styling dargestellt.
Die Idee von Dustin Diaz ist jetzt schon im vierten Jahr.
Damit soll gezeigt werden, dass ordentlich strukturierte Seiten auch ohne Styling, ohne CSS, ordentlich lesbar und benutzbar bleiben. Der erste und wichtigste Schritt zur Barrierefreiheit.

Automatische Tools zum Test auf Barrierefreiheit haben alle ihre - bekannten - Grenzen. Die meisten Tools weisen auch deutlich darauf hin. Manche zeigen auch detailliert auf, wo die Notwendigkeit einer zusätzlichen manuellen Überprüfung durch einen Experten besteht.
Alle mir bekannten Tools können aber eins nicht: Seiten “live” testen, also nach einem Neuaufbau der Seite, z. B. nach der Auswahl einer Option, die geänderte Seite erneut beurteilen.
Die neue Wave 4.0 Beta kann auch das. Und ist damit das erste Werkzeug, mit dem ich meinen Chat automatisiert testen kann.
Hier das Ergebnis.
Möglicherweise landest du mit obigem Link auf der Login-Seite. Aber, da die Seite ja bedienbar bleibt, einfach einloggen, und Wave testet auch den Chat selbst.

Die Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz (BITV) schreibt vor:

Texte sind so zu gestalten, dass die Kombinationen aus Vordergrund und Hintergrundfarbe auf einem Schwarz-Weiß-Bildschirm und bei der Betrachtung durch Menschen mit Farbfehlsichtigkeiten ausreichend kontrastieren.

Was “ausreichend” ist, definiert W3C in Form von 2 Algorithmen.

Diese Forderung zu erfüllen, bereitet häufig Schwierigkeiten. Manchmal scheint es, als ob zu einer gegebenen Hintergrundfarbe oder Schriftfarbe überhaupt keine Schriftfarbe bzw. Hintergrundfarbe existiert, die die strengen Forderungen des W3C nach ausreichender Helligkeitsdifferenz und gleichzeitig ausreichendem Farbkontrast erfüllt.

Und dies ist tatsächlich bei sehr vielen Farben der Fall.

Ich habe die Algorithmen des W3C mal in eine anschauliche Form übertragen. Dort kann man eigene Farben vorgeben, oder einfach zufällige Farben durch Neuladen der Seite erzeugen lassen. Das Script generiert daraus automatisch

1. die Farbe mit der bestmöglichen Helligkeitsdifferenz (also entweder Weiß oder Schwarz), und
2. die Farbe mit dem bestmöglichen Farbkontrast,

und stellt die Ergebnisse jeweils als Schriftfarbe zur gewählten Hintergrundfarbe und als Hintergrundfarbe zur gewählten Schriftfarbe dar.
Die Zahlenwerte für Helligkeitsdifferenz und Farbkontrast nach W3C werden ausgegeben, und anhand der Minimalforderung bewertet.

Ein wenig Spielen mit zufälligen Farben liefert hin und wieder überraschende Ergebnisse. Manche zulässige Farbkombinationen kann ich kaum lesen.

Sie schließen Menschen von der Benutzung der dahinter liegenden Dienste aus.
Wie oft schon habe ich - obwohl mit keiner nennenswerten Sehschwäche geschlagen - beim dritten oder vierten erfolglosen Versuch, so ein Captcha zu entziffern, entnervt aufgegeben.

Aber sie hindern "böse" Bots nicht daran, solcherart vermeintlich geschützte Dienste für ihre Zwecke zu missbrauchen:

… Nach Angaben des Maildienstleisters MessageLabs liegt die Erkennungsrate der Captchas (Completely Automated Public Turing Test to Tell Computers and Humans Apart) durch die Spammer-Tools zwischen 20 und 30 Prozent…

Quelle: Heise Security

Eine Trefferquote von "nur" 20 Prozent ist für einen Spambot - anders als für mich - kein Grund, von seinem Treiben Abstand zu nehmen. Bots werden also von Captchas nicht wirkungsvoll ausgesperrt, wohl aber Menschen! Was für eine Perversion.

Wie zugänglich sind Online Flash Player für behinderte Surfer, die auf Hilfsmittel zum Betrachten von Webseiten angewiesen sind?
Ich hab’ mich mit dieser Frage recht intensiv beschäftigt, und eine pragmatische Lösung erarbeitet.
Artikel lesen

Daß meine Lösung funktioniert, daran habe ich wenig Zweifel.
Erhebliche Zweifel habe ich aber, ob mein Artikel, und insbesondere der Versuch einer Anleitung zum Nachbau richtig und verständlich sind. Ich würde mich daher mehr als sonst über entsprechendes feedback freuen.

Eine Detail, das mich schon lange gestört hat, ohne dass ich mir dessen eigentlich richtig bewusst war:
Wenn ich einem Link auf einer Seite folge, und dann mit dem Zurück-Button oder der Zurück-Taste zur aufrufenden Seite zurückkehre, dann erwarte ich eigentlich, dass ich mich an der gleichen Stelle, an der gleichen Scroll-Position wiederfinde.

Der IE macht das auch erwartungsgemäß. Der Firefox nicht. Und das ist irritierend.

Dabei handelt es sich um einen bekannten Bug im Firefox: http://kb.mozillazine.org/Scroll_position_on_web_pages_not_remembered
Und auf dieser Seite fand ich auch gleich noch einen Workaround: Eine Extension für den Fuchs: http://www.gozer.org/mozilla/extensions/
dort “Restore Scroll Position v0.5.9.10″

Eine akustische Seite. So überschreibt der blinde Webmaster Robert Gemeinhardt seine Homepage. Robert verwendet die fast vergessene Aufnahmetechnik Kunstkopfstereophonie, um möglichst realistische räumliche Tondokumente aus dem Alltag zu erstellen. Ob sich dem sehenden Hörer die alle Feinheiten dieser Aufnahmen ebenso erschließen, wie Robert das in seinen Anmerkungen beschreibt?
Um ein komfortables Stöbern durch die zahlreichen Tonbeispiele zu ermöglichen, setzt Robert meinen mp3-Player ein.

Das Menü gehört mit zu den wichtigsten Komponenten einer Website. Kein Zweifel. Und deshalb befindet es sich auch immer oben, links oder rechts, auf jeden Fall aber »above the fold«, ist also ohne Scrollen sichtbar.
Nutzer von Screen Readern, PDAs und Handys, sowie Suchmaschinen sind diesbezüglich ganz anderer Meinung. Sie hätten gerne das Wichtigste, nämlich den Inhalt, zuerst.
Die Lösung, um Alle zu bedienen: Das Menü kommt im markup, im Quelltext, ans Ende, und wird per CSS in die linke oder rechte Navigationsspalte positioniert. Damit die oben erwähnten Nutzergruppen das Menü leicht erreichen, gibt es einen skip link ganz am Anfang der Seite, um das Menü direkt anzuspringen. Zu erreichen (zu sehen) ist dieser skip link mit der Tab-Taste.
Ich hab’ jetzt mal etwas anderes probiert: Auf dieser Seite bleibt die Navigation unten. Aus Designgründen.
Schön. Und gewagt. Wenn das Browserfenster des Besuchers, warum auch immer, so klein ist, dass er das Menü nur durch Scrollen erreicht? Ist das nicht irritierend?
Nein!
Denn in diesem Fall wird das Menü eben oben angezeigt.
Ich erreiche dies durch ein pfiffiges Javascript. Danke an SELFHTML
(Sollte Javascript nicht verfügbar sein, bleibt das Menü eben unten. Aber die Seite funktioniert weiterhin.)

Nachtrag: Hab’ ich eigentlich erwähnt, daß der IE das natürlich nicht kann?

Mehrzeilige Texteingabefelder in Formularen <textarea> sind auf den meisten Webseiten aus Designgründen viel zu klein. Häufig passen nur 5 oder 6 Zeilen in das Eingabefeld, dann erscheint ein Scrollbalken. Damit wird es äußerst unbequem, das Geschriebene zur Korrektur noch einmal zu lesen.
Safari-Nutzer können das Textfeld mit der Maus vergrößern, und Firefox-Nutzern steht eine gleichwertige Extension zur Verfügung, wie ich hier beschrieben habe.
Eine weitere, elegante Lösung habe ich kürzlich gefunden (ich weiß leider nicht mehr wo, dennoch danke an Unbekannt).
Mittels eines Javascript eventhandlers wird das Textfeld automatisch nach unten verlängert, sobald bei der Texteingabe die letzte sichtbare Zeile erreicht ist:

<textarea onkeyup="this.style.height=Math.max(this.scrollHeight,150) + ‘px’;this.style.overflow=’hidden’” …

Mit den 150 px Höhe muß man eventuell ein wenig experimentieren, um ein Springen der angezeigten Höhe zu vermeiden.
Diese Javascript-Lösung ist selbstverständlich unobtrusive, d. h. wenn Javascript nicht zur Verfügung steht, verhält sich das Texteingabefeld ganz normal, wie oben beschrieben.
Klar, dass ich das gleich hier mal probieren musste.

Ist Ihre Website »compliant«?
Web Compliance ist nicht auf Barrierefreiheit allein beschränkt, sondern stellt ein umfassendes Konzept dar, das folgende Bereiche beinhaltet:

• Standardkonformität und Interoperabilität.
• Qualitätssicherung und Optimierung von Ressourcen.
• Sicherheit und Datenschutz.
• Auffindbarkeit von Ressourcen durch Suchmaschinen und Optimierung des Rankings der Suchergebnisse.
• Unterstützung von Corporate Identity.

Das Fraunhofer Institut für Angewandte Informationstechnik (FIT) hat ein neues Werkzeug zum Testen der Compliance entwickelt. Eine kostenlose Demo [Beta] gibt es hier: http://imergo.de/

Sie können eine URL Ihrer Wahl auf Validität und Compliance mit verschiedenen nationalen und internationalen Bestimmungen für Barrierefreiheit prüfen lassen.

Eine Warnung sei angebracht:
Das Tool stellt hohe Ansprüche an die Kenntnisse des Webmasters, wenn es darum geht, die Auswertung zu verstehen und aufgezeigte Fehler abzustellen.

Das Aktionsbündnis für barrierefreie Informationstechnik veranstaltet am 9. und 10. April 2008 in Berlin einen Kongress zum Thema “Digital informiert - Im Job integriert".
Infos und Anmeldung unter http://kongress2008.abi-projekt.de

Edit 06.02.2008: Ein neuer Anlauf. Das Bildschirmflackern sollte behoben sein (siehe Kommentar). Und auch der Zurück-button funktioniert.
Über Rückmeldungen und Kommentare würde ich mich freuen.

Edit 3.2.2006: wegen eventueller Probleme mit der accessibilty (Flackern) und der usability (die Zurück - Funktionalität des Browsers geht nicht mehr) hab ich das sanfte Scrollen - schweren Herzens - vorläufig? wieder deaktiviert.
Den Beitrag hier lasse ich stehen: das tool ist einfach zu interessant.
weiterlesen…

Seiteninterne Sprunglinks, etwa zum Inhalt, oder zur Navigation, sind ein wichtiges Element, um die Benutzung von Webseiten öhne Maus, ausschließlich mit der Tastatur zu erleichtern.
Vielfach werden diese Sprunglinks per CSS versteckt, und nur beim Durchtabben mit der Tastatur angezeigt.
Hierfür gibt es eine etablierte Technik, die eigentlich immer und überall funktioniert.
Eigentlich.
Nur nicht mit dem IE6 auf der folgenden Testseite, die ich eigens erstellt habe, um diese Technik in verschiedenen Browsern zu testen.
http://webdesign.weisshart.de/test/skiptest/skip.html

Hier der Quelltext der Seite:

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml” xml:lang="de” lang="de">

<head>
<title>Titel</title>
<meta http-equiv="Content-Style-Type” content="text/css” />

<style type="text/css">

#skip a:link,
#skip a:visited {
position:absolute;
left:-500px;
top:-500px;
width:0;
height:0;
display:inline;
}

#skip a:focus,
#skip a:hover,
#skip a:active {
position:absolute;
left:0;
top:0;
width:auto;
height:auto;
display:block;
}

</style>

</head>
<body>

<div id="skip"><a href="#navsprung">Sprung zur Navigation</a></div>

<div id="inhalt">
<h1>Titel</h1>
<p>Irgendwelche Inhalte</p>
<p><a href="http://www.example.com">ein normaler Link</a></p>
</div>

<p>Viele Trennlinien, um Raum zu schaffen:</p>
<hr /><hr /><hr /><hr /><hr /><hr /><hr /><hr />

<h2><a name="navsprung">Navigation</a></h2>

</body>
</html>

Inzwischen kann ich unterwegs fast alles, was das Internet bietet, mit meinem PDA erledigen. Information aller Art abfragen, meine Homepage aktualisieren, ja sogar Börsen- und Bankgeschäfte erledigen. Mit entsprechend gestalteten Seiten sind auch der relativ kleinen Bildschirm und die mancherorts recht schlechte Internetanbindung kein Problem.

Auch meine Bank bot eine entsprechende, für mobile Geräte optimierte Seite an, auf der ich bequem mal schnell z.B. Zahlungseingänge checken konnte.
“Konnte", denn seit kurzem hat sich dieses Angebot geändert, und sieht jetzt so aus:

Anstelle eines Zugangs zum online banking findet sich jetzt lediglich der Menüpunkt “TelefonBanking", und dahinter verbirgt sich eine Seite mit der Telefonnummer der Bank.
Auch eine Art von mobile banking.
Ich weiss nicht, ob ich darüber lachen soll, ob ich mich ärgern soll, oder die Bank wechseln.
Natürlich kann ich auch die “normale” Seite zum online Banking aufrufen. Aufgrund der Dateigößen und der unübersichtlichen Gestaltung der Seiten ein äusserst mühseliges Unterfangen.
Mal sehen, ob und wie die Bank auf meine diesbezügliche Anfrage reagiert.

__________________________
So, die Antwort ist da:

Mit der Umstellung können unter http://mobile/…..de nur noch mobile Services wie Börsenkurse und aktuelle Hinweise zur Verfügung gestellt werden. Sie können alternativ versuchen, ob unser InternetBanking unter https://homebanking…..de über den mobilen Browser Ihres PDAs nutzbar ist.

Kein weiterer Kommentar meinerseits.

Gerade entdeckt:
Safari Browser für Windows
Erster Eindruck: problemlos zu installieren, und funktioniert tadellos.
Für Webworker, die zugängliche Seiten schreiben wollen, aber sich dafür nicht extra einen Mac kaufen können/wollen, eine tolle Sache - vorausgesetzt, der Safari verhält sich unter Windows genau so wie auf dem Mac.
Ich werde über meine weiteren Erfahrungen hier berichten.

Webdesigner, die sich um validen Code bemühen, kennen die “wichtigste” Firefox Extension: Die Web Developer Toolbar.
Noch einen Schritt weiter geht die Extension HTML Tidy. Jawohl, der Veteran HTML Tidy ist auch als Firefox Extension verfügbar:
Download und Installation
Tidy verwendet den Algorithmus des W3C Konsortiums, und bietet aussagekräftige Hinweise zu Fehlern und deren Behebung.
Und das Schönste: Die Extension zeigt direkt in der Toolbar des Browsers eventuelle Fehler. Ganz praktisch, um schnelle Änderungen auf der eigenen Seite auf Validität zu überprüfen.

Unter dem Titel “Musik auf Webseiten barrierefrei anbieten als Flash Stream” habe ich einen Artikel online gestellt, der einen möglichen Weg zur barrierefreien Einbindung eines Flash Musik Players aufzeigt.
Ich hoffe auf eine rege Diskussion, und freue mich über Kritik und/oder Anregungen.

Mit sogenannten Browserweichen versuchen geplagte Seitenschreiberlinge seit Unzeiten, die unterschiedliche Interpretation von CSS durch die verschiedenen Browser in den Griff zu bekommen.
So bedauerlich die uneinheitliche Unterstützung der Standards durch die Browserhersteller auch ist - die vermeintliche, gutgemeinte, Abhilfe kann gründlich in die Hose gehen:

Screenshot der Seite von Michl’s Café
ohne CSS

Ich bin heute zufällig über die Seite von Michl’s Café gestolpert. Und hab’ nicht wenig gestaunt, eine Seite ohne jegliche Formatierung anzutreffen. HTML pur, kein CSS, aber auch keine Tabellen. Einfach HTML. Valide noch dazu, und semantisch korrekt ausgezeichnet, also anscheinend keine Stümperseite. Sollte es tatsächlich so etwas geben? Eine offensichtlich aktuelle Site, die korrektes, valides XHTML bietet, ganz ohne Formatierungen?
Hat mein Firefox ein Problem?
Also ein Versuch mit Opera.
Gleiches Ergebnis.

Erst ein Blick in den Quelltext zeigte die Ursache: Eine ausgefeilte Javascript Browserweiche, die nicht weniger als 3 x 10 = 30 unterschiedliche Betriebssystem/Browserkombinationen abfragt, und das jeweils passende CSS einbindet.

Wenn - ja wenn Javascript aktiviert ist.

Ist es aber bei mir erst mal nicht, wenn ich auf fremden Seiten surfe. Dank Firefox und seinen nützlichen Erweiterung. (Warum Opera das CSS nicht erkannte, obwohl ich dort Javascript nicht deaktiviert habe, hab’ ich nicht mehr untersucht. Vielleicht liegt es daran, dass ich die neueste Version 9.2 installiert hab’?)
Und ohne Javascript wird auf diesen Seiten gar kein Stylesheet eingebunden.

Ich bewundere den Eifer des Webdesigners, der 30! Stylesheets erarbeitet hat. Leider in meinem Fall vergeblich.

Die Moral von der Geschicht?
Javascript nie ohne fallback!

Der Webdesigner der zitierten Seite möge Nachsicht mit mir haben: Das Beispiel ist rein zufällig, und die Kritik absolut konstruktiv zu verstehen. Zumal es sich um eine vorbildlich barrierefreie Seite handelt.

Tastaturkürzel, (engl. access keys) werden dazu benutzt, bestimmte Seiten oder Sprungmarken schnell anzuspringen.
Auf meiner Seite verwende ich diese Tastaturkürzel.

Der Einsatzt von Tastaturkürzeln ist nicht unumstritten. Unter anderem deshalb, weil die Kombination Alt+Taste für fast alle Kombinationen vorbelegt ist: vom Browser, oder von unterschiedlichen Hilfsprogrammen wie z.B. Screenreadern.
Unkritisch verwendbar sind unter diesem Aspekt eigentlich nur die Ziffern 0 bis 9.

Unter Windows gilt die Kombination Alt+Tastenkürzel.
So war das zumindest bisher.
Der Firefox in der neuesten Version 2.0.0.2 hat hier eine Änderung eingeführt:
Alt+Umschalt+Tastenkürzel. release notes

Damit wären die oben beschriebenen Konflikte beseitigt, und der Einsatz auch von Buchstaben für Tastaturkürzel möglich. “Wären", wenn das Standard wäre. Ist es aber nicht.

So blieb nur der Schreck, als anscheinend plötzlich die Tastaturkürzel auf meinen Seiten nicht mehr funktionierten. Und noch etwas mehr Verwirrung, was die Thematik Tastaturkürzel betrifft. Siehe dazu einen Beitrag bei www.einfach-fuer-alle.de

Ich bezeichne meinen Chat als barrierefrei.
Nein, mein Chat ist nicht barrierefrei.
Und zwar, weil WAI und BITV unter anderem verlangen, dass barrierefreie Webseiten auch ohne Javascript zugänglich sein müssen.

In letzter Zeit wird viel über barrierefreies pdf und barrierefreies flash diskutiert.
Wer keinen pdf reader oder kein flash installiert hat, wird auch zu barrierefreien pdfs und barrierefreiem flash keinen Zugang erhalten.

Ist die Analogie erkennbar?
Ich behaupte einfach, dass mein Chat “barrierefreies Javascript” verwendet.
Die Seite, die der Browser darstellt, beinhaltet nämlich gar kein Javascript mehr.
Vielmehr wird durch Javascript - genauer: AJAX - eine (fast) normale (X)HTML Seite erzeugt. (Dass die Quelltext-Anzeige des Internet Explorer dies nicht zeigt, ändert nichts an der Tatsache.) Und damit der Browser dieses Kunststück vollbringen kann, muss natürlich Javascript erlaubt sein.

Noch ein Vergleich gefällig?
Ein hochgradig Hörbehinderter, der sein Hörgerät nicht einschaltet, kann nicht Radio hören.
Wer Javascript deaktiviert hat, kann den Chat nicht benutzen.
Sturheit und Starrsinn sind keine Barrieren.

Weitere Aspekte und denkbare Kritikpunkte:

• HTML und CSS validieren, das Javascript erzeugt keine Fehler und Warnungen.
• Der Chat verwendet weder Frames noch Layout-Tabellen.
• Die Seite ist semantisch korrekt gegliedert, und mit (zum Teil unsichtbaren) Überschriften strukturiert. Listen und Formularelemente sind mit (unsichtbaren) Hinweisen versehen.
• Die Schriftgröße kann (fast) beliebig skaliert werden.
• Kontraste: da jeder Benutzer des Chat die Möglichkeit hat, sowohl die Hintergrundfarbe (verschiedene Skins) als auch die eigene Nick- und Textfarbe zu wählen, kann eine unglückliche Kombination zu schlechten Kontrasten führen. Dieses Manko ist durch wenige, einfache Anpassungen am Script bei Bedarf leicht zu beheben. Durch Wahl der Anzeigeoption “Farben aus” kann der User dies abstellen. In der Demoinstallation auf meiner Seite nehme ich dieses Manko zugunsten des Geschmacks der Mehrheit der typischen Chatter in Kauf.
• Es werden animated gifs für verschiedene Smileys verwendet. Der Admin kann entsprechende Smileys löschen.
• Uralt Browser wie IE 5.0 und Netscape Navigator 4, und natürlich auch alle Textbrowser, wie z.B. Lynx, die kein AJAX verstehen, bleiben leider aussen vor. (IE ab Version 5.5 kann AJAX.)
  Kann man die Verwendung eines Browsers aus dem vorigen Jahrtausend auch schon als Sturheit bezeichnen? ;-)
• Last but not least: Der Chat ist mit einer Vielzahl von Screenreadern auch von Blinden benutzbar. Und dieses Argument zählt meines Erachtens letztlich mehr, als buchstabengetreues Einhalten von Vorschriften und Normen
• Muss ich eigentlich noch erwähnen, dass auch Blinde selbstverständlich meine Smileys “sehen"?

Bei dieser Fragestellung sollte man vielleicht unterscheiden:

Haben Sie eine “Meine Oma, mein Hund, und mein Gartenzwerg mit der rosanen Mütze” Homepage, dann kann ich Ihnen garantieren, daß ich Ihre Homepage auf die erste Seite bei Google bringe.
Ob Sie sich diesen Service leisten wollen, steht auf einem anderen Blatt.

Sollten Sie jedoch beabsichtigen, Ihr Gewerbe mit dem Suchbegriff “Versicherungsvergleich” auf Top-Positionen in die Suchmaschinen zu bringen, dann sollten Sie erstens viel Geld bereitlegen, und zweitens niemandem glauben, der Ihnen das garantiert.

Zwischen diesen beiden Extremen gibt es jedoch ein weites Feld (kommerzieller) Seiten, die durch technische Mängel ihres Internetauftritts mögliche gute Plazierungen in Suchmaschinen verschenken, und damit potenzielle Kunden nicht erreichen. Eine Analyse der fraglichen Seiten zeigt meist recht schnell Fehler, die zu einer schlechten Plazierung führen, und Verbesserung ist in vielen Fällen mit relativ einfachen Maßnahmen möglich.

Aber bitte erwarten Sie kein Rezept a la “man nehme ….”

Moderne Handys, PDAs und handhelds können Internet. Mehr oder weniger gut. Am “weniger” sind in der Regel die Seitenschreiberlinge schuld. Seiten mit Tabellellayout, wie sie von fast allen CMS und WYSIWYG Editoren leider immer noch produziert werden, machen auf den kleinen Displays wirklich keine Freude.
Aber auch Dinge, die mit dem handheld Sinn machen würden, scheitern oftmals am verfügbaren Browser. Auf handheld mit Windows ist in der Regel der Internet Explorer vorinstalliert. Und der versteht Javascript nur unvollständig - und damit ist Online-Banking meist außen vor. Eigentlich schade.
Aber es gibt für handheld den Opera mobile. Der kann nicht nur ordentlich Javascript, sondern sogar AJAX. Zum Beleg hier ein Screenshot meines AJAX Chats auf dem PDA:

Unter diesem Thema fand am 12.10.06 im TechGate Vienna eine Veranstaltung statt, die in jeder Hinsicht meine Erwartungen übertraf. Ich möchte mit diesem kurzen Beitrag den Veranstaltern meinen herzlichen Dank bezeugen.

Der atemberaubende Blick aus dem 19. Stockwerk über das sonnige Wien war die perfekte Einstimmung auf anstrengende 6 Stunden Zuhören.

Die Wahl der Themen und die Abfolge der Beiträge war perfekt, und ließ nie Müdigkeit aufkommen. Von der trockenen Theorie, die der W3C Web Accessibility Specialist Shadi Abou-Zahra in lockerer Form vortrug, über die persönlich gefärbten Meinungen Jo Spelbrinks und der “eierlegenden Wollmilchsau” Tomas Caspers’, bis zur Vorstellung namhafter barrierefreier Auftritte (kurier.at und wien.at) spannte sich ein bunter Bogen, der, nie mit erhobenem Zeigefinger, aber auch nie oberflächlich oder seicht, viele Aspekte der komplexen Thematik dem Teilnehmer nahebrachte.

Die Organisation war perfekt, und die Moderatoren hatten die Veranstaltung stets mit lockerer Hand im Griff.

Ich wünsche der Veranstalterin accessible media, daß diese Veranstaltung sie einen Schritt weiterbringt auf dem Weg zu ihren Zielen.

Eine Nachlese zur Veranstaltung mit Links zu externen Berichten gibt es auf der Seite von accessible media.

Daß ich mir persönlich anschließend noch ein paar Tage in einer wunderschönen Stadt gönnte, und bei dieser Gelegenheit eine “Internetbekanntschaft” zu einem real existierenden Wesen wurde, sei nur am Rande erwähnt.

Viele “Webdesigner” verwenden das Attribut target="_blank” für externe Links, in der Absicht, Besucher auf Ihrer Seite zu halten.
Diese Technik ist benutzerunfreundlich: Der Bildschirm des Benutzers gehört ihm, und nicht dem Webdesigner.

Schlimmer noch: der Schuß geht nach hinten los, und die Absicht unseres “Webdesigners” verkehrt sich ins Gegenteil. Der “Zurück-button” des Browsers funktioniert nämlich auf neu geöffneten Fernstern nicht. Und damit werden weniger geübte Surfer, wenn sie das Browserfenster auf Bildschirmgröße eingestellt haben, gar nicht mehr auf die Seite zurückfinden, die sie mit Klick auf den Link verlassen haben.

Und erfahrene Surfer? Nun, die wissen, daß man z.B. mit Rechtsklick ein Kontextmenü öffnen, und jeden Link wahlweise in einem neuen Browserfenster öffnen kann.
Noch schneller: Strg + Klick (Firefox), oder Shift + Klick (IE, Opera)
Aber dies geschieht eben dann bewußt, und entsprechend der Absicht des Benutzers, und nicht in Form einer Bevormundung durch den “Webdesigner".

Einen Grundsatzartikel zu dieser Thematik hat Altmeister Jakob Nielsen schon vor vielen Jahren in seine Liste der 10 schlimmsten Fehler des Webdesign aufgenommen.

Und wer es gar nicht lassen kann: in diesem Beitrag habe ich eine Technik vorgestellt, wie man dem Benutzer die Entscheidung überlassen kann.

webdesign.weisshart.de ist Unterstützer im Aktionsbündnis für barrierefreie Informationstechnik.

Information soll allen Menschen zugänglich gemacht werden. Natürlich auch im Internet. Menschen mit Behinderungen sind häufig von der Benutzung des Internets wegen völlig unnötiger Barrieren ausgeschlossen.

Daher haben sich Behindertenverbände und Experten im Aktionsbündnis für barrierefreie Informationstechnik (AbI) zusammengeschlossen.

AbI steht dabei für:
A - Aktionsbündnis für
b - barrierefreie
I - Informationstechnik

Gemeinsam unterstützen sie die Umsetzung von Barrierefreiheit in der Informationstechnik.

AbI hat sich die Umsetzung des bestehenden Ordnungsrahmens (mit SGB IX und dem Behindertengleichstellungsgesetz) zum Abbau dieser Barrieren zum Ziel gesetzt.

Bisher haben sich bereits eine ganze Reihe an Partnern und Unterstützern AbI angeschlossen. Weitere Initiativen sind eingeladen, sich an dem Aktionsbündnis aktiv zu beteiligen.

Wer darauf angewiesen ist, weiß in der Regel, wie man die Schrift in seinem Browser vergrößern kann. Und das funktioniert auch, wenn der Ersteller der Website dies ermöglicht. Leider tun das viele Seitenschreiberlinge nicht, entweder aus Unwissenheit, oder, schlimmer, aus Borniertheit, nach dem Motto: »wie meine Seiten aussehen, bestimme ich.«
Klar, daß ich auf diesen Seiten die individuelle Einstellung der Schriftgröße zulasse.

Ich bin aber noch einen Schritt weiter gegangen, und biete jetzt für jedermann eine komfortable Möglichkeit an, die Schriftgröße in 15% Schritten zu vergrößern oder zu verkleinern.
Zu finden unter der Überschrift »Darstellung«
Die Einstellung wird per cookie 1 Jahr lang gespeichert, so daß Sie bei Ihrem nächsten Besuch auf diesen Seiten Ihre ganz persönliche Einstellung wieder vorfinden.

Hoppla! Was ist denn mit dem Design passiert? Ganz einfach, webdesign weisshart beteiligt sich am »CSS Naked Day«. Die Idee dahinter ist recht simpel: ist die Website noch benutzbar, wenn man sämtliche Formatierungen abschaltet? Verwendet die Website semantisches Markup, oder gehen ohne das Design wesentliche Informationen verloren?

Entstanden ist die Idee im Weblog von Dustin Diaz, der den »First Annual Naked Day: April 05« ausgerufen hat. Auf dieser Seite findet man auch eine lange Liste von Websites, die ebenfalls an der Aktion teilnehmen. Die Technik dahinter ist übrigens denkbar einfach – man muss dazu einfach nur sein /css/-Verzeichnis umbenennen.

Nachtrag: auch wenn heute erst der 4. April ist, auf der anderen Seite unseres Planeten ist bereits der 5. April. Daher dauert es auch 48 statt 24 Stunden, bis dieser Zustand vorbei ist.

… es sei denn, Du wählst aus meinem Styleswitcher einen Style aus; dann ist der Spuk vorbei, zumindest so lange, bis Du Deinen Browser neu startest. ;-)

Nachtrag 2: … und weil’s so schön war, hab ich die »Nacktversion« auch noch meinem Styleswitcher hinzugefügt.

Ja, man kann Flash sehr wohl XHTML valide einbinden.
Dazu muß lediglich der Code, der in vielen Beispielen zu finden ist, gehörig entrümpelt werden.
Hier eine Demo, die auch noch Spaß macht.

Die Geister scheiden sich daran, wie denn nun ein Link am besten geöffnet werden soll. Die einen schätzen ein neues Fenster, um die alte Ansicht nicht zu verlieren. Andere hassen das Fenstergewirr.

Ich überlasse die Wahl meinem Besucher!

In der Standardeinstellung werden Links im gleichen Fenster geöffnet. Vorteil: die Zurücktaste funktioniert wie gewohnt.
Und wer Links in einem neuen Fenster öffnen will, kann das jederzeit. Zum Beispiel so: Klick mit der rechten Maustaste, und dann die entsprechende Auswahl treffen (z.B.: “Link in neuem Fenster öffnen"). Moderne Browser bieten zu diesem Zweck mehr Komfort.

Bei Dr. Web hab’ ich mir jetzt eine pfiffige Lösung abgeguckt.
Das sieht so aus (hier nur ein Muster ohne Funktion):

Fremde Seiten in neuem Fenster öffnen?

In Aktion zu sehen hier im Blog gleich nach der Überschrift, oder auf meiner Referenzseite Suchscript im Menü.

Das Ganze erfordert allerdings Javascript. Und wer Javascript nicht aktiviert hat? Nun, dem steht eben dieser zusätzliche Komfort nicht zur Verfügung. Aber die Funktionalität der Seite ist natürlich gewährleistet. Der Fachausdruck hierfür heißt “unobtrusive Javascript”. (Eine griffige deutsche Übersetzung für diesen Begriff hab’ ich noch nicht gefunden. Aber dafür eine hervorragende Abhandlung zum Thema Javascript bei SELFHTML)

… in diese Verlegenheit bin ich kürzlich gekommen. Maus nicht zum Notebook eingepackt - und dann war da irgend ein Defekt am eingebauten Mauspad.
Jetzt galt es, Webseiten ausschließlich mit der Tastatur zu bedienen. Daß dabei die Tab-Taste die wichtigste Taste ist, war mir natürlich klar. Aber auf den meisten Seiten kam ich damit nicht weit.
Als Konsequenz aus dieser Erfahrung hab ich meine eigenen Seiten noch einmal nachgebessert. Wozu ich Tastaturkürzel eingebaut habe, und warum beim Durchtabben der jeweils aktive Link deutlich gekennzeichnet wird, ist mir jetzt erst richtig klar.
Wenn Sie wollen, probieren Sie’s einfach einmal aus, und legen Sie die Maus beiseite. Sie werden staunen.
Es gibt übrigens viele Menschen, die wegen motorischer Einschränkungen die Maus nicht bedienen können, und immer auf diese Weise surfen …

Wer Webseiten entwickelt, kennt das Problem. Die fertigen Seiten müssen zu allen Browsern kompatibel sein und die Darstellung sollte stimmen. Die Vielfalt der Betriebsystem- und Browser-Kombinationen macht jedoch einen Test schwierig.

Hier gibt es einen preiswerten Dienst, der es jedem Entwickler ermöglicht, seine Seiten live unter beliebigen Browsern und Betriebssystemen zu testen, ohne diese selbst vorrätig halten zu müssen.
weiterlesen…

Laaaaaangsam!

Jedenfalls, solange Sie kein UMTS Gerät der neuesten Generation besitzen, oder sich außerhalb des (nur langsam wachsenden) UMTS Empfangsbereichs befinden.
In beiden Fällen müssen Sie die Internetseiten über GPRS laden.
GPRS überträgt maximal 53,6 kbit/s, ist also theoretisch nur etwas langsamer als die früher weit verbreiteten 56 kbit Modems.
Aber eben nur theoretisch. Weil Sie sich die Bandbreite mit Millionen von Handy Nutzern teilen, sinkt die effektiv verfügbare Datenrate in der Hauptverkehrszeit drastisch. Das können auch einmal nur 5 kbit/sec oder noch weniger sein. weiterlesen…

Unter dem Titel “Webdesign für alle Browser” hab ich hier kürzlich gezeigt, wie meine Seite auf einem PDA aussieht. Der Screenshot dort stammt von einem XDA mit Windows CE und dem Internet Pocket IE Browser.

Jetzt hab ich endlich auch einen Screenshot von einem Palm. Danke Jonas alias Archer.
Schade ist nur, daß anscheinend der user den Palm erst in den sogenannten “optimierten Modus” zwingen muß.
weiterlesen…

Der BIENE-Preis wird an die besten barrierefreien Webseiten verliehen. Biene steht für “Barrierefreies Internet eröffnet neue Einsichten".
Mehr als 320 Webseiten wurden für den Wettbewerb 2005 eingereicht, 26 davon qualifizierten sich für das Finale. Insgesamt 16 Internet-Angebote haben die Aktion Mensch und die Stiftung Digitale Chancen im Wettbewerb für ein barrierefreies Internet ausgezeichnet. Der Auszeichnung vorausgegangen waren ein umfangreiches Testverfahren und die Entscheidung einer prominent besetzten Jury aus Medienmachern und Multiplikatoren.

Gleich zwei der prämierten Webauftritte verwenden mein Suchscript:
Das österreichische Jüdische Museum, BIENE in Bronze,
und Rechtsanwalt Dr. Oliver Tolmein, Sonderpreis.

Ja, für alle! und damit meine ich nicht nur Firefox, Opera oder den IE, sondern z.B. auch Browser, die auf einem PDA oder sogar Handy laufen.
Das sieht am Beispiel dieser Seite dann so aus:

Wohlgemerkt:
Es handelt sich nicht um eine spezielle Version dieser Seite, sondern um exakt dieselbe Seite, mit allen Inhalten, und mit der vollen Funktionalität. Lediglich Designelemente, die zum Lesen des Inhalts nicht unbedingt erforderlich sind, werden für handhelds per CSS ausgeblendet. Dafür werden andere Elemente eingeblendet: auf dem Bild zu sehen: der Sprunglink zum Überspringen der Navigation, direkt zum Inhalt. Auf diesen Displays, gerade mal 240 × 320 Pixel klein, hat einfach nicht viel Platz. Und Ladezeit ist ein K.o.-Kriterium.
Wer Lust hat, sich meine Seiten mal in einem PDA anzuschauen, und mit anderen Webseiten zu vergleichen, ist herzlich eingeladen. Ich freu mich über jede Kritik.

Eine wenig bekannte, aber nichts desto weniger berechtigte Forderung aus der Ecke usability lautet:
Die aktuelle Seite darf in der Navigation kein aktiver Link sein (sie sollte sogar für die Nutzer von screenreadern speziell ausgezeichnet sein, z.B. als “Standort").
Im Weblog gibt es diesbezüglich eine Besonderheit:
Sobald ich mir die Kommentare zu einem Beitrag anschaue, oder aus dem Archiv einen älteren Beitrag aufrufe, bin ich zwar immer noch im Weblog, aber eben nicht auf der Startseite des Blogs.
Wenn ich nun auf die Startseite des Blogs zurück wollte, dann war, aus oben genannten Gründen, der Link im Menü nicht aktiv.
Das war nicht gut.
Ich hab’s geändert.
Der Link im Menü ist jetzt immer aktiv, außer auf der Startseite des Weblogs.

so, das dürfte die letzte Aktion des Jahres sein:
Ich hab das Suchformular für die Suche im Weblog an die gleiche Position im Menü gestellt, an der auch die allgemeine Seitensuche zu finden ist. Aus Gründen der usability schon lange notwendig.
(Daß die Blogsuche nur die Beiträge selbst, aber nicht die Kommentare durchsucht, ist eine andere Geschichte - aber vielleicht ist das ganz vernünftig so?)

Dem Webmaster zeigt Lynx kompromißlos den wahren Inhalt seiner Internet-Seiten: So wie Lynx die Seiten anzeigt, d.h. ohne graphischen Schnickschnack, ohne Skript-Elemente, so “sehen” auch die Suchmaschinen die Internet-Seiten. Und auf diese Art zeigt sich recht einfach, wieso manche Internet-Seiten von den Suchmaschinen kaum oder nur zu unpassenden Suchwörtern gefunden werden. Mit Lynx sieht deshalb man auch, ob man Webseiten nach HTML-Standard erstellt hat oder Webseiten, die sich nur unter bestimmten Browsern oder gar nur unter bestimmten Browser-Versionen darstellen lassen.

Einen einfachen Weg, Lynx ohne großen Aufwand zu installieren, bietet Daniel A. Rehbein auf seiner Seite www.mein-dortmund.de

Die Flash Analoguhr, tausend mal im Netz, ist jetzt auch in meinem Menü zu bewundern.
Ja, ich weiß, Du hast selbst eine Uhr …
aber vielleicht wunderst Du Dich ja, wie lange Du auf meinen Seiten verweilst ;-)
Spaß beiseite:
Die Uhr dient nur dazu, zu zeigen, daß man Flash auch XHTML valide einbinden kann (der erste Schritt zur Barrierefreiheit). Der von Macromedia empfohlene Weg macht nämlich die Seiten invalide.
Wie es geht, kannst Du Dir ja im Quellcode meiner Seiten anschauen.
Beschrieben wird die Methode bei alistapart

Das beliebte online tool Bobby ist umgezogen.
Hierhin: webxact.watchfire.com
Und das Papperl gibt es dort nicht mehr. Damit dürften Tausend von Webseiten, die sich bisher damit geschmückt haben, obsolet sein.

Bobby, der accessability Validator, den ich routinemäßig meine Seiten testen lasse, mag das Weblog nicht.
Der einzige Punkt, der bemängelt wird:
Alle Links zum Kommentieren sind gleich bezeichnet.
Na ja, ob das eine echte Barriere ist?
Auf jeden Fall hab ich auf der Weblog Seite den Bobby Link aus dem Footer rausgenommen.
110%ig?
von mir aus!

Zu den wichtigsten Elementen auf einer Webseite zählt die Navigation. Wenn eine Seite wirklich für Alle zugänglich sein soll, dann muß auch und vor allem die Navigation unter allen denkbaren Bedingungen funktionieren.
Daß meine Seite auch unter Extrembedingungen zugänglich ist, dafür steht das folgende Beispiel:
Die Navigation, wie sie von Vorlesesoftware (sogenannten Screenreadern) “gesehen” wird,
hier zum Anhören als Flash Live Stream,
und hier zum download im mp3 Format (87 kB)

Dank an Eva Papst für die Audio Datei.

Das war schon lange auf der todo list:
Vollständige Sprachauszeichnung für Screenreader auf allen Seiten.
Auch das ist jetzt abgehakt - zumindest fast: Wie ich mit Englisch - Deutsch zusammengesetzten Wortungetümen wie z.B. Browserfenster umgehen soll, weiß ich nicht so recht. Ich hab mal gelesen, daß die Screenreader bei jedem Sprachwechsel eine mehr oder weniger lange Pause einlegen. Und dann klingt das so: Browser……..fenster.

Und noch ein Problem bleibt:
beim Schreiben hier im Weblog” muß ich jeden Sprachwechsel manuell codieren; und das ist nicht nur mühsam, sondern beinhaltet auch die Gefahr, daß sich Syntaxfehler einschleichen. Also schreiben - validieren - korrigieren u.s.w.
Mal sehen, ob ich Wordpress nicht doch noch so konfigurieren kann, daß die Tags zur Sprachauszeichnung einfacher einzufügen sind.

Das Navigationsmenü auf dieser Seite ist als <ul> ausgezeichnet, und hierarchisch gegliedert. Damit kann ich u.a. Submenüs kontextabhängig ein- und ausblenden.
Wie die Struktur der Navigation aussieht, kann man am besten auf der Sitemap sehen.
Screenreader haben damit Probleme, weil sie die Listenstruktur nicht erkennen.
Bei einfachfueralle.de wird eine Lösung für dieses Problem vorgestellt, unter Verwendung von logischen Textauszeichnungen mittels <dfn>.
Ich hab das mal hier eingebaut. Zu sehen ist das auf dem Bildschirm aber nur im Style “easy” (und am besten wieder auf der Sitemap). Für alle anderen Styles werden diese logischen Textauszeichnungen per CSS ausgeblendet.
Und im Quellcode kann man sich natürlich das ganze Menü anschauen.

Was für die Navigation gilt, gilt auch für den Styleswitcher:
die aktuelle Auswahl sollte gekennzeichnet und kein aktiver Link sein - ein häufig vernachlässigtes usability feature.
Ich hab das heute mal umgesetzt. Und da meine Navigation einschließlich Styleswitcher per PHP eingebunden wird, mußte ich noch eine Abfrage einbauen, welcher Style gerade aktiv ist. Und das funktioniert natürlich per cookie-Abfrage.

Barrierefreiheit ist ein wichtiges Thema auf diesen Seiten (und nicht nur hier!)
Heute hab ich dazu einige Anregungen von Eva Papst, Verlagsleitung des Bundes-Blindenerziehungsinstituts in Wien erhalten.
Die wesentlichen Kritikpunkte waren:

• accesskeys: manche machen den Browser kaputt
• kein Link zur aktuellen Seite
• Sprachwechsel kennzeichnen

Manche accesskeys machen den Browser kaputt

Die Accesskeys sind ja heiß umstritten, aber dass Sie mir z.B. ALT*D wegnehmen, womit ich doch ins Datei-menü komme, schmerzt ein wenig. Gerade wer keine Maus hat und auf die Tastatur angewiesen ist, benötigt die browser-eigenen Kombinationen dringend!

Die Konsequenz aus diesem Hinweis war drastisch: Ich hab alle accesskeys mit Buchstaben rausgenommen, und verwende nur noch die Ziffern 0 - 9. Denn je nach Browser und der auf diesem Browser eingestellten Sprache können eventuell alle Buchstaben zur Bedienung des Browsers erforderlich sein.

Kein Link zur aktuellen Seite

Noch ein Hinweis auf ein usability-Merkmal: Eine Seite sollte nicht auf sich selbst verweisen und nicht als Link, sondern als Standort angedruckt sein. Ich weiß, dass dies so manches CMS vor Probleme stellt, aber es handelt sich dabei ja nicht um ein BF-Merkmal, sondern eine sehr berechtigte Anforderung aus der Ecke Usability, also für alle!

Ja, ja, das wußte ich ja. Aber mein Menü wird dynamisch per PHP erstellt und in die einzelnen Seiten eingebunden. Und da war doch einiges an Handarbeit erforderlich, um diesen Hinweis umzusetzen. Aber ich denke, die Arbeit hat sich gelohnt.

Sprachwechsel kennzeichnen

…auf die kleinen Mängel weißt man aber hin - wie z.B. auf die fehlenden Sprachwechsel.

Die Auszeichnung von Sprachwechsel betrifft vor allem die vielen Anglizismen, ohne die es anscheinend nicht geht; Homepage ist das erste Beispiel. Und die Auszeichnung eines Sprachwechsels muß im Quelltext vorgenommen werden - da hilft kein PHP, kein CSS und kein Javascript. O.k., ich hab mal angefangen damit.