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.

Falls Sie nichts erkennen können, ziehen Sie Ihre Augenlider mit den Fingern wie bei einem Chinesen zu einem Schlitz.

Auf dem Bild sieht man verschieden große Quader, fast wie Bauklötze. Wenn man gemäß Anleitung die Augenlider zu einem Schlitz zieht, kann man plötzlich lesen: “No sex causes bad eyes” – auf Deutsch: “Kein Sex macht schlechte Augen”

Diesen - nicht ganz ernst gemeinten - , sowie weitere “richtige” Sehtests gibt es bei www.augen.de

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. :-)