Kapitel 1. Dokumente strukturieren
Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com
Dieses Buch konzentriert sich auf das Schreiben von barrierefreien Komponenten, aber Barrierefreiheit beginnt bereits in der ersten Zeile deines HTML-Dokuments. Deine Komponenten befinden sich auf einer Seite, und deine Seite ist Teil eines Dokuments. Mehrere Elemente, vor allem auf <head>, beeinflussen die Barrierefreiheit deines Dokuments.
1.1 Definiere die natürliche Sprache
Problem
Wenn eine Seite keine explizite Definition der natürlichen Sprache enthält, in der sie geschrieben ist, kann die Software den Inhalt möglicherweise nicht richtig übersetzen. Der Begriff " natürliche Sprache" bezieht sich auf die Sprache, die du für den Inhalt der Seite verwendest, nicht auf die Programmiersprache. Das Fehlen von Informationen kann zu fehlerhaften Übersetzungen, falscher Formatierung und schwer verständlichen Inhalten für Bildschirmleser führen.
Lösung
Du kannst die natürliche Sprache einer Seite definieren, indem du das lang Attribut auf dem <html> Element verwendest. Siehe Beispiel 1-1.
Beispiel 1-1. Englisch als natürliche Sprache der Seite definiert
<!DOCTYPE html><htmllang="en"></html>
Du kannst auch einen bestimmten Dialekt der Basissprache definieren. Siehe Beispiel 1-2.
Beispiel 1-2. Britisches Englisch definiert als die natürliche Sprache der Seite
<!DOCTYPE html><htmllang="en-GB"></html>
Das Attribut lang ist global, d.h. du kannst es für jedes Element verwenden, auch wenn es einige davon nicht betrifft. Es kann hilfreich sein, wenn eine Seite in einer Sprache verfasst ist, aber Textpassagen oder sogar einzelne Wörter in anderen Sprachen enthält. Siehe Beispiel 1-3.
Beispiel 1-3. Transliteriertes Japanisch in lateinischer Schrift auf einer Seite in englischer Sprache
<!DOCTYPE html><htmllang="en"><head></head><body><p>The Wind-Up Bird Chronicle (<spanlang="ja-Latn">Nejimakidori Kuronikuru</span>) is a novel published in 1994 by Japanese author Haruki Murakami.</p></body></html>
Verwende die Pseudoklasse lang, um die Typografie und das Layout für bestimmte Sprachen anzupassen. Siehe Beispiel 1-4.
Beispiel 1-4. Auswählen aller Elemente in serbischer Sprache
:lang(sr){font-family:'Cyrillic font',sans-serif;}
Diskussion
Assistive Technologien und andere Software sind unter Umständen nicht in der Lage, die natürliche Sprache einer Seite automatisch zu bestimmen. Bestimmte Funktionen in HTML und Cascading Style Sheets (CSS) verlassen sich auf diese Informationen, um die Lokalisierung von Softwareinhalten zu unterstützen und ein hervorragendes Benutzererlebnis zu bieten. Du musst die Sprache jeder Seite programmatisch und explizit festlegen, indem du das Attribut lang auf dem Element <html> verwendest, wie in Beispiel 1-1 gezeigt. Für Textpassagen, die in einer anderen Sprache als der Hauptsprache der Seite geschrieben sind, kannst du das Attribut ebenfalls verwenden, wie in Beispiel 1-3 gezeigt. Damit können Bildschirmlesegeräte die Aussprache verbessern, indem sie Sprachprofile für bestimmte Wörter oder Sätze entsprechend umschalten. Versuche, dies sparsam zu tun, denn das Umschalten der Sprachprofile kann lästig sein, weil es den Lesefluss unterbricht. Bei gut etablierten Fremdwörtern ist das vielleicht nicht nötig. Beispiele im Deutschen sind englische Wörter wie "Download", "Workshop" oder "Link".
Verwendung
Der Wert des lang Attributs muss ein gültiges BCP 47 Sprach-Tag sein, das aus einem oder mehreren Subtags besteht. Ein Subtag ist eine Folge von alphanumerischen Zeichen, die durch einen Bindestrich von anderen Subtags getrennt sind.
Der Sprach-Subtag ist ein 2- oder 3-stelliger Code, der die Hauptsprache definiert: zum Beispiel en für Englisch, de für Deutsch oder fr für Französisch, wie in Beispiel 1-5 gezeigt.
Beispiel 1-5. Spanisch definiert als die natürliche Sprache der Seite
<htmllang="es"></html>
Das optionale Skript-Subtag ist ein 4-stelliger Code, der das Schriftsystem der Sprache definiert, wie in Beispiel 1-6 gezeigt.
Beispiel 1-6. Ein Name in kyrillischer Schrift neben demselben Namen in lateinischer Schrift, der als solcher gekennzeichnet ist
Никола Јокић (<spanlang="sr-Latn">Nikola Jokić</span>).
Das optionale Region-Subtag besteht normalerweise aus einem zweistelligen Ländercode in Großbuchstaben und definiert einen Dialekt der Basissprache, wie in Beispiel 1-7 gezeigt.
Beispiel 1-7. Österreichisches Deutsch als die natürliche Sprache der Seite definiert
<!DOCTYPE html><htmllang="de-AT"></html>
Du solltest den zweistelligen primären Sprachcode verwenden und nur dann Subtags für die Region hinzufügen, wenn es notwendig ist, Inhalte in verschiedenen Dialekten zu unterscheiden, die möglicherweise nicht gegenseitig verständlich sind. Zumindest für Screenreader-Benutzer sollte es keinen Unterschied machen, wenn du keine Regional-Subtags hinzufügst, da sie von der Software normalerweise ignoriert werden.
Eine Liste aller Tags und Subtags findest du in der BCP 47 Sprache Subtag Lookup.
Vorteile
Das Attribut lang ist sehr mächtig und beeinflusst viele Aspekte der Barrierefreiheit und des Nutzererlebnisses im Allgemeinen. Dazu gehören:
Hilfsmitteltechnologie
Sprachsynthesizer die mehrere Sprachen unterstützen, passen ihre Aussprache und Syntax an die Sprache der Seite an und sprechen den Text mit dem entsprechenden Akzent und der richtigen Aussprache. Bei einer Seite mit deutschem Inhalt, deren Sprache auf Englisch eingestellt ist (lang="en"), wählt die Bildschirmlesesoftware möglicherweise ein englisches synthetisches Stimmprofil und liest den deutschen Text mit englischer Aussprache vor. Wenn du keine Sprache einstellst, kann es sein, dass das Bildschirmleseprogramm auf die Standardeinstellung des Benutzers zurückgreift, die möglicherweise nicht angemessen ist. Das Ergebnis kann schwer zu verstehen, verwirrend oder sogar völlig falsch sein. Alle Bildschirmlesegeräte unterstützen zahlreiche Sprachen. Manche Software schaltet die Sprache automatisch um, bei anderen müssen die Nutzer/innen Sprachstimmen oder -pakete manuell installieren und konfigurieren.
Die Attributdefinition ermöglicht es der Braille-Übersetzungssoftware auch, die Ausgabe zu optimieren und zu verhindern, dass sie fälschlicherweise Braille-Kontraktionen der Stufe 2 erzeugt.
Übersetzung
Übersetzungstools wie Google Translate nutzen die Informationen aus dem lang Attribut, um den Inhalt der Seite zu übersetzen. Obwohl diese Art von Software die Sprache der Seite in der Regel gut erkennt, kann eine Diskrepanz zwischen der tatsächlichen Sprache und der definierten Sprache zu unerwarteten und unerwünschten Übersetzungen führen.
Zitate
Anführungszeichen können sich je nach der natürlichen Sprache der Seite ändern. Im Englischen werden zum Beispiel andere Anführungszeichen verwendet als im Deutschen oder Französischen, und die korrekte lang hilft den Browsern, die richtigen Glyphen auszuwählen, wie in den Beispielen 1-8, 1-9 und 1-10 gezeigt.
Beispiel 1-8. Automatische Anführungszeichen mit dem Element <q> auf Englisch
<plang="en"><q>A quote in English.</q></p><!-- Results in: “A quote in English.” -->
Beispiel 1-9. Automatische Anführungszeichen mit dem Element <q> im Deutschen
<plang="de"><q>Ein Zitat auf Deutsch.</q></p><!-- Results in: „Ein Zitat auf Deutsch.“ -->
Beispiel 1-10. Automatische Anführungszeichen mit dem Element <q> im Französischen
<plang="fr"><q>Une citation en français.</q></p><!-- Results in: « Une citation en français. » -->
Silbentrennung
lang kann die Silbentrennung in CSS beeinflussen. Siehe Beispiel 1-11.
Beispiel 1-11. Ein Absatz mit einer maximalen Breite von 28 Zeichen und eingeschalteter Silbentrennung
p{max-width:28ch;hyphens:auto;}
In den Beispielen 1-12, 1-13 und 1-14 kannst du sehen, wie derselbe auf Deutsch geschriebene Absatz mit einem anderen lang Attributwert in Google Chrome unterschiedlich dargestellt wird. Die Wörter werden entweder gar nicht oder an unterschiedlichen Positionen umbrochen. Nur das erste und das zweite Beispiel sind korrekt. Es ist erwähnenswert, dass Browser sich unterschiedlich verhalten.
Beispiel 1-12. Korrekt mit Bindestrich geschriebener deutscher Text in einem als deutsch definierten Absatz
<plang="de">Weit hinten, hinter den Wortbergen, fern der Länder Vokalien und Konsonantien leben die Blindtexte. Abgeschieden wohnen sie in Buchstabhausen an der Küste des Semantik, eines großen Sprachozeans. Ein kleines Bächlein namens Duden fließt durch ihren Ort und versorgt sie mit den nötigen Regelialien.</p><!-- Results in:Weit hinten, hinter den Wortbergen,fern der Länder Vokalien und Konso-nantien leben die Blindtexte. Abge-schieden wohnen sie in Buchstab-hausen an der Küste des Semantik,eines großen Sprachozeans.-->
Beispiel 1-13. Keine Silbentrennung von deutschem Text in einem als englisch definierten Absatz
<plang="en">Weit hinten,…</p><!-- Results in:Weit hinten, hinter den Wortbergen,fern der Länder Vokalien undKonsonantien leben die Blindtexte.Abgeschieden wohnen sie inBuchstabhausen an der Küste desSemantik, eines großenSprachozeans.-->
Beispiel 1-14. Falsche Silbentrennung von deutschem Text in einem Absatz, der als Französisch definiert ist
<plang="fr">Weit hinten,…</p><!-- Results in:Weit hinten, hinter den Wortbergen,fern der Länder Vokalien und Konso-nantien leben die Blindtexte. Abges-chieden wohnen sie in Buchstabhau-sen an der Küste des Semantik, einesgroßen Sprachozeans.-->
Auswahl der Schriftart
Die Browser können für die Darstellung von Details in ideografischen Zeichen, die sich von Sprache zu Sprache unterscheiden, wie z. B. Chinesisch, Japanisch und Koreanisch (die so genannten " CJK-Sprachen"), sprachgerechte Schriftarten auswählen .
1.2 Beschreiben Sie das Dokument
Problem
Screenreader Benutzer/innen, die auf einer Website navigieren, können nicht immer erkennen, auf welcher Seite sie sich befinden. Sie verstehen vielleicht nicht, worum es auf einer Seite geht, oder bemerken nicht, dass sich der Inhalt geändert hat, wenn der Titel der Seite nicht richtig gesetzt ist.
Lösung
Du kannst Seiten mit dem <title> Element in HTML benennen. Der Titel muss eindeutig sein und das Thema oder den Zweck jeder Seite kurz und bündig beschreiben. Siehe Beispiel 1-15.
Beispiel 1-15. Ein prägnanter und beschreibender Seitentitel
<!DOCTYPE html><htmllang="en"><head><title>Products - Johanna’s Toy Store</title></head></html>
Für Social Media-Vorschauen kannst du optional ein Open Graph meta Tag verwenden, um mehr oder andere Informationen einzuschließen, wie in Beispiel 1-16 gezeigt.
Beispiel 1-16. Ein einprägsamerer Seitentitel für Social Media-Vorschauen
<!DOCTYPE html><htmllang="en"><head><title>Products - Johanna’s Toy Store</title><metaproperty="og:title"content="Find dolls, toy cars, and more in Johanna's Toy Store"></head></html>
Das Hinzufügen von Kontext in Abhängigkeit vom Zustand der Seite kann hilfreich sein (siehe Beispiele 1-17, 1-18, 1-19 und 1-20).
Beispiel 1-17. Der Titel enthält den aktuellen Schritt und die Gesamtzahl der Schritte in einem Checkout-Prozess
<title>Checkout (step 3 of 4) - Johanna’s Toy Store</title>
Beispiel 1-18. Anzahl der Validierungsfehler im Titel einer Anmeldeseite
<title>2 errors - Sign Up - Johanna’s Toy Store</title>
Beispiel 1-19. Anzahl der Ergebnisse im Titel einer Suchseite
<title>21 results for term “crocodile” - Johanna’s Toy Store</title>
Beispiel 1-20. Der Titel, der die aktuelle Suchergebnisseite anzeigt
<title>Page 2 - Product Search Results - Johanna’s Toy Store</title>
Diskussion
Manchmal ist es schwierig, sich auf einer Website zurechtzufinden, z. B. wenn Nutzer/innen auf einer Seite landen, die von einer externen Ressource wie einer Suchmaschine kommt, oder wenn Seitenänderungen unerwartet oder unangekündigt erfolgen. Das gilt besonders für Single-Page-Anwendungen (SPAs), bei denen die Seitennavigation anders funktioniert als bei den meisten Websites.
Der Seitentitel ist eines der wichtigsten Elemente eines HTML-Dokuments, und die Nutzer profitieren von einem wohlgeformten und beschreibenden Seitentitel.
Benutzer von Bildschirmlesern können Abkürzungen verwenden, um den Seitentitel anzuzeigen. Wenn sie z. B. auf einen Link in einem SPA klicken und sich der Inhalt ändert, aber keine Meldung über die Änderungen erscheint, können sie eine Abkürzung verwenden, um sich zu orientieren und zu prüfen, ob sie auf einer anderen Seite gelandet sind. Du kannst es selbst ausprobieren, indem du einen der Shortcuts in Tabelle 1-1 verwendest.
| Bildschirmleser | Befehl | Ankündigung |
|---|---|---|
JAWS |
|
Titel der Seite |
NVDA |
|
Titel der Seite |
VoiceOver macOS |
|
Seitenzusammenfassung, einschließlich Seitentitel |
VoiceOver macOS |
|
Titel der Seite |
Hinweis
In der Standardeinstellung steht VO für die Kombination aus dem gleichzeitigen Drücken von Control und Option in VoiceOver auf macOS. Alternativ kannst du VO in den Einstellungen des VoiceOver-Dienstprogramms Caps Lock zuordnen.
Es gibt noch weitere Gründe, gute Seitentitel zu schreiben: Sie dienen als Kennzeichnung für Lesezeichen/Favoriten und Suchmaschinen verwenden den Titel in ihren Ergebnisseiten. Social-Media-Seiten, Chat- und Mail-Anwendungen und ähnliche Software verwenden den Titel in Link-Vorschauen, wenn kein anderer Titel angegeben ist. Bitte beachte, dass das in Beispiel 1-16 gezeigte Open-Graph-Meta-Tag keine Alternative zum Element <title> ist. Ob eine Website oder Anwendung den Open-Graph-Titel interpretiert, hängt von der Website ab. Idealerweise sollte der Inhalt des nativen Titels gut genug sein, um alle Zwecke zu erfüllen.
Es gibt einige bewährte Methoden, die du beim Schreiben von Seitentiteln beachten solltest:
Der Titel muss einzigartig sein
Die <title> dient als Bezeichnung in Tabs oder Browserfenstern. Eindeutige Titel helfen dabei, eine Seite von einer anderen zu unterscheiden, wenn mehrere Tabs der gleichen Website geöffnet sind. Ein häufiges Problem ist, dass der Titel auf allen Seiten derselbe ist (siehe Beispiel 1-21). Das Ergebnis ist in Abbildung 1-1 dargestellt.
Beispiel 1-21. Schlechte Praxis: Drei verschiedene Seiten mit demselben Titel
<!-- products.html --><title>Johanna’s Toy Store</title><!-- team.html --><title>Johanna’s Toy Store</title><!-- contact.html --><title>Johanna’s Toy Store</title>
Abbildung 1-1. Es ist unmöglich, diese Seiten anhand der Registerkarten zu unterscheiden
Verwende eindeutige Titel, um den Zweck der Seite zu vermitteln und die Orientierung zu verbessern (siehe Beispiel 1-22 und das Ergebnis in Abbildung 1-2).
Beispiel 1-22. Drei verschiedene Seiten, jede mit einem eigenen Titel
<!-- products.html --><title>Products - Johanna’s Toy Store</title><!-- team.html --><title>Our Team - Johanna’s Toy Store</title><!-- contact.html --><title>Get in Touch - Johanna’s Toy Store</title>
Abbildung 1-2. Anhand der Registerkarten kannst du erkennen, worum es auf den einzelnen Seiten geht
Das gilt für Websites mit mehreren Seiten, aber auch für SPAs. In einer SPA musst du vielleicht zusätzliche Schritte unternehmen, aber wenn der Nutzer zu einer anderen Route navigiert, muss sich auch der Seitentitel ändern. Wie das geht, erklärt Hidde De Vries in "Barrierefreie Seitentitel in einer Single Page App".
Der Titel sollte prägnant sein
Der Titel von sollte prägnant sein und den Zweck der Seite genau beschreiben. Er ist die erste Information, die ein Screenreader-Nutzer erhält, wenn er eine Seite aufruft. Sie brauchen keine detaillierte Zusammenfassung des Seiteninhalts, sondern eine knappe Beschreibung.
Ein weiterer Grund, die Länge des Titels zu begrenzen, ist, dass er auf den Suchergebnisseiten in der Regel bei einer bestimmten Zeichenlänge (etwa 50 bis 60 Zeichen) abgeschnitten wird.
Der Titel sollte beschreibend sein
Wenn du einen Seitentitel gibst, solltest du den Nutzer im Hinterkopf behalten. SEO ist zwar wichtig, aber das Nutzererlebnis ist viel wichtiger. Der Titel sollte den Zweck der Seite beschreiben und darf keine Marketing- oder SEO-Begriffe enthalten, nur um das Ranking der Seite zu verbessern.
Die relevanten Informationen kommen zuerst
Der Titel von sollte mit dem Namen der Seite beginnen, gefolgt von dem Namen der Website, des Unternehmens oder der Organisation, wie in Beispiel 1-15 gezeigt. Indem du die relevanten Informationen an den Anfang stellst, werden Wiederholungen für Screenreader-Nutzer vermieden, die mehrere Seiten einer Website besuchen, da sie die einzigartigen seitenbezogenen Details zuerst erhalten. Diese Art der Anordnung der Inhalte erleichtert das Scannen und Identifizieren von Seiten, wenn viele Registerkarten geöffnet sind, wie in Abbildung 1-3 dargestellt.
Abbildung 1-3. Der Name der Seite ist die erste Information in der Registerkarte des Browsers
Setze den Namen der Organisation nicht an die erste Stelle (wie in Beispiel 1-23), da sonst die relevanten Informationen abgeschnitten werden, wie du in Abbildung 1-4 sehen kannst.
Beispiel 1-23. Schlechte Praxis: Name der Website gefolgt von dem Namen der Seite
<title>Johanna’s Toy Store - Products</title>
Abbildung 1-4. Mit dem Namen der Website als erste Information im Browser-Tab wird in einigen Fällen der Name der Seite abgeschnitten
Kontextabhängige Informationen
Manchmal ist es hilfreich, Kontext oder zusätzliche Informationen hinzuzufügen. Wenn du zum Beispiel eine Seite in mehrere Schritte unterteilst, sollte der Titel den aktuellen Schritt enthalten. Beispiel 1-17 zeigt den Titel des dritten von vier Schritten in einem Checkout-Prozess. Wenn es in einem Formular Validierungsfehler gibt, kannst du die Anzahl der Fehler angeben (siehe Beispiel 1-18). Bei Suchergebnisseiten kannst du die Anzahl der Ergebnisse oder die aktuelle Seite hinzufügen, wie in Beispiel 1-19 und 1-20 zeigt.
1.3 Festlegen der Ansichtsbreite
Lösung
Konfiguriere den viewport Meta-Tag so, dass er die größtmögliche Flexibilität bietet. Vermeide restriktive Einstellungen.
Der meta Tag in Beispiel 1-24 funktioniert für die meisten Websites und Webanwendungen. Er ist alles, was du brauchst, um Viewport-Einstellungen zu konfigurieren und eine flexible, anpassungsfähige, responsive Website zu erstellen.
Beispiel 1-24. Die Seite verwendet die verfügbare Breite des Geräts als Breite für das Ansichtsfenster
<metaname="viewport"content="width=device-width, initial-scale=1">
Es gibt bestimmte Eigenschaften oder Werte, die du vermeiden solltest.
Wenn du den Wert der width Eigenschaft auf einen anderen Wert als device-width setzt, kann das zu Problemen führen. Wenn die definierte Breite des Ansichtsfensters größer ist als die verfügbare Breite auf dem Bildschirm, kann der Inhalt überlaufen, was zu horizontalen Bildlaufleisten führt. Beispiel 1-25 wendet eine explizite Viewport-Breite an.
Beispiel 1-25. Schlechte Praxis: Breite des Ansichtsfensters auf einen absoluten Wert gesetzt
<metaname="viewport"content="width=500, initial-scale=1">
maximum-scale ermöglicht es dir, die maximale Zoomstufe zu begrenzen, die in den meisten Browsern standardmäßig 10 ist. Wenn du ihn auf 1 setzt, deaktivierst du den Zoom in einigen Browsern (siehe Beispiel 1-26).
Beispiel 1-26. Schlechte Praxis: Zoom deaktiviert, indem der maximale Maßstab auf 1 gesetzt wird
<metaname="viewport"content="width=device-width, maximum-scale=1, initial-scale=1">
Die Einstellung user-scalable legt fest, ob das Zoomen erlaubt ist. Die Einstellung no oder 0 deaktiviert den Zoom, wie in Beispiel 1-27 gezeigt.
Beispiel 1-27. Schlechte Praxis: Zoom deaktiviert durch Einstellung von user-scalable auf "nein"
<metaname="viewport"content="width=device-width, user-scalable=no, initial-scale=1">
Diskussion
Die Nutzer/innen müssen die Möglichkeit haben, ihr Surferlebnis an ihre Vorlieben und Bedürfnisse anzupassen. Die Browser bieten verschiedene Einstellungen und Funktionen, um dies zu unterstützen. Die Möglichkeit, größere Schriftgrößen einzustellen oder die Seite zu zoomen, ist wichtig, aber viele Websites verbieten das Zoomen auf Handheld-Geräten.
Bevor das responsive Webdesign aufkam, wurden Websites für große Viewports entworfen und oft feste Breitenwerte wie 960px oder 1024px für den Hauptinhalt der Seite verwendet. Mit dem Aufkommen von Smartphones und anderen Handhelds wurde dies zu einem Problem, da die Pixelbreiten der Bildschirme auf diesen Geräten in der Regel viel kleiner waren als 960px. Der anfängliche enthaltende Block, das Rechteck, in dem das Wurzelelement (<html>) lebt, hat die Abmessungen des Viewports. Wenn die Seite größer als der Viewport ist, kann dies zu unbeabsichtigtem Layout-Umbruch, abgeschnittenen Inhalten und unangenehmen Scroll-Bounds führen. Aus diesem Grund verwenden die mobilen Browser von in der Regel eine feste Breite (in der Regel 980px bis 1024px) für den ersten enthaltenen Block. Das resultierende Layout wird dann verkleinert, damit es auf den verfügbaren Bildschirmplatz passt. Das entschärft die Probleme, bedeutet aber auch, dass die CSS-Pixelgröße auf diesen Seiten viel kleiner ist und die Nutzer zum Zoomen gezwungen werden.
Bei responsiven Websites ist das kein Problem, denn sie wurden so entwickelt, dass sie in verschiedenen Viewports gut funktionieren. Allerdings musst du die feste Breite des enthaltenen Blocks auf mobilen Geräten in eine Breite relativ zu den Abmessungen des Viewports ändern, um mit responsiven Designs zu funktionieren. Dazu verwendest du das viewport meta Tag, wie in Beispiel 1-24 gezeigt.
width=device-width setzt die Breite des Viewports auf die verfügbare Breite des Geräts.
initial-scale=1 stellt sicher, dass die Standardzoomstufe 100% beträgt. Das ist nicht immer die Standardeinstellung in allen Browsern. Deshalb empfehle ich, ihn explizit einzustellen.
Die Tatsache, dass eine Seite responsive und für kleine Viewports optimiert ist, bedeutet nicht, dass die Nutzer nicht zoomen wollen. Adrian Roselli listet in seinem Artikel "Don't Disable Zoom" mehrere Gründe auf, warum die Zoomfunktion wichtig ist :
-
Der Text kann für den Nutzer zu klein sein, um ihn zu lesen.
-
Der/die Nutzer/in möchte vielleicht mehr Details in einem Bild sehen.
-
Die Auswahl von Wörtern zum Kopieren/Einfügen kann für die Nutzer einfacher sein, wenn der Text größer ist.
-
Der Nutzer möchte animierte Elemente aus der Ansicht herausschneiden, um die Ablenkung zu verringern.
-
Der Entwickler hat das responsive Design schlecht umgesetzt, und der Nutzer muss zoomen, um die Seite zu nutzen.
-
Es gibt einen Browserfehler, der dazu führt, dass die Standard-Zoomstufe ungerade ist.
-
Es kann für die Nutzer verwirrend sein, wenn der Browser eine Kneif-/Spreiz-Geste als etwas anderes interpretiert.
Websites, die den Zoom deaktivieren, sind ein weit verbreitetes Problem. Laut dem Kapitel über Barrierefreiheit im Web Almanach 2022 versuchen 23 % der Desktop-Homepages und 28 % der mobilen Homepages, den Zoom zu deaktivieren. Der Autor des Berichts verwendet den Begriff Versuch, weil einige Browser, wie Safari auf iOS oder Samsung Internet auf Android, die Eigenschaften maximum-scale=1 und user-scalable=no ignorieren. Chrome und Firefox tun das nicht, aber die Nutzer können den Zoom in ihren Browsereinstellungen erzwingen. In Firefox findest du die Browsereinstellungen, wählst "Barrierefreiheit" und aktivierst "Zoom auf allen Websites". In Chrome findest du die Browsereinstellungen, wählst "Eingabehilfen" und aktivierst "Zoom erzwingen".
Begründete Gründe für die Deaktivierung des Zooms
Auf , der durchschnittlichen Website, gibt es keinen guten Grund, den Zoom auszuschalten. Das Gleiche gilt für app-ähnliche Websites, die nativen Apps ähneln. Es gibt seltene Ausnahmen, bei denen die Gesten zum Zoomen die Funktionalität der Website beeinträchtigen würden. Ein Beispiel wäre eine Website, die nur eine interaktive Karte enthält. In diesem Fall kann es in Ordnung sein, die native Zoomfunktion zu deaktivieren, aber du musst eine alternative benutzerdefinierte Lösung anbieten.
1.4 Optimierung der Rendering-Reihenfolge
Problem
Der Kopf eines Dokuments kann verschiedene Elemente enthalten, die unterschiedlichen Zwecken dienen: Metatags, Skripte, Links zu anderen Ressourcen und mehr. Die Reihenfolge kann beliebig sein, aber bestimmte Elemente sollten vor anderen stehen, um eine gute Ladeleistung zu gewährleisten. Ineffizientes Laden von Assets verhindert, dass die Nutzer/innen Informationen schnell oder gar nicht abrufen können.
Lösung
Der Experte für Web-Performance Harry Roberts empfiehlt eine bestimmte Reihenfolge der Elemente innerhalb der <head>, um die bestmögliche Ladestrategie zu gewährleisten, wie in Beispiel 1-28 gezeigt.
Beispiel 1-28. Die ideale Reihenfolge der Elemente in der <head>
<head><!-- Character encoding --><metacharset="UTF-8"><!-- Viewport meta tag --><metaname="viewport"content="width=device-width, initial-scale=1"><!-- CSP headers --><metahttp-equiv="Content-Security-Policy"content="upgrade-insecure-requests"><!-- Page title --><title>Johanna’s Toy Store</title><!-- preconnect --><linkrel="preconnect"href="#"/><!-- Asynchronous JavaScript --><scriptsrc=""async></script><!-- CSS that includes @import --><style>@import"file.css";</style><!-- Synchronous JavaScript --><scriptsrc=""></script><!-- Synchronous CSS --><linkrel="stylesheet"href="#"><!-- preload --><linkrel="preload"href="#"/><!-- Deferred JavaScript --><scriptsrc=""defer></script><scriptsrc=""type="module"></script><!-- prefetch / prerender --><linkrel="prefetch"href="#"/><linkrel="prerender"href="#"/><!-- Everything else (meta tags, icons, open graphs, etc.) --><metaname="description"content=""></head>
Diskussion
Es gibt verschiedene Bereiche im Webdesign und in der Webentwicklung, wie Barrierefreiheit, Benutzerfreundlichkeit, Benutzererfahrung, Leistung und Sicherheit. Sie alle konzentrieren sich auf unterschiedliche Dinge, aber sie schließen sich nicht gegenseitig aus. Barrierefreiheit zum Beispiel überschneidet sich mit all diesen Bereichen. Die Verbesserung der Zugänglichkeit von Formularfeldern kann zu einem besseren Nutzererlebnis für alle führen. Wenn eine Website langsam lädt, wirkt sich das auf das Nutzererlebnis und die Barrierefreiheit aus. Eine Website, die bei einer langsamen Verbindung zu lange oder gar nicht lädt , ist nicht zugänglich. Barrierefreie Websites zu entwerfen und zu erstellen bedeutet, ein inklusives Erlebnis ohne Barrieren zu schaffen, die Menschen daran hindern, mit dem Internet zu interagieren. Zu diesen Barrieren gehören körperliche, vorübergehende und situationsbedingte Behinderungen sowie sozioökonomische Einschränkungen bei Hardware, Bandbreite und Geschwindigkeit.
Die richtige Reihenfolge der Elemente in <head> wirkt sich nicht nur auf die Leistung im Allgemeinen aus, sondern auch auf die Darstellung bestimmter Elemente, die wichtige Informationen für Benutzer von Hilfsmitteln enthalten können. HTML wird zeilenweise geparst, was bedeutet, dass ein Browser nicht weiß, dass Zeile 4 existiert, wenn Zeile 3 noch nicht fertig geparst ist. Wenn etwas das Rendering zu Beginn eines Dokuments blockiert, müssen die nachfolgenden Zeilen warten, bis der Browser das Parsen der vorangegangenen Zeilen abgeschlossen hat. Deshalb ist die richtige Reihenfolge der Elemente auf <head> entscheidend für die Leistung und Zugänglichkeit des Webs.
Leistungsexperten schlagen verschiedene Regeln und Optimierungen vor, darunter:
-
Wenn etwas nicht in die
<head>gehört, entferne es oder stelle es in die<body>. Das gilt auch für Skripte mit niedriger Priorität, Weiterleitungen oder jede unnötige Nutzlast. -
Hosten Sie so weit wie möglich selbst und verlassen Sie sich nicht auf Content Delivery Networks (CDNs) von Dritten. Harry Roberts erklärt in seinem Artikel "Self-Host Your Static Assets" warum .
-
Validiere deinen HTML-Code, denn ungültige Elemente in der
<head>können Leistungsprobleme verursachen. -
Metadaten über die Seite, wie z. B. die Zeichenkodierung und Informationen über den Viewport, werden zuerst angezeigt.
-
Nichts Rendering-Blockierendes muss vor der
<title>kommen. -
Synchrones JavaScript kommt vor CSS, weil CSS die Ausführung von nachfolgendem JavaScript blockiert.
-
Vermeide
@importin CSS. -
SEO- und Social-Meta-Tags kommen zuletzt.
Harry Roberts hat eine CSS-Datei mit dem Namen ct.css erstellt, die auch als Bookmarklet verfügbar ist und mit der du Tests für deine <head> Elemente durchführen kannst (siehe Abbildung 1-5).
Abbildung 1-5. ct.css zeigt Meldungen auf einer Seite an, nachdem Tests durchgeführt wurden
1.5 Struktur des Dokuments
Lösung
Verwende Orientierungspunkte: Regionen, die die Organisation und Struktur einer Webseite darstellen. Sie kennzeichnen normalerweise Bereiche, auf die der Nutzer schnell zugreifen möchte.
Kapitel 2, "Seitenstrukturierung" konzentriert sich auf Seitenregionen, aber es gibt auch allgemeine Orientierungspunkte, die du auf deiner gesamten Website verwenden wirst, wie <header>, <main> und <footer>. Jedes Element auf der Seite sollte sich innerhalb einer dieser Orientierungspunkte befinden, wie in Beispiel 1-29 gezeigt.
Beispiel 1-29. Eine beispielhafte Struktur einer Webseite
<!DOCTYPE html><htmllang="en"><head><metacharset="UTF-8"><metaname="viewport"content="width=device-width, initial-scale=1.0"><title>Products - Johanna’s Toy Store</title></head><body><header><ahref="/">Johanna’s Toy Store</a><navaria-label="Main"><ul><li><ahref="/home">Home</a></li><li><ahref="/products"aria-current="page">Products</a></li><li><ahref="/team">Team</a></li><li><ahref="/contact">Contact</a></li></ul></nav><formrole="search"><labelfor="search">Search</label><inputtype="text"id="search"></form></header><mainid="content"><h1>All products</h1></main><footer>©2024</footer></body></html>
Die Kopfzeile der Website (Banner-Wahrzeichen).
Die Hauptnavigation (Navigationslandmarke).
Die Website-Suche (Suchmarkierung).
Der Hauptinhalt (Hauptmerkmal).
Die Fußzeile der Website (contentinfo landmark).
Diskussion
Die Verwendung semantischer Elemente innerhalb von Komponenten und Regionen einer Seite ist die Grundlage jeder barrierefreien Website, aber die Nutzer können auch von größeren semantischen Gruppen profitieren. Die Seite muss vermitteln, wie sie strukturiert ist, und gemeinsame seitenweite und seitenbezogene Elemente gruppieren. Landmarken in HTML helfen dabei.
Du kannst Orientierungspunkte mit den entsprechenden HTML-Elementen definieren oder das Attribut role verwenden, wenn kein Element vorhanden ist. Die Elemente in Beispiel 1-30 sind semantisch identisch.
Beispiel 1-30. Zwei Banner Landmarken
<!-- <header> with an implicit banner role --><header></header><!-- <div> with an explicit banner role --><divrole="banner"></div>
Tipp
Die meisten semantischen Elemente in HTML enthalten zwei Informationen: ihre zugängliche Rolle und einen zugänglichen Namen. Die Rolle legt fest, um welche Art von Element es sich handelt: eine Schaltfläche, ein Link, ein Bild usw. Der zugängliche Name ist ein Text, mit dem Software eine Komponente identifizieren kann. Er stammt aus dem Textinhalt des Elements, einem anderen zugehörigen Element wie <label> oder einem Attribut wie aria-label, aria-labelledby, alt oder title.
Befolge die erste Regel der Verwendung von ARIA (Accessible Rich Internet Application) und ziehe Elemente mit impliziten Rollen der Verwendung des role Attributs vor, wenn die Browserunterstützung dies zulässt. Ältere Browser und Screenreader, die Elemente mit impliziten Landmark-Rollen nicht unterstützen, benötigten früher die zusätzliche explizite Rolle, wie in Beispiel 1-31 gezeigt, aber die Angabe beider Rollen ist nicht mehr notwendig.
Beispiel 1-31. <header> mit einer zusätzlichen expliziten Bannerrolle
<headerrole="banner"></header>
Es gibt verschiedene Arten von Regionen, die in unterschiedlichen Kontexten anderen Zwecken dienen. Tabelle 1-2 listet HTML-Elemente, ihre entsprechenden ARIA-Rollen und den Kontext auf, in dem sie als Orientierungspunkte verwendet werden.
| Element | ARIA-Rolle | Bedingungen |
|---|---|---|
|
banner |
Nur im Zusammenhang mit dem body-Element; nicht, wenn es ein Nachkomme von |
|
Navigation |
|
|
Haupt |
|
|
Region |
Wenn sie einen zugänglichen Namen hat. |
|
Formular |
Wenn sie einen zugänglichen Namen hat. |
|
Suche |
Oder bilde mit |
|
komplementär |
|
|
contentinfo |
Nur im Zusammenhang mit dem body-Element; nicht, wenn es ein Nachkomme von |
Vorteile
Es gibt viele Gründe, Landmarken zu verwenden. Im Folgenden werden einige dieser Gründe im Detail erläutert.
Navigation
Bildschirm Leserinnen und Leser können mit Tastenkombinationen oder Gesten von Orientierungspunkt zu Orientierungspunkt springen und so bequem zu bestimmten Bereichen springen, ohne mit dem Rest der Seite zu interagieren (siehe Tabelle 1-3).
In VoiceOver auf iOS kannst du im Rotor die Option "Orientierungspunkte" auswählen, mit der du direkten Zugriff auf bestimmte Elemente auf der Seite hast, und mit den Wischgesten nach oben und unten zwischen den Orientierungspunkten navigieren. In TalkBack auf Android kannst du die Lesesteuerung auf "Orientierungspunkte" einstellen und zum Navigieren nach oben und unten streichen. In NVDA unter Windows kannst du D oder Shift + D drücken und in JAWS unter Windows R und Shift + R, um dasselbe zu tun (siehe Tabelle 1-3).
| Bildschirmleser | Befehl |
|---|---|
NVDA |
|
JAWS |
|
Erzähler |
|
VoiceOver auf iOS |
Rotor |
TalkBack auf Android |
Lesekontrollen |
Vor allem Screenreader-Nutzer/innen profitieren von den Landmarken, aber auch Browser-Erweiterungen wie "Landmarken-Navigation über Tastatur oder Pop-up" fügen dem Browser Tastaturkürzel hinzu, die auch Nicht-Screenreader-Nutzer/innen Zugang zu den Landmarken bieten . Siehe Abbildung 1-6.
Übersicht
Auf dem Bildschirm können Leserinnen und Leser alle Orientierungspunkte auf einer Seite auflisten und direkt aufrufen (siehe Tabelle 1-4).
| Bildschirmleser | Befehl |
|---|---|
NVDA |
|
JAWS |
|
VoiceOver auf macOS |
Rotor |
Abbildung 1-6. Die Landmarke main auf handbuch.wien.gv.at, hervorgehoben durch die Browsererweiterung "Landmark Navigation".
Ortsspezifische Wahrzeichen
Die drei wichtigsten Orientierungspunkte von sind <header>, <main>, und <footer>.
Banner-Wahrzeichen
Die Seite <header> mit und ihrer impliziten Rolle banner enthält hauptsächlich standortbezogene und nicht seitenbezogene Inhalte. Das sind in der Regel ein Logo, Sprunglinks, die Hauptnavigation, Sekundärnavigationen, ein Such-Widget und andere Inhalte, die relevant und auf jeder Seite sichtbar sind.
Nicht jeder <header> ist ein Orientierungspunkt. Wenn es innerhalb von <article>, <aside>, <main>, <nav> oder <section> verschachtelt ist, ist es semantisch einem <div> ähnlich und wird nicht mehr als Orientierungspunkt angezeigt. Es ist in Ordnung, wenn du mehrere header Elemente auf einer Seite hast, aber du solltest nur einen einzigen banner Orientierungspunkt hinzufügen.
Normalerweise findest du banner am Anfang der <body> im Dokument. Optisch stehen sie meist oben auf der Seite. Das ist ein gängiges Muster, aber keine strikte Regel; es kann auch wie eine Seitenleiste aussehen. Die Position hat keinen Einfluss auf seinen semantischen Zweck. Nur weil sie sich an der Seite befindet, muss sich ihre Rolle nicht ändern.
wichtigstes Wahrzeichen
Die implizite main Rolle des <main> Elements repräsentiert den Kerninhalt der Seite. Es sollte nur ein sichtbares Hauptelement auf einer Seite geben, und seine Vorfahren sollten auf html und body beschränkt sein, um eine hierarchisch korrekte Struktur zu gewährleisten. Falls nötig, kann es in <div> Elemente eingepackt werden.
Wenn du mit einer SPA mit mehreren <main> Elementen auf einer Seite arbeitest, blende alle inaktiven Elemente aus, wie in Beispiel 1-32 gezeigt. Wenn du mehr als ein sichtbares und erreichbares Hauptelement auf einer Seite hast, kann das die Nutzer verwirren und dazu führen, dass sie Inhalte verpassen, weil sie normalerweise nur eines pro Seite erwarten.
Beispiel 1-32. Mehrere main Elemente, aber nur eines ist sichtbar
<mainhidden><h1>Home</h1></main><main><h1>Products</h1></main><mainhidden><h1>Team</h1></main><mainhidden><h1>Contact</h1></main>
contentinfo Wahrzeichen
Die implizite contentinfo Rolle des Elements <footer> enthält auch standortbezogene Inhalte. Das sind in der Regel Copyright-Daten, sekundäre Navigationen und andere Links.
Ähnlich wie bei <header> ist <footer> nur im Kontext von <body> ein Orientierungspunkt. Wenn es innerhalb von <article>, <aside>, <main>, <nav> oder <section> verschachtelt ist, ist es kein Orientierungspunkt mehr. Es ist in Ordnung, wenn du mehrere footer Elemente auf einer Seite hast, aber du solltest nur eine contentinfo Landmarke hinzufügen.
Get Web Accessibility Cookbook now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
