CSS und JavaScript: Barrierefreiheits-Best Practices

CSS und JavaScript haben nicht die gleiche unmittelbare Bedeutung für die Barrierefreiheit wie HTML, können jedoch je nach Verwendung die Barrierefreiheit unterstützen oder verschlechtern. Anders ausgedrückt, es ist wichtig, einige Best Practices zu beachten, um sicherzustellen, dass Ihre Verwendung von CSS und JavaScript die Barrierefreiheit Ihrer Dokumente nicht beeinträchtigt.

Beginnen wir mit einem Blick auf CSS.

Es ist möglich, mit CSS jedes HTML-Element wie alles aussehen zu lassen, aber das bedeutet nicht, dass Sie dies tun sollten. Wie wir in unserem Artikel HTML: Eine gute Basis für Barrierefreiheit häufig erwähnt haben, sollten Sie das passende semantische Element für die jeweilige Aufgabe verwenden, wann immer dies möglich ist. Andernfalls kann dies Verwirrung und Nutzungsprobleme für alle verursachen, insbesondere aber für Benutzer mit Behinderungen. Die richtige Semantik hat viel mit den Erwartungen der Benutzer zu tun – Elemente sehen und verhalten sich auf bestimmte Weise entsprechend ihrer Funktionalität, und diese allgemeinen Konventionen werden von den Benutzern erwartet.

Ein Beispiel: Ein Screenreader-Benutzer kann eine Seite nicht über Überschriften navigieren, wenn der Entwickler die entsprechenden Überschriftselemente nicht zum Markieren des Inhalts verwendet hat. In gleicher Weise verliert eine Überschrift ihren visuellen Zweck, wenn Sie sie so stilisieren, dass sie nicht mehr wie eine Überschrift aussieht.

Fazit: Sie können das Styling eines Seitenelements aktualisieren, um es in Ihr Design einzupassen, aber ändern Sie es nicht so sehr, dass es nicht mehr den Erwartungen entspricht. Die folgenden Abschnitte fassen die wichtigsten HTML-Funktionen zusammen, die berücksichtigt werden sollten.

"Standard"-Textinhaltstruktur

Überschriften, Absätze, Listen — der Kerntextinhalt Ihrer Seite:

<h1>Heading</h1>

<p>Paragraph</p>

<ul>
  <li>My list</li>
  <li>has two items.</li>
</ul>

Typisches CSS könnte folgendermaßen aussehen:

h1 {
  font-size: 5rem;
}

p,
li {
  line-height: 1.5;
  font-size: 1.6rem;
}

Sie sollten:

• Sinnvolle Schriftgrößen, Zeilenhöhen, Buchstabenabstände usw. auswählen, damit Ihr Text logisch, lesbar und angenehm zu lesen ist.
• Sicherstellen, dass sich Ihre Überschriften vom Fließtext abheben, typischerweise groß und fett wie das Standardstyling. Ihre Listen sollten wie Listen aussehen.
• Ihre Textfarbe sollte gut mit Ihrer Hintergrundfarbe kontrastieren.

Weitere Informationen finden Sie unter HTML-Textgrundlagen und Textstyling.

Hervorgehobener Text

Inline-Markup, das dem umschlossenen Text bestimmte Hervorhebungen verleiht:

<p>The water is <em>very hot</em>.</p>

<p>
  Water droplets collecting on surfaces is called <strong>condensation</strong>.
</p>

Vielleicht möchten Sie Ihrem hervorgehobenen Text eine einfache Farbgebung hinzufügen:

strong,
em {
  color: #a60000;
}

In der Regel brauchen Sie Hervorhebungselemente jedoch nicht in signifikantem Maße zu stylen. Die Standardkonventionen für fett und kursiv sind sehr erkennbar, und das Ändern des Stils kann Verwirrung stiften. Mehr zu Hervorhebungen finden Sie unter Betonung und Bedeutung.

Abkürzungen

Ein Element, das eine Abkürzung, ein Akronym oder eine Initialisierung mit seiner Erweiterung in Verbindung bringen kann:

<p>
  Web content is marked up using Hypertext Markup Language, or
  <abbr>HTML</abbr>.
</p>

Auch hier möchten Sie es vielleicht einfach stylen:

abbr {
  color: #a60000;
}

Die anerkannte Stilkonvention für Abkürzungen ist eine gepunktete Unterstreichung, und es ist unklug, hiervon erheblich abzuweichen. Mehr zu Abkürzungen finden Sie unter Abkürzungen.

Links

Hyperlinks — die Möglichkeit, neue Orte im Web zu erreichen:

<p>Visit the <a href="https://www.mozilla.org">Mozilla homepage</a>.</p>

Ein sehr einfaches Linkstyling wird unten gezeigt:

a {
  color: #ff0000;
}

a:hover,
a:visited,
a:focus {
  color: #a60000;
  text-decoration: none;
}

a:active {
  color: #000000;
  background-color: #a60000;
}

Die Standard-Linkkonventionen sind unterstrichen und eine andere Farbe (Standard: Blau) in ihrem Normalzustand, eine andere Farbvariante, wenn der Link bereits besucht wurde (Standard: Lila), und noch eine andere Farbe, wenn der Link aktiviert wird (Standard: Rot). Zusätzlich ändert sich das Maussymbol zu einem Zeiger, wenn Links mit der Maus überfahren werden, und der Link erhält eine Hervorhebung, wenn er fokussiert (z.B. via Tabben) oder aktiviert wird. Das folgende Bild zeigt die Hervorhebung sowohl in Firefox (eine gepunktete Umrandung) als auch in Chrome (eine blaue Umrandung):

Sie können kreativ mit Linkstilen sein, solange Sie den Benutzern weiterhin Feedback geben, wenn sie mit den Links interagieren. Etwas sollte definitiv passieren, wenn sich die Zustände ändern, und Sie sollten den Zeigerzeiger oder die Umrandung nicht entfernen — beide sind sehr wichtige Hilfen für die Zugänglichkeit für Benutzer, die Tastatursteuerungen verwenden.

Formularelemente

Elemente, die es Benutzern erlauben, Daten in Webseiten einzugeben:

<div>
  <label for="name">Enter your name</label>
  <input type="text" id="name" name="name" />
</div>

Gute Beispiel-CSS-Code für Formulare finden Sie in unserem form-css.html Beispiel (sehen Sie es live auch).

Die meiste CSS, die Sie für Formulare schreiben, wird darauf abzielen, die Elemente zu dimensionieren, Labels und Eingaben auszurichten und sie ordentlich und übersichtlich aussehen zu lassen.

Sie sollten jedoch nicht zu sehr von der erwarteten visuellen Rückmeldung abweichen, die Formularelemente erhalten, wenn sie fokussiert werden, was im Wesentlichen dasselbe wie bei Links (siehe oben) ist. Sie könnten Fokus-/Hover-Zustände von Formularelementen so stylen, dass dieses Verhalten in allen Browsern konsistenter ist oder besser in Ihr Seitendesign passt, aber entfernen Sie es nicht einfach — Menschen sind auf diese Hinweise angewiesen, um zu verstehen, was gerade passiert.

Tabellen

Tabellen zur Darstellung tabellarischer Daten.

Ein gutes einfaches Beispiel für HTML- und CSS-Tabellen finden Sie in unserem table-css.html Beispiel (sehen Sie es live).

Tabellen-CSS dient in der Regel dazu, die Tabelle besser in Ihr Design zu integrieren und weniger unschön aussehen zu lassen. Es ist eine gute Idee, sicherzustellen, dass die Tabellenüberschriften hervorstechen (normalerweise fett), und Zebramuster zu verwenden, um verschiedene Zeilen leichter lesbar zu machen.

Bei der Auswahl eines Farbschemas für Ihre Website sollten Sie sicherstellen, dass die Textfarbe (Vordergrund) mit der Hintergrundfarbe gut kontrastiert. Ihr Design mag toll aussehen, aber es nützt nichts, wenn Menschen mit Sehbehinderungen wie Farbenblindheit Ihre Inhalte nicht lesen können.

Es gibt eine einfache Möglichkeit zu überprüfen, ob Ihr Kontrast stark genug ist, um keine Probleme zu verursachen. Es gibt eine Reihe von Online-Tools zur Kontrastprüfung, in die Sie Ihre Vordergrund- und Hintergrundfarben eingeben können, um sie zu überprüfen. Zum Beispiel ist WebAIMs Color Contrast Checker einfach zu bedienen und bietet eine Erklärung, was Sie tun müssen, um den WCAG-Kriterien in Bezug auf den Farbkontrast zu entsprechen.

Ein weiterer Tipp ist der Verzicht auf farbliche Alleinstellungsmerkmale für Hinweise/Informationen, da das für diejenigen nutzlos ist, die die Farbe nicht sehen können. Markieren Sie beispielsweise erforderliche Formularfelder nicht nur in Rot, sondern kennzeichnen Sie sie mit einem Sternchen und in Rot.

Es gibt viele Fälle, in denen ein visuelles Design erfordert, dass nicht alle Inhalte gleichzeitig angezeigt werden. In unserem Tabbed Info Box Beispiel (siehe Quellcode) haben wir beispielsweise drei Informationspanels, die wir jedoch positionieren sie übereinander und bieten Registerkarten, die angeklickt werden können, um jede anzuzeigen (sie sind auch tastaturzugänglich — Sie können alternativ Tab und Enter/Return verwenden, um sie auszuwählen).

Screenreader-Benutzern ist das alles egal — sie sind mit dem Inhalt zufrieden, solange die Quellreihenfolge sinnvoll ist und sie auf alles zugreifen können. Absolute Positionierung (wie in diesem Beispiel verwendet) gilt allgemein als einer der besten Mechanismen, Inhalte für visuelle Effekte zu verbergen, da sie Screenreader nicht daran hindert, auf sie zuzugreifen.

Auf der anderen Seite sollten Sie nicht visibility: hidden oder display: none verwenden, da sie Inhalte vor Screenreadern verbergen. Es sei denn natürlich, es gibt einen guten Grund, warum Sie möchten, dass dieser Inhalt vor Screenreadern verborgen bleibt.

Benutzer können Ihre Stile mit ihren eigenen benutzerdefinierten Stilen überschreiben, beispielsweise:

• Sehen Sie sich Sarah Maddoxs How to use a custom style sheet (CSS) with Firefox an, einen nützlichen Leitfaden, der erklärt, wie Sie dies manuell in Firefox tun können.
• Es ist wahrscheinlich einfacher, dies mit einer Erweiterung zu tun. Beispielsweise ist die Stylus-Erweiterung für Firefox verfügbar, wobei Stylish eine Chrome Äquivalent ist.

Benutzer könnten dies aus verschiedenen Gründen tun. Ein User mit Seheinschränkungen könnte wollen, dass der Text auf allen von ihnen besuchten Websites größer ist, oder ein User mit schwerer Farbsehschwäche könnte alle Websites in kontraststarken Farben sehen wollen, die für sie einfach zu erkennen sind. Wie auch immer der Bedarf aussieht, Sie sollten sich damit wohlfühlen und Ihre Designs flexibel genug gestalten, damit solche Änderungen in Ihrem Design funktionieren. Beispielsweise könnten Sie sicherstellen, dass Ihr Hauptinhaltbereich mit größerem Text umgehen kann (vielleicht beginnt er zu scrollen, um alles sichtbar zu machen) und ihn nicht einfach versteckt oder komplett bricht.

Auch JavaScript kann die Barrierefreiheit beeinträchtigen, abhängig davon, wie es verwendet wird.

Modernes JavaScript ist eine leistungsstarke Sprache, und wir können heutzutage viel damit machen, von einfachen Inhalts- und UI-Updates bis hin zu vollständigen 2D- und 3D-Spielen. Es gibt keine Regel, die besagt, dass alle Inhalte zu 100% für alle Menschen zugänglich sein müssen — Sie müssen nur tun, was Sie können, und Ihre Apps so zugänglich wie möglich machen.

Einfache Inhalte und Funktionen sind argumentierbar leicht zugänglich zu machen — zum Beispiel Text, Bilder, Tabellen, Formulare und Schaltflächen, die Funktionen aktivieren. Wie wir in unserem Artikel HTML: Eine gute Basis für Barrierefreiheit betrachtet haben, sind die wichtigsten Überlegungen:

• Gute Semantik: Das richtige Element für die richtige Aufgabe verwenden. Beispielsweise sicherstellen, dass Sie Überschriften und Absätze verwenden und <button> und <a> Elemente.
• Sicherstellen, dass Inhalte als Text vorliegen, entweder direkt als Textinhalt, gute Textbezeichnungen für Formularelemente oder textuelle Alternativen, z.B. Alt-Text für Bilder.

Wir haben auch ein Beispiel dafür betrachtet, wie man mit JavaScript Funktionen nachrüstet, wo sie fehlen — siehe Tastaturzugänglichkeit wiederherstellen. Dies ist nicht ideal — wirklich sollten Sie einfach das richtige Element für die richtige Aufgabe verwenden — aber es zeigt, dass es in Situationen möglich ist, in denen Sie aus irgendeinem Grund das verwendete Markup nicht kontrollieren können. Eine andere Möglichkeit, die Barrierefreiheit für nicht-semantische JavaScript-gesteuerte Widgets zu verbessern, besteht darin, WAI-ARIA zu verwenden, um zusätzliche Semantik für Screenreader-Benutzer bereitzustellen. Der nächste Artikel wird dies ebenfalls im Detail behandeln.

Komplexere Funktionen wie 3D-Spiele lassen sich nicht so einfach barrierefrei gestalten — ein komplexes 3D-Spiel, das mit WebGL erstellt wurde, wird auf einem <canvas> Element gerendert, das derzeit keine Möglichkeit bietet, textuelle Alternativen oder andere Informationen für Benutzer mit starker Sehbehinderung bereitzustellen. Es ist arguierbar, dass ein solches Spiel nicht wirklich diese Personengruppe als Teil seiner Hauptzielgruppe hat, und es wäre unvernünftig, von Ihnen zu erwarten, dass es zu 100% für blinde Menschen zugänglich ist. Sie könnten jedoch Tastatursteuerungen implementieren, sodass es von Nicht-Maus-Benutzern verwendet werden kann und das Farbschema kontrastierend genug machen, um von denen mit Farbsehschwächen benutzt zu werden.

Das Problem tritt häufig auf, wenn Menschen zu sehr von JavaScript abhängen. Manchmal sehen Sie eine Website, auf der alles mit JavaScript gemacht wurde — das HTML wurde von JavaScript generiert, die CSS wurde von JavaScript generiert, usw. Dies hat alle möglichen Barrierefreiheits- und anderen Probleme damit, sodass es nicht empfohlen wird.

Neben der Verwendung des richtigen Elements für den richtigen Zweck sollten Sie auch sicherstellen, dass Sie die richtige Technologie für den richtigen Zweck verwenden! Überlegen Sie sorgfältig, ob Sie diese schicke, JavaScript-gesteuerte 3D-Informationsbox benötigen oder ob alter einfacher Text ausreicht. Überlegen Sie sorgfältig, ob Sie ein komplexes nicht standardmäßiges Formular-Widget benötigen oder ob ein Texteingabefeld ausreicht. Und generieren Sie bitte nicht den gesamten HTML-Inhalt mit JavaScript, wenn dies möglich ist.

Sie sollten unaufdringliches JavaScript im Hinterkopf behalten, wenn Sie Ihre Inhalte erstellen. Der Gedanke bei unaufdringlichem JavaScript ist, dass es wenn möglich verwendet werden sollte, um Funktionalität zu erweitern, nicht komplett zu erstellen — Grundfunktionen sollten idealerweise ohne JavaScript funktionieren, auch wenn dies nicht immer eine Option ist. Aber wieder, ein großer Teil davon ist, eingebaute Browserfunktionalität wo möglich zu verwenden.

Gute Anwendungsbeispiele für unaufdringliches JavaScript beinhalten:

• Bereitstellung von Client-seitiger Formularvalidierung, die Benutzer schnell auf Probleme mit ihren Formulareingaben aufmerksam macht, ohne warten zu müssen, bis der Server die Daten überprüft. Wenn es nicht verfügbar ist, funktioniert das Formular trotzdem, aber die Validierung könnte langsamer sein.
• Bereitstellung benutzerdefinierter Steuerelemente für HTML <video>s, die für reine Tastaturbenutzer zugänglich sind, zusammen mit einem direkten Link zum Video, das verwendet werden kann, um es zuzugreifen, falls JavaScript nicht verfügbar ist (die Standard-<video>-Browsersteuerelemente sind in den meisten Browsern nicht keyboard-zugänglich).

Wir haben ein schnelles und einfaches Beispiel für Client-seitige Formularvalidierung erstellt — siehe form-validation.html (auch sehen Sie das Demo live). Hier sehen Sie ein einfaches Formular; wenn Sie versuchen, das Formular abzusenden, während eines oder beide Felder leer sind, schlägt die Übermittlung fehl, und eine Fehlermeldungsbox erscheint, um Ihnen mitzuteilen, was falsch ist.

Diese Art der Formularvalidierung ist unaufdringlich — Sie können das Formular problemlos verwenden, auch wenn JavaScript nicht verfügbar ist, und jede sinnvolle Formularimplementierung wird auch serverseitige Validierung aktiviert haben, da es zu einfach ist, clientseitige Validierung zu umgehen (z.B. indem JavaScript im Browser ausgeschaltet wird). Die clientseitige Validierung ist dennoch sehr nützlich, um Fehler zu melden — Benutzer können umgehend über Fehler informiert werden, anstatt auf eine Runde zum Server und ein Seitenneuladen warten zu müssen. Dies ist ein definitiver Benutzervorteil.

Wir haben diese Formularvalidierung auch ziemlich barrierefrei gemacht. Wir haben <label> Elemente verwendet, um sicherzustellen, dass die Formularbezeichnungen eindeutig mit ihren Eingaben verknüpft sind, sodass Screenreader sie zusammen mit dem Elementnamen vorlesen können:

<label for="name">Enter your name:</label>
<input type="text" name="name" id="name" />

Wir führen die Validierung nur durch, wenn das Formular übermittelt wird — dies ist, damit wir die Benutzeroberfläche nicht zu oft aktualisieren und Screenreader (und möglicherweise andere) Benutzer verwirren:

form.onsubmit = validate;

function validate(e) {
  errorList.textContent = "";
  for (let i = 0; i < formItems.length; i++) {
    const testItem = formItems[i];
    if (testItem.input.value === "") {
      errorField.style.left = "360px";
      createLink(testItem);
    }
  }

  if (errorList.hasChildNodes()) {
    e.preventDefault();
  }
}

Echte Formularvalidierung wäre viel komplexer als dies — Sie würden überprüfen wollen, dass der eingegebene Name tatsächlich wie ein Name aussieht, das eingegebene Alter tatsächlich eine Zahl ist und realistisch (z.B. nicht negativ und weniger als 4 Stellen). Hier haben wir nur eine einfache Überprüfung implementiert, dass in jedes Eingabefeld ein Wert eingegeben wurde (if (testItem.input.value === '')).

Wenn die Validierung durchgeführt wurde, das heißt, wenn die Tests bestanden werden, wird das Formular abgesendet. Wenn es jedoch Fehler gibt (if (errorList.hasChildNodes())), stoppen wir die Formularübermittlung (unter Verwendung von preventDefault()), und zeigen alle Fehlermeldungen an, die erzeugt wurden (siehe unten). Dieser Mechanismus bedeutet, dass die Fehler nur angezeigt werden, wenn Fehler vorhanden sind, was besser für die Benutzerfreundlichkeit ist.

Für jedes Eingabefeld, das keinen Wert hat, wenn das Formular übermittelt wird, erstellen wir ein Listenelement mit einem Link und fügen es in die errorList ein.

function createLink(testItem) {
  const listItem = document.createElement("li");
  const anchor = document.createElement("a");

  const name = testItem.input.name;
  anchor.textContent = `${name} field is empty: fill in your ${name}.`;
  anchor.href = `#${name}`;
  listItem.appendChild(anchor);
  errorList.appendChild(listItem);
}

Jeder Link dient einem doppelten Zweck — er sagt Ihnen, was das Problem ist, plus Sie können darauf klicken/ihn aktivieren, um direkt zu dem jeweiligen Eingabeelement zu springen und Ihre Eingabe zu korrigieren.

Zusätzlich wird das errorField an den Anfang der Quellreihenfolge platziert (auch wenn es in der Benutzeroberfläche mithilfe von CSS anders positioniert wird), was bedeutet, dass Benutzer genau wissen können, was mit ihren Formulareingaben falsch ist und zu den jeweiligen Eingabeelementen gelangen, indem sie zur Anfang der Seite zurück gehen.

Als abschließende Bemerkung haben wir in unserem Demo einige WAI-ARIA Attribute verwendet, um Barrierefreiheitsprobleme zu lösen, die von Bereichen, die ständig ohne Seitenneuladen aktualisiert werden, verursacht werden (Screenreader erkennen dies nicht oder benachrichtigen Benutzer standardmäßig nicht):

<div class="errors" role="alert" aria-relevant="all">
  <ul></ul>
</div>

Wir werden diese Attribute in unserem nächsten Artikel erläutern, der WAI-ARIA ausführlicher behandelt.

Es gibt noch andere Dinge, zu denen man hinsichtlich der Implementierung von JavaScript und der Überlegungen zur Barrierefreiheit aufmerksam sein sollte. Wir fügen mehr hinzu, wenn wir sie finden.

Maus-spezifische Ereignisse

Wie Sie wissen, werden die meisten Benutzerinteraktionen in clientseitigem JavaScript mithilfe von Ereignishandlern implementiert, die es uns erlauben, Funktionen als Reaktion auf bestimmte Ereignisse auszuführen. Einige Ereignisse können Barrierefreiheitsprobleme haben. Das Hauptbeispiel, dem Sie begegnen werden, sind maus-spezifische Ereignisse wie mouseover, mouseout, dblclick, usw. Funktionalität, die als Reaktion auf diese Ereignisse abläuft, wird nicht zugänglich für andere Mechanismen, wie Tastatursteuerungen.

Um solche Probleme zu mildern, sollten Sie diese Ereignisse mit ähnlichen Ereignissen koppeln, die auf andere Weise aktiviert werden können (sogenannte geräteunabhängige Ereignishandler) — focus und blur würden dafür sorgen, dass Tastaturbenutzer auch Zugang erhalten.

Sehen wir uns ein Beispiel an, das aufzeigt, wann dies nützlich sein könnte. Vielleicht möchten wir ein Miniaturbild bereitstellen, das eine größere Version des Bildes zeigt, wenn es mit der Maus überfahren oder fokussiert wird (wie Sie es in einem Produktkatalog eines E-Commerce-Anbieters sehen würden.)

Wir haben ein sehr einfaches Beispiel erstellt, das Sie unter mouse-and-keyboard-events.html finden können (siehe auch den Quellcode). Der Code beinhaltet zwei Funktionen, die das verkleinerte Bild zeigen und verstecken; diese werden durch die folgenden Zeilen ausgeführt, die sie als Ereignishandler einrichten:

imgThumb.onmouseover = showImg;
imgThumb.onmouseout = hideImg;

imgThumb.onfocus = showImg;
imgThumb.onblur = hideImg;

Die ersten beiden Zeilen führen die Funktionen aus, wenn sich der Mauszeiger über die Miniatur bewegt und aufhört, sie zu überfahren. Dies erlaubt uns jedoch nicht, die Zoomansicht mit der Tastatur zugänglich zu machen — um dies zu ermöglichen, haben wir die letzten zwei Zeilen eingeschlossen, die die Funktionen ausführen, wenn das Bild fokussiert und verschwommen (fokussierter Bereich wird verlassen) wird. Dies kann durch Tabben über das Bild erreicht werden, weil wir tabindex="0" darauf eingefügt haben.

Das click Ereignis ist interessant — es klingt mausabhängig, aber die meisten Browser aktivieren onclick Ereignishandler, nachdem Enter/Return auf einem Link oder Formularelement gedrückt wurde, das den Fokus hat, oder wenn ein solches Element auf einem Touchscreen-Gerät angetippt wird. Dies funktioniert standardmäßig jedoch nicht, wenn Sie ein standardmäßig nicht-fokusierbares Ereignis mit dem Tabindex fokussieren lassen — in solchen Fällen müssen Sie spezifisch erkennen, wenn genau diese Taste gedrückt wird (siehe Tastaturzugänglichkeit wiederherstellen).

Sie haben das Ende dieses Artikels erreicht, aber können Sie sich an die wichtigsten Informationen erinnern? Sie finden einige weitere Tests, um zu überprüfen, ob Sie diese Informationen behalten haben, bevor Sie weitermachen — siehe Testen Sie Ihre Fähigkeiten: CSS- und JavaScript-Barrierefreiheit.

Wir hoffen, dieser Artikel hat Ihnen eine gute Menge an Details und Verständnis über die Barrierefreiheitsprobleme im Zusammenhang mit der Verwendung von CSS und JavaScript auf Webseiten gegeben.

Als nächstes kommt WAI-ARIA!

• Zurück
• Übersicht: Accessibility
• Weiter