verhindernDefault(), Scrollen und Barrierefreiheit

Question

Ich füge einer Site ein JavaScript-gestütztes Unterfenster hinzu.Grundsätzlich wird ein Teil der Benutzeroberfläche am linken Rand des Bildschirms positioniert, bis der Benutzer einen Link auslöst.dann wird es in eine sichtbare Position verschoben.Ich habe eine Serie von fünf Testfälle, habe aber noch nicht die Reputationspunkte, um sie einzeln zu verknüpfen.

Aus Gründen der Barrierefreiheit möchte ich einen Link verwenden, der ein Dokumentfragment enthält, also:

<a href="#quicklinks" id="quicklinks-trigger">Quick Links</a>

Mit entsprechendem JavaScript (mit jQuery):

$("#quicklinks-trigger").click(function(e){ 
 $("#shadow").removeClass("default");
 $("#shadow").addClass("active");
});

Der #quicklinks HREF leitet den internen Cursor (auch Caret genannt) von Bildschirmleseprogrammen an den Anfang der neu enthüllten Benutzeroberfläche um.Im Unterfenster „Quick Links“ gibt es einen entsprechenden Link, der den Cursor zurück zum Hauptteil des Dokuments leitet (<a href="#main" id="close-quicklinks"></a>).Sie können dies anhand von Testfall 1 in Aktion sehen.Wenn Sie es mit einem Screenreader anhören (ich teste mit NVDA), springt der Screenreader problemlos zu den Quick-Links, wenn der Link ausgelöst wird, und zurück zum Hauptdokument, wenn der Quick-Links-Schließlink ausgelöst wird.

Außerdem wird die Seite als Reaktion auf die Dokumentfragmente nach oben und unten gescrollt, was hässlich und nervig ist.Das kann mit unterdrückt werden window.preventDefault() -- siehe Testfall 2, der sehr reibungslos funktioniert und nicht durch das Dokument scrollt, also:

$("#quicklinks-trigger").click(function(e){ 
 $("#shadow").removeClass("default");
 $("#shadow").addClass("active");

e.preventDefault();});

Leider verhindert der Aufruf von PreventDefault() auch, dass der Browser den Cursor an die richtige Stelle bewegt.Ein blinder Benutzer kann den Link dort auslösen, und dann fährt der Bildschirmleser mit dem nächsten Element in der Reihenfolge des Quellcodes fort, nicht mit der Quick-Links-Benutzeroberfläche.Der einfachste Weg, DAS zu beheben, besteht darin, den HTML-Code, der das Unterfenster „Quick Links“ definiert, direkt nach dem Trigger-Link zu platzieren.Aber das kann ich nicht, weil das CMS, für das dies gedacht ist, nicht gut mit großen HTML-Blöcken, die in Menüs eingefügt werden, zurechtkommt.

Ich habe einige andere Ansätze ausprobiert, um das Scrollen zu eliminieren.Testfall 3 scrollt das Fenster manuell zurück:

$("#quicklinks-trigger").click(function(e){ 
 $("#shadow").removeClass("default");
 $("#shadow").addClass("active");
 window.setTimeout(function(){ scrollTo(0,0); }, 1); 
});

...Das funktioniert, hat aber einen sichtbar ruckartigen Effekt, da nach unten und dann wieder nach oben gescrollt wird. Das ist also nicht besser als Testfall 1.

In Testfall 4 habe ich versucht, PreventDefault() in Kombination mit Focus() zu verwenden, in der Hoffnung, den internen Cursor manuell zu bewegen:

$("#quicklinks-trigger").click(function(e){ 
 $("#shadow").removeClass("default");
 $("#shadow").addClass("active");
 $("#quicklinks").focus();
 e.preventDefault();
});

Aber es hat nicht funktioniert, weil #quicklinks ein DIV und kein fokussierbares Element ist.Ich nehme an, ich könnte ein verstecktes, fokussierbares Element in den Quick-Links-HTML einfügen, aber das wäre umständlich.

In Testfall 5 habe ich versucht, das ID-Attribut aus dem Zielelement zu entfernen, die Fragment-ID mit dem Ereignis onhashchange neu zu schreiben und dann die ID wiederherzustellen:

function cfl_hash(fragment){
 // Get the section the fragment refers to.
 var target = $(fragment);

 // Save its current ID.
 var id = target.attr("id");

 // Remove the ID so the browser won't scroll.
 target.attr("id","");

 // Rewrite the hash to the desired fragment, only if onhashchange event supported.
 if("onhashchange" in window){ location.hash = fragment; }

 // Put the ID back in place.
 target.attr("id", id);
}

$("#quicklinks-trigger").click(function(e){ 
 $("#shadow").removeClass("default");
 $("#shadow").addClass("active");
 cfl_hash("#quicklinks");
});

Was den unglücklichen Effekt hatte, dass das Scrollen möglich war, die Cursorbewegung jedoch verhindert wurde.Ich glaube, ich habe die Abfolge der Ereignisse beim ID-Tausch falsch verstanden.Dies sollte funktionieren, um das Scrollen zu unterdrücken, obwohl ich bezweifle, dass sich der Cursor dadurch bewegen lässt.

Es ist wirklich ärgerlich, dass Sie das Scrollen für sehende Benutzer nicht abbrechen können, ohne auch die Cursorumleitung für Benutzer von Bildschirmleseprogrammen abzubrechen.

Bisher habe ich nur mit Firefox und NVDA getestet.Ich habe keine Ahnung, wie sich das in anderen Kombinationen aus Browser und Screenreader auswirken würde.

Vorschläge?

Answer 1

Ich habe eine Problemumgehung gefunden, die die Verwendung von Dokumentfragment-Links ermöglicht, die Caret-Umleitung für Bildschirmleseprogramme ermöglicht und kein Scrollen im Ansichtsfenster ermöglicht.Die Methode ist

1. Platzieren Sie ein ausgeblendetes Element oben auf dem Element, auf das Sie verlinken
2. Verlinken Sie auf das ausgeblendete Element statt auf den darauf folgenden Inhalt
3. Verwenden Sie eine feste Positionierung, um das ausgeblendete Element bündig mit der Oberseite des Ansichtsfensters zu verschieben

Wenn Sie auf diese Weise auf den Link klicken, der auf das ausgeblendete Element abzielt, versucht der Browser, den Bildschirm an die richtige Stelle zu „scrollen“, dieser befindet sich jedoch bereits oben im Ansichtsfenster, sodass kein tatsächlicher Scrollvorgang stattfindet.Die Caret-Umleitung erfolgt, sodass Benutzer von Bildschirmleseprogrammen zu der Stelle gelangen, auf die der Link verwiesen hat.

Es gibt ein paar Macken.In Opera, Safari und Chrome führt das Klicken auf einen so angeordneten Link zu einem Bildlauf, allerdings NUR, wenn der Benutzer bereits nach unten gescrollt hat.Ich bin mir nicht sicher, warum das so ist;Vielleicht aktualisieren sie nicht die Positionen von Elementen mit fester Position, die sich links vom Bildschirm befinden?In jedem Fall betrifft dieses Problem nur ganz bestimmte Umstände, die durch sinnvolles Seitenlayout größtenteils vermieden werden können.Daher denke ich, dass die Vorteile (zugänglicher, vergleichsweise einfacher Code) die Nachteile (geringfügige visuelle Besonderheiten bei manchen Browsern und Umständen) überwiegen.

Eine ausführlichere Beschreibung dieser Technik finden Sie unter:

http://www.accessifyforum.com/viewtopic.php?p=77132

Ich hoffe, das hilft jemand anderem.