Verhindern Sie, dass bestimmte Elemente den Fokus erhalten

Lesezeit: 6 Minuten

Also habe ich folgende Funktion. Was es tut, ist, auf das Fokusereignis auf allen Elementen zu lauschen. Wenn dieses Element entweder in ist $mobileMenu oder $menuItems es erlaubt es sonst entfernt es den Fokus:

var $body = $("body");
var $mobileMenu = $("#mobile-menu");
var $menuItems = $("#main-menu a");

$body.on("focus.spf", "*", function(e){
  e.stopPropagation();
  $this = $(this);

  // Prevent items from recieving focus and switching view
  if (!$this.is($mobileMenu) && !$this.is($menuItems)) {
    $this.blur();
  } else {
    console.log(this);
  }
})

Das Problem, das ich habe, ist, dass dies den Benutzer daran hindert, sich auf irgendetwas zu konzentrieren, wenn ein normalerweise fokussierbares Element, das jetzt nicht fokussierbar ist, einem meiner Elemente auf der weißen Liste vorangeht, da es nur versucht, sich immer wieder auf dasselbe Element zu konzentrieren.

Weiß jemand, wie ich ihm sagen kann, dass er stattdessen zum nächsten fokussierbaren Element springen soll?

Vielleicht liegt es an der Platzierung stopPropogation() Aussage? Ich bin ein wenig verwirrt von dem, was Sie direkt nach dem Code gesagt haben.

– es funktioniert nicht

7. Januar 2014 um 0:56 Uhr
@funktioniert nicht stopPropagation() ist gut, weil wir nicht sprudeln und Ressourcen verschwenden wollen. Grundsätzlich wird der interne Tab-Index zurückgesetzt blur() Jedes Mal, wenn Sie mit der Tabulatortaste tippen, versucht es, sich auf das erste Element zu konzentrieren, das verschwommen wird, und wenn Sie das nächste Mal mit der Tabulatortaste tippen, versucht es, es erneut auszuwählen.

– Georg Reith

7. Januar 2014 um 1:03
e.preventDefault() könnte helfen?

– Erich

7. Januar 2014 um 1:11 Uhr
@ Eric Verhindert das Fokusereignis nicht, fürchte ich.

– Georg Reith

7. Januar 2014 um 1:23 Uhr
Ich muss darauf hinweisen, dass dieser Ansatz die Seite für Personen, die Screenreader verwenden, unbrauchbar machen könnte. Der Versuch, den Fokus zu steuern, kann den Tastaturfokus beeinträchtigen und Benutzer daran hindern, auf den Rest der Seite zuzugreifen.

– AlastairC

9. Januar 2014 um 18:16 Uhr

npn_oder_pnp

Wenn Sie die einstellen tabindex zu -1 auf dem Element wird die Registerkarte ignoriert.

Ich bin mir nicht sicher, ob dies in allen Browsern funktioniert, aber es funktioniert in Google Chrome.

<input type="text" value="regular"/>
<input type="text" tabindex="-1" value="with tabindex set to -1"/>

Es ist eine Standardlösung. developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/…

– Reza Nooralizadeh

12. Juli um 14:10 Uhr
Unnötiges Update von vsync zu dieser Antwort. Es verkompliziert die ursprüngliche Antwort zu sehr.

– npn_oder_pnp

5. September um 14:34 Uhr

Davidkonrad

Das funktioniert (aktualisiert):

$body.on("focus.spt", "*", function(e){
  $this = $(this);
  if (!$this.is($mobileMenu) && !$this.is($menuItems)) {
    $this.blur();
    var next=$this.nextAll().find('a,input');
    if (next.length>0) next[0].focus();
  } else {
    console.log('ok',this);
    e.stopPropagation();
  }
})

(aktualisiert) Geige -> http://jsfiddle.net/CADjc/

Sie können in der Konsole sehen, welche Elemente den Fokus erhalten (main-menu a und mobile-menu)

Getestet am:

<input type="text" tabindex="1" value="test">
<span><input type="text" tabindex="2" value="test"></span>
<div><input type="text" id="mobile-menu" tabindex="3" value="mobile-menu"></div>
<div><span>
    <div id="main-menu">
        <a tabindex="4">main-menu</a>
        <a tabindex="5">main-menu</a>
    </div>
</span></div>
<span>
<input type="text" tabindex="6" value="test">
</span>

Danke… das funktioniert aber nur, weil die Elemente direkt nebeneinander liegen (sonst next() funktioniert nicht) im Fluss … siehe jsfiddle.net/e96EV/2

– Georg Reith

7. Januar 2014 um 1:55 Uhr
@GeorgeReith Sie haben Recht, Sie haben blind auf dem selbst erstellten Test-Markup getestet könnte habe ein Markup-Beispiel bereitgestellt 🙂 – siehe Update oben und die aktualisierte Geige auch. Warum schließen Sie Ihr Markup zB ?? (habe das in deinem Geigenupdate gesehen)

– davidkonrad

7. Januar 2014 um 3:19 Uhr
Ich habe gerade festgestellt, dass es nur funktioniert, wenn das zulässige fokussierbare Element das erste fokussierbare Element in seinem übergeordneten Element ist … siehe jsfiddle.net/CADjc/2 – Das ist wegen next[0] Ich glaube, das testet nur das erste gefundene Element. Außerdem habe ich die Elemente geschlossen, weil es für JSfiddle schwierig ist, nicht geschlossene Elemente hervorzuheben (selbst wenn sie gültig sind).

– Georg Reith

7. Januar 2014 um 4:35 Uhr
Ok ich habe das behoben next[0] aber es geht immer noch nicht rund. Wenn es am Ende ankommt, wechselt es einfach zwischen den letzten beiden … jsfiddle.net/CADjc/3

– Georg Reith

7. Januar 2014 um 5:08 Uhr
Änderung war notwendig, weil es kein fokussierbares Element gibt next[0] es wird sich einfach fortpflanzen und alle anderen potenziellen Geschwisterelemente ignorieren. Ein weiteres Problem ist, dass Geschwisterelemente, die sich später im DOM befinden, früher als untergeordnete Elemente ausgewählt werden.

– Georg Reith

7. Januar 2014 um 7:31 Uhr

Wenn Sie etwas deaktivieren, erhält es keinen Fokus. Zum Beispiel:

<input type="text" disabled="disabled" />

Fügen Sie es programmgesteuert hinzu, Sie könnten Folgendes tun:

var el = document.getElementById('disableme');
el.setAttribute('disabled', 'disabled');

Deaktivierte Eingabeelemente werden beim Absenden des Formulars nicht an den Server gesendet. Hat nicht viel mit dem aktuellen Szenario zu tun, aber gut im Hinterkopf zu behalten.

– Antares42

13. Mai 2015 um 22:42 Uhr
Mein Rat wäre, das Wort “etwas” durch “ein Formularelement” zu ersetzen, weil disabled gilt nur für Formularelemente und sonst nichts.

– Armen Michaeli

10. Juli 2016 um 22:47 Uhr

attr (“readonly”, “readonly”), Eingabefokus verhindern und Wert werden an den Server gesendet.

Ghanashyam Sateesh

Nur-CSS-Lösung aus einem meiner vergangenen Projekte

/* Prevents all mouse interactions */
.disabled-div {
  opacity: 0.5;
  pointer-events: none;
}

/* Prevents all other focus events */
.disabled-div:focus,
.disabled-div:focus-within {
  visibility: hidden;
}

<h1>CSS Only Disable with Prevent Focus</h1>

<input placeholder="Normal text field">
<br><br>
<input class="disabled-div" placeholder="Disabled text field">
<br><br>
<input placeholder="Normal text field">
<br><br>
<input class="disabled-div" placeholder="Disabled text field">
<br><br>

Flackert leicht, wenn es fokussiert wird. Das liegt daran, dass, wenn es den Fokus erhält, die Sichtbarkeit auf „ausgeblendet“ gesetzt wird und der Fokus verloren geht und die Sichtbarkeit wieder auf „sichtbar“ zurückgesetzt wird. Das ist eigentlich gut, weil der Benutzer jetzt eine Vorstellung davon hat, wo der Fokus liegt, während er über deaktivierte Felder geht …

Das ist nett, funktioniert aber leider nicht mit Safari oder Firefox.

– mhenry1384

5. Mai um 17:30 Uhr
Ich wünschte, das würde funktionieren, aber das Deaktivieren der Sichtbarkeit wirkt sich in einigen Browsern überhaupt nicht auf den Fokus aus. Ich denke, jedes Verhalten, das Sie im Gegenteil sehen, ist nicht standardisiert.

– Lummox JR

21. September um 20:28 Uhr

Das ist nett, funktioniert aber leider nicht mit Safari oder Firefox.

– mhenry1384

5. Mai um 17:30 Uhr
Ich wünschte, das würde funktionieren, aber das Deaktivieren der Sichtbarkeit wirkt sich in einigen Browsern überhaupt nicht auf den Fokus aus. Ich denke, jedes Verhalten, das Sie im Gegenteil sehen, ist nicht standardisiert.

– Lummox JR

21. September um 20:28 Uhr

14313500cookie-checkVerhindern Sie, dass bestimmte Elemente den Fokus erhalten

#Abfrage #Barrierefreiheit #html #Javascript