Damit Benutzern von Screen Readern der Inhalt von Webseiten verständlich vorgelesen wird, kann / soll man fremdsprachige Wörter / Passagen mit dem lang-Attribut auszeichnen. Darüber habe ich mehrfach gebloggt. Zuletzt hier: Sprachwechsel oder nicht - die Dritte

Ein Sonderfall sind “denglische” Ausdrücke, also Wörter, die einem deutschsprachigen Leser wie englisch erscheinen, aber nicht wirklich englisch sind. Beispiel: “Webdesign” gibt es im Englischen nicht. Korrektes Englisch ist vielmehr “web design".

Hier 4 Varianten:

• webdesign ohne Auszeichnung
• webdesign mit Auszeichnung
• web design ohne Auszeichnung
• web design mit Auszeichnung

Wie der verbreitete Screen Reader Jaws (Version 11.0) mit dieser Situation umgeht, zeigt folgendes Hörbeispiel.

Download des Hörbeispiels (mp3 - 82 kB)

Der kostenlose Screen Reader NVDA wiederum zeigt sich von jeglicher Sprachauszeichnung unbeeindruckt. Die von mir verwendete Spache “Steffi” hat aber dafür ein integriertes Aussprachewörterbuch, um den gebräuchlichen Ausdruck “Webdesign” korrekt auszusprechen:

Download des Hörbeispiels (mp3 - 77 kB)

Es gibt übrigens noch viele solcher Beispiele. Um nur eins zu nennen: Screen Reader ist englisch. Nicht aber Screenreader, oder (von) Screen Readern.

Der geneigte Web Worker (nicht: Webworker!) möge sein eigenes Urteil fällen.

Sprachwechsel innerhalb eines HTML-Dokuments sollen/müssen entsprechend ausgezeichnet werden. Unter anderem, damit die jeweiligen Passagen von Screen Readern richtig vorgelesen werden.
Zu diesem Thema habe ich mich hier im Blog bereits mehrmals geäussert:
/blog/2009/09/26/sprachwechsel-fur-screen-reader-auszeichnen/
und
/blog/2010/04/10/sprachauszeichnung-oder-nicht-sprachauszeichnung/
Mein Fazit: Zurückhaltung beim Auszeichnen von Sprachwechseln ist angesagt. Auch der Blind-Text Blog vertritt im Wesentlichen meine Haltung.

Eine zufällige Erfahrung bestärkt mich in meiner Haltung: Ich hatte den Screen Reader NVDA mit der deutschen Stimme von Steffi aktiviert, und besuchte die englischsprachige Seite angularjs.org. Das hört sich dann folgendermaßen an:

Download des Hörbeispiels (mp3 - 306 kB)

Erstaunlicherweise ist der Text relativ gut verständlich, obwohl, wie gesagt, der Screen Reader auf Deutsch eingestellt war. Zu verdanken ist dies dem Hersteller des Screen Readers bzw. dem Hersteller der synthetischen Sprache, der viele gebräuchliche englische Begriffe in ein entsprechendes Wörterbuch aufgenommen hat.

Was will ich damit zeigen? Nein, ich plädiere nicht für falsche/fehlende Sprachauszeichnung für das ganze Dokument. Ich will nur zeigen, dass auch längere Passagen in Englisch ohne eine “richtige” Sprachauszeichnung relativ gut verständlich sind. Möglicherweise, abhängig vom verwendeten System aus Screen Reader und Sprachdatei, sogar besser als mit ausgezeichnetem Sprachwechsel.

Der Firefox macht um den Absende-Button von Formularen einen gepunkteten Rahmen, wenn man den Button per Tabulator-Taste ansteuert.
Das kann im Falle eines sorgfältig gestaltetes Designs arg stören. Ein Beispiel ist der per CSS “rund gemachte” Absende-Button meines Suchformulars. (siehe diesen Beitrag.)

Ein eckiger Rahmen um einen runden Button, das sieht wirklich nicht gut aus.
Aber dieser Rahmen widersetzt sich sich allen Versuchen, ihn per CSS zu entfernen, recht störrisch.

Und es geht doch

Dirk Ginader hat es ganz kurz und trocken getwittert.

Die CSS Anweisung dazu lautet:

input[type=submit]::-moz-focus-inner {border: 1px dotted transparent;}

Ja, genau so. Auch wenn die Syntax fremd erscheint.

Wer nicht generell alle Submit-Buttons stylen will, sondern nur bestimmte mit id oder class ausgezeichnete Buttons, kann die CSS Anweisung natürlich entsprechend abändern. Für einen Button mit der Klasse senden :

.senden::-moz-focus-inner {border: 1px dotted transparent;}
bzw. für einen Button mit der id senden:
#senden::-moz-focus-inner {border: 1px dotted transparent;}

Wichtig: Bitte unbedingt sicherstellen, dass der Fokus, wenn nicht mittels des gepunkteten Rahmens, dann auf andere Art klar kenntlich gemacht wird! Dies ist unentbehrlich für Tastatur-Nutzer, damit sie den Fokus sehen, d. h. wissen, welches Seitenelement gerade aktiv ist.

PS: Kennt jemand eine Methode, den Rahmen auch für Webkit (Chrome, Safari) und Opera zu entfernen. Nach dem IE frag’ ich erst gar nicht. Dort fällt es übrigens gar nicht so sehr ins Gewicht, weil der IE ohnehin den per CSS rund gestalteten Submit-Button nicht darstellen kann.

Eine alte Usability- und Accessibility-Forderung: Besuchte Links kennzeichnen. Und zwar nicht nur farblich.
Auf webdesign weisshart wurde das bisher ganz deutlich in Form eines Häkchens hinter besuchten Links gemacht.

hacks.mozilla.org hat vor einiger Zeit angekündigt, dass der CSS Selector :visited aus Sicherheitsgründen zukünftig nicht mehr unterstützt wird:

For many years the CSS :visited selector has been a vector for querying a user’s history. It’s not particularly dangerous by itself, but when it’s combined with getComputedStyle() in JavaScript it means that someone can walk through your history and figure out where you’ve been. And quickly – some tests show the ability to test 210,000 URLs per minute. At that rate, it’s possible to brute force a lot of your history or at least establish your identity through fingerprinting. Given that browsers often keep history for a long time it can reveal quite a bit about where you’ve been on the web.

At Mozilla we’re serious about protecting people’s privacy, so we’re going to fix this problem for our users. To do so we’re making changes to how :visited works in Firefox. We’re not sure what release this will be part of yet and the fixes are still making their way through code review, but we wanted to give a heads up to people as soon as we understood how we wanted to approach fixing this.

Seit gestern setzt als erster Browser der Safari 5 diese “Drohung” um. Es ist also wohl nur eine Frage der Zeit, bis Firefox nachzieht. Das Häkchen ist damit Geschichte. Es bleibt die farbliche Kennzeichnung. Eine spannende Frage kann ich derzeit nicht testen: Wie sind besuchte Links zukünftig in Screen Readern erkennbar?

Nachtrag: VoiceOver, der Screen Reader von Apple, erkennt besuchte Links, hat mir eben ein Bekannter bestätigt.

Eine berechtigte Forderung, wenn es um Usability im Allgemeinen, oder um Barrierefreiheit im Besonderen geht:

Eine Seite soll nicht auf sich selbst verweisen.

Es leuchtet ohne nähere Erklärung ein, dass das folgende Beispiel irritieren kann:

Du bist hier: Startseite - zur Startseite wechseln

Dieses Beispiel findet sich auf einer ansonsten technisch absolut sauber umgesetzten Seite. Der Seitenbetreiber mag mir nachsehen, dass ich ausgerechnet sein Projekt als negatives Beispiel zitiere. Im günstigsten Fall ist er mir für den Hinweis dankbar. Übrigens: Toscho nannte das Problem beim Namen: Deppenlink

Mehr als irritierend kann so etwas für Menschen sein, die nicht den Überblick über den ganzen Bildschirm haben. Zum Beispiel Benutzer von Screen Readern. Idealerweise sollte man die jeweils aktuelle Seite in einer Navigation nicht nur nicht verlinken, sondern auch mit einem Hinweis ausstatten, z. B.: “Standort:". Wie dies gedacht ist, zeigt folgender Screenshot aus der Navigation auf meiner Startseite, mit abgeschaltetem CSS (wie auch Screen Reader die Seite vorlesen):

Aber jetzt mein Rezept gegen den “Deppenlink”

Das Problem: Die Navigation wird per PHP in alle Seiten eingebunden. Immer die gleiche Navigation. Nun muss natürlich PHP entscheiden, welches die jeweils aktuelle Datei ist, und den Link auf sich selbst durch einen unverlinkten Text ersetzen.

Zuerst den Dateinamen der aktuellen Seite in eine Variable:
<?php $a = $_SERVER['PHP_SELF']; ?>


Und dann eine if-else Abfrage, hier am Beispiel eines Links, der zur Seite /index.php führt:

<?php
if ($a!="/index.php") {
echo '<a href="/">Startseite</a>';
} else {
echo '<span class="cur"><dfn>Standort: </dfn>Startseite</span>';
}
?>


Anmerkung:
In der Praxis schreibe ich diese if-else Abfrage in Kurzform. Hier jedoch zugunsten der einfacheren Lesbarkeit die ausgeschriebene Form.

Wozu nun der span class="cur"? Nun, dieser Span kann jetzt individuell per CSS so gestylt werden, dass er zum Design der Seite passt.

Und was hat es mit <dfn>Standort: </dfn> auf sich?
Der Hinweis “Standort:” soll nur von Screen Readern vorgelesen werden.
Eine einfache CSS-Regel erledigt dies:

dfn {
position:absolute;
left:-9000px;
width:0;
height:0;
overflow:hidden;
display:inline;
}


Formular-Eingaben, z. B. Kommentare hier im Blog, müssen selbstverständlich überprüft werden, bevor die Eingaben in die Datenbank auf dem Server geschrieben werden.
Heute geht es aber um die Überprüfung der Eingaben vor dem Absenden. Genauer: die Prüfung, ob alle Pflichtfelder ausgefüllt wurden. Noch genauer: Um die Behandlung von Fehleingaben.
Dies muss auf dem Server erfolgen. Weil eine clientseitige Überprüfung, z. b. mittels JavaScript, nicht greift, wenn der Besucher JavaScript deaktiviert hat.

Aber um die Usability zu verbessern, kann man eine Prüfung per JavaScript vorschalten.
Der Benutzer erhält so beim Drücken des Absende-Buttons sofort eine - möglichst aussagefähige - JavaScript-Meldung, wenn ein Pflichtfeld nicht ausgefüllt wurde, und nach Quittieren dieser Meldung wird er unmittelbar auf das fehlerhafte Eingabefeld geschickt.
Hier eine gute Anleitung.

Danke an Eva Papst für das Einfordern dieses Usability-Features.

Farbfehlsichtigkeit ist weit verbreitet. 8 bis 10% der Männer leiden unter irgend einer Form von Farbfehlsichtigkeit. Farbfehlsichtigkeit ist häufig auch mit anderen Sehbehinderungen verbunden.
Dennoch kommt dieses Thema im Zusammenhang mit Barrierefreiheit wenig bis kaum zur Sprache.
Dabei gibt es viele gute Tools zum Testen.
Ich benutze und empfehle Wickline
Wickline simuliert online verschiedene Arten von Farbfehlsichtigkeit. Wickline kann, wie viele andere Tools, nicht automatisch Barrierefreiheit testen. Aber Wickline kann für das Thema Farbfehlsichtigkeit sensibilisieren, und ist in der Hand eines verantwortungbewussten Webdesigners ein wertvolles Werkzeug.

Ich habe Wickline in meine Werkzeugsammlung aufgenommen.

Lange gesucht - und endlich gefunden: eine Möglichkeit, Text vor Screen Readern zu verstecken.
(Nein, das ist nicht ernst gemeint. Alle erbosten Kommentare bitte vorläufig zurückstellen.)
Danke an www.textdreher.de/ für die Idee.
Den folgenden Satz können Screen Reader nicht lesen (oder, besser gesagt, nicht verstehen):

:nednufeg hcildne dnu - thcuseg egnaL
.nekcetsrev uz nredaeR neercS rov txeT ,tiekhcilgöM enie

Nachtrag 7. Mai 2010
Der Kommentar von Eva veranlasst mich jetzt doch zu einigen Ergänzungen.

1. So hört sich der Text mit dem Screen Reader NVDA an:
   
   
   Download des Hörbeispiels (mp3 - 345 kB)
2. Eva schlägt eine Retourkutsche vor: Text so verschlüsseln, dass nur Braille-Kundige ihn verstehen. Das sieht dann so aus:
   

   lge &su4t’- u cd_ &f/dc:
   6e m_k, te’xt ? s’crec read7n z -}e$c.

   Und hier noch auszugsweise Evas Erläuterungen dazu:

   In der [Braille-]Kurzschrift gibt es so genannte Zweilautkürzungen, z.B. lg = lang.
   Diese können Endungen annehmen; lge = lange.

   Einlautkürzungen: z.B. u = und. Hier darf nichts angehängt werden.

   Silbenkürzungen:
   - 6 = ein
   - & = ge
   - 4 = ch
   usw.

Danke, Eva. Die beste Kurz-Erklärung zu Braille-Kurzschrift, die ich bisher sah.

WAI ARIA ist eine Technologie, die es Entwicklern ermöglicht, ihre Seiten besser für Nutzer von Screen Readern zugänglich zu machen.
Eine Einführung in WAI ARIA in deutscher Sprache
Eine Teilmenge von WAI ARIA, die landmark roles, hilft bei der Orientierung, indem typische Bereiche von Webseiten mit standardisierten Namen bezeichnet werden.
Ich habe landmark roles auf meinen Seiten eingesetzt. Für die Bereiche

• Kopf
• Suchformular
• Navigation, und
• Inhalt

Screen Reader können jetzt mit einem Tastenkürzel (NVDA: d, Jaws: ö) diese Bereiche anspringen. Die angesprungenen Bereiche werden mit standardisierten Namen angesagt. Diese Namen lauten im Falle meiner vier Bereiche

• Logo
• Suche
• Navigation, und
• Haupt

Das Anspringen der landmarks mit dem Screen Reader NVDA:


Download des Hörbeispiels (mp3 - 349 kB)

Das Einfügen von ARIA landmarks

Der HTML-Code hierfür lautet beispielsweise:
<div role="navigation">
Wollte man diesen Code manuell in alle Seiten einpflegen, dann könnte das in Arbeit ausarten. Wir machen uns einfach den Umstand zunutze, dass die betroffenen Bereiche ohnehin mit id-Attributen ausgezeichnet sind. Mit wenigen Zeilen JavaScript lässt sich ganz einfach zusätzlich zur id das jeweilige role-Attribut setzen.

function addARIARole(strID, strRole)
{
    // Find the element to add a role property to
    var objElement = document.getElementById(strID);
    if (objElement)
    {
        // Add the role property to the element
        objElement.setAttribute('role', strRole);
    }
}
function setupARIA()
{
// Add ARIA roles to the document
    addARIARole('inhalt', 'main');
    addARIARole('menu', 'navigation');
    addARIARole('suchform', 'search');
    addARIARole('headimg', 'banner');
}

Nun noch dafür sorgen, dass die Funktion setupARIA onload aufgerufen wird, und ohne viel Arbeit ist ein weiterer Schritt zur Barrierefreiheit getan.

Sprachauszeichnung - die zweite Lektion für jeden, der sich mit Barrierefreiheit beschäftigt. Damit Screen Reader das Web-Dokument in der richtigen Sprache vorlesen.

Klar, die (Haupt-)Sprache des Dokuments muss im <head> ausgezeichnet werden. Artikel zu Sprachauszeichnung bei www.456bereastreet.com

Ganze Sätze, z.B. Zitate, in abweichender Sprache, sollte man auf jeden Fall auszeichnen.

Aber wie verhält es sich mit einzelnen Wörtern oder Phrasen? In diesen Fällen gilt es, unter Anderem auch Folgendes zu bedenken:

• Nicht jeder Screen Reader unterstützt automatisch jede Sprache. Im Grundpaket sind wohl etliche fremdsprachliche Stimmen enthalten, andere müssen hingegen separat gekauft und installiert werden.
• Eine Besonderheit stellt der kostenlose Screen Reader NVDA dar, der ständig mehr Anhänger findet: Er unterstützt keine Sprachwechsel innerhalb eines Dokuments.
• Einen abweichenden Ansatz verfolgt der Screen Reader VoiceOver, der in iPhone, iPod und iPad ab Werk verfügbar ist: dort sind zig (20?) Sprachen standardmäßig enthalten.
• Jeder Sprachwechsel innerhalb eines Dokuments unterbricht den Lesefluss. Es dauert, bis die Software “den Schalter umlegt". Und jede Sprache hat einen abweichenden Klang; auch das kann den Lesefluss stören.
• Viele gebräuchliche Fremdwörter, z.B. aus der Informationstechnologie, sind in Screen Readern bereits mit der korrekten Aussprache hinterlegt, und werden auch ohne Sprachauszeichnung korrekt ausgesprochen.
  Hier ein Beispiel mit solchen Ausdrücken ("Open Source Flash Video Player") gelesen vom NVDA:
  
  
  Download des Hörbeispiels (mp3 - 294 kB)
• “Eingedeutschte” Deklination von Fremdwörtern (z. B. “in Screen Readern") darf nicht in der Fremdsprache ausgezeichnet werden, weil es diese deklinierte Form in der jeweiligen Fremdsprache höchstwahrscheinlich gar nicht gibt. Gleiches gilt für zusammengesetzte Fremdwörter, die laut neuer deutscher Rechtschreibung zusammen geschrieben werden. Beispiel: Longdrink.
• Zuletzt noch ein Fall, der zwingend die Auszeichnung einzelner Wörter verlangt: Eigennamen. In diesem Fall dürfte kein Screen Reader die korrekte Aussprache “erraten". Beispiel mit korrekter Auszeichnung: Giscard d’Destaing oder ohne Auszeichnung: Giscard d’Destaing

Ein schönes Beispiel mit Sprachauszeichnungen gibt es bei 456bereastreer. Wer einen oder gar mehrere Screen Reader verfügbar hat, findet hier interessantes Material für eigene Tests.

Mein Fazit: Ich bin mit Sprachauszeichnung von einzelnen Wörtern inzwischen äußerst zurückhaltend. Im Zweifel verzichte ich darauf. Wenn ich es ganz genau machen will, und mir viel Zeit nehme, dann teste ich ausgewählte Texte mit NVDA und Jaws.

Gerrit van Aaken hat in seinem Blog einen guten Artikel über den aktuellen Stand von Videos im Web geschrieben.
Das Ergebnis unter Einsatz von HTML5 und einem Fallback unter Verwendung des Open Source Flash Video Players Flowplayer überzeugt erst einmal durch wunderschön schlanken Code.
Um die vorgestellte Technik selbst zu erproben, habe ich hier eine eigene Demo erstellt.
Und ich muss leider feststellen, dass der aktuelle Stand zwar technisch hochinteressant, aber eben doch noch nicht ganz reif ist für die freie Wildbahn.
Meine Beobachtungen:

• Unter Windows kann nur der Google Chrome Browser das HTML5 <video> im H.264 Format abspielen.
• Alle anderen Browser verwenden das - zugegebenermaßen elegante - JavaScript, das auf das Flowplayer-Fallback umschaltet.
• Opera/Win in der aktuellen Version 10.51 kann das Video im Flowplayer gar nicht abspielen
• Safari/Win in der aktuellen Version 4.0.5 spielt das Video erst, nachdem es komplett heruntergeladen ist. Je nach Größe des Videos und Qualität der Internetverbindung kann das unakzeptabel lange dauern.
• Und das gewichtigste “Aber": Für Nutzer eines Screen Readers oder für Besucher ohne Maus ist sowohl der vom HTML5 <video> Tag erzeugte Player, als auch der Flowplayer vollkommen unbenutzbar. In beiden Fällen wäre eine zusätzliche Steuerung per JavaScript nachzurüsten, wie ich es z. B. in diesem Artikelvorstelle. Und damit ist der Charme des schlanken Codes wieder hinfällig.
  Accessibility-Features wie Untertitel oder Audio-Descriptions: Leider auch Fehlanzeige.

Es heißt also weiter warten auf den “heiligen Gral", den Gerrit van Aaken etwas vollmundig versprochen hat.

CAPTCHAs sind unwirksam, und schließen Menschen aus. Wie oft wurde darüber schon geschrieben. CAPTCHAs wollen sicherstellen, dass ein Mensch, und nicht eine Maschine, ein Formular ausfüllt. Wobei man Maschine gleichsetzt mit Spambot. Wer täglich gegen Spam jeglicher Art kämpft, hat mein volles Verständnis. Und ich kann auch verstehen, dass man jede Maßnahme bereitwillig übernimmt, die Abhilfe gegen die lästigen Spambots verspricht. Aber CAPTCHAs sind einfach der falsche Weg.
CAPTCHAs können von Maschinen leichter gelöst werden als von Menschen!
Lassen Sie mich das an einem Beispiel erläutern:
Das homepage-forum.de verwendet die Forensoftware vBulletin.
Dort versucht man, Spambots mit CAPTCHAs auszuschließen. Diese CAPTCHAs sehen z. B. so aus:

Ich schaffe es nicht, auch nur eines der gezeigten CAPTCHAs zu lösen. Und weil es vermutlich nicht nur mir so geht, hat vBulletin eine pfiffige Funktion eingebaut: Ein Link unter dem CAPTCHA “Grafik neu laden” ermöglicht es, ein neues CAPTCHA aufzurufen. Beliebig oft! Und nach einigen Versuchen sind auch lesbare CAPTCHAs dabei:

Klasse.
Denkste!
Genau diese leicht lesbaren CAPTCHAs sind ein Kinderspiel für Maschinen, die mit OCR arbeiten. Und Maschinen, anders als Menschen, haben keine schlechten Nerven. Sie geben nicht nach einigen erfolglosen Versuchen entnervt auf. Vielmehr haben sie schier endlose Geduld. Wie gesagt: ein neues CAPTCHA kann beliebig oft angefordert werden. Und anders als bei Menschen, genügen den Spambots Trefferquoten von 10%, 1% und sogar weniger. Im Klartext: Wenn ein Mensch ein CAPTCHA nach dem 10 Versuch noch nicht gelöst hat, dann dürfte auch der Geduldigste entnervt aufgeben. Anders ein Spambot: wenn der nur bei jedem 100sten Versuch erfolgreich ist, dann genügt das immer noch, um die Welt mit Spam zu beglücken.
Nach dieser langatmigen Einleitung komme ich auf den Punkt:
Offensichtlich wurde auch das homepage-forum.de von Spambots beglückt. Und der vermeintliche Spamschutz mit CAPTCHAs war offensichtlich unwirksam. Deshalb hat homepage-forum.de zusätzlich! zur CAPTCHA-Abfrage jetzt noch eine Rechenaufgabe eingeführt. Rührend! Warum man sich von den CAPTCHAs nicht trennen konnte oder wollte, kann ich nicht nachvollziehen. Eine intelligente Kombination alternativer Möglichkeiten, wie hier beschrieben, würde Menschen nicht ausschließen/nerven, und Spambots sicher in die Schranken weisen.

Wenn einer eine Reise tut … dann sollte er sich tunlichst vorbereiten. Im Falle einer Urlaubsreise, auch wenn sie mit einer Reisegruppe erfolgt, gehört dazu unter anderem das Studium der Reiseroute. Google bietet hierfür mit Google Maps ein Werkzeug, um eine Route mit beliebig vielen Stationen auf einer Karte einzuzeichnen.


Bis hierher ist das nichts Besonderes, und kaum der Rede wert.
Wenn aber blinde Menschen verreisen - oh ja, sie tun das, wie man hier nachlesen kann - dann erfordert die Reise Vorbereitungen besonderer Art. Nicht zu sehen bedeutet ja keineswegs, kein Interesse an der Geographie des Urlaubsziels zu haben.
Mir war also die Aufgabe gestellt, die von Google Maps ausgegebene Reiseroute “erfühlbar” zu machen. Moderne Technik macht’s möglich. Ein spezieller Drucker kann neben normaler Grafik zusätzlich ein erhabenes, tastbares Relief der Grafik “drucken". Zusätzlich heißt, die sichtbare und die tastbare Grafik überlagern sich; sehende und tastende Betrachter können ein und denselben Ausdruck benutzen, und sich z. B. über Details austauschen.
Das klingt großartig, und ist es auch. Wie anders als mittels einer Grafik sollte man den zerklüfteten Umriss von Schottland erklären, und die Lage einer Reiseroute und der einzelnen Stationen beschreiben.
Gut, bei sehr detailreichen und/oder kontrastschwachen Grafiken - beides trifft auf Google Maps zu - ist einiges an manueller Vorbereitung nötig. Die Fingerkuppen von geschulten blinden Menschen sind zwar unvorstellbar sensibel, aber an die Auflösung des Gesichtssinns kann der Tastsinn nicht heranreichen. Weniger wichtige Details müssen also manuell entfernt, wesentliche Konturen, wie die Küstenlinie oder die Reiseroute hervorgehoben werden.
Das folgende Bild zeigt die für den Reliefdruck bearbeitete Grafik, und vermittelt einen Eindruck, wie die Prägung “aussehen” wird.


Bei der Vorbereitung für den Prägedruck hilft natürlich eine spezielle Software.

Nochmals zur Klarstellung: die beiden Versionen der Grafik, farbiges Bild und tastbare Prägung, werden auf einem Blatt deckungsgleich übereinander gedruckt.

Als letzter Schritt noch die wichtigsten Stationen der Reise mit Braille-Schrift markieren. Anders als auf normalen Landkarten kann die Braille-Beschriftung jedoch nicht einfach “über” das Bild gelegt werden, weil die tastenden Finger einen “ruhigen” Hintergrund brauchen. Um Platz zu sparen, werden für die Beschriftung daher möglichst nur einzelne Buchstaben oder Ziffern verwendet, und eine separate Legende bereitgestellt:

A: Hull
B: York
C: Carlisle
D: Glasgow
E: Loch Lomond
F: Oban
G: Isle of Mull
H: Aviemore
I: Edinburgh
J: Newcastle upon Tyne

Gute Reise!

Nachtrag 3. Mai 2010 - ein Belegexemplar

Eva, die sich in einem Kommentar als “Nutznießerin” outete, hat mir netterweise ein “Belegexemplar” zukommen lassen; mit dem genannten Spezialdrucker erzeugt, also sichtbare und tastbare Grafik überlagert. Im Gegenlicht aufgenommen, kann man auf dem Foto die Prägung gut erkennen. Und mit etwas Phantasie kann man auch Evas Begeisterung nachempfinden.

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.