ich bin etwas aufbrausend, was das Thema angeht und ich findn Deinen Artikel zu unobtrusiven Javascript wirklich gut. Einige Dinge sind mit kurzen Worten sehr gut erklärt.

Und du hast auch recht, dass das ein wichtiges Thema ist.

Meine Grundkritik bleibt dennoch bestehen – gerade weil es erkennbar ein Einsteigertutorial ist.

Der Artikel vermittelt den Eindruck, dass das Wichtigste an zugänglichem JS schlichtweg die Frage ist, ob die Seite auch ohne JS noch funktioniert. Und diese Halbwahrheit schadet mehr, als dass sie hilft. Das führt in aller Regelmäßigkeit dazu andere schwerwiegende Barrieren nicht zu berücksichtigen.

Dieser Eindruck wird insbesondere dadurch verstärkt, dass das Beispiel einen Teil der Funktionalität ausschließlich bei einem mouse-enter/leave Event zugänglich macht. Angesichts der Tatsache, dass man nicht weiss, welche Funktionalität sich dahinter verbirgt, hätte man es sich leicht machen und dieselben Eventhandler – unter Hinweis der Tastaturbenutzbarkeit – ebenso für focus/blur verwenden können.

Bzgl. Tab-Script bin ich tatsächlich sehr gespannt. Gerade bei dem Tab-Widget weiß ich nicht wie andere zu dem Problem um die Ctrl-PageUp/PageDown – Behandlung stehen. (Bei Jaws wird bei eingeschalteter "Menühilfe" diese Nutzungsmöglichkeit zu allem Überfluß auch noch angesagt.) kurze Beschreibung der Ctrl-PageUp/PageDown-Funktionalität und dem dazugehörigen Problem

vielleicht geht es aus Überschrift und Teaser nicht eindeutig genug hervor, doch dieser Beitrag richtet sich an JS-Einsteiger. jQuery, YUI und andere JS-Frameworks haben die Hemmschwelle für den JS-Einsatz stark verringert.

Natürlich hast Du recht damit, dass diese Regeln noch lange nicht alles sind, aber sie sind die notwendigen Schritte für den Start.

Dieser Artikel beschreibt mehr wie man Webseiten für User mit augeschaltetem JS zugänglich macht, nicht wie man barrierefreies JavaScript schreibt.

Genau das ist ein wichtiger Punkt, der in Verbindung mit der einfachen Anwendung von JS-Frameworks oft vergessen wird. Zwar zwingt die WCAG 2.0 nicht mehr dazu, dass in jedem Fall ein HTML/CSS-Fallback vorhanden sein muss, in den vielen Fällen macht dies jedoch auch weiterhin Sinn.

Der Beitrag soll nicht vermitteln, dass die oben genannten 7 Regeln bereits das Ende der Weisheit sind. Es sind die absoluten Basics und wer sich in das Thema einlesen will, wird ohne Zweifel weitere Literaturquellen bemühen müssen.

Was das gezielte Setzen des Focus betrifft, wird es hoffentlich in Kürze einen Artikel von Dirk Ginader zu einem barrierefreien Tab-Script geben. Für den Adventskalender wurde es leider zu spät fertig. Dirk wird aber sicherlich dazu entweder hier oder in seinem eigenen Blog in Kürze einen Beitrag veröffentlichen.

Ich hatte das mal so gemacht, dass ich die Style Auswahlbox erst per Javascript erzeugt und eingebaut habe. Der Gedanke dahinter: Wenn Javascript nicht aktiv ist, wird der Nutzer auch nicht durch eine nicht funktionierende select Box genervt. Hat in allen Browsern funktioniert, nur nicht im IE. Der hat die Box zwar eingebaut, es aber nicht geschafft, die Javascript event Handler dazu mit zum laufen zu bringen. Also habe ich das wieder rausgeschmissen. Mit der .js Klasse und etwas CSS ließe sich eiwas Ähnliches und funktionierendes auch für den IE anbieten.

Ich habe dann nur noch ein Problem damit, diesmal mit dem Firefox. Bei diesem wird die Styleauswahl persistent durch eine Extension. Diese weiss aber Nix von einer Änderung via Javascript und macht selbige Änderung stante pede wieder rückgängig. Dieses Problem muss ich noch lösen. Aber immerhin hat mich dieser Artikel hier einen Schritt weiter gebracht.

Ein einfaches Fokusieren mit JS hat bei Screenreadern i.d.R. nur "im Formular"- oder "Applikationmodus" Aussicht auf Erfolg. Sollte i es funktionieren, ist es sowieso keine so gute Idee den User auf einen leeren Link springen zu lassen. Da Screenreader i.d.R. nur den Inhalt, Label und Rolle des fokusierten Bereichs selbst vorlesen und der Link keinen wirklichen Inhalt hat, ist der Srpung nicht wirklich bemerkbar. Eine Einführung des tabindex-Tags, als Universalantribut, hätte dem hoffentlich noch kommenden Aria Artikel bestimmt nichts weggenommen.

Dieser Artikel beschreibt mehr wie man Webseiten für User mit augeschaltetem JS zugänglich macht, nicht wie man barrierefreies JavaScript schreibt.

Wenn ich demnächst einen Artikel über einen barrierefreien Fahrstuhl schreiben würde, würde ich auch 3/4 meines Artikels ersteinmal darauf verwenden, die Grundlagen einer (barrierearmen) Treppe zu erklären (auch Häuser mit Fahrstühlen müssen ja Treppen haben).

Ich hoffe nur, dass meine Leser dann nicht wirklich glauben der Fahrstuhl, den sie bauen könnten, wäre barrierefrei.

Das gefährliche an diesen vermeintlich barrierefreien JS-Tuorials und Artikeln ist, dass viele Entwickler eben an dieser sehr oberflächlichen Betrachtung von barrierefreiem JS stehen bleiben und nicht über die Ein- und Ausgabe-Unabhängigkeit ihres JavaScripts selbst nachdenken.

Während sich die WCAG 1.0 vor allem auf HTML und CSS beziehen und für fast alle anderen Techniken im Grunde immer eine HTML-Alternative verlangen, akzeptieren die WCAG 2.0 grundsätzlich jede Technologie, die gewissen Mindestanforderungen in Sachen Zugänglichkeit entspricht. Zu diesen akzeptierten Technologien zählt aus Sicht der WCAG 2.0 auch Javascript.

Was spricht gegen die erprobte Off-Left-Methode? Deren Eigenschaften sind alle nötig, soweit ich weiß.

Das ist zum Teil sicher Geschmacksache, richtet sich aber auch nach den Inhalten, die es zu verstecken gilt.

Ich empfehle mittlerweile, die Eingriffe so gering wie möglich zu halten und daher auch nicht willkürlich Eigenschaften wie width oder height auf Null zu setzen, gleiches gilt für overflow (oder Dinge wie Schriftgröße und Zeilenhöhe auf Null setzen – sieht man auch häufig).

Beim Verstecken ist die Vergabe all dieser Eigenschaften i.d.R. unproblematisch. Beim wieder Erscheinen lassen (.skip:focus, .skip:active), hat man aber unter Umständen plötzlich viel Arbeit, wenn man die Klassen mal nicht nur auf einfachen Fließtext anwendet, sondern beispielsweise auf Seitenelemente mit definierten Geometrien. Denn für das Verstecken von Inhalten ist deren Ausgangsgeometrie egal, beim wieder Erscheinen lassen, muss man sie jedoch wiederherstellen – was u.U. dann recht aufwändig werden kann.

Die absolute Positionierung nach links oben mit ausreichend großen Versatzwerten hat mich bisher nie im Stich gelassen. Daher sehe ich keinen dringenden Grund für weitere zwingende Eingriffe. Sollte ein solcher tatsächlich einmal nötig werden, ist es vermutlich einfacher, diesen dann gesondert zu behandeln.

Nur der aktuelle Safari scheint sich aufgrund eines Bugs dagegen zu sträuben. Um auch im Safari Dinge sauber zu verstecken, ist daher zusätzlich die Eigenschaft top:-1000em erforderlich.

Kleiner Performance-Vorschlag: $('a[rel="external"]') muss nur einmal ausgeführt werden. jQuery erlaubt folgendes Chaining:

$('a[rel="external"]')   .hover(...)   .click(...)