Fokusmanagement und inert

Fokus-Trapping

Es kann vorkommen, dass Sie verhindern müssen, dass Dinge fokussiert werden. Ein gutes Beispiel dafür ist Fokus-Trapping, das ist die bedingte Beschränkung von Fokusereignissen auf ein Element und seine Kindelemente.

Fokus-Trapping darf nicht mit Keyboard-Fallen (manchmal als Fokus-Fallen bezeichnet) verwechselt werden. Keyboard-Fallen sind Situationen, in denen jemand, der mit der Tastatur navigiert, ein Widget oder eine Komponente nicht verlassen kann, da eine störende Schleife aus schlecht geschriebener Logik vorhanden ist.

Ein praktisches Beispiel dafür, wofür Sie Fokus-Trapping verwenden würden, wäre ein Modalfenster

Warum ist es wichtig?

Das Halten des Fokus innerhalb eines Modalfensters kommuniziert seine Grenzen und hilft zu informieren, was Modalinhalt ist und was nicht – es ist analog dazu, wie eine sehende Person sehen kann, wie ein Modalfenster über anderen Website- oder Webanwendungsinhalten "schwebt". Dies sind wichtige Informationen, wenn: 

• Sie haben geringe oder keine Sehkraft und verlassen sich auf Screenreader-Ankündigungen, um die Änderung des Interaktionsmodus zu vermitteln.
• Sie haben geringe Sehkraft und ein vergrößertes Display, wobei der Fokus außerhalb der Grenzen des Modalfensters verwirrend und desorientierend sein kann.
• Sie navigieren ausschließlich per Tastatur und könnten sonst aus dem Modalfenster heraus tabben und sich auf der zugrunde liegenden Seite oder Ansicht verirren, um wieder in das Modalfenster zu gelangen.

Wie macht man das?

Zuverlässiges Fokusmanagement ist eine komplizierte Angelegenheit. Sie müssen JavaScript verwenden, um

1. die Container-Elemente aller fokussierbaren Elemente auf der aktuellen Seite oder Ansicht zu bestimmen.
2. die Grenzen des gefangenen Inhalts zu identifizieren, einschließlich des ersten und letzten fokussierbaren Elements.
3. sowohl Interaktivität als auch Auffindbarkeit von allem zu entfernen, was als fokussierbar identifiziert wurde, aber nicht innerhalb dieses gefangenen Inhalts liegt.
4. den Fokus in den gefangenen Inhalt zu verschieben.
5. auf Ereignisse zu hören, die das Schließen des gefangenen Inhalts signalisieren (Speichern, Abbrechen, Schließen/Drücken der Esc-Taste usw.).
6. den gefangenen Inhaltsbereich zu schließen, wenn er durch ein relevantes Ereignis ausgelöst wird.
7. die zuvor entfernte Interaktivität wiederherzustellen. 
8. den Fokus zurück auf das interaktive Element zu verschieben, das den gefangenen Inhalt ausgelöst hat. 

Warum machen wir das?

Ich werde nicht lügen: Das alles ist knifflig und zeitaufwendig. Allerdings ist Fokusmanagement und eine sinnvolle, nutzbare Fokusreihenfolge eine Web Content Accessibility Guideline. Es ist wichtig genug, dass es als Teil eines internationalen, rechtlich bindenden Standards für Benutzerfreundlichkeit gilt.

Per Tabulator erreichbar und auffindbar

Es gibt einen kleinen Trick, um sowohl die Auffindbarkeit als auch die Interaktivität zu entfernen. 

Screenreader haben einen Interaktionsmodus, der es ihnen ermöglicht, die Seite oder Ansicht über einen virtuellen Cursor zu erkunden. Der virtuelle Cursor ermöglicht es dem Screenreader-Benutzer auch, nicht-interaktive Teile der Seite (Überschriften, Listen usw.) zu entdecken. Im Gegensatz zur Verwendung von Tab und Fokusstilen ist der virtuelle Cursor nur für Benutzer von Screenreadern verfügbar.

Wenn Sie den Fokus verwalten, möchten Sie möglicherweise die Möglichkeit einschränken, dass der virtuelle Cursor Inhalte entdeckt. Für unser Modalfenster-Beispiel bedeutet dies, dass verhindert wird, dass jemand versehentlich aus den Grenzen des Modalfensters "ausbricht", wenn er es liest.

Die Auffindbarkeit kann durch eine gezielte Anwendung von aria-hidden="true" unterdrückt werden. Die Interaktivität ist jedoch etwas nuancierter.

inert betreten

Das Attribut inert ist ein globales HTML-Attribut, das das Entfernen und anschließende Wiederherstellen der Fähigkeit interaktiver Elemente, entdeckt und fokussiert zu werden, erheblich erleichtern würde. Hier ist ein Beispiel, wie es funktionieren würde

<body>
  <div 
    aria-labelledby="modal-title"
    class="c-modal" 
    id="modal" 
    role="dialog" 
    tabindex="-1">
    <div role="document">
      <h2 id="modal-title">Save changes?</h2>
      <p>The changes you have made will be lost if you do not save them.<p>
      <button type="button">Save</button>
      <button type="button">Discard</button>
    </div>
  </div>
  <main inert>
    <!-- ... -->
  </main>
</body>

Ich vermeide bewusst die Verwendung des Elements <dialog> für das Modalfenster aufgrund seiner vielen Probleme mit der Unterstützung durch assistierende Technologien.

inert wurde auf das Element <main> angewendet, nach einem Modalfenster zur Bestätigung des Speicherns. Das bedeutet, dass alle Inhalte innerhalb von <main> weder den Fokus empfangen noch angeklickt werden können. 

Der Fokus ist auf das Innere des Modalfensters beschränkt. Wenn das Modalfenster geschlossen wird, kann inert vom Element <main> entfernt werden. Diese Art der Behandlung von Fokus-Trapping ist im Vergleich zu bestehenden Techniken weitaus einfacher.

Denken Sie daran: Ein Schließungsereignis kann durch die beiden Schaltflächen innerhalb unseres Modalfenster-Beispiels ausgelöst werden, aber auch durch Drücken von Esc auf Ihrer Tastatur. Einige Modalfenster lassen Sie auch außerhalb des Modalbereichs klicken, um sie zu schließen.

Unterstützung für inert

Die neuesten Versionen von Edge, Chrome und Opera unterstützen inert, wenn experimentelle Webplattformfunktionen aktiviert sind. Firefox-Unterstützung wird ebenfalls bald eintreffen! Der einzige Ausreißer sind sowohl Desktop- als auch mobile Versionen von Safari.

Ich würde mir wünschen, dass Apple die native Unterstützung für inert implementiert. Obwohl ein Polyfill verfügbar ist, hat es nicht-triviale Support-Probleme für alle wichtigen Screenreader. Nicht gut! 

Darüber hinaus möchte ich auf diese Notiz aus der README-Datei des inert-Polyfill-Projekts hinweisen.

Der Polyfill wird im Vergleich zu einer nativen inert-Implementierung leistungsmäßig teuer sein, da er eine beträchtliche Menge an Tree-Walking erfordert. 

Tree-Walking bedeutet, dass die JavaScript-Datei im Polyfill potenziell viel Rechenleistung benötigt, um zu funktionieren, und daher die Benutzererfahrung des Endbenutzers verlangsamt. 

Für Geräte mit geringerer Leistung, wie z. B. günstige Android-Smartphones, ältere Laptops und leistungsfähigere Geräte, die rechenintensive Aufgaben ausführen (wie z. B. das Ausführen mehrerer Electron-Apps), kann dies zum Einfrieren oder Abstürzen führen. Native Browser-Unterstützung bedeutet, dass diese Art von Verhalten für das Gerät weniger belastend ist, da sie auf Teile des Browsers zugreifen kann, auf die JavaScript keinen Zugriff hat. 

Safari

Persönlich bin ich von Apples mangelnder Unterstützung für inert enttäuscht. Obwohl ich verstehe, dass das Hinzufügen neuer Funktionen zu einem Browser extrem kompliziert und schwierig ist, scheint inert eine Funktion zu sein, die Apple viel früher hätte unterstützen sollen.

macOS und iOS hatten historisch gesehen eine hervorragende Unterstützung für Barrierefreiheit, und assistiven Technologien freundliche Funktionen sind ein üblicher Bestandteil ihrer Marketingkampagnen. Die Unterstützung von inert scheint eine natürliche Erweiterung von Apples Mission zu sein, da die Funktion selbst viel dazu beitragen würde, zugängliche Weberfahrungen einfacher zu entwickeln.

Frustrierenderweise hält sich Apple auch bedeckt, woran sie arbeiten und wann wir damit rechnen können. Aus diesem Grund ist die Zukunft von inert eine offene Frage.

Igalia

Igalia ist ein Unternehmen, das an Browserfunktionen arbeitet. Sie haben derzeit ein Experiment, bei dem die Öffentlichkeit abstimmen kann, welche Funktionen sie sehen möchten. Die Begründung für diese Initiative liegt außerhalb des Rahmens dieses Artikels, aber Sie können mehr darüber auf Smashing Magazine lesen.

Eine Funktion, die Igalia in Betracht zieht, ist die Hinzufügung von WebKit-Unterstützung für inert. Wenn Sie nach einer Möglichkeit gesucht haben, die Barrierefreiheit im Web zu verbessern, aber unsicher waren, wie Sie anfangen sollen, ermutige ich Sie, eine Spende zu tätigen. 5 $, 10 $, 25 $. Es muss kein großer Betrag sein, jeder kleine Beitrag zählt.

Leider hat inert das Open Prioritization-Experiment nicht gewonnen. Das bedeutet, wir wissen wieder nicht, ob Apple daran arbeitet oder wann wir es in Safari Technology Preview erwarten können.

iOS 15.4 wird mit deaktivierter Unterstützung für das Attribut inert ausgeliefert. Das sind tolle Neuigkeiten, da es signalisiert, dass Apple daran arbeitet.

Zusammenfassung

Fokusmanagement erfordert Geschick und Sorgfalt, ist aber sehr lohnenswert. Das Attribut inert kann wesentlich dazu beitragen, dies zu erleichtern.

Technologien wie inert stellen auch eine der größten Stärken der Webplattform dar: die Fähigkeit, die ausgetretenen Pfade zu pflastern und sie in etwas Einfaches und Effektives zu kodifizieren.

Weitere Lektüre

• Fokus mit tabindex steuern (A11ycasts, Folge 04)
• Verwendung des tabindex-Attributs (The Paciello Group)
• JavaScript verwenden, um den Fokus in einem Element zu sperren (Hidde de Vries)

Vielen Dank an Adrian Roselli und Sarah Higley für ihr Feedback.