Alexander Lehner – Oida, is des org!

Dialoge mit dem closedby-Attribut aufwerten

Sat, 28 Mar 2026 00:00:00 GMT

Das native HTML-Element <dialog> ist einfach großartig. Damit lassen sich auf einfache Weise barrierefreie Modal-Dialoge erstellen, die für alle Nutzer:innen gut funktionieren. Und es wird seit 2022 von allen modernen Browsern unterstützt.

Aber es wird noch besser: Mit dem neuen Attribut closedby könnt ihr festlegen, durch welche Aktionen der Dialog geschlossen wird. Ihr könnt ein Light-Dismiss-Verhalten hinzufügen oder genau das Gegenteil tun: z.B. verhindern, dass der Dialog durch Drücken der ESC Taste geschlossen wird.

Foto: © Miguel Á. Padriñán / pexels.com

Wir sehen uns die technische Spezifikation sowie ein paar Anwendungsfälle für das neue Attribut an.

So funktioniert es

Die HTML-Spezifikation definiert closedby als ein enumeriertes Attribut mit den folgenden Werten:

any – Durch Close-Requests oder Klicken außerhalb des Dialogs wird dieser geschlossen.
closerequest – Close-Requests schließen den Dialog.
none – Der Dialog wird durch keine Benutzeraktion automatisch geschlossen.

Wenn ihr das Attribut closedby nicht für einen Modaldialog definiert, verhält dieser sich so, als wäre der Wert closerequest . Das bedeutet, dass der Dialog durch Drücken der ESC Taste auf Desktop-Plattformen oder durch eine „Zurück“- oder „Schließen“-Geste auf mobilen Plattformen geschlossen wird.

Anwendungsfälle

Light-Dismiss für Informations-Dialoge

Manche Dialoge dienen lediglich der Darstellung von Information. Von Benutzer:innen wird nicht erwartet, dass diese eine Entscheidung treffen oder ein Formular ausfüllen. Meiner Meinung nach ein idealer Anwendungsfall für Light-Dismiss: Das Dialogfeld sollte sich schließen, wenn man außerhalb des Feldes klickt oder tippt.

Bevor es das closedby Attribut gab, war zusätzlicher JavaScript-Code erforderlich, um das Schließen des Dialoges zu implementieren. Ein Beispiel findet ihr in meinem Artikel „Warum du das native Dialog-Element nutzen solltest“. Zum Glück benötigen wir jetzt nur noch den folgenden HTML-Code:

<dialog closedby="any">
    <!-- content -->
</dialog>

Genial! 🥳

Versehentliches Schließen verhindern

Dialogfelder eignen sich hervorragend, um Arbeitsabläufe wie beispielsweise die Dateneingabe über ein Formular zu kapseln. Auch den Onboarding-Prozess für eine Webanwendung könnt ihr mithilfe eines Dialogs abwickeln.

In diesen Fällen solltet ihr verhindern, dass Nutzer:innen den Dialog versehentlich schließen, z.B. über die ESC Taste. Andernfalls gingen die Daten verloren, die bereits in das Formular eingegeben wurden. Oder man könnte den Onboarding-Dialog nicht erneut aufrufen.

Daher solltet ihr closedby=“none” auf das Dialogelement setzen. Nun können Nutzer das Dialogfeld nur noch über einen von der Entwicklerin festgelegten Mechanismus schließen, beispielsweise über eine Schaltfläche zum Schließen. Hier ein Beispiel:

<dialog id="mydialog" closedby="none">
    <!-- content -->
    <button commandfor="mydialog" command="close">
        Continue
    </button>
</dialog>

Vielleicht kennt ihr die Attribute command und commandfor für Button-Elemente noch nicht. Sie sind Teil eines neuen Web-Features namens Invoker Commands API. Ihr müsst sie nicht unbedingt verwenden. Aber ich mag ihre Einfachheit und Eleganz, deshalb wollte ich sie in mein Codebeispiel aufnehmen. 😉

Browser-Unterstützung

Das closedby Attribut wird bereits von Firefox, Chrome und Edge unterstützt. Dank Interop 2026 sollte auch Safari/WebKit bis Ende des Jahres nachziehen.

Nützliche Links

Das closedby-Attribut (MDN)
„Accessibility Engineering — Lass die Web-Plattform die Arbeit machen“ (Abschnitt: „Das dialog Element: Immer oben auf“)
„Native Dialoge und die Popover API — Das solltet ihr wissen“

Best Practices für CSS Scope in Angular-Applikationen

Tue, 24 Feb 2026 00:00:00 GMT

Die neue @scope CSS-At-Regel wird seit Dezember 2025 von allen gängigen Browsern unterstützt. Dieses großartige neue Feature macht es super einfach, Styles auf bestimmte DOM-Teilbereiche, wie beispielsweise den Inhalt einer Komponente, anzuwenden.

In der Arbeit implementiere ich hauptsächlich Webanwendungen mit dem Angular-Framework. In den letzten Monaten habe ich begonnen, die View Encapsulation von Angular zu deaktivieren und stattdessen das native CSS-Feature zu verwenden. Nun möchte ich meine Erfahrungen und einige Best Practices mit euch teilen.

Foto: © Aditya Aiyar / pexels.com

Wenn ihr mit CSS Scope nicht vertraut seid, lest bitte zuerst meinen Artikel „Wird das CSS Scope Feature die View Encapsulation von Angular ersetzen?“. Darin erkläre ich die Grundlagen der @scope CSS-At-Regel und ihren Einsatz in Angular.

Demo-Projekt: CSS Scope Sandbox

Ich habe ein Projekt mit zwei Angular-Anwendungen erstellt, die denselben Inhalt anzeigen. Der einzige Unterschied besteht darin, dass die app-without-css-scope die standardmäßige View Encapsulation des Angular-Frameworks verwendet. Die app-with-css-scope hingegen deaktiviert diese Funktion und verwendet stattdessen die @scope Regel.

Hier ist die deployte Anwendung mit CSS Scope. Schaut euch den Code mit den Entwicklertools eures Browsers an:

Ich finde es toll, wie übersichtlich und aufgeräumt das DOM aussieht. Es ist viel einfacher, die Seitenstruktur zu verstehen und die Styles eines Elements zu überprüfen.

Die CSS-Selektoren, die ihr in den Browser-Entwicklertools seht, stimmen mit denen überein, die ihr im Quellcode definiert habt. Keine seltsamen Ergänzungen von benutzerdefinierten Attributen wie _ngcontent-xxx mehr.

Was sind also die Best Practices für CSS Scope, die ich empfehlen würde?

Best Practice 1: Effiziente Donut Scopes

Zunächst müssen wir die View Encapsulation für jede unserer Komponenten deaktivieren. Hier ist ein Beispiel aus meiner Demo:

@Component({
    selector: 'app-beer-item-list',
    encapsulation: ViewEncapsulation.None,
    ...
})
export class BeerItemList { ... }

Jetzt werden die CSS-Selektoren nicht mehr mit benutzerdefinierten Attributen erweitert und die Komponenten-Styles werden global angewendet. Als Nächstes müssen wir stattdessen die @scope At-Regel verwenden, um die Styles zu kapseln.

@scope (app-beer-item-list) {
    :scope {
        display: grid;
        ...
    }
}

Dadurch wird das Containerelement app-beer-item-list der Komponente als Scoping Root definiert, welche die obere Grenze des Teilbaums bestimmt, auf den wir abzielen.

Aber was ist mit den Inhalten, die von den Kind-Komponenten im Template gerendert werden? Die Komponente BeerItemList enthält die Kind-Komponente <app-beer-item-details> . Wir möchten nicht, dass die Styles der übergeordneten Komponente den Inhalt ihrer Kind-Komponenten beeinflusst.

Mit der @scope At-Regel können wir ein Scoping Limit definieren, das die untere Grenze festlegt. Diese Art von Scope – mit einer oberen und einer unteren Grenze – wird als Donut Scope bezeichnet:

@scope (app-beer-item-list) to (app-beer-item-details > *) {
    :scope {
        display: grid;
        ...
    }

    app-beer-item-details {
        background: var(--canvas-bg-color);
        ...
    }
}

Dieser Scope umfasst das <app-beer-item-details> Container-Element, schließt jedoch den Inhalt der Kind-Komponente aus.

Was passiert, wenn ihr eine Komponente stylt, die mehrere Kind-Komponenten im Template enthält? Die App-Komponente in meiner Demo enthält beispielsweise die Kind-Komponenten AppFooter , AppHeader und BeerItemList . Ihr müsstet jede Kind-Komponente als untere Grenze definieren, was sehr schnell lästig werden würde.

Um die Verwendung von CSS-Scope zu vereinfachen, habe ich die Angular-Direktive CustomNgHostDirective erstellt. Die Direktive fügt das benutzerdefinierte Attribut data-ng-host zum Container-HTML-Element einer Komponente hinzu. Wendet die Direktive einfach mit hostDirectives auf eine Komponente an:

@Component({
    selector: 'app-beer-item-details',
    encapsulation: ViewEncapsulation.None,
    hostDirectives: [CustomNgHostDirective],
    ...
})
export class BeerItemDetails { ... }

Jetzt können wir das Attribut data-ng-host für eine effiziente Definition der unteren Grenze einer @scope At-Regel verwenden. Zum Beispiel:

@scope (app-beer-item-list) to ([data-ng-host] > *) {
    :scope {
        display: grid;
        ...
    }

    app-beer-item-details {
        background: var(--canvas-bg-color);
        ...
    }
}

Best Practice 2: Ohne `::ng-deep` in den Untiefen des DOMs wühlen

Wenn ihr die View Encapsulation von Angular verwendet, gelten Komponenten-Styles normalerweise nur für das HTML im eigenen Template der Komponente. Mit der Pseudoklasse ::ng-deep könnt ihr die View Encapsulation für eine bestimmte Regel deaktivieren. Diese Pseudoklasse ist jedoch seit einiger Zeit deprecated und sollte nicht mehr verwendet werden.

Mit CSS Scopes übernehmt ihr wieder die Kontrolle! Ihr könnt den Gültigkeitsbereich so definieren, dass ihr beispielsweise die internen Styles einer Drittanbieter-Bibliothek sicher überschreiben könnt.

Beispiel: Angenommen, ihr verwendet eine Angular Material-Tabelle, um tabellarische Daten anzuzeigen. Ihr seid mit dem Design weitgehend zufrieden, möchtet aber die Hintergrundfarben ein wenig anpassen. So könnten die Styles eurer Komponente aussehen:

@scope (app-fancy-table) {
    table[mat-table] {
        thead tr {
            background-color: lightblue;
        }
    }
}

Best Practice 3: Geteilte Styles als globale CSS-Klassen definieren

Ihr müsst nicht alle eure Styles mit CSS Scope in der CSS-Datei einer Komponente definieren. Besser ist, wenn ihr mehrmals genutzte Styles in globalen Dateien, z. B. im src/styles Ordner, ablegt und sie für die gesamte Anwendung bereitstellt.

Ich persönlich bevorzuge es, SCSS-Dateien mit allgemeinen Styles für jeden Inhaltstyp oder Element zu erstellen. Zum Beispiel: _details.scss , _forms.scss und _table.scss . Sie enthalten Styles für bestimmte HTML-Selektoren wie etwa details sowie globale CSS-Klassen wie z.B. .default-expansion-panel .

Um es den Komponenten zu erleichtern, diese allgemeinen Styles bei Bedarf zu überschreiben, habe ich sie in einem eigenen Cascade-Layer abgelegt:

@use "sass:meta";

@layer reset, general, components;

@layer general {
    @include meta.load-css("base/details");
    @include meta.load-css("base/forms");
    @include meta.load-css("base/table");
}

Erfahrt mehr über Cascade Layers in meinem Artikel „CSS Cascade Layers in Angular verwenden“.

Alternativ könnt ihr auch SCSS-Features wie Platzhalter oder Mixins verwenden, um wiederverwendbare Styles zu erstellen. Ich kann bestätigen, dass das Einfügen eines Mixins mit @include auch im Kontext der nativen @scope At-Regel funktioniert.

Leider hat die Verwendung eines SCSS-Platzhalters mit @extend für mich im Kontext von CSS Scope nicht funktioniert. Der SCSS-Präprozessor berücksichtigt offenbar noch nicht die @scope At-Regel, was zu ungültigen Styles führt. Zumindest war das bei mir mit Angular 21 der Fall. Vielleicht wird das in Zukunft noch behoben.

Fazit

Wie ihr seht, ist es ziemlich einfach, die View Encapsulation von Angular zu deaktivieren und Komponenten-Styles innerhalb einer @scope At-Regel zu definieren. Der generierte HTML- und CSS-Code ist viel besser lesbar und lässt sich viel einfacher debuggen.

Oder mit anderen Worten: Angulars View Encapsulation ist tot! Lang lebe CSS Scope! 🤩

Nutze die Temporal API in Angular ohne Einbindung eines Polyfills

Sat, 31 Jan 2026 00:00:00 GMT

Die Temporal API nimmt Fahrt auf! Vor kurzem wurden Chrome und Edge 144 mit Temporal-Unterstützung releast. Damit haben sie endlich zu Firefox aufgeholt, der die Temporal API bereits im Mai 2025 aktiv geschalten hat. Auch die Implementierung in WebKit/Safari macht Fortschritte.

Also ich kann es kaum erwarten, endlich das schreckliche Date Objekt hinter mir zu lassen und das moderne Datums- und Zeit-Management von Temporal zu nutzen, einschließlich integrierter Zeitzonen- und Kalenderdarstellung. Ihr wisst nicht, wovon ich rede? Dann lest zuerst meinen Artikel „Datums- und Zeitverwaltung mit der Temporal API“!

Foto: © Łukasz Martenka / pexels.com

In meinem aktuellen Projekt in der Arbeit entwickle ich eine neue Webanwendung mit Angular 21, die Safari nicht unterstützen muss. Die perfekte Gelegenheit, um voll auf die Temporal API zu setzen.

Es gibt aber ein Problem: Der Temporal-Vorschlag befindet sich noch in Phase 3 des TC39-Vorschlagsprozesses. Daher enthält die aktuelle TypeScript-Version noch keine Typen für Temporal-Objekte. Wenn ich versuche, Temporal in meiner Angular-Anwendung zu verwenden, lehnt der TypeScript-Compiler das mit den Worten ab: „Name ‚Temporal‘ nicht gefunden.“ 😢

Nach einigem Herumprobieren habe ich eine Lösung gefunden: Ich zeige euch, wie ihr Typ-Definitionen für Temporal hinzufügen könnt, ohne dass die Bundle-Größe eurer App explodiert. 🤩

Schritt 1: Den Temporal Polyfill installieren

Installiert das Paket @js-temporal/polyfill als Entwickler-Dependency in eurem Angular-Projekt:

npm install --save-dev @js-temporal/polyfill

Die Dokumentation empfiehlt, den Polyfill auf folgende Weise zu importieren:

import { Temporal } from '@js-temporal/polyfill';

Tut das nicht! Der Polyfill enthält den kompletten JavaScript-Code für alle Objekte und Methoden der Temporal API. Dieser Import würde die Bundle-Größe eurer Anwendung um etwa 150 kB erhöhen.

Stattdessen macht ihr folgendes.

Schritt 2: Ein globales `Temporal` Objekt deklarieren

Erstellt eine neue Datei src/types/temporal.d.ts im Repository und fügt den folgenden Code ein:

import type { Temporal as TemporalType } from "@js-temporal/polyfill";

declare global {
    const Temporal: typeof TemporalType;
}

Wir importieren nur die Typ-Definitionen für den Temporal Namespace aus dem Polyfill-Paket. Dann deklarieren wir eine globale Konstante namens Temporal und weisen ihr den importierten Typ zu. Auf diese Weise teilen wir TypeScript mit, dass der Temporal-Namespace existiert und mehrere Objekte wie Instant , Now und ZonedDateTime enthält.

Jetzt könnt ihr alle Features der Temporal API in jeder .ts Datei ohne zusätzlichen Import verwenden. Zum Beispiel:

const zdt = Temporal.ZonedDateTime.from("2026-01-30T12:34:56-04:00[America/New_York]");

Während der Laufzeit der Webanwendung wird das tatsächliche globale Temporal Objekt des Browsers verwendet.

Schritt 3: Typen aus dem `Temporal` Namespace verwenden

Das letzte Puzzleteil: Wenn ihr Temporal-Typen für Variablen oder Klassen-Eigenschaften verwenden möchtet, müsst ihr die Typ-Definitionen wie folgt importieren und einsetzen:

import type { Temporal as TemporalType } from "@js-temporal/polyfill";

interface MyInterface {
    property: TemporalType.ZonedDateTime;
}

Demo-Anwendung

Ich habe eine einfache Demo-App mit Angular 21 erstellt, in der ich die oben genannten Schritte befolgt habe. Sie enthält eine Zeitzonen-Auswahl und einen einfachen Datumsrechner. Beides war dank der eleganten und mächtigen Temporal API superleicht zu implementieren.

Wenn ihr gerade mit der Arbeit an einer neuen Angular-Anwendung begonnen habt, probiert es doch aus! Temporal ist einfach großartig und ihr werdet euch schnell in die API verlieben. 😉

Meine ersten Schritte als Astronaut

Mon, 12 Jan 2026 00:00:00 GMT

Ich bin jetzt offiziell Astronaut! Nun ja, kein echter Astronaut, der ins All fliegt. Sondern ein begeisterter Nutzer des Web-Frameworks Astro.

Viele Mitglieder der Astro-Community bezeichnen sich liebevoll als „Astronauten“ – in Anlehnung an den Namen des Frameworks. Und jetzt bin ich einer von ihnen! Nachdem ich meinen Weblog vier Jahre lang mit Gatsby gestaltet habe, war es an der Zeit für einen Neuanfang mit einem anderen Framework.

Foto: © cottonbro / pexels.com

Ich erkläre euch, warum ich Gatsby hinter mir gelassen habe und was mir an Astro gefällt.

Warum nicht länger Gatsby?

Ich muss zugeben, dass ich einfach faul war! Im Jänner 2022 habe ich meinen Weblog mit Gatsby 4 aufgesetzt. Nachdem ich mit der Konfiguration zufrieden war und alles gut funktionierte, habe ich mich nie wieder um das Setup gekümmert. Auch die Abhängigkeiten des Projekts habe ich nie aktualisiert.

Das Setup hat einfach funktioniert. Also habe ich meine Zeit lieber damit verbracht, mit neuen Web-Features zu experimentieren und Blogbeiträge zu schreiben.

Jetzt, vier Jahre später, musste ich mir eingestehen, dass meine Konfiguration völlig veraltet war! Die Gatsby-CLI fühlte sich klobig und langsam an, und der Produktions-Build meines Weblogs dauerte bis zu 15 Minuten. Furchtbar!

Mein erster Gedanke war, auf die neueste Gatsby-Version zu aktualisieren und meine Konfiguration zu optimieren. Aber dann stieß ich auf GitHub-Issues wie „Ist GatsbyJS offiziell tot?“ und „Wird Gatsby eingestellt?“. Anscheinend wird das Framework nicht mehr aktiv weiterentwickelt und ist hoffnungslos veraltet.

„Es ist Zeit für was Neues!“, lautete meine Schlussfolgerung. Nach etwas Recherche zu verschiedenen Frameworks für statische Seitengenerierung entschied ich mich für Astro.

Was mir an Anstro gefällt

Ich habe jetzt die Einrichtung meines Weblogs mit Astro abgeschlossen und dabei die Grundfunktionen beibehalten:

Eine zweisprachige Website in Englisch und Deutsch.
Eine Startseite mit einer kurzen Einführung und einer Liste der neuesten Blogbeiträge.
Eine „Über mich”-Seite mit weiteren Informationen über mich und die Website.
Ein Blogarchiv mit Links zu allen meinen veröffentlichten Beiträgen.
Blogbeiträge, die aus Markdown-Dateien erstellt wurden.
Automatische Erstellung von RSS-Dateien.

Die Umstellung auf Astro verlief ziemlich reibungslos – dank der vertrauten Komponentenstruktur und der integrierten Unterstützung für Markdown. Besonders gefallen mir folgende Features:

Das Framework bietet eine sehr detaillierte Dokumentation, einschließlich eines interaktiven Tutorials zum Erstellen eines Blogs. Perfekt für meinen Anwendungsfall! Es gibt sogar mehrere Migrationsanleitungen, z.B. Migration von Gatsby, in denen die wichtigsten Unterschiede erläutert werden.
Astro-Komponenten (.astro Dateien) erleichtern die Implementierung grundlegender Bausteine für verschiedene Seiten. Wenn ihr mit JSX vertraut seid, werdet ihr euch sofort zurechtfinden! 🤩
Standardmäßig rendert Astro eure Webseiten in schnelles, statisches HTML. Wenn ihr interaktive JavaScript-Logik benötigt, definiert einfach eine Client-Insel: eine interaktive UI-Komponente, die separat vom Rest der Seite hydriert wird. Damit habe ich meiner Blog-Archivseite eine Filterkomponente hinzugefügt. Hat wunderbar funktioniert!
Es gibt eine lebendige Community und eine Menge Plugins.

Die Zukunft sieht rosig aus

Ich bin sehr glücklich mit meinem neuen Framework. Die Arbeit mit Astro macht einfach Spaß. Und ich habe das Gefühl, dass ich erst an der Oberfläche dessen gekratzt habe, was möglich ist.

Hoffentlich bleibt Astro noch lange Open Source und aktiv. Ich möchte nicht in ein paar Jahren wieder das Framework wechseln müssen. 😝

Flexible Menü-Animation mit verankerten Container Queries

Sun, 23 Nov 2025 00:00:00 GMT

Chrome hat vor kurzem die neue Version 143 mit Support für verankerte Container-Queries in CSS veröffentlicht. Mit diesen Abfragen können wir den Inhalt eines verankerten Elements basierend auf der aktuellen Position relativ zum Anker stylen. Einfach cool! 🤩

Vor ein paar Monaten habe ich einen Artikel über die Erstellung eines barrierefreien Menüs mit der Popover API und CSS Anchor Positioning veröffentlicht. Damals habe ich gejammert, dass ich auf JavaScript zurückgreifen muss, um die Skalierungs-Animation für verschiedene Positionen des Menüfelds relativ zum Menübutton umzusetzen.

Jetzt ist das nicht mehr nötig! Ich zeige euch, wie ihr allein mit CSS die Animation des Menüfelds definieren könnt.

Foto: © Snapwire / pexels.com

Die Grundlagen verankerter Container Queries

Das Dokument CSS Anchor Positioning Module Level 2 definiert den neuen Wert anchored für die container-type Eigenschaft. Konkret heißt es:

Establishes a query container for container queries, allowing for descendants of an anchor positioned element to be styled based on certain features of the anchoring. (Currently, limited to which of the position-try-fallbacks are applied, if any.)

In unserem Fall haben wir ein benutzerdefiniertes Menüfeld, das mit dem Menü-Button als Anker verbunden ist. Wenn wir container-type: anchored für das Menüfeld setzen, wird es zum Abfrage-Container für die Position des verankerten Elements.

Dadurch können wir den Skalierungs-Effekt des Menüfelds an seine aktuelle Position anpassen, indem wir die neue At-Regel @container anchored(fallback: …) verwenden. Beispiel: Wenn das Menüfeld oben links neben der Schaltfläche platziert ist, lassen wir es aus der unteren rechten Ecke herauswachsen.

Bevor wir uns dem HTML- und CSS-Code widmen, werft erstmal einen Blick auf die fertige Demo des benutzerdefinierten Menüs.

Demo: Barrierefreies Menü mit reiner CSS-Animation

Ich habe eine neue CodePen-Demo erstellt, die viermal das gleiche Menüelement enthält. Die Menü-Buttons sind grob bei den vier Ecken des Bildschirms platziert, damit ihr leicht testen könnt, wie die Animation des Menüfelds dessen aktuelle Position berücksichtigt:

See the Pen Menu Anchor Positioning (with Container Query) by Alexander Lehner (@alexlehner86) on CodePen.

Wenn euer Browser keine verankerten Container Queries unterstützt, wird das Menüfeld einfach nur eingeblendet. Ich zeige euch, wie ihr den Skalierungseffekt als progressive Verbesserung implementiert.

Wie ihr flexible Animationen mit verankerten Container Queries baut

Ich werde nicht alle Details meines barrierefreien Custom-Menüs wiederholen. Lest bitte zuerst meinen Artikel „Wir bauen ein barrierefreies Menü mit modernen Web-Features“, bevor es hier weitergeht.

Schritt 1: Die grundlegende HTML-Struktur

Damit die verankerte Container Query funktioniert, müssen wir die HTML-Struktur unseres Menüs leicht anpassen. Ich habe zunächst versucht, direkt die Styles des div[role=“menu”] Elements zu ändern, aber es hat nicht funktioniert. Warum ist das so?

Die offizielle Spezifikation sagt eindeutig, dass eine verankerte Container Query nur das Stylen der Inhalte des positionierten Elements erlaubt. Das bedeutet, dass wir einen zusätzlichen inneren Container benötigen:

<button id="menu-btn-1" class="menu-btn" aria-label="More options" popovertarget="menu-content-1" type="button">
    <span>/* icon */</span>
</button>
<div id="menu-content-1" role="menu" aria-labelledby="menu-btn-1" popover>
    <div class="menu-inner-box">
        <button role="menuitem" type="button">...</button>
        <button role="menuitem" type="button">...</button>
        <button role="menuitem" type="button">...</button>
    </div>
</div>

Das .menu-inner-box Element ist ein Kind-Element des Menüfelds. Daher können wir dessen transform-origin beliebig ändern, abhängig von der aktuellen Anker-Positionierung.

Schritt 2: Animation des Menüfelds

Das Menüfeld sollte eingeblendet und vergrößert werden, wenn es geöffnet wird. Da wir die Transition auf ein Popover anwenden, das von display: none zu display: flex wechselt, müssen wir auch die Eigenschaften overlay und display berücksichtigen. So sieht das Basis-Setup für das Menüfeld aus:

div[role="menu"] {
    /* General animation and end of fade-out */
    opacity: 0;
    transition-property: opacity, overlay, display;
    transition-behavior: allow-discrete;
    transition-duration: 100ms;
    transition-timing-function: linear;
}

Wir definieren die Skalierungs-Animation separat für den inneren Container. Da das Menüfeld standardmäßig unterhalb und rechts vom Menübutton positioniert wird, legen wir für den Skalierungseffekt transform-origin: top left fest:

div[role="menu"] > .menu-inner-box {
    transform: scale(1);
    transform-origin: top left;
    transition-property: transform;
    transition-duration: inherit;
    transition-timing-function: inherit;
}

Die Einblende-Animation soll 120 Millisekunden dauern und eine weiche kubisch-beziersche Zeitfunktion verwenden. Am Ende des Übergangs ist das Popover vollständig sichtbar und auf 100 Prozent skaliert:

div[role="menu"]:popover-open {
    /* End of fade-in and start of fade-out */
    transition-duration: 120ms;
    transition-timing-function: cubic-bezier(0, 0, 0.2, 1);
    opacity: 1;
}

div[role="menu"]:popover-open > .menu-inner-box {
    transform: scale(1);
}

Da das Menüfeld von einem verborgenen in einen sichtbaren Zustand wechselt, gibt es keine berechneten Werte, die der Übergang als Ausgangspunkt verwenden kann. Daher nutzen wir @starting-style , um die initiale Deckkraft auf 0 und die anfängliche Skalierung auf 80 Prozent zu setzen:

/* Start of fade-in */
@starting-style {
    div[role="menu"]:popover-open {
        opacity: 0;
    }
    div[role="menu"]:popover-open > .menu-inner-box {
        transform: scale(0.8);
    }
}

Damit funktioniert die Skalierungs-Animation schon mal für die Standardplatzierung des Menüfelds. Als Nächstes verwenden wir verankerte Container Queries, um die Animation an verschiedene Positionen anzupassen.

Schritt 3: Positions-Fallbacks

Unser Menü-Button ist bereits implizit als Ankerelement des Menüfelds definiert. Daher reicht es, wenn wir eine Default-Position sowie mehrere Fallbacks für das Menüfeld definieren:

div[role="menu"] {
    position: fixed;
    position-area: end span-end;
    position-try-fallbacks: flip-block, flip-inline, flip-block flip-inline;
}

Wenn das verankerte Element (das Menüfeld) seinen Containing Block überläuft, probiert der Browser automatisch die Liste der alternativen Positionen aus, die mithilfe der Eigenschaft position-try-fallbacks definiert wurden. Er verwendet die erste Alternative, die nicht über den Containing Block bzw. den Viewport hinausragt.

Wie können wir erkennen, welche Fallback-Position vom Browser ausgewählt wurde? Zunächst machen wir das Menüfeld zum Abfrage-Container für seine Ankerposition:

div[role="menu"] {
    container-type: anchored;
}

Jetzt können wir den aktiven Fallback des verankerten Elements abfragen und die Animation entsprechend anpassen. Hier ist ein Beispiel:

@container anchored(fallback: flip-block) {
    div[role="menu"] > .menu-inner-box {
        transform-origin: bottom left;
    }
}

Diese At-Regel wird wirksam, wenn die Position des Menüfelds nur in der Blockachse umgedreht wird. Das Menüfeld befindet sich nun oberhalb des Menü-Buttons und wirkt beim Einblenden so, als würde es von unten links herauswachsen. Genial! 😍

Die restlichen Container Queries, die wir für alle Positionen benötigen, findet ihr im CSS-Code meiner CodePen-Demo.

Schritt 4: Progressive Verbesserung

Zu guter Letzt möchten wir sicherstellen, dass die Animation des Menüfelds auch funktioniert, wenn ein Browser noch keine verankerten Container Queries unterstützt. Mit der @supports At-Regel definieren wir den Skalierungseffekt sowie die Container Queries nur dann, wenn der Browser diese unterstützt:

@supports (container-type: anchored) {
    div[role="menu"] {
        container-type: anchored;
    }

    /* Styles related to the scaling effect animation */
}

Progressive Verbesserung war noch nie so einfach!

Nützliche Links

Lasst uns Akkordeon spielen: Das HTML details-Element im Fokus

Sat, 27 Sep 2025 00:00:00 GMT

Inhalte auf einer Website zu platzieren kann eine Herausforderung sein. Ihr möchtet eure Nutzer:innen nicht mit zu vielen Infos auf einmal überfordern. Hierbei können Abschnitte mit Ein-/Ausblendfunktion hilfreich sein. Ein typisches Beispiel hierfür wäre eine FAQ-Seite mit einer Liste von erweiterbaren Fragen und Antworten.

Wir können das native HTML-Element <details> verwenden, um ein solches Offenlegungs-Widget zu erstellen. Das Element gibt es schon seit vielen Jahren, aber früher war es schwierig, es zu stylen und zu animieren. Dank Interop 2025 haben Browser die Implementierung des Elements erheblich verbessert und neue Features hinzugefügt.

Foto: © Jefferson Lucena / pexels.com

Ich werde kurz die Grundlagen des nativen HTML-Elements erläutern. Anschließend sehen wir uns die neuen Funktionen an. 🤩

Das `<details>` HTML-Element

Das native Details-Element erstellt ein Offenlegungs-Widget. Die in diesem Element enthaltenen Informationen sind nur sichtbar, wenn das Widget in einen offenen Zustand versetzt wird. Mit dem HTML-Element <summary> geben wir dem Widget eine Beschriftung. Hier ein Beispiel:

<details>
    <summary>An interesting question?</summary>
    <p>A fascinating answer!</p>
</details>

Mit nur wenigen Zeilen Code erhalten wir ein vollständig barrierefreies Offenlegungs-Widget. Es vermittelt seinen Namen, seine Rolle und seinen aktuellen Status an assistive Technologien und ist vollständig über die Tastatur bedienbar.

Neue Features

Exklusive Akkordeons mit dem `name` Attribut

Eine Akkordeon-Komponente ist ein gängiges UI-Muster, das auf vielen Websites zu finden ist. Es besteht aus mehreren Widgets, die einzeln erweitert und reduziert werden können.

Eine Variante des Akkordeon-Musters ist das exklusive Akkordeon, bei dem jeweils nur ein Abschnitt geöffnet sein kann. Mit dem Attribut name könnt ihr eine Liste von <details> Elementen zum exklusiven Akkordeon machen. Hier ein Code-Ausschnitt aus meiner CodePen-Demo:

<details name="faq">
    <summary>What is the Doctor's real name?</summary>
    <p>I'll never tell!</p>
</details>
<details name="faq">
    <summary>Who are the Daleks?</summary>
    <p>The Daleks are...</p>
</details>

Jetzt sind die einzelnen Offenlegungs-Widgets miteinander verknüpft. Wenn ihr einen der Abschnitte im Akkordeon öffnet, schließt der Browser automatisch alle anderen Abschnitte. Probiert es selbst aus:

See the Pen FAQ Accordion with Details Element by Alexander Lehner (@alexlehner86) on CodePen.

Inhalte mit `::details-content` stylen

Ihr könnt den erweiterbaren Inhalt des <details> Elements ganz einfach mit dem neuen CSS-Pseudo-Element ::details-content stylen. Hier ist ein Beispiel:

details::details-content {
    color: rgb(54, 69, 79);
    line-height: 1.3;
    padding-inline: 0.5rem;
}

Darüber hinaus können wir das Pseudo-Element verwenden, um das Öffnen und Schließen des Widgets zu animieren. Unser Ziel ist es, den Inhalt sanft von null zur vollen Höhe anwachsen zu lassen. Um dies zu erreichen, sind wir auf die noch experimentelle CSS-Eigenschaft interpolate-size angewiesen, die derzeit nur in Chromium-Browsern unterstützt wird.

Aber keine Sorge! Wir können die Animation als progressive Verbesserung implementieren. Mithilfe von @supports wenden wir die Animation nur an, wenn der Browser sie auch unterstützt:

@supports (interpolate-size: allow-keywords) {
    details {
        interpolate-size: allow-keywords;

        &::details-content {
            height: 0;
            overflow-y: clip;
            transition:
                height 0.35s ease,
                content-visibility 0.35s ease allow-discrete;
        }
    }

    details[open]::details-content {
        height: auto;
    }
}

Ich weiß, dass in dem obigen CSS-Code viel passiert. Ich werde es Schritt für Schritt erklären:

Standardmäßig unterstützen Browser keine Animationen und Übergänge, die einen intrinsischen Größenwert wie auto beinhalten. Wir aktivieren dieses Verhalten, indem wir interpolate-size: allow-keywords setzen.
Wir setzen die initiale Höhe des Inhalts auf null (height: 0 ) und schneiden überstehenden Inhalt ab.
Mit transition definieren wir die Animation der Eigenschaft height . Wir müssen auch die Eigenschaft content-visibility einbeziehen, die vom Browser automatisch gesetzt wird, wenn das Details-Element erweitert oder reduziert wird. Mehr Informationen findet ihr im Artikel zu transition-behavior.
Schließlich setzen wir height: auto für den Inhalt, wenn das Details-Element geöffnet ist.

Öffnet meine CodePen-Demo in Chrome oder Edge, um euch selbst von den flüssigen Animationen zu überzeugen. 😎

Benutzerdefinierter Indikator für offen/geschlossen

Browser zeigen das <details> Element in der Regel mit einem kleinen Dreieck an, das sich dreht, um den geöffneten/geschlossenen Zustand anzuzeigen. Dieser Indikator sieht je nach Plattform und Browser anders aus.

Um das Dreieck durch einen benutzerdefinierten Indikator zu ersetzen, müssen wir den Wert display: list-item des Elements <summary> überschreiben. Ich verwende Flexbox, da dies mein gewünschtes Layout unterstützt. Ihr könnt aber beispielsweise auch display: block setzen.

Darüber hinaus müssen wir auch die Pseudo-Elemente für das Standard-Dreieck ausblenden. Dazu gehört ::-webkit-details-marker , das im Safari-Browser verwendet wird:

details summary {
    display: flex;
    align-items: center;
    justify-content: space-between;
    gap: 1rem;

    &::marker,
    &::-webkit-details-marker {
        display: none;
    }
}

Als Nächstes definieren wir unseren benutzerdefinierten Indikator. Ich möchte ein Pfeilsymbol anzeigen, das nach unten zeigt, wenn das Offenlegungs-Widget geschlossen ist. Dank modernem CSS benötigen wir keine Bilder oder Icon-Fonts. Wir können die Form einfach mit dem Pseudo-Element ::after und der CSS-Eigenschaft clip-path zeichnen.

details summary::after {
    --shape-chevron-width: 1rem;
    --s: calc(var(--shape-chevron-width) / 4);

    content: "";
    aspect-ratio: 7/5;
    background: currentColor;
    clip-path: polygon(0 0, 0 var(--s), 50% 100%, 100% var(--s), 100% 0, 50% calc(100% - var(--s)));
    flex-shrink: 0;
    width: var(--shape-chevron-width);
}

Ich habe ein Code-Beispiel von der Website CSS Shape adaptiert. Dort findet ihr unzählige Code-Schnipsel für reine CSS-Formen, die mit einem einzigen Element und modernem CSS erstellt wurden. Schaut euch die Website unbedingt einmal an! 🥰

Schließlich möchten wir, dass das Pfeilsymbol nach oben zeigt, wenn das Offenlegungs-Widget geöffnet ist. Natürlich sollte der Übergang animiert sein. Hier ist der Code:

details {
    summary::after {
        rotate: 0deg;
        transition: rotate 0.35s ease;
    }

    &[open] summary::after {
        rotate: -180deg;
    }
}

Et voilà! Wir haben das Standard-Dreieck durch ein Pfeilsymbol ersetzt, das auf allen Plattformen und Browsern gleich aussieht. Hier ist das Endergebnis:

See the Pen Accordion with Custom Arrows by Alexander Lehner (@alexlehner86) on CodePen.

Flexbox und Grid-Layouts

Früher war es nicht möglich, den display Wert des <details> Elements zu ändern. Diese Einschränkung wurde nun in allen gängigen Browsern (z.B. Firefox 143) aufgehoben.

Endlich ist es möglich, Grid- oder Flex-Layouts für <details> zu verwenden. Weitere Informationen findet ihr im Artikel „More options for styling <details>” im Chrome Developer Blog.

Fazit

Die Elemente <details> und <summary> sind großartig! Dank der neuen Features können wir ganz einfach Widgets zum Ein- und Ausblenden und sogar exklusive Akkordeons mit benutzerdefinierten Stilen und Animationen erstellen.

Das bedeutet: Es gibt eine weitere Art von Inhalten, die wir mit nativen Webfunktionen erstellen können. Wir brauchen keine UI-Bibliotheken und deren lästige Neigung zu Breaking Changes mehr. Ich liebe das (native) Web! ❤️

Eine barrierefreie Tabelle mit anklickbaren Zeilen bauen

Mon, 25 Aug 2025 00:00:00 GMT

Tabellen auf Websites zeigen meistens statische Informationen in Zeilen und Spalten an. Aber was ist, wenn ihr die Zeilen anklickbar machen möchtet, z.B. um weitere Informationen anzuzeigen? Euer erster Gedanke könnte sein, Klick-Ereignis-Handler auf die Tabellenzeilen (<tr> ) zu setzen, um sie anklickbar zu machen. Bitte lasst die Finger davon!

Eine Tabellenzeile mit einem Klick-Ereignis-Handler wird nicht auf magische Weise zu einem barrierefreien Steuerelement. Ihr könnt die Zeile nicht mit der Tastatur ansteuern, geschweige denn das Klick-Ereignis mit der ENTER Taste auslösen. Der Zweck des Klick-Ereignis-Handlers wäre für Screenreader-Nutzer:innen unklar. Was können wir also tun?

Foto: © Kampus Production / pexels.com

Um eine barrierefreie Tabelle mit anklickbaren Zeilen zu erstellen, nehmen wir einfach ein <button> Element und erhöhen dessen Reichweite, sodass es die gesamte Zeile abdeckt. Meine Lösung ist inspiriert von Adrian Rosellis Artikel „Don’t Turn a Table into an ARIA Grid Just for a Clickable Row“.

Demo: Tabelle mit anklickbaren Zeilen

Ich habe eine CodePen-Demo erstellt, die mehrere Filme von Studio Ghibli in Tabellenform auflistet. Durch Anklicken einer Zeile öffnet sich ein Dialogfeld mit weiteren Informationen zum Film:

See the Pen Table with Clickable Row by Alexander Lehner (@alexlehner86) on CodePen.

Der Aufbau der barrierefreien Tabelle

Die ideale Lösung

Wir fügen ein <button> Element in die letzte Tabellenzelle jeder Zeile ein. Der barrierefreie Name der Schaltfläche (“More Information” ) zusammen mit der Zeilenüberschrift (das <th> Element in der Zeile) informiert Screenreader-Nutzer:innen über den Zweck des Steuerelements:

<tr>
    <th>Spirited Away</th>
    <td>2001</td>
    <td>2h 4m</td>
    <td>
        <button id="info-btn-1" aria-label="More Information" type="button">
            <span>/* icon */</span>
        </button>
    </td>
</tr>

Der Button ist standardmäßig über die Tastatur bedienbar. Wir müssen lediglich visuell vermitteln, dass die gesamte Tabellenzeile fokussiert ist. Dazu können wir die CSS-Pseudoklasse :focus-within verwenden:

table tbody tr {
    &:focus-within, &:hover {
        outline: 0.188rem solid black;
        outline-offset: -0.313rem;
    }

    button:focus {
        outline: none;
    }
}

Auf diese Weise wird die Tabellenzeile bei Hover mit der Maus hervorgehoben oder wenn die Schaltfläche innerhalb der Zeile den Fokus erhält.

Schließlich möchten wir die Schaltfläche auslösen, wenn jemand auf die Tabellenzeile klickt. Um dies zu erreichen, verwenden wir das Pseudo-Element ::after zusammen mit der CSS-Eigenschaft inset :

table tbody tr {
    position: relative;

    button::after {
        content: "";
        position: absolute;
        inset: 0;
    }
}

Das Pseudo-Element ist relativ zu seinem übergeordneten <tr> Element absolut positioniert und deckt dank inset: 0 die gesamte Tabellenzeile ab. Jetzt zählt ein Klick auf die Tabellenzeile als Klick auf die darin enthaltene Schaltfläche. Genial! 🤩

Es gibt nur ein Problem: Das ganze funktioniert (aktuell) nicht in Safari. Die Definition position: relative für das <tr> Element wird einfach ignoriert. 🤬

Die Safari-kompatible Version

Solange der WebKit-Fehler nicht behoben ist, benötigen wir einen Workaround. Ich habe eine alternative CodePen-Demo erstellt, die auch in Safari funktioniert:

See the Pen Table with Clickable Row (Safari Support) by Alexander Lehner (@alexlehner86) on CodePen.

Die Lösung ist etwas umständlich, aber sie funktioniert. Anstatt die Tabellenzeile als relativen Anker zu verwenden, positionieren wir das Pseudo-Element relativ zu seinem übergeordneten <td> Element. Seht selbst:

table {
    overflow: clip;
}

table tbody tr {
    td:has(button) {
        position: relative;
    }

    button::after {
        content: "";
        position: absolute;
        inset: 0;
        left: auto;
        width: 100vw;
    }
}

Wir setzen die Eigenschaft left des Pseudo-Elements auf auto zurück und legen seine Breite auf 100 % der Viewport-Breite fest. Zusätzlich setzen wir overflow: clip für die Tabelle, um die Reichweite jeder Schaltfläche auf die tatsächliche Breite der Tabellenzeile zu beschränken.

Fazit

Wie ihr seht, ist es gar nicht so schwer, eine barrierefreie Tabelle mit anklickbaren Zeilen zu erstellen. Denkt immer daran, dass nicht alle eure Nutzer:innen eine Maus oder ein Touch-Gerät verwenden. Testet daher immer auch mit der Tastatur und Screenreadern. 😉

Wir bauen ein barrierefreies Menü mit modernen Web-Features

Mon, 14 Jul 2025 00:00:00 GMT

Wir alle kennen Menüelemente auf Websites. Ein Menü ist ein Widget, das den Nutzer:innen eine Liste von Optionen bietet, z.B. eine Reihe von Aktionen. Solche Menüs verhalten sich wie native Betriebssystem-Menüs und sollten nicht mit Navigationsmenüs verwechselt werden, die üblicherweise im Header der Seite platziert werden.

Leider verhält sich das vorhandene <menu> Element nicht wie erwartet. Es gibt Pläne, das native Element anzupassen, aber in der Zwischenzeit müssen wir unser eigenes Menü erstellen. Wir könnten eine Menükomponente aus einer UI-Bibliothek verwenden. Das würde eine weitere Abhängigkeit im Projekt und möglicherweise Breaking Changes in der Zukunft bedeuten. Lieber nicht.

Aber es gibt gute Nachrichten! Dank neuer Web-Features wie der Popover API und CSS Anchor Positioning ist es viel einfacher geworden, ein benutzerdefiniertes Menüelement zu erstellen. Lasst uns gemeinsam ein barrierefreies Menü erstellen!

Foto: © Zachary DeBottis / pexels.com

Was wir erreichen wollen

Unser selbstgebautes Menü sollte die folgenden Anforderungen erfüllen:

Das Menü ist komplett barrierefrei, sprich:
- Es vermittelt seine Rolle und Status an assistive Technologien wie Bildschirmlesegeräte.
- Es unterstützt die Tastaturbedienung und hat einen sichtbaren Fokusindikator.
- Der Text und die grafischen Elemente haben einen ausreichenden Farbkontrast.
Innerhalb des Menüfelds können Nutzer:innen einen von mehreren Menüpunkten aktivieren. Der Einfachheit halber unterstützen wir keine verschachtelten Menüs (vielleicht probiere ich das später mal aus).
Das Menüfeld öffnet sich neben der Auslösetaste und bleibt beim Scrollen daran haften.
Das Öffnen und Schließen des Menüfelds ist flüssig animiert.

Ich zeige euch, wie ihr dies Schritt für Schritt erreichen könnt. Aber werft zuerst einmal einen Blick auf das Ergebnis.

Demo: Barrierefreies Menü

Ich habe eine CodePen-Demo erstellt, die viermal das gleiche Menüelement enthält. Die Menübuttons sind grob bei den vier Ecken des Bildschirms platziert, damit ihr leicht testen könnt, wie die Platzierung des Menüfelds den verfügbaren Platz berücksichtigt:

See the Pen Menu Anchor Positioning Testcase by Alexander Lehner (@alexlehner86) on CodePen.

Aufbau des Menüelements Schritt für Schritt

Schritt 1: Die grundlegende HTML-Struktur

Wir definieren eine Icon-Schaltfläche mit einem aria-label , um ihren Zweck für Screenreader-User:innen zu kommunizieren. Daneben platzieren wir einen div Container mit mehreren Schaltflächen darin, was unser Menüfeld darstellt. Die Attribute role=“menu” für den Container und role=“menuitem” für die einzelnen Schaltflächen vermitteln die korrekten Rollen:

<button id="menu-btn-1" class="menu-btn" aria-label="More options" type="button">
    <span>/* icon */</span>
</button>
<div role="menu" aria-labelledby="menu-btn-1">
    <button role="menuitem" type="button">More information</button>
    <button role="menuitem" type="button">Share</button>
    <button role="menuitem" type="button">Download the file</button>
</div>

Mit CSS gestalten wir unseren Menü-Button so, dass er eine ausreichende Zielgröße und Farbkontrast hat. Wir verwandeln das Menüfeld in einen Flex-Container, der die Menüoptionen in einer Spalte anordnet. Hier ist ein Auszug:

button.menu-btn {
    color: white;
    background-color: #00514c;
    /* other styling */
}
div[role="menu"] {
    display: flex;
    flex-direction: column;
    margin: 0.25rem 0;
    /* other styling */
}

Was haben wir bisher? Einen Icon-Button mit einer stets sichtbaren Liste von Schaltflächen daneben. Nun bauen wir auf dieser Grundlage auf, um unser barrierefreies Menü zu erstellen.

Als Nächstes fügen wir das popover Attribut dem Menüfeld hinzu. Dadurch ist das Menüfeld beim Laden der Seite zunächst ausgeblendet. Wenn das Popover angezeigt wird, wird es im Top-Layer eingefügt, sodass es über allen anderen Seiteninhalten angezeigt wird.

Wir wollen, dass unser Menü-Button steuert, wann das Menüfeld ein- oder ausgeblendet wird. Um diese Verbindung herzustellen, weisen wir dem Popover-Element eine id zu und setzen das Attribut popovertarget mit diesem ID-Wert auf dem Menü-Button. Hier ist das Endergebnis:

<button popovertarget="menu-content-1" id="menu-btn-1" class="menu-btn" aria-label="More options" type="button">
    <span>/* icon */</span>
</button>
<div popover id="menu-content-1" role="menu" aria-labelledby="menu-btn-1">
    /* menu items */
</div>

Diese einfachen Schritte bringen uns bereits eine Menge Features: Der Menü-Button öffnet und schließt das Panel, er übermittelt seinen Status an assistive Technologien (wie es aria-expanded tun würde), wir erhalten Light-Dismiss und eine gewisse Tastaturbedienbarkeit. Weitere Infos enthält der MDN-Artikel Using the Popover API.

Ein wichtiger Hinweis zur Gestaltung von Popover-Inhalten: Wenn ihr ein Flexbox- oder Grid-Layout verwenden möchten, solltet ihr den Wert der display Eigenschaft des Popover nur ändern, wenn das Popover geöffnet ist. Andernfalls würdet ihr den Wert display: none überschreiben, wenn das Popover geschlossen ist, so dass es immer sichtbar ist. Hier ist ein Code-Beispiel:

div[role="menu"] {
    flex-direction: column;
    margin: 0.25rem 0;
    /* other styling */

    &:popover-open {
        display: flex;
    }
}

Schritt 3: Menü-Platzierung mit CSS Anchor Positioning

Um eine visuelle Verbindung zwischen Menü-Button und dem zugehörigen Menüfeld herzustellen, müssen wir sie nebeneinander platzieren. Und wir wollen sicherstellen, dass das Menüfeld beim Button haften bleibt, z.B. beim Scrollen. Historisch gesehen würde dies die Verwendung einer JavaScript-Overlay-Bibliothek erfordern. Wie nervig!

Zum Glück erledigt das neue Feature CSS Anchor Positioning diese Aufgabe für uns. Sie ist derzeit Teil der Interop 2025 und sollte bis Ende des Jahres in allen Browsern unterstützt werden.

Generell müsst ihr ein Ankerelement mit der Eigenschaft anchor-name definieren. Dann bindet ihr ein anderes Element mit der Eigenschaft position-anchor an diesen Anker an. Im Falle von Popover-Elementen müsst ihr jedoch nichts von alledem tun. Ein Blick in die Spezifikation zeigt:

Some specifications can define that, in certain circumstances, a particular element is an implicit anchor element for another element. Implicit anchor elements can be referenced with the auto keyword in position-anchor.

Genau das gilt für eine Schaltfläche, die als Popover-Steuerelement dient, wie unser Menü-Button. Das bedeutet: Wir sind startklar! Unser Menü-Button ist bereits implizit als Ankerelement des Menüfelds definiert.

Wo wollen wir das Menüfeld platzieren? Wie wäre es unterhalb und rechts von der Schaltfläche? Wir könnten dies mit der CSS-Funktion anchor() erreichen. Ich bevorzuge aber die elegantere position-area Eigenschaft. Werft einen Blick darauf:

div[role="menu"] {
    position: absolute;
    position-area: end span-end;
}

Stellt euch das Ankerelement und die sie umgebende Fläche als ein 3x3-Raster vor. Der erste Wert, den wir definieren, bezieht sich auf die Blockachse, der zweite auf die Inline-Achse. So bedeutet position-area: end span-end , dass wir unser Menüfeld am Ende der Blockachse (unterhalb des Buttons) platzieren und es von der Mitte bis zum Ende der Inline-Achse aufspannen.

Aber was passiert, wenn der Menü-Button am rechten Bildschirmrand platziert ist? Oder wenn die Scroll-Position der Seite die Schaltfläche am unteren Rand des Bildschirms platziert? In beiden Fällen reicht der Platz nicht aus, um das Menüfeld mit allen Optionen unterhalb und rechts vom Menü-Button anzuzeigen.

Mit Hilfe der Eigenschaft position-try-fallbacks können wir dieses Problem leicht lösen. Ihr definiert einfach eine Liste mit einer oder mehreren alternativen Positionen. Wenn das Element andernfalls seinen Inhaltsblock überfüllen würde, versucht der Browser, das positionierte Element in den verschiedenen Fallback-Positionen zu platzieren.

position-try-fallbacks: flip-block, flip-inline, flip-block flip-inline;

Im Grunde sagen wir dem Browser: Wenn unter dem Menü-Button nicht genug Platz ist, dann platziere das Menüfeld oberhalb der Schaltfläche. Nicht genug Platz auf der rechten Seite? Ok, dann dreh die Inline-Achse um und lass das Menüfeld den Platz von links bis zur Mitte abdecken. Und wenn keines von beiden alleine funktioniert, dann mach beides (flip-block flip-inline ).

Schritt 4: Tastaturbedienbarkeit mit JavaScript

Unser benutzerdefiniertes Menü sollte für Tastaturbenutzer:innen vollständig bedienbar sein. Das ARIA APG Menu Pattern definiert die folgenden Anforderungen:

Wenn ein Menü geöffnet wird, wird der Tastaturfokus auf das erste Element gesetzt.
Mit Tab und Shift + Tab kann der Fokus nicht zwischen den Menüoptionen verschoben werden.
Wenn sich der Fokus in einem Menü befindet, verschiebt Pfeil-nach-unten den Fokus zum nächsten Element, wobei man optional vom letzten zum ersten Element wechselt.
Wenn sich der Fokus in einem Menü befindet, verschiebt Pfeil-nach-oben den Fokus zum vorherigen Element, wobei man optional vom ersten zum letzten Element wechselt.
Wenn sich der Fokus auf einer Option im Menü befindet, bewegen Tab und Shift + Tab den Fokus aus dem Menü hinaus und alle Menüs und Untermenüs werden geschlossen.
Mit Enter wird die Menüoption aktiviert und das Menü geschlossen.
Escape schließt das Menü, das den Fokus enthält, und fokussiert den Menü-Button.

Für die letzte Anforderung ist dank der Popover API bereits gesorgt. Für den Rest müssen wir etwas JavaScript-Code implementieren und unsere HTML-Struktur anpassen. Zunächst setzen wir tabindex=“-1” für alle Menüoptionen, um sie aus der Fokusreihenfolge herauszunehmen:

<div popover id="menu-content-1" role="menu" aria-labelledby="menu-btn-1">
    <button role="menuitem" tabindex="-1" type="button">More information</button>
    <button role="menuitem" tabindex="-1" type="button">Share</button>
    <button role="menuitem" tabindex="-1" type="button">Download the file</button>
</div>

Ich habe eine JavaScript-Klasse namens MenuNavigationHandler geschrieben, welche die erforderliche Interaktivität des benutzerdefinierten Menüelements kapselt. Einfach eine neue Instanz der Klasse erstellen, wobei ihr ein konkretes Menüelement als Parameter übergebt. Hier ist ein Auszug aus dem Code:

class MenuNavigationHandler {
    constructor(menuEl) {
        this.menuEl = menuEl;
        this.menuBtn = document.getElementById(this.menuEl.getAttribute("aria-labelledby")
    );
        this.menuItems = Array.from(menuEl.children);
        this.selectedItem = null;
        this.selectedItemIndex = 0;
        // Handle interaction with menu
        this.menuEl.addEventListener("toggle", (event) => this.onMenuOpen(event));
        this.menuEl.addEventListener("keydown", (event) => this.onMenuKeydown(event));
        this.menuEl.addEventListener("click", (event) => this.onMenuClick(event));
    }

    // Private methods
}

const menus = document.querySelectorAll('div[role="menu"]');
menus.forEach(item => new MenuNavigationHandler(item));

Der Konstruktor speichert Verweise auf den Menü-Button und das Menüfeld. Er fügt Event-Listener für das Popover-Toggle-Ereignis sowie für Keydown- und Click-Ereignisse auf dem Menüfeld hinzu. Ihr könnt euch den gesamten Code in meiner CodePen demo ansehen.

Schritt 5: Flüssige Animationen hinzufügen

Nicht zuletzt soll das benutzerdefinierte Menü gut aussehen und sich gut anfühlen. Wir verwenden CSS-Transitionen, um das Öffnen und Schließen des Menüfelds zu animieren.

div[role="menu"] {
    transition: opacity, transform, overlay, display;
    transition-behavior: allow-discrete;
}

div[role="menu"]:popover-open {
    /* End of fade-in and start of fade-out */
    transition-duration: 120ms;
    transition-timing-function: cubic-bezier(0, 0, 0.2, 1);
    opacity: 1;
    transform: scale(1);
}

@starting-style {
    /* Start of fade-in */
    div[role="menu"]:popover-open {
        opacity: 0;
        transform: scale(0.8);
    }
}

Um nun die Endwerte für die Ausblendung zu definieren, lassen wir einfach die Pseudoklasse :popover-open weg und definieren die Stile für das Menüelement direkt. Wir wollen eine zügigere, lineare Animation, die nur 100 Millisekunden dauert:

div[role="menu"] {
    /* End of fade-out */
    transition-duration: 100ms;
    transition-timing-function: linear;
    opacity: 0;
    transform: scale(1);
}

Na gut, die Animation sieht schon ziemlich cool aus. Wir könnten es dabei belassen. Aber ich möchte noch etwas erreichen: Das Menüfeld soll aus dem Menü-Button herauswachsen. Da wir die Eigenschaft transform für den Skalierungseffekt verwenden, müssen wir einfach den Ursprung wie folgt definieren:

transform-origin: top left;

Aber es gibt ein Problem! Der Ursprung sollte sich an die Platzierung des Menüfelds neben dem Menü-Button anpassen. Wenn sich das Menüfeld zum Beispiel oberhalb und links von der Schaltfläche öffnet, müssen wir als Ursprung bottom right festlegen.

Leider wirken sich die von uns definierten position-try-fallbacks nicht auf die Eigenschaft transform-origin aus. Ich habe auch versucht, benutzerdefinierte Positions-Optionen mit der @position-try Regel zu definieren. Aber dann wurde mir klar, dass die Spezifikation (und die Browser-Implementierung) nur eine sehr begrenzte Anzahl von Eigenschaften zulässt. Es hat einfach nicht funktioniert.

In der Spezifikation gibt es aber einen Hinweis, der mich für die Zukunft hoffen lässt:

It is expected that a future extension to container queries will allow querying an element based on the position fallback it’s using, enabling the sort of conditional styling not allowed by this restricted list.

In der Zwischenzeit müssen wir auf das gute alte JavaScript zurückgreifen. Wenn das Menüfeld geöffnet wird, rufen wir die folgende Methode der MenuNavigationHandler Klasse auf, um den passenden transform-origin festzulegen:

setTransformOriginOnMenuPanel() {
    const menuPanelPos = this.menuEl.getBoundingClientRect();
    const menuTriggerBtnPos = this.menuBtn.getBoundingClientRect();
    let originY = menuTriggerBtnPos.y > menuPanelPos.y ? "bottom" : "top";
    let originX = menuTriggerBtnPos.x > menuPanelPos.x ? "right" : "left";
    this.menuEl.setAttribute("style", `transform-origin: ${originY} ${originX};`);
}

Ich weiß, es ist ein bisschen holprig. Aber es funktioniert! Zumindest in Chrome und Edge. Ich werde das ganze benutzerdefinierte Menü in Firefox und Safari gründlich testen müssen, wenn sie endlich CSS Anchor Positioning unterstützen.

Bonus: Benutzerdefiniertes Menü in Angular

Wenn ihr das JavaScript-Framework Angular weder kennt noch euch dafür interessiert, dann überspringt bitte diesen Abschnitt.

Ihr seid immer noch hier? Gut, dann schaut euch mein Accessible Popover Menu project an. Es enthält die benutzerdefinierten Direktiven CustomMenuTrigger , CustomMenu und CustomMenuItem . Diese Direktiven kapseln alle Funktionen, die ich bisher in diesem Artikel beschrieben habe. Ihr könnt sie verwenden, um barrierefreie Menü-Komponenten in eurem Angular-Projekt zu erstellen.

Fazit

Die Popover-API und CSS Anchor Positioning sind einfach genial! Sie machen es so viel einfacher, komplexe Widgets wie ein benutzerdefiniertes Menü zu erstellen, wie ich euch gezeigt habe. Ich werde noch einen gründlichen Testlauf in Firefox und Safari durchführen, sobald diese ebenfalls die Ankerpositionierung unterstützen. Aber ich bin sehr optimistisch! 🤩

Ich hoffe, dieser Artikel inspiriert euch dazu, selbst mit den neuen Web-Features zu experimentieren. Ich bin gespannt, welche Art von Widgets und Komponenten ihr damit baut!

Update am 23.11.2025

Verankerte Container Queries werden ab Chrome 143 unterstützt. Also vergesst den Einsatz von JavaScript für Animationen in diesem Artikel. Lest stattdessen meinen neuen Artikel “Flexible Menü-Animation mit verankerten Container Queries”.

Bringe Screen Reader mit der ARIA Notify API zum Sprechen

Thu, 22 May 2025 00:00:00 GMT

Du drückst auf den Suchen-Button und der Seiteninhalt wird aktualisiert, um die Ergebnisse anzuzeigen. Oder du klickst auf die Schaltfläche „Zum Warenkorb hinzufügen“ und das Einkaufswagen-Symbol im Header erhält einen visuellen Indikator, dass ein Produkt hinzugefügt wurde. Typische Abläufe auf modernen Websites.

Eine sehende Person kann einfach die visuelle Veränderung des Seiteninhalts wahrnehmen. Aber was ist mit blinden und sehbehinderten Nutzer:innen? Wie können sie wichtige Änderungen bemerken, die nicht den Tastaturfokus erhalten? Aktuell müssen Webentwickler:innen ARIA-Live-Regionen verwenden, um Statusmeldungen zu erstellen, die von Screenreadern vorgelesen werden.

Foto: © Edmond Dantès / pexels.com*

Leider sind ARIA-Live-Regionen eng an DOM-Elemente gekoppelt, die aktualisiert werden müssen. In manchen Fällen wäre es jedoch einfacher, den Screenreader einfach einen bestimmten Text vorlesen zu lassen. Das ist die Idee hinter der neuen ARIA Notify API.

Microsoft Edge hat vor kurzem die neue API als Ursprungstest implementiert. Also habe ich ein Demoprojekt erstellt, um die neue Funktionalität auszuprobieren. Das sind meine Eindrücke.

Wie funktioniert ARIA Notify?

ARIA Notify ist eine imperative Benachrichtigungs-API, welche die Nutzung von ARIA-Live-Regionen ersetzen soll, wenn eine visuelle Darstellung des Textes nicht notwendig ist. Die API bietet eine einfache Möglichkeit, assistiven Technologien wie Screenreadern genau mitzuteilen, was sie den Nutzer:innen wann vorlesen sollen.

Entwickler:innen können die ariaNotify() Methode mit dem Text aufrufen, der vom Screenreader vorgelesen werden soll. Hier ist ein Beispiel:

document.ariaNotify("This is an audible notification");

Optional könnt ihr mit der Option priority angeben, wie der Screenreader die Benachrichtigung im Vergleich zu anderen, noch ausstehenden Benachrichtigungen einstufen soll:

document.ariaNotify("Critical error", { priority: "high" });

Wollt ihr es ausprobieren?

Demo: Online-Shop mit Warenkorb

Ich habe eine CodePen-Demo eines Online-Shops namens „The Shop“ gebaut. Ihr könnt Produkte wie „Fancy Stuff“ oder „Useless Junk“ in den Einkaufswagen legen. Der Einkaufswagen zeigt visuell an, dass Produkte hinzugefügt wurden. Screenreader-Nutzer:innen hören eine Meldung wie z.B. „Artikel Fancy Stuff wurde dem Warenkorb hinzugefügt.“

See the Pen Shop Demo with ARIA Notify API by Alexander Lehner (@alexlehner86) on CodePen.

Während ich diesen Blogbeitrag schreibe, wird die ARIA Notify-API nur als Testversion in Microsoft Edge unterstützt. Ihr müsst Edge Canary installieren und den Browser mit dem folgenden Befehl starten:

"C:\Users\[username]\AppData\Local\Microsoft\Edge SxS\Application\msedge.exe" --enable-blink-features=AriaNotify

Das Flag -enable-blink-features=AriaNotify aktiviert die ARIA Notify API. Nun sollte euer Screenreader eine Meldung ausgeben, wenn ihr ein Produkt in den Einkaufswagen legt. Ich habe das erfolgreich mit den aktuellen Versionen von NVDA und JAWS getestet.

Erste Eindrücke

Mir gefällt, wie direkt und einfach zu nutzen die neue API ist. Man ruft einfach ariaNotify() auf und der Screenreader liest die Nachricht vor. Großartig! 🤩
Das W3C wird bald die Liste an ausreichenden Techniken auf WCAG 4.1.3 Status Messages aktualisieren müssen. 😅
Die priority Option hat in meinen Testfällen nicht wirklich einen Unterschied gemacht. Ich habe eine zweite Demo mit einem Toggle für hohe oder normale Priorität erstellt. Aber die Screenreader-Ankündigungen kamen zur gleichen Zeit. Vielleicht habe ich etwas missverstanden. 😩
Webentwickler:innen müssen mit der neuen API sehr vorsichtig sein. Wenn es so einfach ist, einen Screenreader einfach Text vorlesen zu lassen, dann besteht die Gefahr, dass die Nutzer:innen mit zu vielen Meldungen überflutet werden. Ich denke da an Autoplay-Karussells, die ständig Statusmeldungen ausgeben! 😨

Wie auch immer. Wir befinden uns noch in einer sehr frühen, experimentellen Phase. Ich werde abwarten, bis auch andere Browser die neue API implementiert haben, und sie ein wenig reifen lassen. Dann werde ich es auf mehr Plattformen testen, insbesondere auf mobilen Geräten.

Generell bin ich begeistert und optimistisch, was die ARIA Notify API angeht.

Datums- und Zeitverwaltung mit der Temporal API

Thu, 17 Apr 2025 00:00:00 GMT

Hast du die Schnauze voll vom Date Objekt in JavaScript? Ich auch! Zum Glück wird sie bald von der Temporal API abgelöst. Diese umfasst mehrere Klassen für die Datums- und Zeitverwaltung, einschließlich integrierter Zeitzonen- und Kalenderdarstellung.

Foto: © KoolShooters / pexels.com

Die neue API ist bereits in Firefox Nightly verfügbar. Wir sehen uns kurz die wichtigsten Funktionen von Temporal an. Danach zeige ich euch einige von mir zusammengestellte Code-Beispiele.

Grober Überblick

Die Temporal API stellt über 200 Utility-Methoden über mehrere Klassen zur Verfügung. Das ist eine ganze Menge! Ich werde daher nicht auf alle eingehen, sondern nur die wichtigsten Funktionen nennen.

Es gibt mehrere Objekte für die Arbeit mit einfachen Datums- und Zeitangaben, ohne Zeitzone:

Temporal.PlainDate stellt ein Kalenderdatum ohne Zeit oder Zeitzone dar. Beispiel: 2025-04-14
Temporal.PlainTime stellt eine Zeit ohne Datum oder Zeitzone dar. Beispiel: 21:10:30.025
Temporal.PlainDateTime steht für ein Datum und eine Uhrzeit ohne Zeitzone. Beispiel: 2025-04-14T21:10:30.025

Zur Darstellung eines eindeutigen Zeitpunkts verwenden wir das Objekt Temporal.Instant . Es ist semantisch identisch zu Date , aber präziser (im Nanosekundenbereich).

Schließlich kommen wir zum Objekt Temporal.ZonedDateTime , das einen Zeitpunkt, eine Zeitzone und ein Kalendersystem kombiniert. Beispiel: 2025-04-16T21:22:26.384+02:00[Europe/Vienna] .

Außerdem können wir mit dem Objekt Temporal.Now die aktuelle Zeit in verschiedenen Formaten abrufen. Und Temporal.Duration stellt eine Differenz zwischen zwei Zeitpunkten dar, die wir auch in Datum/Zeit-Berechnungen verwenden können.

Code-Beispiele

Ich habe eine Liste von Code-Beispielen für die Arbeit mit der neuen Temporal API in JavaScript zusammengestellt. Hier sind ein paar davon:

Ein einfaches Datumsobjekt erstellen und auf Teile davon zugreifen

let calendarDate = Temporal.PlainDate.from("2025-04-09");
calendarDate.day; // 9
calendarDate.dayOfWeek; // 3
calendarDate.month; // 4
calendarDate.year; // 2025

Hinzufügen einer Dauer zu einem unveränderlichen einfachen Zeitobjekt

let t1 = new Temporal.PlainTime(14, 55, 10, 250); // "14:55:10.25"
let t2 = t1.add({ seconds: 5000 });
t2.toString(); // "16:18:30.25"

Sprachabhängige Formatierung eines Datum/Zeit-Objekts mit Zeitzone

let datetime = Temporal.ZonedDateTime.from("2020-10-15T08:30Z[America/New_York]");
datetime.toLocaleString("en-US"); // "10/15/2020, 4:30:00 AM EDT"

Zwei Zeitpunkte vergleichen

let inst1 = Temporal.Instant.from("2022-07-10T12:00Z");
let inst2 = Temporal.Instant.from("2023-01-01T15+01:00");
inst1.equals(inst2);  // false
Temporal.Instant.compare(inst1, inst2); // -1 (is before)

Runden einer Dauer auf eine bestimmte Einheit

let duration = Temporal.PlainTime.from("12:30").until("17:45"); // "PT5H15M"
duration = duration.round("hours"); // "PT5H"

Browser-Unterstützung

Na, schon begeistert? Ich auf jeden Fall! Und es wird noch besser: Firefox wird bald der erste Browser sein, der Temporal in einer stabilen Version ausliefert. Firefox 139 soll am 27. Mai erscheinen.

Die Implementierung in anderen Browsern ist noch in Arbeit (Chromium, WebKit/Safari). Aber ich bin sicher, dass es nicht mehr lange dauert. In der Zwischenzeit: Macht euch mit Temporal in Firefox Nightly vertraut. 😉

Meine Lieblings-Tools zum Testen von Web-Accessibility

Sun, 30 Mar 2025 00:00:00 GMT

Web-Accessibility hat viele Facetten: Die Bedienung mit der Tastatur und anderen Eingabegeräten, Alternativtexte für Bilder, verständliche Überschriften und Fehlertexte, usw. Ebenso vielfältig ist das Angebot an Tools, um die Barrierefreiheit von Websites zu testen.

Eines gleich vorweg: Es gibt nicht das eine Power-Tool , welches alle Barrieren automatisch erkennt und am besten auch gleich behebt. Das gilt auch für KI-basierte Accessibility-Tools. Ja, künstliche Intelligenz hat großes Potential, aber aktuelle Tools können keinen umfassenden Barrierefreiheits-Test ersetzen. Auch wenn gewisse Leute im Rausch des KI-Hypes etwas anderes behaupten.

Foto: © Thirdman / pexels.com

Damit das zarte Pflänzchen Barrierefreiheit gedeiht, brauchen wir die richtigen Werkzeuge. Hier ist meine persönliche Auswahl an kostenlosen Bookmarklets, Browser-Erweiterungen und Tools zum Testen von Barrierefreiheit.

Struktur und Semantik

WAVE (Web Accessibility Evaluation Tools): Ein Barrierefreiheits-Analysetool von WebAIM. Als Browser-Erweiterung für Firefox, Chrome und Edge verfügbar. Besonders praktisch finde ich die Struktur-Ansicht, wo man auf einen Blick sieht, ob sinnvolle Landmarks (header , main etc.) und Überschriften-Ebenen definiert wurden.
Firefox Accessibility Inspector ist ein fixer Bestandteil der Firefox-Entwicklertools. Ihr wollt wissen, welche Informationen ein interaktives Element an assistive Technologien übermittelt? Einfach Rechtsklick darauf und “Barrierefreiheit-Eigenschaften untersuchen” auswählen. Firefox öffnet den “Barrierefreiheit”-Tab in den Entwicklertools und springt zum zugehörigen Knoten im Accessiblity-Tree. Debugging war noch nie so einfach! 😍
Testen mit Screenreader: Keine Barrierefreiheits-Prüfung ist komplett ohne Screenreader-Tests. Angesichts begrenzter Budgets in Projekten, kann man nicht mit allen Screenreadern auf allen Plattformen testen. Auf der Basis aktueller Statistiken habe ich daher folgende Testszenarien definiert:
- NVDA in Windows
- VoiceOver in iOS
- TalkBack in Android
Falls ihr noch nie mit dem Screenreader getestet habt, dann lest am besten meinen Artikel „5 Tipps für den Einstieg in Barrierefreiheits-Prüfungen mit dem Screenreader“.

Ideal zum Testen der WCAG-Kriterien 1.3.1 Info und Beziehungen und 4.1.2 Name, Rolle, Wert.

Tastaturbedienung

Testen mit Tastatur: Mit der Tabulatortaste die interaktiven Elemente der Seite (Buttons, Links etc.) durchgehen. Ist die Fokus-Reihenfolge sinnvoll? Können Tastatur-Nutzer:innen alle interaktiven Elemente erreichen und aktivieren? Wird das fokussierte Element sichtbar hervorgehoben? Am Smartphone oder Tablet könnt ihr einfach eine Bluetooth-Tastatur verbinden.
taba11y: Diese praktische Browser-Erweiterung berechnet die Tab-Reihenfolge aller interaktiven Elemente und stellt sie visuell dar, entweder durch Zeichnen eines Pfades oder durch Hervorheben der Elemente.

Ideal zum Testen der WCAG-Kriterien 2.1.1 Tastatur, 2.1.2 Keine Tastaturfalle, 2.4.3 Fokus-Reihenfolge und 2.4.7 Fokus sichtbar.

Responsive Inhalte

Browser-Einstellungen: Ändere die Standardschriftgröße deines Browsers, um zu kontrollieren, ob die Website automatisch die Textgröße anpasst. Die meisten Browser wie z.B. Edge erlauben nur die Auswahl aus vordefinierten Optionen wie “Klein”, “Mittel” und “Groß”. Im Firefox können Nutzer:innen hingegen einen konkreten Pixelwert als Standardschriftgröße definieren.
Alternativ könnt ihr mit der Zoom-Funktion des Browsers (STRG und + Taste) den gesamten Seiteninhalt proportional zur Schriftgröße vergrößern.
Benutze das Textabstände-Bookmarklet oder eine Browser-Erweiterung (z.B. Editor for Textlayout), um die Werte für Zeilenhöhe, Abstand nach Absätzen, Buchstabenabstand und Wortabstand auf die maximal geforderten Werte zu setzen. Es sollten keine Inhalte abgeschnitten werden oder einander überlappen.

Ideal zum Testen der WCAG-Kriterien 1.4.4 Textgröße ändern, 1.4.10 Automatischer Umbruch (Reflow) und 1.4.12 Textabstand.

Zielgröße von interaktiven Elementen

Target Size Bookmarklet: Es identifiziert interaktive Elemente, errechnet deren Mittelpunkt und zeichnet einen halbtransparenten Kreis von 24 mal 24 Pixeln um den Mittelpunkt des Elements: Ein grüner Kreis mit dickem Rand bedeutet, dass die Zielgröße ausreicht. Elemente mit blauem Kreis sollten manuell untersucht werden.
Auf diese Weise findet ihr viel schneller Buttons und Links, bei denen Nutzer:innen mit motorischer Beeinträchtigung Probleme beim Anklicken oder Antippen haben könnten.

Ideal zum Testen des WCAG-Kriteriums 2.5.8 Zielgröße (Minimum).

Mindestkontrast

Chrome Lighthouse ist Teil der Entwickler-Tools in Chrome. Der Accessibility-Check von Lighthouse findet zuverlässig einen Großteil der Elemente mit zu geringem Kontrastverhältnis.
PowerToys Farbwähler: Die Microsoft PowerToys sind eine Sammlung von Hilfsprogrammen für Poweruser. Mit der Tastenkombination WIN +Umschalt +C könnt ihr jederzeit den Farbwähler aktivieren und den Farbwert eines Pixels am Bildschirm auslesen.
WebAIM Contrast Checker: Einfaches Tool, um das Kontrastverhältnis einer Schriftfarbe zur Hintergrundfarbe zu prüfen. Besonders praktisch ist das Feature, dass man die gewählten Farbwerte inklusive Auswertung als Permalink teilen kann.

Ideal zum Testen der WCAG-Kriterien 1.4.3 Kontrast (Minimum) und 1.4.11 Nicht-Text-Kontrast.

Weitere Links

Accessibility Engineering — Lass die Web-Plattform die Arbeit machen

Mon, 03 Feb 2025 00:00:00 GMT

Web-Entwickler:innen haben es schwer. Du bekommst ein paar schriftliche Anforderungen und ein visuelles Design. Du beginnst mit der Umsetzung: Du fügst HTML-Elemente hinzu, gestaltest sie mit CSS und implementierst Geschäftslogik mit JavaScript. Du machst dir Gedanken über Usability, Web-Sicherheit, Geschwindigkeit, Datenverwaltung und so weiter.

Du atmest tief durch und sagst zu dir selbst: „Ich schaffe das!“

Plötzlich ruft dein Projektmanager an: „Die Website wird doch barrierefrei sein, oder?“ Du gerätst in Panik und tippst das Wort Barrierefreiheit in die Suchmaschine ein. Du wirst mit Informationen überflutet. Einige davon sind widersprüchlich. Du bittest ChatGPT um Hilfe. Es zeigt dir übertrieben komplexen Code, der mit ARIA-Attributen gespickt ist. Seufz! Du denkst: „Das wird eine Menge Arbeit!“

Ich habe gute Nachrichten für dich: Barrierefreiheit muss nicht anstrengend sein. Sie kann sogar ganz einfach und, ich wage zu behaupten, wunderschön sein. Die Web-Plattform ist dein Verbündeter. Lass sie einfach die Arbeit machen!

Foto: © ThisIsEngineering / pexels.com

Wir werden einen kurzen Blick auf die Grundlagen des Webs werfen und wie man sie effizient einsetzt. Dann gebe ich euch einige konkrete Beispiele für Web-Features mit eingebauter Barrierefreiheit.

Die grundlegenden Werkzeuge des Accessibility Engineering

Die Web-Plattform ist eine Sammlung von Technologien, die vom World Wide Web Consortium und anderen Gremien als offene Standards entwickelt wurden. Zu diesen Technologien gehören HTML, CSS, JavaScript und WAI-ARIA. Diese Bausteine des Webs ermöglichen es uns, Websites zu gestalten, die für alle Menschen zugänglich sind.

Warum tun sich so viele Web-Entwickler:innen dann mit Barrierefreiheit so schwer? Ich sehe dafür zwei Hauptgründe:

Übermäßige Abhängigkeit von externen Bibliotheken.
Unzureichende Erfahrung mit nativen Web-Features.

Die meisten Junior-Developer lernen heutzutage Webentwicklung auf der Grundlage von Frameworks wie Angular, React oder Vue.js. Sie lernen alles über Komponenten und Datenmanagement, machen sich aber kaum mit nativen HTML-Elementen und fortgeschrittenen CSS-Features vertraut.

Ich mache ihnen keinen Vorwurf! Moderne JavaScript-Frameworks und UI-Bibliotheken bieten mächtige Funktionen, die uns bei der Implementierung komplexer Webanwendungen helfen. Aber sie sind eine weitere Ebene der Abstraktion. Sie entfernen uns von den wesentlichen Bausteinen des Webs. Was können wir also tun?

HTML First und die Regel der geringsten Macht

Die Regel der geringsten Macht besagt, dass man die am wenigsten leistungsfähige Sprache wählen sollte, die für einen bestimmten Zweck geeignet ist. Was heißt das für Web-Entwickler:innen? Wenn du etwas mit HTML machen kannst, verwende HTML. Du musst das Styling anpassen? Verwende CSS. Etwas ist nicht allein mit HTML und CSS machbar? Dann verwende JavaScript und WAI-ARIA.

Native HTML-Elemente sind so konzipiert, dass sie in verschiedenen Browsern und mit diversen assistiven Technologien wie Screenreadern funktionieren. Sie sind in der Regel robuster und zuverlässiger als benutzerdefinierte Lösungen. Wenn du das nächste Mal ein neues Feature implementierst, solltest du nach einer Lösung in der folgenden Reihenfolge suchen:

HTML
CSS
JavaScript
WAI-ARIA
Externe Bibliotheken

Als erstes suche ich immer nach einer nativen Lösung in den MDN Web Docs. Wenn ich etwas mit HTML und CSS allein nicht hinbekomme, recherchiere ich die richtige Verwendung von ARIA-Attributen und JavaScript, um eine barrierefreie Lösung zu schaffen. Der ARIA Authoring Practices Guide (APG) bietet alle Infos, die du brauchst.

Warum stehen externe Bibliotheken an letzter Stelle der Liste? Weil sie eine zusätzliche Abhängigkeit für dein Projekt schaffen. Sobald du dich für eine UI-Komponentenbibliothek entschieden hast, bist du daran gebunden. Deshalb achte unbedingt darauf, eine barrierefreie UI-Bibliothek zu verwenden. Schau dir am besten meine „Checkliste für barrierefreie UI-Komponenten-Bibliotheken“ an.

Der aktuelle Zustand des Webs

Die Web-Plattform entwickelt sich ständig weiter. Jeden Tag werden neue HTML-Elemente, CSS-Eigenschaften und Web-APIs spezifiziert und von den Browsern implementiert. Initiativen wie Interop 2024 tragen dazu bei, die Interoperabilität des Webs zu verbessern.

Für Web-Entwickler:innen ist es heute viel einfacher und unkomplizierter, barrierefreie Websites zu erstellen als noch vor 10 Jahren. Ich gebe zu, nicht alles lässt sich allein mit HTML und CSS bewerkstelligen. Im Moment braucht man noch ARIA und JavaScript, um eine Tab-Liste oder benutzerdefinierte Tooltips zu implementieren.

Aber ich möchte mich auf das Positive konzentrieren! Werfen wir einen Blick auf einige native HTML-Features, die es euch sehr einfach machen, robuste, barrierefreie Websites zu erstellen.

Beispiele für native HTML-Features

Das `button` Element: Ein mächtiger Allrounder

Vielleicht ist das button Element schon älter als du! Es wurde erstmals im Dezember 1997 in der HTML 4.0-Spezifikation definiert. Das heißt, Schaltflächen gibt es schon eine ganze Weile. Dennoch unterschätzen viele Entwickler:innen dieses mächtige und vielseitige HTML-Element. Manche halten es sogar für eine gute Idee, stattdessen ein div Element zu verwenden. Horror! 😱

Vielleicht denkst du jetzt: „Na gut, Romeo! Warum bist du so verliebt in das Button-Element?“ Lass mich mit der kurzen Beschreibung von MDN antworten:

The <button> HTML element is an interactive element activated by a user with a mouse, keyboard, finger, voice command, or other assistive technology. Once activated, it then performs an action, such as submitting a form or opening a dialog.

Das button Element wurde so konzipiert, dass es für alle Nutzer:innen gut funktioniert. Du kannst es mit der Maus anklicken. Du kannst eine Schaltfläche mit der TAB Taste fokussieren und sie mit der Eingabe- oder Leertaste aktivieren. Wenn du mit einem Screenreader zu einem Button navigierst, wird er dir sagen, dass es sich um eine Schaltfläche handelt, die aktiviert werden kann.

Browser wenden auch Standard-Styles auf HTML-Schaltflächen an. Einige Web-Entwickler:innen empfinden das als lästig, weil sie das Styling mit CSS überschreiben müssen. Da verwenden sie lieber das div Element und klatschen einen click Event-Handler darauf, weil sie glauben, das sei genug. Das ist es aber nicht!

Es gibt große Unterschiede zwischen button und div Elementen! Eine Schaltfläche löst den click Event-Handler für alle Arten der Interaktion aus: Maus, Tastatur, Screenreader usw. Das div Element hingegen wird nur bei Maus- oder Touch-Interaktion ausgelöst. Um ein div-Element in eine barrierefreie Schaltfläche zu verwandeln, ist folgendes notwendig:

Einen tabindex hinzufügen, um das Element fokussierbar zu machen.
Einen sichtbaren Fokusindikator anzeigen, wenn die Schaltfläche den Fokus erhält.
Tastatur-Event-Handler für die Enter- und Leertaste definieren.
Ein role Attribut hinzufügen, um Screenreader-Nutzer:innen mitzuteilen, dass es sich um eine Schaltfläche handelt.

Wow, das sind eine Menge Arbeit und viele unnötige Code-Zeilen! Wenn du stattdessen eine native Schaltfläche verwendest, ist dein Code einfacher zu lesen und zu pflegen. Immer noch nicht überzeugt? Dann lies meinen Artikel „3 Gründe, warum auch Web-Entwickler:innen von Barrierefreiheit profitieren“.

Das ist schon eine Menge Text über Buttons. Aber es gibt noch eine Sache, die ich erwähnen möchte: Native Schaltflächen bekommen laufend mehr Superkräfte!

Das letzte Upgrade verdanken wir der neuen Popover-API. Du kannst das popovertarget Attribut verwenden, um das button Element in einen Popover-Steuerungs-Button zu verwandeln. Hier eine Demo für Menü-Buttons (funktioniert derzeit nur in Chromium-Browsern):

See the Pen Accessible Menu with Popover API by Alexander Lehner (@alexlehner86) on CodePen.

Es gibt so viele Anwendungsfälle für Buttons mit angehängten Popovers: Menüs, Tooltips, Datumsauswahlen usw. Wenn das Thema für dich neu ist, kannst du einen Blick auf die folgenden Artikel von mir werfen:

Aber das ist noch nicht alles! Das nächste Button-Upgrade beschert uns die (derzeit noch experimentelle) Invoker Commands API. Diese API bietet die Möglichkeit, Schaltflächen deklarativ Aktionen zuzuweisen, wie das Öffnen oder Schließen eines modalen Dialogs. Genial! 🥰

Na schau an, was für ein Zufall! Dialoge sind das nächste native HTML-Feature auf meiner Liste.

Das `dialog` Element: Immer oben auf

Dialoge sind ein wesentlicher Bestandteil moderner Web-Oberflächen: Von einfachen Aufforderungen, eine Aktion zu bestätigen, bis hin zu Fenstern mit komplexen Inhalten. Mit dem nativen dialog Element ist es ganz einfach, einen barrierefreien Modal-Dialog über den anderen Seiteninhalten zu öffnen.

Das Dialog-Element ist standardmäßig barrierefrei. Wenn du die Methode showModal() verwendest, um einen modalen Dialog zu öffnen, geschieht Folgendes:

Der Browser setzt den Fokus automatisch auf das erste interaktive Element innerhalb des Dialogs.
Ein Screenreader weist darauf hin, dass der neue Inhalt Teil eines Dialogs ist.
Solange der Modal-Dialog geöffnet ist, können Nutzer:innen mit dem restlichen Inhalt der Seite nicht interagieren. Das bedeutet, dass Tastaturnutzer:innen den Dialog nicht mit der TAB Taste verlassen können. Auch der virtuelle Cursor des Screenreaders kann sich nur innerhalb des Dialogs bewegen.
Der Modal-Dialog kann standardmäßig mit der ESC Taste geschlossen werden.
Nach dem Schließen wird der Fokus automatisch zurück auf das Bedienelement gesetzt, mit dem der Dialog geöffnet wurde. Davon profitieren Tastatur- und Screenreader-Nutzer:innen, die sofort an der Stelle weitermachen können, wo sie aufgehört hatten.

Natürlich musst du nicht unbedingt das native dialog Element verwenden. Du kannst auch ein benutzerdefiniertes, barrierefreies Dialogfeld mit ARIA und JavaScript implementieren. Aber warum solltest du das tun? Komm schon! Sei clever und lass die Web-Plattform die Arbeit machen. 😉

Wenn du mit dem nativen dialog Element nicht vertraut bist und mehr darüber erfahren möchtest, lies meinen Artikel „Warum du das native Dialog-Element nutzen solltest“.

Formularfelder: Gute Zeiten, schlechte Zeiten

Allzu oft verwenden Web-Entwickler:innen benutzerdefinierte Formularfelder, um Designanforderungen zu erfüllen – und vernachlässigen dabei die Barrierefreiheit. Das können wir besser!

Mit modernen Browsern kannst du auf die meisten nativen Formular-Elemente dein eigenes Styling anwenden. Auf diese Weise können wir barrierefreie Webformulare erstellen, die auf allen Plattformen ein einheitliches Aussehen haben.

Native Formular-Elemente wie input oder select sind standardmäßig barrierefrei. Sie erhalten den Tastaturfokus und können mit der Eingabetaste oder der Leertaste aktiviert werden, z.B. um eine Checkbox auszuwählen. Sie kommunizieren ihre Rolle und ihren aktuellen Status an Screenreader.

Die folgende Demo zeigt ein barrierefreies Webformular mit eigenem Styling für die native Auswahlliste und die Radio-Buttons:

See the Pen Styling Native Form Controls by Alexander Lehner (@alexlehner86) on CodePen.

Leider lassen sich nicht alle nativen Formular-Elemente leicht mit benutzerdefinierten Styles anpassen. Mozilla bietet einen tollen Artikel über die Gestaltung von Webformularen, den ich sehr empfehlen kann. Darin werden native Formular-Elemente in drei Gruppen eingeteilt: „Die Guten“, „Die Schlechten“ und „Die Hässlichen“.

Meiner Meinung nach sind die nativen Elemente für Eingabefelder, Radio-Buttons, Checkboxen und einfache Auswahllisten sehr gut gestaltbar. Es gibt keinen Grund, stattdessen benutzerdefinierte Elemente zu verwenden. Es sei denn, du hast eine masochistische Veranlagung. Mehr Infos findest du in meinem Artikel „Barrierefreie Web-Formulare mit individuellem Design gestalten“.

Und was ist mit dem Rest? Einige native Formular-Elemente verfügen über interne Elemente, die nicht allein mit CSS gestaltet werden können. Dazu gehören der Farbwähler, der Datumswähler, die Datei-Auswahl und das select Element. In diesen Fällen verstehe ich den Bedarf an benutzerdefinierten Komponenten. Stellt nur sicher, dass sie barrierefrei sind.

Zum Glück für uns wird das select Element bald ein wichtiges Upgrade erhalten. Eine anpassbare Version des Elements befindet sich offiziell in Phase 2 der WHATWG, mit starkem Cross-Browser-Interesse und einem in Chrome Canary verfügbaren Prototypen. Weitere Informationen findest du in diesem Chrome-Blogbeitrag. 🤩

Disclosure- und Akkordeon-Widgets mit nativem HTML

Das native HTML-Element details erzeugt ein Disclosure-Widget, dessen Inhalt nur dann sichtbar ist, wenn das Widget geöffnet wurde. Der Inhalt des verschachtelten summary Elements liefert das Label für das Disclosure-Widget. Die perfekten HTML-Elemente für eine FAQ-Seite oder einen ausklappbaren Info-Abschnitt in einem Artikel.

<details>
    <summary>What is HTML?</summary>
    HTML is the standard markup language for web pages, defined by the W3C and WHATWG.
</details>

Früher war es nicht möglich, den display Typ des details Elements zu ändern. Diese Einschränkung wurde in Chromium-Browsern bereits gelockert, so dass du Grid- oder Flex-Layouts verwenden kannst. Der Artikel „More options for styling <details>“ enthält eine wirklich coole Demo für ein exklusives Akkordeon.

Fazit

Also gut. Dieser Artikel ist viel länger geworden, als ich beabsichtigt hatte. 😂

Ich hoffe, er hilft dir auf deinem Weg zum Accessibility Engineer. Die wichtigste Botschaft: Native HTML-Elemente sind einfach klasse und (meistens) von Haus aus barrierefrei. Nutze sie!

Platzhaltertext braucht guten Farbkontrast

Fri, 20 Dec 2024 00:00:00 GMT

Müssen Platzhaltertexte in Formularen den Anforderungen an hohen Farbkontrast genügen? Die kurze Antwort lautet: „Ja, natürlich!“

Die lange Antwort: Nicht alle Nutzer:innen haben eine perfekte Sehkraft. Vor allem mit zunehmendem Alter wird es schwieriger, Text vom Hintergrund zu unterscheiden, wenn der Farbkontrast gering ist. Daher solltet ihr immer für einen ausreichenden Kontrast zwischen Text und Hintergrund sorgen.

Das gilt auch für Platzhaltertext in Webformularen oder Dokumenten. Der Platzhalter liefert in der Regel einen nützlichen Hinweis, der beim Ausfüllen eines Eingabefeldes unterstützt. Er ist nicht rein dekorativ. Daher sollten alle Nutzer:innen in der Lage sein, den Platzhaltertext wahrzunehmen.

Foto: © Egor Komarov / pexels.com

Anforderungen an den minimalen Farbkontrast

Das Erfolgskriterium 1.4.3 Kontrast (Minimum) der WCAG 2.2 definiert Anforderungen an den Farbkontrast. Text muss mindestens ein Kontrastverhältnis von 4,5 zu 1 zum Hintergrund haben, oder ein Kontrastverhältnis von 3 zu 1, wenn es sich um großen Text handelt. Das Understanding-Dokument sagt eindeutig:

This Success Criterion applies to text in the page, including placeholder text and text that is shown when a pointer is hovering over an object or when an object has keyboard focus.

Es gibt viele Werkzeuge, mit denen ihr das Kontrastverhältnis zweier Farbwerte überprüfen könnt. Ich verwende meistens den WebAIM Contrast Checker.

Platzhaltertext in Webformularen gestalten

In den meisten Browsern wird Platzhaltertext standardmäßig in einer hellgrauen Farbe dargestellt. Auch UI-Bibliotheken verwenden manchmal sehr helle Farben. Dies führt zu Platzhaltertext mit schlechtem Farbkontrast.

Verwendet das CSS-Pseudo-Element ::placeholder , um eine Textfarbe mit ausreichendem Farbkontrast zu definieren:

input::placeholder {
    color: #5b5b5b;
}

Ihr könnt auch den Schriftstil und die Schriftgröße des Platzhaltertextes ändern. Werft einen Blick auf meine Demo, in der ihr das Standard-Styling des Browsers mit dem benutzerdefinierten Styling vergleichen könnt:

See the Pen Style placeholder text by Alexander Lehner (@alexlehner86) on CodePen.

Mit dieser kleinen Änderung könnt ihr schnell die Barrierefreiheit eurer Website verbessern. Manchmal ist es so einfach! 😊

Nützliche Links

Barrierefreie Navigationsmenüs mit der Popover API erstellen

Thu, 17 Oct 2024 00:00:00 GMT

Navigationsmenüs sind ein wesentlicher Bestandteil jeder Website. Sie sind meistens in der Kopfzeile platziert und bieten einen Überblick über die Seitenhierarchie einer Website. Nutzer:innen können sich einen Überblick über den Inhalt verschaffen und schnell zu den wichtigsten Abschnitten der Website navigieren.

Viele Websites verwenden Fly-Out-Menüs (oder Drop-Down-Menüs), bei denen bestimmte Menüpunkte ein Untermenü öffnen, wenn man sie anklickt oder den Mauszeiger über sie bewegt. Oft sind diese Menüs für Screenreader- und Tastatur-Nutzer:innen nur sehr schlecht zugänglich. Aber wir können es besser machen!

Ich zeige euch, wie ihr auf einfache Weise ein barrierefreies Fly-Out-Menü bauen könnt. Dazu nutzen wir die Fähigkeiten moderner Web-Features wie der Popover API.

Foto: © Valentin Antonucci / pexels.com

Was wir erreichen wollen

Unser Navigationsmenü sollte für verschiedene Nutzergruppen einfach zu bedienen sein:

Die Untermenüs sollten über dem Inhalt der Website erscheinen und nicht sofort verschwinden, wenn die Maus den anklickbaren Bereich verlässt.
Nutzer:innen von Bildschirmlesegeräten benötigen aussagekräftiges Markup, um das Navigationsmenü zu verstehen und zu bedienen.
Tastaturnutzer:innen sollen das Menü allein mit der Tastatur bedienen können.

Demo: Barrierefreies Navigationsmenü

Ich habe eine CodePen-Demo eines barrierefreien Navigationsmenüs mit der Popover-API erstellt. Öffnet die Demo auf einem Desktop-Bildschirm oder einem Tablet im Querformat, um das Fly-Out-Menü zu sehen. Auf kleineren Geräten wird die Demo stattdessen ein mobiles Menü anzeigen.

Foto: © Alexander Lehner

Das Navigationsmenü ist für Maus-, Tastatur- und Screenreader-Nutzer:innen leicht zu bedienen. Schauen wir uns die wichtigsten Elemente an.

Aussagekräftiges Markup

Wir verwenden das nav Element, um die Rolle des Menüs zu vermitteln. Die Menüpunkte befinden sich in einer ungeordneten Liste (ul Element). So können assistive Technologien die Anzahl der Menüpunkte vorlesen und entsprechende Navigationsfunktionen bereitstellen.

<nav class="main-nav">
    <ul>
        <li>
            <button popovertarget="nav-panel-solutions" type="button">Solutions</button>
            <div id="nav-panel-solutions" popover>...</div>
        </li>
        <li><a href="#">Products</a></li>
        <li>...</li>
        <li>...</li>
    </ul>
</nav>

Die Listenelemente enthalten entweder einen direkten Link zu einer Unterseite, oder sie enthalten ein button Element, das ein Untermenü mit popover Attribut öffnet. Die Schaltfläche ist mit dem Popover-Inhalt über das Attribut popovertarget verknüpft.

Einer der großen Vorteile der Popover-API: Sie teilt den assistiven Technologien automatisch mit, ob das Untermenü gerade ein- oder ausgeklappt ist. Weitere Informationen findet ihr im Artikel „On popover accessibility: what the browser does and doesn’t do“.

Vermeidet die `menu` Rolle

In meiner Demo verwende ich die Rollen menu und menuitem nicht für das Navigationsmenü. Das ist Absicht! Diese ARIA-Rollen sind nur für Menü-Widgets gedacht, die sich wie native Betriebssystem-Menüs verhalten.

Lest den Artikel „Don’t Use ARIA Menu Roles for Site Nav“ von Adrian Roselli für eine detaillierte Erklärung.

Visuelle Platzierung

Wenn ein Untermenü geöffnet wird, erscheint es automatisch im Top-Layer, einer separaten Ebene, die über allen anderen im Webdokument angezeigten Ebenen liegt. Ihr müsst euch nur um die Platzierung und Größe des Untermenüs kümmern:

header nav.main-nav [popover] {
    top: var(--header-height);
    margin: 0;
    width: 100%;
}

Popover-Inhalte erscheinen standardmäßig in der Mitte des Bildschirms. Um unsere Untermenüs direkt unterhalb der Kopfzeile zu platzieren, setzen wir für top die Höhe der Kopfzeile und entfernen jeglichen margin . Anschließend setzen wir width auf 100% , damit das Untermenü die gesamte Breite der Seite einnimmt.

Tastaturbedienbarkeit

Mit der TAB Taste könnt ihr die Links und Schaltflächen im Navigationsmenü fokussieren. Nach dem Öffnen eines Untermenüs ist dessen Inhalt der nächste in der Fokusreihenfolge. Durch Drücken der ESC Taste wird das Untermenü geschlossen und der Fokus automatisch wieder auf die Trigger-Schaltfläche gesetzt. Alles dank der mächtigen Popover-API! 🤩

Light-Dismiss der Untermenüs

Ein weiteres integriertes Feature der Popover-API ist Light-Dismiss: Wenn ihr einen Bereich außerhalb des Untermenüs anklickt, wird das Untermenü geschlossen und der Fokus auf das Trigger-Element zurückgesetzt. Ihr müsst euch nicht mehr mit focusout Events in JavaScript herumschlagen.

Nützliche Links

Offlinedaten einfach speichern mit idb und der IndexedDB API

Mon, 09 Sep 2024 00:00:00 GMT

Ich nutze gerne die JavaScript-Bibliothek idb, einen minimalen Wrapper für die IndexedDB API. Ich habe sie schon in mehreren Web-Applikationen verwendet, um Offline-Features bereitzustellen.

Die idb Bibliothek macht es einfach, Daten auf dem Endgerät zu speichern und sie später über ein Promise abzurufen. Sie bietet auch großartige TypeScript-Typen und -Interfaces, welche die Erstellung generischer Logik für die Interaktion mit dem Offline-Speicher unterstützen.

Foto: © RDNE Stock project / pexels.com

Sehen wir uns an, wie wir eine Datenbank mit idb einrichten können. Danach zeige ich euch einige Codebeispiele für wiederverwendbare generische Methoden zum Speichern und Abrufen von Daten.

Die Datenbank einrichten

Als erstes müsst ihr das Schema für die zu speichernden Daten definieren. Hier ist ein einfaches Beispiel:

import { DBSchema } from "idb";

export interface MyAwesomeDB extends DBSchema {
    images: {
        value: MyImageData;
        key: string;
    };
    videos: {
        value: MyVideoData;
        key: string;
    };
}

Ich empfehle euch, die DB-Operationen in einer eigenen Klasse zu bündeln. Diese Klasse hat allein den Zweck, mit der Datenbank zu interagieren. Das macht euren Code einfacher zu lesen und zu verstehen. In einer Angular-Anwendung würde ich eine Serviceklasse wie diese erstellen:

import { IDBPDatabase, openDB } from "idb";

@Injectable()
export class OfflineStorageService {
    private _databaseVersion = 1;
    // The promise returned when opening the IndexedDB with openDB() method.
    private _myDatabase$: Promise<IDBPDatabase<MyAwesomeDB>> | null = null;

    public init(): void {
        this._myDatabase$ = openDB<MyAwesomeDB>(
            "my-awesome-database",
            this._databaseVersion,
            {
                // Initialize objects in database if opened for the first time.
                upgrade: (database, oldVersion) => { ... },
            },
        );

        // Handle success and error case.
        this._myDatabase$.then(
            () => console.log("IndexedDB was successfully opened.""),
            () => this.onOpeningDatabaseFailed(),
        );
    }
}

Daten speichern

Nehmen wir an, ihr wollt mehrere Objekte in einem bestimmten Objektspeicher der Datenbank ablegen. Dazu startet ihr eine Transaktion mit Lese- und Schreibzugriff und speichert dann die Objekte. Für diesen Vorgang könnt ihr eine generische Methode mit den Parametern storeName und items definieren:

import { StoreNames, StoreValue } from "idb";

// Stores all items in the object store named "storeName".
private storeAllItemsInObjectStore<Name extends StoreNames<MyAwesomeDB>>(storeName: Name, items: StoreValue<MyAwesomeDB, Name>[]): void {
    this._myDatabase$?.then((database) => {
        const transaction = database.transaction(storeName, "readwrite");
        items.forEach((item) => transaction.store.add(item));
    });
}

Die Methode verwendet die Typen StoreNames und StoreValue aus der idb-Bibliothek . Diese stellen sicher, dass der an die Methode übergebene Parameter storeName tatsächlich Teil der Datenbank ist und dass die items die erwartete Datenstruktur haben. Hier ist ein Beispiel für die Verwendung dieser generischen Methode:

public storeImages(items: MyImageData[]): void {
    this.storeAllItemsInObjectStore("images", items);
}

Daten abrufen

Beim Abrufen von Daten aus der lokalen Datenbank ziehe ich es vor, das native Promise in ein Observable umzuwandeln. Das erleichtert die Integration des Offline-Speichers in eine auf Observables basierende Application-State-Logik (z.B. NgRx store). Hier ist eine generische Methode, die ein bestimmtes Element aus einem Objektspeicher, verpackt in ein Observable, zurückgibt:

import { StoreKey, StoreNames, StoreValue } from "idb";
import { Observable, catchError, from, of, switchMap } from "rxjs";

// Retrieves the item identified via "itemKey" from the object store named "storeName". Resolves with undefined if no match is found, the database is unavailable, or there's an error.
private getItemFromObjectStore<Name extends StoreNames<MyAwesomeDB>>(
    storeName: Name,
    itemKey: StoreKey<MyAwesomeDB, Name>,
): Observable<StoreValue<MyAwesomeDB, Name> | undefined> {
    if (this._myDatabase$ === null) {
        return of(undefined);
    }

    return from(this._myDatabase$).pipe(
        switchMap((database) => from(database.get(storeName, itemKey))),
        catchError((error) => {
            console.error(error);
            return of(undefined);
        }),
    );
}

Ihr könnt die generische Methode folgendermaßen verwenden:

public getImage(imageId: string): Observable<MyImageData | undefined> {
    return this.getItemFromObjectStore("images", imageId);
}

Viel Spaß mit IndexedDB und der idb Bibliothek!

Native Dialoge und die Popover API — Das solltet ihr wissen

Sat, 15 Jun 2024 00:00:00 GMT

Das moderne Web ist großartig! Wir können leicht barrierefreie, robuste Modal-Dialoge mit dem nativen <dialog> Element erstellen. Ihr möchtet ein Menü oder einen Tooltip über dem anderen Seiteninhalt öffnen? Kein Problem! Das HTML-Attribut popover verwandelt jedes Element in ein Popup.

In den letzten Monaten habe ich einige Dialoge mit dem nativen HTML-Element erstellt. Und im April, als die Popover API endlich browserübergreifend unterstützt wurde, begann ich mit Popover in verschiedenen Projekten zu experimentieren. Mir wurde schnell klar: Diese Web-Features erleichtern uns Web-Entwickler:innen das Leben sehr, aber es gibt auch einige Herausforderungen. Vor allem, wenn man beide Features miteinander kombiniert!

Foto: © Rama Khandkar / pexels.com

Ich werde kurz darauf eingehen, wie Dialoge und Popovers miteinander interagieren. Dann werde ich meine hart erarbeiteten Erkenntnisse mit euch teilen. Wenn ihr mit den Features noch nicht vertraut seid, empfehle ich euch, meine Blogbeiträge „Warum du das native Dialog-Element nutzen solltest“ und „Einfach herausragend! Die neue Popover API und CSS Anchor Positioning“ zu lesen.

Wenn ihr einen Modal-Dialog mit der Methode showModal() öffnet, wird das Dialogfeld zum Top-Layer hinzugefügt und über anderen Seiteninhalten gerendert. Dasselbe geschieht, wenn ihr Popover-Inhalte mit der Methode showPopover() anzeigt.

Was passiert nun, wenn ein Element im Top-Layer bereits geöffnet ist und ihr ein weiteres Element hinzufügt? Die Elemente werden in der Reihenfolge übereinander gelegt, in der sie dem Top-Layer hinzugefügt wurden. Das zuletzt hinzugefügte Element erscheint immer oben. Mit der CSS-Eigenschaft z-index könnt ihr diese Reihenfolge auch nicht verändern. Es zählt allein, wann ein Element dem Top-Layer hinzugefügt wurde.

Um ein Beispiel zu geben: Eine Schaltfläche öffnet ein Menüfeld als Popover. Dieses Menü enthält eine Option, die einen Modal-Dialog öffnet, der über dem Menü-Panel gerendert wird. Dieses Dialogfeld enthält eine Schaltfläche, die ein Tooltip-Popover über dem Dialogfeld öffnet. Und so weiter, und so fort. 😉

Was ihr über Dialoge und Popovers wissen solltet

Animation als Progressive Enhancement

Alles sieht besser aus mit flüssigen Animationen. Es gibt nur ein Problem: Dialoge und Popovers haben display: none gesetzt, wenn sie ausgeblendet sind, und display: block , wenn sie angezeigt werden. Und wir alle wissen, dass man Inhalte nicht von oder zu display: none animieren kann. Richtig? Falsch!

Die neue @starting-style Regel zusammen mit der CSS-Eigenschaft transition-behavior ermöglicht die Animation von Dialogen und Popovers. Ich habe beide Features in meinem Blogbeitrag „Barrierefreie Alerts leicht gemacht mit der Popover API“ ausführlich beschrieben.

Seht euch meine Demo für einen Modal-Dialog mit sanfter Ein- und Ausblend-Animation an. Zum Zeitpunkt des Verfassens dieses Artikels funktioniert das nur in Chrome und Edge:

See the Pen Dialog Animation Demo by Alexander Lehner (@alexlehner86) on CodePen.

Ihr könnt Transitionen für das Dialogfeld (oder Popover) selbst sowie für den Hintergrund definieren. Hier ist der CSS-Code für die Animation des Dialogs:

dialog {
    --duration: 150ms;
    --start-opacity: 0.5;
    --start-scale: scale(0.8);

    /* End values for fade out. */
    opacity: var(--start-opacity);
    transform: var(--start-scale);
    transition:
        opacity var(--duration) ease-out,
        transform var(--duration) cubic-bezier(0, 0, 0.2, 1),
        overlay var(--duration) allow-discrete,
        display var(--duration) allow-discrete;
}

dialog[open] {
    /* End values for fade in; start values for fade out. */
    opacity: 1;
    transform: scale(1);

    @starting-style {
        /* Start values vor fade in. */
        opacity: var(--start-opacity);
        transform: var(--start-scale);
    }
}

Und so animiert ihr den Hintergrund des Dialogs:

/* Styling for backdrop behind the dialog */
dialog::backdrop {
    background: rgb(0 0 0 / 0.32);
    /* End value for fade out. */
    opacity: 0;
    transition: opacity var(--duration),
        overlay var(--duration) allow-discrete,
        display var(--duration) allow-discrete;
}

dialog[open]::backdrop {
    /* End value for fade in; start value for fade out. */
    opacity: 1;
}

/* This starting-style rule cannot be nested inside the above selector because the nesting selector cannot represent pseudo-elements. */
@starting-style {
    dialog[open]::backdrop {
        /* Start value vor fade in. */
        opacity: 0;
    }
}

Aber was ist mit der Browser-Unterstützung? Keine Sorge! Die @starting-style Regel und die Eigenschaft transition-behavior sind perfekte Beispiele für Progressive Enhancement. Wenn ein Browser die neuen Features nicht unterstützt, wird das Dialog- oder Popover-Element trotzdem gerendert, allerdings ohne die Animation.

Den Dialog automatisch schließen bei Klick auf den Hintergrund

Das native <dialog> Element hat einige tolle Funktionen eingebaut:

Wenn ein Modal-Dialog geöffnet wird, setzt der Browser den Fokus auf das erste interaktive Element innerhalb des Dialogs.
Beim Schließen des Modal-Dialogs wird der Fokus wieder auf das Element gesetzt, das den Dialog geöffnet hat.
Benutzer können den Modal-Dialog mit der ESC Taste schließen.

Eine wichtige Funktion wird jedoch standardmäßig nicht unterstützt: Automatisches Schließen des Dialogs, wenn die Nutzer:innen auf den Hintergrund klicken. In meinem ersten Blogbeitrag über Dialoge habe ich folgende Implementierung dieses Light-Dismiss-Verhaltens vorgestellt: Man ermittelt die Koordinaten des Klicks und vergleicht sie mit dem Rechteck des Dialogs.

Vor kurzem bin ich auf eine elegantere Lösung gestoßen: Ihr definiert einen Klick-Event-Listener für den Dialog und überprüft dann den Tag-Namen des Ereignis-Ziels. Hier ist der JavaScript-Code für die Funktion:

function onDialogClick(event) {
    event.stopPropagation();
    if (event.target.tagName === "DIALOG") {
        dialogElementRef.close();
    }
}

Ein Klick auf den Dialog-Hintergrund wird als Klick auf das Dialogelement registriert. Damit dies funktioniert, muss der Inhalt des Dialogs von einem zusätzlichen Element umschlossen werden. Andernfalls würde ein Klick in bestimmte Bereiche des Dialogs diesen auch schließen.

Schaut euch die CodePen-Demo oben an, in der ich dieses benutzerdefinierte Verhalten ebenfalls implementiert habe.

Unlängst habe ich für einen Kunden an einem Webprojekt gearbeitet, das eine Liste von Elementen enthält. Die Nutzer:innen können auf eines der Elemente klicken, um einen Modal-Dialog mit weiteren Details zu öffnen. Dieser Dialog enthält eine Schaltfläche, mit der man das Element zur Favoritenliste hinzufügen kann. Dann wird am unteren Rand des Bildschirms eine Snackbar angezeigt, die auch eine Rückgängig-Schaltfläche enthält.

Als hipper, moderner Webentwickler wollte ich natürlich das <dialog> Element in Kombination mit einem popover Element für die Snackbar verwenden. Nachdem ich alles implementiert hatte, begann ich, die Rückgängig-Funktion zu testen und war verblüfft: Obwohl die Snackbar mit der Rückgängig-Schaltfläche sichtbar war und über dem Modal-Dialog angezeigt wurde, konnte ich nicht mit ihr interagieren. Ich so: „Was zum Teufel ist hier los?!“

Nach etwas Recherche habe ich die Ursache des Problems gefunden. Aber bevor ich euch die Lösung verrate, seht euch diese Demo mit einer Minimalversion des oben beschriebenen Webprojekts an. Der Dialog enthält zwei Schaltflächen: Die erste öffnet eine Snackbar, mit der ihr nicht interagieren könnt. Die zweite Schaltfläche öffnet eine Snackbar mit einer funktionierenden Rückgängig-Taste. Könnt ihr den Unterschied erkennen?

See the Pen Dialog with Popover Demo by Alexander Lehner (@alexlehner86) on CodePen.

Ich erkläre euch was los ist: Im Allgemeinen hat die Position eines popover Elements im DOM keinen Einfluss auf seine Sichtbarkeit. Wenn ihr das Popover einblendet, fügt der Browser es dem Top-Layer hinzu und es erscheint über allen anderen Inhalten. Aber nur weil ihr etwas sehen könnt, heißt das nicht, dass ihr damit interagieren könnt. Die Antwort findet sich in der Beschreibung der Methode showModal():

The showModal() method of the HTMLDialogElement interface displays the dialog as a modal […]. Interaction outside the dialog is blocked and the content outside it is rendered inert.

Das heißt, wenn ihr das popover Element für die Snackbar außerhalb des Dialogs platziert, wird es inaktiv gemacht. Alle Eingabe-Events der Nutzer:innen für das Element und seine Inhalte werden ignoriert. Was könnt ihr also tun? Platziert das Popover-Element einfach innerhalb des Dialogelements. Jetzt betrachtet der Browser es als Teil des Dialoginhalts und macht es nicht mehr inaktiv.

Manuelle Popovers innerhalb von Dialogen solltet ihr immer schließen

Eine letzte Bemerkung zu manuellen Popovers, die in einem Modal-Dialog eingebettet sind. Wenn ihr den Dialog schließt, dann schließt auch immer das Popover mit der Methode hidePopover() . Andernfalls wäre das Popover zwar nicht sichtbar, aber immer noch offen und würde im Top-Layer verbleiben.

Wenn ihr nun den Dialog erneut öffnet, wird er über dem Popover im Top-Layer platziert. Selbst wenn ihr also versucht, das Popover erneut mit der Methode showPopover() zu öffnen, wird nichts passieren! Das Popover ist bereits geöffnet und befindet sich im Top-Layer unterhalb des Modal-Dialogs. Was für ein Schlamassel!

Fazit

Das native <dialog> Element und das popover Attribut sind sehr mächtige und praktische Features. Aber es gibt auch einige Besonderheiten. Ich hoffe, meine Erkenntnisse helfen euch dabei, diese großartigen Features in euren eigenen Projekten zu nutzen. Viel Spaß beim Coden! 😊

Update am 28.03.2026

Verwendet das neue closedby Attribut anstelle von JavaScript, um Light-Dismiss-Verhalten zu implementieren. Das Feature sollte bis Ende des Jahres browserübergreifend unterstützt werden. Erfahrt mehr in meinem neuen Artikel „Dialoge mit dem closedby-Attribut aufwerten“.

Wird das CSS Scope Feature die View Encapsulation von Angular ersetzen?

Thu, 02 May 2024 00:00:00 GMT

Entwickler:innen sind oft bequem. Wir lieben Tools und Features, die uns das Leben leichter machen. Das gilt insbesondere für die Gestaltung von Webinhalten mit CSS.

Eine große Herausforderung ist die Definition von CSS-Regeln, die nur bestimmte Bereiche stylen, ohne allzu spezifische Selektoren zu schreiben, die nur schwer zu überschreiben sind. Außerdem sollte man Selektoren nicht zu eng an die DOM-Struktur koppeln, da diese anfällig für Änderungen ist.

Verschiedene JavaScript-Frameworks haben unterschiedliche Lösungen für dieses Problem entwickelt: React verwendet CSS-Module, die das Scoping von CSS ermöglichen, indem sie automatisch einen eindeutigen Klassennamen für Komponenten-Styles erstellen. In Angular werden die Styles mit benutzerdefinierten HTML-Attributen gekapselt, so dass sie sich nicht auf den Rest der Applikation auswirken.

Foto: © cottonbro studio / pexels.com

Aber warum ist das Scoping von Styles nicht allein mit CSS möglich? Mittlerweile geht das! Mithilfe der neuen CSS-Regel @scope können wir Styles auf bestimmte DOM-Abschnitte beschränken. Ihr könnt sogar untere Grenzen für den Geltungsbereich festlegen und einen sogenannten Donut Scope schaffen.

Ich erkläre euch die Grundlagen dieses neuen Features und erprobe ihre Anwendung in einer Angular-Demo.

Demo: CSS Scope vs View Encapsulation

Meine Demo-Anwendung wurde mit Angular 17 erstellt. Sie enthält einen Header und einen Hauptabschnitt mit einigen Absätzen, Links und mehreren Rezeptblöcken.

Die Komponente app-recipe-card (gelber Hintergrund) verwendet die neue Scope-Funktion, um nur die HTML-Elemente in ihrem eigenen Teilbaum anzusprechen. Wichtig: Zum Zeitpunkt des Verfassens dieses Artikels funktioniert Scope nur in Chrome, Edge und Safari!

Zum Vergleich habe ich auch die Komponente app-recipe-card-old (blauer Hintergrund) definiert, welche die Standard-View-Encapsulation von Angular verwendet. Untersucht die Elemente mit den Entwicklerwerkzeugen eures Browsers.

Wie die Demo zeigt, können wir mit CSS-Scope einfache Selektoren mit geringer Spezifität und ohne zusätzliche Klassennamen schreiben. Schauen wir uns nun genauer an, wie das Ganze funktioniert.

Die Grundlagen von CSS-Scoping

Das neue CSS-Scope-Feature ist im Modul CSS Cascading and Inheritance Level 6 definiert, das zum Zeitpunkt des Verfassens dieses Beitrags noch ein Arbeitsentwurf ist. Es besagt:

A scope is a subtree or fragment of a document, which can be used by selectors for more targeted matching. A scope is formed by determining: The scoping root node, which acts as the upper bound of the scope, and optionally the scoping limit elements, which act as the lower bounds.

Das heißt, ihr müsst das Root-Element des DOM-Teilbaums definieren, auf den ihr eure Styles anwenden möchtet. Optional könnt ihr auch innere Elemente auflisten, welche die untere Grenze des Scopes darstellen.

Die @scope CSS-Regel

Die app-recipe-card Komponente in meiner Demo enthält Überschriften, Absätze und eine ungeordnete Liste. Wir stylen sie mit dem folgenden CSS-Code:

@scope (app-recipe-card) {
    h3 {
        color: var(--highlight-color);
        font-size: 1.3rem;
    }

    p {
        margin-block: 0 1em;
    }

    ul {
        list-style: square;
        margin: 0;
        padding-inline-start: 1.25rem;
    }

    li::marker{
        color: var(--highlight-color);
    }
}

Der obige @scope Block definiert app-recipe-card als die Scoping Root , welche die obere Grenze des Teilbaums bestimmt, auf den wir abzielen. Nun beziehen sich alle enthaltenen Style-Regeln, wie h3 { … } , nur auf diesen begrenzten Abschnitt des DOM.

Einen Donut Scope erzeugen

Manchmal reicht es nicht aus, nur einen Scoping-Root zu setzen. In Angular und React verschachteln wir meistens Komponenten innerhalb anderer Komponenten, um komplexe Benutzeroberflächen zu erstellen. Wie können wir sicherstellen, dass sich das Styling der Eltern-Komponente nicht auf ihre Kind-Komponenten auswirkt?

Die @scope Regel akzeptiert auch ein Scoping Limit , das die untere Begrenzung bestimmt. In meiner Demo sind die Rezeptblöcke in der Komponente app-recipes-list eingebunden. Hier ist ein Teil des CSS-Codes:

@scope (app-recipes-list) to (app-recipe-card, app-recipe-card-old) {
    p {
        font-style: italic;
    }
}

Auf diese Weise werden nur die von der übergeordneten Komponente app-recipes-list definierten Absätze kursiv gesetzt. Die Absätze innerhalb der untergeordneten Komponenten app-recipe-card und app-recipe-card-old sind davon nicht betroffen.

Diese Art von Scoping – mit einer oberen und unteren Grenze – wird als Donut Scope bezeichnet. Ich kann euch den Artikel “Limit the reach of your selectors with the CSS @scope at-rule” von Bramus Van Damme empfehlen. Er enthält tolle Visualisierungen verschiedener Scope-Szenarien.

Der :scope Selektor

Eine weitere nützliche Funktion ist der Selektor :scope . Damit könnt ihr innerhalb des @scope Blocks auf das Root-Element des Scopings selbst abzielen. Hier ist ein Beispiel aus meiner Demo:

@scope (app-recipe-card) {
    :scope {
        --highlight-color: rgb(194 34 2);
        display: block;
        background: lightgoldenrodyellow;
        color: black;
        padding: 1rem;
    }
}

Browser-Unterstützung

Wie bitte? Ihr findet das Scope-Feature total genial und wollt es sofort in allen Projekten einsetzen? Leider müsst ihr euch noch etwas gedulden.

Im Moment wird die @scope Regel nur von Chrome 118+, Edge 118+ und Safari 17.4+ unterstützt. Firefox unterstützt das Feature noch nicht, aber Mozilla arbeitet aktiv an der Implementierung. Hoffen wir auf eine browserübergreifende Unterstützung im Laufe des Jahres!

Wie ihr @scope in einer Angular-Applikation verwendet

In Angular sind Komponenten-Styles standardmäßig gekapselt. Das Framework erstellt eigene HTML-Attribute wie _ngcontent-pmm-6 , fügt sie in die generierten HTML-Elemente ein und ändert die CSS-Selektoren der Komponente so, dass sie nur auf die View der Komponente angewendet werden.

Wenn ihr stattdessen die @scope Regel verwenden möchtet, müsst ihr View Encapsulation für jede Komponente manuell deaktivieren.

Die View Encapsulation abschalten

Um die View Encapsulation zu deaktivieren, müsst ihr im Dekorator der Komponente für encapsulation den Wert ViewEncapsulation.None setzen. Hier ein Beispiel aus meiner Demo:

@Component({
    selector: 'app-recipe-card',
    standalone: true,
    templateUrl: './recipe-card.component.html',
    styleUrl: './recipe-card.component.css',
    encapsulation: ViewEncapsulation.None,
})
export class RecipeCardComponent {
    @Input({ required: true }) recipe!: Recipe;
}

Jetzt werden eure CSS-Selektoren nicht mehr mit eigenen Attributen erweitert und die Styles der Komponente werden global angewendet. Ihr solltet nun die @scope Regel verwenden, um die Styles zu kapseln.

Vergleich des HTML- und CSS-Outputs

Wie wir gesehen haben, erfordert der Einsatz von CSS-Scope ein wenig Aufwand bei der Erstellung einer Komponente. Es ist komfortabler, einfach die Standard-View-Encapsulation von Angular zu verwenden.

Aber ich wage zu behaupten, dass die Vorteile von CSS-Scope diesen kleinen Aufwand rechtfertigen. Werfen wir einen Blick auf den HTML- und CSS-Code, der für die Komponente app-recipe-card in meiner Demo erzeugt wird:

<app-recipe-card>
    <h3>Pizza Margherita</h3>
    <p>The best pizza in town!</p>
    <h4>Ingredients</h4>
    <ul>
        <li>Cutting edge CSS features!</li>
        /* More list items */
    </ul>
</app-recipe-card>

/* Generated CSS code (excerpt) */
@scope (app-recipe-card) {
    h3 {
        color: var(--highlight-color);
        font-size: 1.3rem;
    }
}

Vergleichen wir das mit dem HTML- und CSS-Code, der für die Komponente app-recipe-card-old erzeugt wird:

<app-recipe-card-old _nghost-ng-c2291633987>
    <h3 _ngcontent-ng-c2291633987>Pizza Margherita (Old)</h3>
    <p _ngcontent-ng-c2291633987>The (second) best pizza in town!</p>
    <h4 _ngcontent-ng-c2291633987>Ingredients</h4>
    <ul _ngcontent-ng-c2291633987>
        <li _ngcontent-ng-c2291633987>DOM cluttering view encapsulation</li>
        /* More list items */
    </ul>
</app-recipe-card-old>

/* Generated CSS code (excerpt) */
h3[_ngcontent-ng-c2291633987] {
    color: var(--highlight-color);
    font-size: 1.3rem;
}

Stellt euch nun vor, ihr müsst eure Applikation debuggen. Die Rezeptblöcke werden nicht richtig gerendert. Ihr öffnet die Entwicklertools eures Browsers und untersucht das DOM und die angewandten Styles. Welcher Code wäre leichter zu lesen und zu verstehen?

Ich glaube, dass mich die unzähligen _ngcontent-ng-c2291633987 Attribute sehr ablenken würden. Es würde mir leichter fallen, den @scope (app-recipe-card) { h3 } Selektor zu verstehen als den h3[_ngcontent-ng-c2291633987] Selektor. 😉

Fazit

Zurück zu meiner ursprüngliche Frage: Wird das CSS Scope Feature die View Encapsulation von Angular ersetzen? Vielleicht. Ich weiß es wirklich nicht. Im Idealfall wird das Angular-Team seinen Standard-Mechanismus zur View Encapsulation anpassen und die @scope Regel verwenden.

Unabhängig davon, was das Angular-Team tut: Es ist jetzt schon sehr einfach, die View Encapsulation für eine Komponente abzuschalten und die Styles innerhalb eines @scope Blocks zu definieren. Der generierte HTML- und CSS-Code ist besser lesbar und viel einfacher zu debuggen. Außerdem verringert es die Dateigröße der Webanwendung.

Für mich steht fest: Sobald CSS-Scope browserübergreifend unterstützt wird, werde ich es in meinen Projekten einsetzen. 🤩

Update am 24.02.2026

Natives CSS Scope wird nun browserübergreifend unterstützt. Erfahrt mehr über dieses großartige Feature in meinem neuen Artikel „Best Practices für CSS Scope in Angular-Applikationen”.

Verschiedene Farbthemen mit einem zweifarbigen Fokusindikator unterstützen

Thu, 21 Mar 2024 00:00:00 GMT

Benutzt ihr die Tastatur, um im Internet zu surfen? Wenn ja, dann werdet ihr es zu schätzen wissen, wenn der Fokusindikator deutlich sichtbar ist. Dieses Barrierefreiheits-Feature ist besonders wichtig für Menschen mit motorischen Beeinträchtigungen, welche die Tastatur statt der Maus nutzen, um auf einer Webseite zu navigieren.

Ich empfehle generell, die Pseudoklasse :focus-visible zu verwenden, um eigene Fokusindikatoren zu definieren. Weitere Informationen findet ihr in meinem Artikel „Gestalte deutlich sichtbaren Tastaturfokus mit :focus-visible“. Aber wie berücksichtigt man verschiedene Farbthemen und den Dark Mode?

Foto: © cottonbro / pexels.com

Die elegante Lösung lautet: Definiert einen zweifarbigen Fokusindikator, der einen ausreichenden Kontrast zu jedem einfarbigen Hintergrund aufweist. Die Technik C40 des W3C empfiehlt diese Lösung als eine Möglichkeit, die WCAG-Kriterien 2.4.7: Fokus sichtbar und 2.4.13: Fokus-Erscheinungsbild zu erfüllen.

Demo: Zweifarbiger Fokusindikator

Hier ist meine Demo einer barrierefreien zweifarbigen Fokusanzeige. Mit der Checkbox „Dark Mode“ könnt ihr zwischen hellem und dunklem Modus umschalten. Fokussiert die Schaltfläche und den Link mit der Tab-Taste und beobachtet den Fokusindikator:

Öffne das Code-Beispiel Two-color focus indicator von Alexander Lehner (@alexlehner86) auf CodePen.

Wie funktioniert das Ganze?

Die (nicht allzu) geheimen CSS-Zutaten

Um den zweifarbigen Fokusindikator zu erstellen, kombiniert einfach die CSS-Eigenschaften outline und box-shadow , um eine helle und dunkle Linie um das fokussierte Element zu zeichnen.

:is(a[href], button):focus-visible {
    /* inner indicator */
    outline: 3px #fff solid;
    outline-offset: 0;
    /* outer indicator */
    box-shadow: 0 0 0 5px #000;
}

Eine der Linien bietet immer einen ausreichenden Kontrast zur aktuellen Hintergrundfarbe. In meiner Demo habe ich eine einfache Kombination aus reinem Weiß und Schwarz verwendet. Ihr könnt aber auch andere Farben verwenden, wie die W3C-Technik erklärt:

As long as the two indicator colors have a contrast ratio of at least 9:1 with each other, at least one of the two colors is guaranteed to meet 3:1 contrast with any solid background color.

Der zweifarbige Fokusindikator funktioniert sogar im Forced Colors Modus. Wenn ihr mit diesem Feature nicht vertraut seid, lest meinen Artikel „CSS-Tricks für bessere Sichtbarkeit im Forced Colors Modus“.

Optimiert eure Designs mit Barrierefreiheits-Anmerkungen

Mon, 26 Feb 2024 00:00:00 GMT

Barrierefreiheit ist ein Gemeinschaftsprojekt. Damit eine Website für alle Nutzer:innen gut bedienbar ist, sollte Accessibility im gesamten Entwicklungsprozess berücksichtigt werden. Wie können Designer:innen am besten dazu beitragen?

Als Web-Entwickler und Requirements Engineer arbeite ich eng mit UI/UX-Designer:innen zusammen. Auf Basis der Anforderungen erarbeiten sie Entwürfe und Prototypen für die Benutzeroberfläche, die Entwickler:innen später implementieren. Diese Arbeit ist oft sehr visuell dominiert: Welche Farben kommen zum Einsatz? Wie berücksichtigen wir die Corporate Identity des Kunden optimal?

Foto: © Amina Filkins / pexels.com

Bei Barrierefreiheit denken Designer:innen daher oft an die Verwendung von Farbe und ausreichende Kontrastverhältnisse. Doch Designs können noch mehr: Barrierefreiheits-Anmerkungen vermitteln wichtige Informationen über die Struktur und Semantik der Website.

Es gibt verschiedene Programme zum Erstellen von Prototypen. Meine Kolleg:innen arbeiten gerne mit Figma, einer kollaborativen Plattform für UI/UX Design.

Um dort Überlegungen zur Barrierefreiheit zu dokumentieren, können Designer:innen selbst passende Elemente definieren oder mit fertigen Bibliotheken wie dem A11y Annotation Kit arbeiten. Dieses bietet eine breite Palette an Tools, um semantische Informationen im Design auszuzeichnen. Sehen wir uns ein paar davon näher an.

Überschriften auszeichnen

Sehende Nutzer:innen scannen meist instinktiv eine Website nach Überschriften, um das zu finden, wonach sie suchen. Auch für blinde und sehbeeinträchtigte Nutzer:innen sind Überschriften von zentraler Bedeutung: Laut der letzten Umfrage von WebAIM sagen 9 von 10 Screenreader-Nutzer:innen, dass sinnvoll eingesetzte Überschriften-Ebenen für sie sehr oder eher nützlich seien.

Überschriften müssen semantisch korrekt ausgezeichnet werden, damit Screenreader sie als Überschrift ankündigen können. Bei Websites passiert das mit den HTML-Tags h1 bis h6 . Nutzer:innen können dann etwa mit Tastaturkürzel von Überschrift zu Überschrift springen und sich somit schnell einen Überblick verschaffen.

Designer:innen sollten sich daher möglichst früh überlegen, wie der Inhalt einer Seite sinnvoll mit Überschriften strukturiert werden kann. Im finalen Design sollten alle Überschriften sowie ihre Ebene (1 bis 6) markiert sein. Hier ein Beispiel:

Screenshot: © Alexander Lehner

Zwei Fragen werden euch dabei ständig begleiten: Was macht eine Überschrift zur Überschrift? Welche Überschriften-Hierarchie ist sinnvoll? Um euch das Leben etwas zu erleichtern, hier ein paar Tipps:

Überschriften strukturieren den Inhalt der Seite: Eine Überschrift leitet einen neuen Inhaltsabschnitt ein und sollte diesen beschreiben. Große Schrift, Fettdruck oder eine eigene Zeile machen einen Text nicht automatisch zur Überschrift!
Überspringt niemals eine Überschriften-Ebene! Die wichtigste Überschrift sollte als h1 ausgezeichnet werden, danach folgt h2 , h3 , usw. Überschriften mit gleichem oder höherem Rang beginnen einen neuen Abschnitt. Überschriften mit niedrigerem Rang beginnen neue Unterabschnitte.
Styling und Semantik trennen: Die visuelle Darstellung einer Überschrift sollte niemals darüber entscheiden, welche Überschriften-Ebene verwendet wird! Mein Tipp: Definiert eigene Überschriften-Klassen wie heading-sm , heading-md , heading-lg , usw. Somit könnt ihr Überschriften unabhängig von ihrer Position in der Hierarchie stylen.
In manchen Fällen kann auch eine visuell verborgene Überschrift Sinn machen, um die Seitenstruktur zu verbessern.
Seid kreativ! Eine perfekte Überschriften-Struktur ist harte Arbeit. Macht einen Entwurf. Holt euch Feedback von außen. Verfeinert eure Designs schrittweise. Es ist noch kein Meister vom Himmel gefallen 😉

Alternativtext für Bilder

Fehlende oder schlechte Alternativtexte zählen zu den häufigsten Barrieren auf Websites. Laut der Studie WebAIM Million 2023 weisen über ein Drittel der Bilder auf beliebten Websites einen fehlenden, fragwürdigen oder sich wiederholenden Alternativtext auf.

Design-Prototypen sollten daher Alternativtexte für Bildinhalte definieren, so dass visuell vermittelte Informationen auch für Screenreader-Nutzer:innen zugänglich sind. Hierbei solltet ihr folgende Punkte beachten:

Funktionale Bilder: Wenn ein Button oder Link nur ein Bild oder Icon enthält, dann muss der Alternativtext den Zweck des Elements beschreiben.
Informative Bilder: Das sind Bilder, die relevante Informationen vermitteln. Hier sollte das Design einen konkreten Alternativtext vorgeben oder zumindest definieren, dass ein sinnvoller Alternativtext definiert werden muss.
Dekorative Bilder: Wenn Bilder nur die Seite aufhübschen sollen, dann müssen sie vor assistiven Technologien verborgen werden. Die Barrierefreiheits-Anmerkung kann dies mit alt="" darstellen.

Screenshot: © Alexander Lehner

Weitere Infos sowie einige Negativbeispiele findet ihr in meinem Artikel „Ein Bild sagt mehr als tausend Worte – außer du bist blind!“.

Button oder Link?

Links sind unterstrichen. Buttons sind klickbare Boxen. Oder? 🤔

Visuell sind Links und Buttons oft nicht klar voneinander zu unterscheiden. In manchen Designs sehen Links wie klassische Buttons aus, und umgekehrt. Für sehende Nutzer:innen ist das meistens kein Problem: Hauptsache sie verstehen, dass es sich um interaktive Elemente handelt.

Für assistive Technologien ist die semantische Rolle der Elemente jedoch besonders wichtig. Je nachdem, ob der Screenreader ein Element als Link oder Button ankündigt, erwarten Nutzer:innen ein anderes Verhalten:

Links führen zu einer neuen Ressource, z.B. einer anderen Website oder einem anderen Abschnitt auf derselben Seite. Man verlässt den aktuellen Kontext.
Buttons lösen hingegen eine Aktion im selben Kontext aus, z.B. ein Popup-Menü oder das Abspielen eines Videos.

Das heißt: Das Aussehen ist zweitrangig. Die Funktion des Elements ist entscheidend. Ich empfehle euch den Artikel „Links vs. Buttons in Modern Web Applications“, der noch tiefer in das Thema eintaucht.

Also liebe Designer: Markiert Links und Buttons entsprechend ihrer Funktion. Und erklärt am besten in der Legende des Designs, dass Entwicklerinnen dafür native Elemente verwenden sollten. Also a für Links und button für Buttons. Eure Nutzer:innen werden es euch danken! 🤩

Barrierefreie Alerts leicht gemacht mit der Popover API

Sat, 06 Jan 2024 00:00:00 GMT

Benachrichtigungen (Alerts) sind ein gängiges Element auf Websites. Sie lenken die Aufmerksamkeit der Nutzer:innen auf eine wichtige Nachricht, ohne den aktuellen Workflow zu unterbrechen. Zum Beispiel: „Artikel wurde dem Warenkorb hinzugefügt“ oder „Login ist fehlgeschlagen: Prüfen Sie Benutzernamen/Kennwort“ .

Dank der neuen Popover API und der neuen Möglichkeiten von CSS-Animationen wird es bald viel einfacher werden, barrierefreie und schön animierte Alerts zu erstellen. Ich habe eine Demo vorbereitet, die ihr ausprobieren könnt.

Foto: © Thirdman / pexels.com

Falls ihr mit der Popover API noch nicht vertraut seid, solltet ihr zuerst meinen Artikel „Einfach herausragend! Die neue Popover API und CSS Anchor Positioning“ lesen. Ich werde hier die Grundlagen nicht wiederholen und mich stattdessen auf den speziellen Anwendungsfall konzentrieren.

Barrierefreie Alerts Demo

Hier ist meine Demo für barrierefreie Alerts mit der Popover API. Ihr könnt sowohl die Nachricht als auch die Dauer und Position der Meldung anpassen. Probiert es aus:

Das Alert erscheint über allen anderen Elementen der Seite und wird von Screenreadern automatisch vorgelesen. Ich habe dieses Verhalten mit JAWS, NVDA, TalkBack und VoiceOver. getestet. Die aktuelle Tätigkeit des Nutzers wird nicht unterbrochen und das Alert verschwindet nach einiger Zeit.

Details der Implementierung

Schauen wir uns nun die verschiedenen Bausteine an, mit denen ich die barrierefreien, animierten Alerts gestaltet habe.

Dynamisches HTML erzeugen

Ich habe einen Angular-Service implementiert, der das Popover-Element mit JavaScript-Methoden wie createElement() und appendChild() dynamisch erzeugt. Im Demo-Code findet ihr weitere Details. Ihr müsst nicht mit dem Angular-Framework vertraut sein, um das Wichtigste zu verstehen.

Der folgende HTML-Code wird einem Container am Ende des body-Elements hinzugefügt:

<div popover="manual" role="alert" class="alert top-right">
    This is a very important message
</div>

Das popover Attribut verwandelt das div Element in ein Popover, das zunächst vom Browser ausgeblendet wird. Wir zeigen das Popover-Alert an, indem wir die Methode showPopover() des Elements aufrufen.

Mittels popover=“manual” definieren wir einen manuellen Popover-Status für das Element. Damit verhindern wir Light-Dismiss, also das automatische Schließen des Popovers, wenn Nutzer:innen mit anderen Elementen auf der Seite interagieren. Stattdessen schließen wir das Popover programmatisch mit der Methode hidePopover().

Semantisches Markup

Setzt role=“alert” auf das Popover-Element, um es als Alert zu definieren. Das Dokument Accessible Rich Internet Applications (WAI-ARIA) 1.2 beschreibt die Alert-Rolle wie folgt:

A type of live region with important, and usually time-sensitive, information. […] Alerts are assertive live regions, which means they cause immediate notification for assistive technology users.

Im Allgemeinen verwenden wir ARIA-Live-Regionen, um dynamische Inhaltsänderungen zu kommunizieren. Das Setzen von role=“alert” hat denselben Effekt wie das Setzen von aria-live=“assertive” und aria-atomic=“true” . Das heißt, Screenreader lesen die Nachricht des Alerts sofort vor, sobald das Popover angezeigt wird.

Animation

Jetzt machen wir noch den visuellen Feinschliff und fügen dem Popover-Element eine Animation hinzu. Es gibt aber ein Problem: Popover werden anfangs durch display: none ausgeblendet. Was für ein Albtraum! Das erzeugt gleich zwei Hindernisse:

Ein Element mit dem Wert none für die display Eigenschaft wird nicht gerendert. Daher hat es keine berechneten Werte für die verschiedenen CSS-Eigenschaften wie z.B. opacity . Wenn es keinen berechneten Wert gibt, haben wir keinen Ausgangspunkt für die transition .
Das gleiche Problem besteht auch in umgekehrter Richtung: Wenn die Eigenschaft display auf none gesetzt wird, wird das Element sofort aus dem gerenderten HTML-Dokument entfernt, ohne dass der transition Effekt ausgelöst wird.

Glücklicherweise bietet die CSS Transitions Level 2 Spezifikation neue Möglichkeiten für CSS-Übergänge. Sie definiert die neue @starting-style Regel:

The @starting-style rule is a grouping rule. The style rules inside it are used to establish styles to transition from, if the previous style change event did not establish a before-change style for the element whose styles are being computed.

So können wir einen Ausgangszustand für den Übergang definieren, wenn sich der Anzeigetyp von none zu einem anderen Typ ändert.

Der zweite Puzzlestein ist die neue transition-behavior Eigenschaft und ihr Wert allow-discrete :

The transition-behavior property specifies whether transitions will be started or not for discrete properties.

Diskrete Eigenschaften haben Werte, die nicht interpoliert werden können. Dies ist z.B. bei den Eigenschaften display und overlay der Fall. Um Übergänge für sie zuzulassen, müssen wir den Wert allow-discrete definieren. Ihr könnt den Wert für transition-behavior auch als Teil einer Shorthand-Deklaration angeben.

Wie passt das nun alles zusammen? Meine Demo enthält die Position “top-right”, bei der das Alert langsam sichtbar wird und von rechts in den sichtbaren Bereich rutscht. Hier ist der CSS-Code für den Übergang:

.alert[popover].top-right {
    /* Final state of the exit animation */
    opacity: 0;
    transform: translateX(100%);

    transition: opacity 0.5s,
        transform 0.5s,
        overlay 0.5s allow-discrete,
        display 0.5s allow-discrete;
}

.alert[popover].top-right:popover-open {
    /* Final state of the show animation */
    opacity: 1;
    transform: translateX(0);
}

/* Needs to be after the previous [popover]:popover-open rule to take effect, as the specificity is the same */
@starting-style {
    .alert[popover].top-right:popover-open {
        opacity: 0;
        transform: translateX(100%);
    }
}

Im obigen Beispiel werden die Eigenschaften opacity und transform für die Dauer einer halben Sekunde animiert. Wir möchten, dass der Browser den animierten Inhalt anzeigt und das Popover im Top Layer bleibt, solange die Animation läuft. Um dies zu erreichen, definieren wir auch overlay 0.5s allow-discrete und display 0.5s allow-discrete .

Achtung! Diese Funktionen sind experimentell und können sich in Zukunft ändern!

Browser-Unterstützung

Das popover Attribut wird bereits von allen wichtigen Browsern unterstützt. Zum Zeitpunkt der Erstellung dieses Artikels hatte Firefox die Funktion nur in seinen experimentellen Nightly-Builds aktiviert. Ich erwarte aber, dass Firefox die Funktion bald releast.

Die neuen Funktionen für transition werden derzeit nur von Chrome und Edge unterstützt. Ich hoffe, dass sie Teil der Interop 2024 sein werden und bis Ende des Jahres eine browserübergreifende Kompatibilität erreichen.

Nützliche Links

Der PDF Accessibility Checker: Stärken und Schwächen

Wed, 06 Dec 2023 00:00:00 GMT

Von der Rechnung beim Online-Shoppen bis zum amtlichen Bescheid: PDF-Dokumente sind heute allgegenwärtig. Zahlreiche Unternehmen und Organisation nutzen das Dateiformat, um Informationen darzustellen und auszutauschen. Doch sind PDFs auch barrierefrei? Die kurze Antwort: Nicht automatisch!

Foto: © ANTONI SHKRABA production / pexels.com

Der Standard PDF/UA wurde 2012 veröffentlicht. Dieser definiert, wie ein PDF-Dokument die Anforderungen an Barrierefreiheit erfüllen kann. Leider werden auch heute noch zahlreiche Dokumente erstellt, welche diesen Standard nicht einhalten.

Damit euch das nicht passiert, solltet ihr eure PDFs auf Barrierefreiheit prüfen. Diese Prüfung beginnt am besten immer mit dem PDF Accessibility Checker, kurz PAC. Dieses kostenlose Standardtool ist vor kurzem in der Version 2024 erschienen: https://pac.pdf-accessibility.org/de

Ich nutze das Tool schon seit einigen Jahren und weiß seine Stärken zu schätzen. Allerdings ersetzt das automatisierte Tool keine manuelle Prüfung, etwa mit Screenreader und Tastatur. Daher gebe ich euch einen kurzen Überblick zu den Stärken und Schwächen des PDF Accessibility Checkers.

Stärken des Prüftools

Der PAC ist ein Tool zur automatisierten Prüfung von PDF-Dokumenten auf Barrierefreiheit, gemäß dem Standard PDF/UA (DIN/ISO 14289–1). Darüber hinaus werden relevante Punkte der Web Content Accessibility Guidelines (WCAG) sowie zusätzliche Qualitätsmerkmale geprüft.

Dabei kann der PAC u.a. folgende Barrieren automatisch erkennen:

Für das PDF-Dokument ist kein Titel gesetzt.
Die Sprache des Dokuments ist nicht definiert.
Die Inhalte des PDF-Dokuments sind nicht getaggt.
Ein Bild verfügt über keinen Alternativtext.

Weiters vermittelt das Tool im WCAG-Reiter auch transparent, welche Richtlinien es überprüft und welche nicht. Richtlinien wie z.B. „2.1 Per Tastatur zugänglich“ und „3.2 Vorhersehbar“ können nur manuell geprüft werden.

Schwächen des Prüftools

Der PDF Accessibility Checker kann den Code eines PDF-Dokuments nach gewissen Regeln prüfen. Aber es kann den Inhalt des Dokuments nicht inhaltlich verstehen und interpretieren. Das können automatisierte Prüftools generell nicht.

Um die Schwächen des Tools aufzuzeigen, habe ich ein Experiment durchgeführt: Wie viele Barrieren kann ich in ein PDF-Dokument einbauen, ohne dass der PAC Alarm schlägt? Mein Test-Dokument besteht aus mehreren Überschriften, Fließtext und einem Bild. Ihr könnt das Dokument herunterladen und selbst überprüfen.

Sehen wir uns nun die einzelnen Barrieren im Detail an.

Kein aussagekräftiger Titel

Mein Test-Dokument hat den Titel „Ein schöner Titel“ . PAC gibt sich damit zufrieden. Wenn jedoch Screenreader-Nutzer:innen diesen Titel zu hören bekommen, werden sie nicht viel damit anfangen können.

Der Titel einer Webseite oder eines Dokuments ist die erste Information, auf die Nutzer:innen stoßen. Der Titel sollte den Inhalt beschreiben und den Nutzer:innen Orientierung bieten. Das hierbei relevante WCAG-Erfolgskriterium 2.4.2 besagt:

Webseiten haben einen Titel, der Thema oder Zweck beschreibt.

Daher muss bei einer manuellen Prüfung ein Mensch einschätzen, ob der gesetzte Titel des PDF-Dokuments aussagekräftig genug ist.

Falsch getaggte Überschriften

Wie PAC korrekt feststellt, ist der gesamte Inhalt meines Test-Dokuments getaggt. Das bedeutet: Für jedes Element im PDF ist definiert, welche Art von Inhalt es darstellt. Diese Information ist u.a. für Screenreader-Nutzer:innen essenziell, um den Inhalt korrekt erfassen und schnell im Dokument navigieren zu können.

Allerdings habe ich PAC reingelegt: Alle Überschriften, wie z.B. „Das ist eine wunderschöne Überschrift“ , sind mit dem <P> Tag als Fließtext ausgezeichnet. Während sehende Menschen die Überschriften visuell als solche erfassen können, ist diese Information semantisch nicht erfasst. Das WCAG-Erfolgskriterium 1.3.1 fordert:

Informationen, Struktur und Beziehungen, die über die Darstellung vermittelt werden, können durch Software bestimmt werden oder stehen in Textform zur Verfügung.

Automatisierte Tools wie der PAC können nicht einschätzen, was als Überschrift getaggt sein sollte und was nicht. Daher sollte sich ein Mensch das PDF-Dokument von einem Screenreader vorlesen lassen. Zusätzlich bietet auch PAC selbst die nützliche Screenreader-Vorschau-Funktion, welche die Tagging-Struktur visualisiert.

Keine logische Lesereihenfolge

Seht euch den Screenshot oben nochmal genau an. Na, fällt euch was auf? Genau, das Bild befindet sich visuell an einer anderen Stelle als in der Screenreader-Vorschau.

In einem getaggten PDF wird die Lesereihenfolge separat gespeichert. Besonders bei Dokumenten mit komplexen Layouts kann damit eine logische Lesereihenfolge definiert werden. Wenn etwa blinde Nutzer:innen mit Screenreader durch das Dokument navigieren, folgt der virtuelle Cursor des Screenreaders dieser Reihenfolge.

Daher definiert das WCAG-Erfolgskriterium 1.3.2 folgende Bedingung für Barrierefreiheit:

Wenn die Reihenfolge, in der Inhalte präsentiert werden, sich auf deren Bedeutung auswirkt, kann die korrekte Leseabfolge durch Software bestimmt werden.

Bei einer manuellen Prüfung sollte daher ein Mensch mit aktiviertem Screenreader sequenziell durch das Dokument navigieren und dabei überlegen, ob die Abfolge der Inhalte Sinn macht. Die visuelle Anordnung dient hier als Richtschnur. Es kann jedoch auch eine davon abweichende Lesereihenfolge sinnvoll sein.

Alternativtext beschreibt das Bild nicht

Der PDF Accessibility Checker prüft Bilder nur darauf, ob diese korrekt getaggt sind und ein Alternativtext definiert ist. Das WCAG-Erfolgskriterium 1.1.1 verlangt aber mehr:

Alle Nicht-Text-Inhalte, die dem Benutzer präsentiert werden, haben eine Textalternative, die einem äquivalenten Zweck dient, mit Ausnahme der unten aufgelisteten Situationen. […]

Das Bild in meinem Test-Dokument zeigt das blaue, offene Meer vor der Küste Mallorcas. Der Alternativtext des Bildes lautet hingegen „Eine staubtrockene Wüste“ . Ein automatisiertes Tool kann nicht erkennen, dass das Quatsch ist.

Fazit

Der PDF Accessibility Checker ist ein großartiges Tool, um ein PDF-Dokument auf grobe Mängel zu prüfen. Die manuelle Prüfung ersetzt es aber nicht. Eine umfassende Prüfung der Barrierefreiheit sollte sowohl automatisierte als auch manuelle Prüfschritte umfassen.

PS: Testet auch die korrigierte Fassung meines Test-Dokuments mit dem Screenreader, um die verbesserte Nutzererfahrung selbst zu erleben.

Wie Ihr die WCAG 2.2 erfüllt — Ein paar praktische Beispiele

Tue, 17 Oct 2023 00:00:00 GMT

Die neue Version 2.2 der Web Content Accessibility Guidelines wurde vor kurzem veröffentlicht. Sie definiert 9 neue Erfolgskriterien und streicht das alte Kriterium 4.1.1 Parsing.

Ich werde euch nicht mit einem weiteren „WCAG 2.2 ist endlich da!“ -Artikel langweilen. Andere Expert:innen für Barrierefreiheit, die mehr Erfahrung haben als ich, haben bereits die Änderungen im Vergleich zu WCAG 2.1 erläutert (siehe die Links am Ende).

Stattdessen möchte ich mich auf einzelne neue Kriterien konzentrieren und euch praktische Beispiele geben, wie ihr diese erfüllen könnt.

Foto: © George Milton / pexels.com

Die neuen Kriterien der WCAG 2.2

Mehrere neue Kriterien zielen darauf ab, die Bedienbarkeit von Websites und Apps zu verbessern: Fokus-Indikatoren sollten klar erkennbar sein und die fokussierten Bedienelemente sollten nicht durch andere Inhalte auf der Seite verdeckt werden.

Die Bedienelemente sollten so groß sein, dass sie leicht aktiviert werden können, ohne versehentlich ein benachbartes Ziel zu aktivieren. Wenn eine Website Funktionalitäten anbietet, die eine Ziehbewegung zur Bedienung verwenden, dann muss sie eine alternative Möglichkeit für Maus- und Tastatur-Nutzer:innen anbieten.

Hier ist eine Liste aller neuen Erfolgskriterien, die sich auf die Bedienbarkeit beziehen:

Die folgenden Erfolgskriterien zielen darauf ab, die Zugänglichkeit für Menschen mit kognitiven Beeinträchtigungen zu verbessern:

Schauen wir uns nun einige praktische Beispiele für die neuen Erfolgskriterien an.

Praktische Beispiele

Anwendungsfall: Fixierte Kopfzeile

Viele Websites enthalten einen Header, der am oberen Rand der Seite verbleibt, auch wenn die Seite gescrollt wird. Eine gute gemachte, fixierte Kopfzeile verbessert die Benutzerfreundlichkeit der Website. Stellt euch einen Benutzer vor, der einen langen Artikel liest: Wenn er am Ende der Seite angelangt ist, muss er nicht wieder nach oben scrollen, um auf die Hauptnavigation im Header zuzugreifen.

Leider kann eine fixierte Kopfzeile allen Nutzer:innen, die keine Maus benutzen können, das Leben schwer machen. Wenn sie auf eine Website mit der Tastatur navigieren, müssen sie immer sehen, was den Tastaturfokus hat. Eine fixierte Kopf- oder Fußzeile kann dazu führen, dass fokussierte Elemente hinter diesen Elementen verschwinden.

Doch es gibt eine einfache und elegante Lösung für dieses Problem: Die CSS-Eigenschaft scroll-padding ermöglicht es, Offsets für den optimalen Sichtbereich des Scrollports zu definieren — den Bereich, der als Zielbereich für die Platzierung von Elementen im Sichtfeld des Benutzers verwendet wird. Ihr braucht nur folgendes:

html {
    scroll-padding: 4rem 0;
}

Hier ist eine Demo einer Website mit fixierter Kopf- und Fußzeile. Versucht mit der Tabulatortaste zu navigieren und achtet darauf, wie der Browser den fokussierten Link im sichtbaren Bereich hält:

Auf diese Weise erfüllt die Website die Kriterien 2.4.11 Fokus nicht verdeckt (Minimum) (AA) und 2.4.12 Fokus nicht verdeckt (Erweitert) (AAA).

Eine weitere verwandte CSS-Eigenschaft ist scroll-margin . Ihr könnt sie verwenden, um z.B. Inhalte unter einem Banner mit fester Position freizulegen, wie die WCAG-Technik C43 zeigt: „Using CSS margin and scroll-margin to un-obscure content“.

Anwendungsfall: Interaktive Karte mit Ziehen-zum-Verschieben

Bei einer interaktiven Karte können Nutzer:innen normalerweise die Ansicht der Karte mit der Maus oder durch Berührung verschieben. Aber manche Menschen können Ziehbewegungen nicht präzise ausführen. Oder sie verwenden ein spezielles Eingabegerät, z.B. einen Trackball oder einen Kopfzeiger, was die Ziehbewegung umständlich und fehleranfällig macht.

Eine barrierefreie Karte sollte auch Schaltflächen zum Verschieben der Ansicht nach oben/unten/links/rechts enthalten, um dem Erfolgskriterium 2.5.7 Ziehbewegungen (AA) zu entsprechen. Nutzer:innen mit motorischen Beeinträchtigungen können die Steuerelemente einfach mit der Tabulatortaste ansteuern und den Kartenausschnitt damit verschieben.

Seht euch meine Demo einer Karte mit Zoom- und Verschiebe-Buttons an:

Foto: © Alexander Lehner

Wie der Screenshot oben zeigt, wird die fokussierte Schaltfläche durch einen dicken Umriss und einen Farbwechsel deutlich hervorgehoben. Lest den nächsten Abschnitt, um mehr über barrierefreie Fokusindikatoren zu erfahren.

Anwendungsfall: Gut sichtbare Fokus-Indikatoren

Gut wahrnehmbare Fokus-Indikatoren zählen zu den grundlegenden Features von barrierefreien Websites und Apps. Das Erfolgskriterium 2.4.7 Fokus sichtbar (AA) besagt:

Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

Dieses Kriterium gibt es schon seit fast 15 Jahren, seit der Veröffentlichung der WCAG 2.0. Leider gibt es immer noch viele Websites, die keine oder kaum sichtbare Fokus-Indikatoren aufweisen. Einer der Gründe dafür könnte sein, dass die WCAG nie normativ definiert haben, was „sichtbar“ in der Praxis bedeutet.

Das neue Erfolgskriterium 2.4.13 Fokus-Erscheinungsbild (AAA) definiert endlich die Mindestabmessungen und das Design von Fokus-Indikatoren. Sie sollten ausreichend groß sein und einen Kontrast von mindestens 3:1 zwischen dem fokussierten und dem unfokussierten Zustand eines Elements bieten.

Oft lehnt eine Kundin oder ein Designer starke Fokus-Indikatoren aus ästhetischen Gründen ab. In diesem Fall empfehle ich die Verwendung der CSS-Pseudoklasse :focus-visible . Damit könnt ihr Fokus-Indikatoren nur dann anzeigen, wenn sie benötigt werden (z.B. bei der Tastaturnavigation). Seht euch meine Demo an, die :focus mit :focus-visible vergleicht.

Wenn ihr weitere Details erfahren wollte, dann lest meinen Artikel „Gestalte deutlich sichtbaren Tastaturfokus mit :focus-visible“.

Nützliche Links

Warum ich Zertifizierungen für Barrierefreiheit sinnvoll finde

Thu, 14 Sep 2023 00:00:00 GMT

Das Thema Barrierefreiheit gewinnt immer mehr an Bedeutung. Der European Accessibility Act schreibt ab 2025 verbindliche Anforderungen für Produkte und Dienstleistungen vor. Damit steigt auch der Bedarf an Fachleuten, die Unternehmen bei der barrierefreien Gestaltung ihrer Websites und Apps unterstützen.

Doch was zeichnet eine Barrierefreiheits-Expertin oder einen -Experten aus? Woher weiß ich, dass jemand tatsächlich Ahnung hat oder nur mit Schlagwörtern um sich wirft?

Aus meiner Sicht spielen anerkannte Zertifizierungen hierbei eine wichtige Rolle. In diesem Artikel möchte ich auf die Vor- und Nachteile von Accessibility-Zertifizierungen eingehen und eine Definition wagen, welche Skills man von Fachleuten erwarten kann.

Foto: © Marcus Aurelius / pexels.com

Hinweis: Ich habe 2019 das Zertifikat „Certified Web Accessibility Expert” der UBIT-Akademie incite erworben. Seit Anfang 2023 bin ich „IAAP Certified Professional in Accessibility Core Competencies (CPACC)“ (Nachweis bei Credly).

Mindestanforderungen an Expert:innen

Barrierefreiheits-Expert:innen sollten Empathie für Menschen mit Behinderung mitbringen. Sie sollten ein aufrichtiges Interesse am Alltag dieser Menschen haben und versuchen, sich in ihre jeweilige Situation hineinzuversetzen:

Wie surfen blinde Menschen mithilfe eines Screenreaders im Internet?
Unter welchen Bedingungen können Personen mit motorischer Beeinträchtigung eine Website alleine mit der Tastatur bedienen?
Wann sind Video- und Audioinhalte auch für gehörlose Menschen barrierefrei?
usw.

Eine Expertin oder Experte muss die verschiedenen Nutzergruppen und assistiven Technologien kennen. Dazu zählen Bildschirmlupen, Hochkontrast-Modus, Screenreader, Spracheingabe-Software, Tastaturen, und viele mehr.

Wissen über die relevanten Normen und Gesetze sind eine weitere Mindestanforderung. Dazu zählen sowohl die Erfolgskriterien der Web Content Accessibility Guidelines (WCAG), der europäische Standard EN 301 549 sowie relevante nationale Gesetze wie etwa das österreichische Barrierefreiheitsgesetz (BaFG).

Darüber hinaus sollten Accessibility-Expert:innen auch Erfahrung im Testen auf Barrierefreiheit mitbringen. Sie müssen beurteilen können, ob eine Website bzw. App konkrete Kriterien einhält, und Lösungswege für gefundene Barrieren aufzeigen können.

Barrierefreiheits-Zertifizierungen

Verschiedene Institutionen bieten Zertifizierungen zum Thema Barrierefreiheit an. Es gibt nationale Zertifizierungsstellen wie etwa die UBIT-Akademie incite in Österreich. Diese bietet die Zertifizierung zum Certified WebAccessibility Expert an.

Die International Association of Accessibility Professionals (IAAP) bietet gleich mehrere Zertifizierungen an, darunter etwa den Certified Professional in Accessibility Core Competencies (CPACC) und den Web Accessibility Specialist (WAS) . Accessibility-Expert:innen sollen gezielt beim Aufbau von Expertise unterstützt werden.

Welche Vor- und Nachteile bieten solche Zertifizierungen?

Vorteile

Erhöhte Glaubwürdigkeit: Eine Zertifizierung ist ein Nachweis, dass man über bestimmte Fähigkeiten und Erfahrungen verfügt. Dies unterstreicht die Glaubwürdigkeit von Expert:innen.
Einheitlicher Standard: Um eine Zertifizierung zu erwerben, müssen Interessierte in Prüfungen bzw. Einzelgesprächen ihr Wissen über konkrete Inhalte unter Beweis stellen. Seriöse Institutionen definieren hierfür einen öffentlich zugänglichen Syllabus, der diese Inhalte transparent macht.
Community für Austausch und Weiterbildung: Die IAAP unterstützt die Vernetzung von Accessibility-Expert:innen mit Online-Foren, Webinaren und verschiedenen Veranstaltungen.

Nachteile

Kosten: Eine Zertifizierung ist nicht gratis. Der CPACC kostet zum Beispiel knapp 500 US-Dollar (für Mitglieder etwas weniger). Nicht jeder kann sich das leisten. Im Vergleich zu vielen anderen Zertifizierungen im IT-Bereich finde ich den Preis jedoch sehr moderat.
Kognitive Barriere: Oft besteht eine Zertifizierung aus einem Multiple-Choice-Test mit unzähligen Fragen. Zum Beispiel muss man beim CPACC ganze 100 Fragen in zwei Stunden beantworten. Das ist anstrengend. Für Menschen mit kognitiver Beeinträchtigung kann das auch eine unüberwindbare Barriere darstellen.

Fazit

Aus meiner Sicht sind Barrierefreiheits-Zertifizierungen eine sinnvolle Sache. Sie stellen einen einheitlichen, transparenten Nachweis für konkrete Fähigkeiten dar. Sie helfen Unternehmen dabei, echte Expertinnen von Schaumschlägern zu unterscheiden.

Müssen alle Accessibility-Expert:innen eine Zertifizierung machen? Natürlich nicht. Es gibt auch andere Mittel und Wege, seine Expertise unter Beweis zu stellen. Etwa indem man schon viele Jahre barrierefreie Websites oder Apps gestaltet und diese als Referenzen vorweisen kann.

Ich bin jedenfalls froh über meine Zertifizierungen. Sie stellen zentrale Meilensteine in meiner Laufbahn als Barrierefreiheits-Experte dar. Und das erworbene Abzeichen sieht einfach cool aus! 😉

Nützliche Links

Wie ihr verkettete Datenabfragen und zeitgleiche Requests mit RxJS managt

Sun, 20 Aug 2023 00:00:00 GMT

Musstet ihr schon einmal Informationen aus mehreren Datenquellen oder verschiedenen API-Endpunkten abrufen? Habt ihre eine Optimierung hinsichtlich Parallelität und voneinander abhängigen Datenabfragen vorgenommen?

Wenn ihr mindestens eine dieser Fragen mit Ja beantwortet, solltet ihr jetzt weiterlesen. Ich zeige euch meine Lösung mit dem Angular-Framework und RxJS. Lasst eure Datenabrufe fließen wie eine Reihe miteinander verbundener Wasserfälle.

Foto: © Quang Nguyen Vinh / pexels.com

Bevor wir uns einige Codebeispiele genauer ansehen, hier eine kurze Erklärung von RxJS.

Was ist RxJS und was sind Observables?

Der Name RxJS ist eine Abkürzung für Reactive Extensions Library for JavaScript . In der offiziellen RxJS-Einführung heißt es:

RxJS is a library for composing asynchronous and event-based programs by using observable sequences.

Der Begriff „observable sequence“ ist hier der Schlüssel. Er steht für die Idee einer aufrufbaren Sammlung von zukünftigen Werten. Die entsprechende Funktionalität ist in der Klasse Observable gekapselt.

Ihr könnt zum Beispiel ein Observable erstellen, das den Wert eines Eingabefeldes bei jeder Wertänderung ausgibt. Oder ihr könnt das Promise eines fetch-Aufrufs in ein Observable verpacken, welches den Response-Wert ausgibt, wenn das Promise abgeschlossen ist.

Ein weiteres wichtiges Konzept ist die Verwendung einer pipe . Mit der Pipe-Funktion eines Observables können wir eine Reihe von Aktionen auf dem Observable und seinem Datenstrom ausführen. Ihr solltet auf jeden Fall die Grundlagen von RxJS mit der offiziellen Dokumentation lernen. Ich kann auch die Website Learn RxJS empfehlen.

Die Herausforderung

In einem Kundenprojekt stand ich vor folgender Herausforderung: Die Webanwendung sollte es Nutzer:innen ermöglichen, bestimmte Datensätze offline verfügbar zu machen. In einem ersten Schritt habe ich die App in eine Progressive Web App umgewandelt und einen Service erstellt, der die Datenspeicherung mit IndexedDB übernimmt.

Dann wusste ich plötzlich nicht mehr weiter!

Um ehrlich zu sein: Ich musste noch nie Daten von verschiedenen API-Endpunkten abrufen, bei denen sich das Ergebnis initialer Abfragen auf hunderte weitere Abfragen auswirken würde. Ich musste die Abfragesequenz sowohl für die Parallelität als auch für gegenseitige Abhängigkeiten optimieren.

Nach einer Menge Online-Recherche und viel Ausprobieren bin ich zu einer zufriedenstellenden Lösung gekommen. Der folgende Quellcode ist eine angepasste Version meines Kundenprojekts, die ich gerne mit euch teilen möchte.

Die Lösung

Geht ihr gerne ins Kino? Stellt euch eine Webanwendung vor, die das Kinoprogramm für verschiedene Kinos anzeigt. Ihr könnt sehen, wann welcher Film läuft, Informationen über die Schauspieler:innen abrufen, Filmausschnitte ansehen und durch Screenshots blättern. Ihr könnt auch allgemeine Informationen über die Kinos (z.B. Name, Standort) und ihre Kinosäle (z.B. Anzahl der Sitzplätze) lesen.

Foto: © Pixabay / pexels.com

Um all diese Daten abzurufen und offline zu speichern, müssen wir auf verschiedene Endpunkte zugreifen. Einige der Abfragen (z.B. für jeden Film) hängen von Informationen ab, die in anderen Abfragen (z.B. für das Filmprogramm) abgerufen werden. Das bedeutet, dass wir zunächst eine logische Reihenfolge für unsere Download-Sequenz festlegen müssen.

Schritt 1: Die zentrale Download-Pipe

In meinem Projekt enthält die Klasse CinemaDownloadService die gesamte Download-Logik. Der Service kann z.B. von einer Angular-Komponente eingebunden werden. Er bietet die öffentliche Methode downloadCinemaInfo , die alle notwendigen Informationen herunterlädt, um ein Kino und sein Filmprogramm offline verfügbar zu machen:

public downloadCinemaInfo(cinemaId: number): Observable<CinemaOfflineData> {
    return this.downloadDataForCinemaId(cinemaId).pipe(
        switchMap(this.downloadMovies),
        switchMap(this.downloadActorBiographies),
        switchMap(this.downloadFilmClips),
        switchMap(this.downloadScreenshots),
    );
}

Die Methode gibt ein Observable zurück, das die Datensammlung CinemaOfflineData ausgibt, sobald alle einzelnen Downloads abgeschlossen sind.

export interface CinemaOfflineData {
    generalInfo: CinemaGeneralInfo;
    movieHalls: MovieHall[];
    movieProgram: MovieProgram;
    movies: Movie[];
    actorBios: Actor[];
    filmClips: FilmClip[];
    screenshots: MovieScreenshot[];
}

Um die Daten zu sammeln, lädt die Methode zunächst alle Informationen herunter, die direkt von cinemaId abhängen. Wir werden uns das gleich genauer ansehen. Anschließend verwendet sie eine pipe und den switchMap Operator, um die restlichen Daten herunterzuladen.

Der switchMap-Operator verwendet den vom Observable ausgegebenen Wert, um ein neues Observable zu erstellen, welches das alte ersetzt. Kurz gesagt: Sobald wir mit einem bestimmten Download-Vorgang fertig sind, starten wir einen neuen, der das Ergebnis des vorherigen Vorgangs enthält.

Schritt 2: Basis-Informationen herunterladen

In einem ersten Schritt wollen wir die allgemeinen Informationen über das Kino, seine Kinosäle und das aktuelle Kinoprogramm herunterladen:

private downloadDataForCinemaId(cinemaId: number): Observable<CinemaOfflineData> {
    return forkJoin([
        this._request.getCinemaGeneralInfo(cinemaId).pipe(
            retryStrategy()
        ),
        this._request.getMovieHalls(cinemaId).pipe(
            retryStrategy()
        ),
        this._request.getMovieProgram(cinemaId).pipe(
            retryStrategy()
        ),
    ]).pipe(
        map(([generalInfo, movieHalls, movieProgram]: [CinemaGeneralInfo, MovieHall[], MovieProgram]) => {
            const data: CinemaOfflineData = {
                generalInfo, movieHalls, movieProgram,
                movies: [], actorBios: [],
                filmClips: [], screenshots: [],
            };
            return data;
        })
    );
}

Die einzelnen Backend-Abfragen werden über einen eigenständigen RequestService gestellt, auf den wir über this._request zugreifen. Die Details der Implementierung sind für diesen Beitrag nicht relevant. Alles, was ihr wissen müsst, ist: Jede Request-Methode gibt ein Observable zurück, das den Response ausgibt und dann abgeschlossen wird.

Wir verwenden den Operator forkJoin, um abzuwarten, bis alle Abfragen beendet sind. Erst dann erstellen wir die erste Instanz unseres CinemaOfflineData Objekts. Die übrigen Eigenschaften, wie movies , werden als leere Arrays initialisiert. Wir werden die entsprechenden Daten in den nächsten Schritten unserer Download-Pipe herunterladen.

Schritt 3: Zeitgleiche Requests mit `mergeMap` begrenzen

Nachdem wir das Kinoprogramm erfolgreich heruntergeladen haben, wollen wir Infos über alle darin enthaltenen Filme abrufen. Je nach Größe des Kinos und des abgedeckten Zeitraums könnte dies Hunderte von Einzelabfragen bedeuten.

Das moderne HTTP/2-Protokoll unterstützt das vollständige Multiplexing von Abfragen. Je nach eurem Backend-Server und der maximalen Anzahl von Abfragen pro Sekunde kann es jedoch sinnvoll sein, die Anzahl der gleichzeitigen Abfragen zu begrenzen.

Um dies zu erreichen, verwenden wir eine Kombination der folgenden RxJS-Funktionen: from , mergeMap und reduce . Hier ist die vollständige Methode zum Herunterladen von Filminfos:

private downloadMovies = (data: CinemaOfflineData): Observable<CinemaOfflineData> => {
    const movies: Movie[] = [];
    const movieIds = this.getMovieIds(data.movieProgram);
    return from(movieIds).pipe(
        mergeMap(
            id => this._request.getMovieInfo(id).pipe(
               retryStrategy()
            ),
            MAX_CONCURRENT_BACKEND_REQUESTS
        ),
        reduce(
            (accumulator, item) => {
                accumulator.push(item);
                return accumulator;
            },
            movies
        ),
        map(movies => ({ ...data, movies }))
    );
};

Ich weiß, das ist ein ziemlicher Brocken! Schauen wir uns die Umsetzung Schritt für Schritt an:

Wir holen uns die eindeutigen movieIds aus dem bereits heruntergeladenen Filmprogramm. Dann verwenden wir from, um das Array der Film-IDs in ein Observable zu verwandeln.
Als Nächstes verwenden wir mergeMap, um für jeden Film eine Abfrage zu erstellen. Wir übergeben die Konstante MAX_CONCURRENT_BACKEND_REQUESTS als zweiten Parameter, um die maximale Anzahl der gleichzeitigen Abfragen zu begrenzen.
Jedes einzelne Request-Observable nutzt den retryStrategy Operator, um die Abfrage im Fehlerfall zu wiederholen. Dabei handelt es sich um meinen eigenen, benutzerdefinierten Operator, der die retry-Funktion verwendet.
Das nächste Element in unserer Observable-Pipe ist reduce. Wir verwenden diese Funktion, um die Ergebnisse aller Backend-Abfragen in dem Array movies zusammenzufassen.
Zuletzt integrieren wir die Filmdaten in eine neue Instanz unseres CinemaOfflineData Objekts, indem wir den map-Operator verwenden.

Jetzt kann die zentrale Download-Pipe zum nächsten Schritt übergehen: Den Download der Biografien aller Schauspieler:innen. Wir ermitteln die eindeutigen actorIds aus den Filmdaten und wenden die gleiche Download-Logik wie zuvor an:

private downloadActorBiographies = (data: CinemaOfflineData): Observable<CinemaOfflineData> => {
    const actorBios: Actor[] = [];
    const actorIds = this.getActorIds(data.movies);
    return from(actorIds).pipe(
        mergeMap(
            id => this._request.getActorBiography(id).pipe(
                retryStrategy()
            ),
            MAX_CONCURRENT_BACKEND_REQUESTS
        ),
        reduce(
            (accumulator, item) => {
                accumulator.push(item);
                return accumulator;
            },
            actorBios
        ),
        map(actorBios => ({ ...data, actorBios }))
    );
};

Wir wiederholen dieselben Schritte für die Filmausschnitte und Screenshots.

Schritt 4: Das Download-Observable ausführen

Um die gesamte Download-Logik auszuführen, müsst ihr die öffentliche Methode downloadCinemaInfo aufrufen und dann die subscribe-Methode für das zurückgegebene Observable aufrufen:

this._cinemaDownloadService.downloadCinemaInfo(cinemaId)
    .subscribe((cinemaData: CinemaOfflineData) => {
        /* Store data offline, e.g., with IndexedDB */
    });

Das war’s! Ihr habt erfolgreich eine elegante Download-Logik erstellt, die für Parallelität und voneinander abhängige Daten optimiert ist.

Natürlich solltet ihr auch die Fehlerbehandlung mit catchError implementieren. Weiters könntet ihr auch den Download-Prozess visualisieren, indem ihr mithilfe eines Subject den aktuellen Status kommuniziert.

Fazit

Wie wir gesehen haben, bietet RxJS eine Reihe mächtiger Werkzeuge wie mergeMap und reduce . Sie helfen uns, effiziente und robuste Lösungen zu implementieren.

Ihr könnt eine zentrale Download-Pipe definieren, die einen schnellen Überblick über die einzelnen Schritte bietet. Dann platziert ihr die spezifische Download-Logik in isolierten privaten Funktionen. Damit könnt ihr euren Code sauber und wartbar halten.

Nützliche Links

Einfach herausragend! Die neue Popover API und CSS Anchor Positioning

Sun, 09 Jul 2023 00:00:00 GMT

Menüs, Tooltips, Datumsauswahlen oder Dialoge – das Web steckt voller Popover-Inhalte. Trotz ihrer weiten Verbreitung existieren kaum native HTML-Elemente für diese Komponenten (außer für Dialoge). Und ihre Implementierung erfordert eine ganze Menge JavaScript.

Doch die neue Popover API in Kombination mit CSS Anchor Positioning ändert alles. Die Darstellung von einzelnen Elementen über anderen Seiteninhalten wird damit für Entwickler:innen zum Kinderspiel.

Foto: © Zachary DeBottis / pexels.com

Ich habe zwei Demos mit Beispielen für Popover-Inhalte vorbereitet. Wir werden sowohl die technischen Aspekte als auch die Barrierefreiheit der neuen Funktionen eingehend betrachten.

Was können wir damit machen?

Ich mag das Motto: Zeigen, nicht erzählen! Deshalb habe ich zwei Demos erstellt, um die Möglichkeiten der neuen API zu veranschaulichen.

Im Moment funktionieren die Beispiele nur in Chrome Canary, dem Nightly Build für Entwickler:innen. Öffnet den Browser, ruft die Seite chrome://flags auf und aktiviert dort die experimentellen Web-Plattform-Funktionen.

Warnung: Die Anker-Positionierung ist noch sehr experimentell. Daher können die Demos eventuell nicht funktionieren, falls sich die Spezifikation ändert.

Standard-Tooltips, die mit dem Attribut title erstellt werden, sind ziemlich langweilig. Deshalb habe ich mich an einem schicken benutzerdefinierten Tooltip versucht. Klickt auf die Info-Schaltfläche neben der Überschrift:

See the Pen Accessible Tooltip with Popover API by Alexander Lehner (@alexlehner86) on CodePen.

Ich habe mein Bestes gegeben, um den Tooltip barrierefrei zu gestalten. Dazu bin ich den Vorgaben des Tooltip Pattern im ARIA Authoring Practices Guide gefolgt. Leider gibt es noch keinen Konsens zur idealen Implementierung. Darüber hinaus bietet die Popover API noch keinen Mechanismus für Hover- und Fokus-Events.

Beispiel 2: Menü mit einer Reihe von Aktionen

Ich habe auch eine Demo für ein barrierefreies Menü erstellt. Jeder Eintrag in der Liste der ausgeliehenen Bücher enthält eine Schaltfläche, die ein Menüfeld mit einer Reihe von Aktionen für jedes Buch einblendet:

See the Pen Accessible Menu with Popover API by Alexander Lehner (@alexlehner86) on CodePen.

Meine Implementierung folgt dem Menu and Menubar Pattern, das im ARIA Authoring Practices Guide definiert ist. Ich habe die entsprechenden ARIA-Rollen und -Eigenschaften verwendet und auch (die meisten) der empfohlenen Tastatur-Interaktionen implementiert.

Schauen wir uns nun die verschiedenen Bausteine an, die ich zur Erstellung dieser Komponenten verwendet habe.

Das magische `popover` Attribut

Dieses HTML-Attribut verwandelt jedes Element in einen Popover-Inhalt. Die HTML-Spezifikation besagt:

All HTML elements may have the popover content attribute set. When specified, the element won’t be rendered until it becomes shown, at which point it will be rendered on top of other page content.

Dieser Popover-Inhalt ist immer nicht-modal, d. h. Nutzer:innen können weiterhin mit dem Rest der Seite interagieren, während das Popover geöffnet ist. Wenn ihr ein modales Popover (z. B. einen Bestätigungs-Dialog) anzeigen wollt, solltet ihr das Element <dialog> verwenden.

Um ein Popover zu erstellen, fügt ihr das Attribut popover zu einem Element hinzu und definiert eine id . Anschließend setzt ihr das Attribut popovertarget mit dem Wert der ID des Popovers auf jenes Element, welches das Popover öffnet. Ein Beispiel:

<button popovertarget="popover-1">
    Info
</button>
<div id="popover-1" popover>
    Hi, I'm a popover!
</div>

Das war’s! Ihr habt gerade ein Popover mit ein paar Zeilen HTML und null JavaScript erstellt. Genial!

Wenn ihr das popover Attribut verwendet, erhaltet ihr die folgenden Funktionen mit dazu:

Platzierung im Top-Layer: Popover-Inhalte werden automatisch im Top-Layer angezeigt, einer separaten Ebene, die über allen anderen Inhalten im Webdokument liegt. Ihr müsst euch nicht länger um die DOM-Reihenfolge oder den z-Index Sorgen machen.
Light-dismiss: Wenn ihr außerhalb des Popover-Bereichs klickt, wird das Popover geschlossen und der Fokus wieder auf das auslösende Element zurückgesetzt.
Barrierefreie Tastaturbedienung: Wenn das Popover geöffnet ist, könnt ihr die ESC Taste drücken, um das Popover zu schließen und den Fokus wieder auf das auslösende Element zu setzen.
Semantische Beziehung: Die Verknüpfung eines Popover-Elements mit einer Schaltfläche erzeugt automatisch eine semantische Beziehung für assistive Technologien. Quasi ein eingebautes aria-controls plus aria-expanded .

Weitere Optionen und Styling

Wenn ihr ein Popover mit popovertarget erstellt, blendet die Schaltfläche das Popover standardmäßig ein und aus. Alternativ könnt ihr auch einen expliziten Wert für das Attribut popovertargetaction festlegen:

“hide”: Die Schaltfläche blendet ein angezeigtes Popover aus. Das kann nützlich sein, wenn ihr innerhalb eines Popovers eine Schaltfläche zum Schließen anbieten möchtet.
“show”: Die Schaltfläche blendet ein Popover ein.
“toggle”: Die Schaltfläche blendet ein Popover ein und aus. Dies ist das Standardverhalten.

Darüber hinaus ist das popover Attribut eigentlich eine Abkürzung für popover=“auto” . Dieser Standardtyp von Popover erzwingt das Schließen anderer Auto-Popovers. Es kann über Light-Dismiss oder eine Schließen-Schaltfläche ausgeblendet werden.

Mit popover=“manual” könnt ihr ein manuelles Popover erstellen. Diese Popover werden nicht über Light-Dismiss geschlossen und sie erzwingen auch nicht das Schließen anderer Popover. Ihr müsst sie durch eine explizite Schließ-Aktion ausblenden. Ein möglicher Anwendungsfall für manuelle Popovers sind Alarm-Snackbars, die vom Nutzer bestätigt werden müssen.

Popovers bieten auch nützliche CSS-Funktionen: Mit dem Pseudoelement ::backdrop könnt ihr Effekte auf den Seiteninhalt hinter dem Popover anwenden. Ihr könnt die Pseudoklasse :popover-open verwenden, um das Styling von eingeblendeten Popover-Elementen zu definieren.

CSS Anchor Positioning

Wenn ihr’s bis hierher geschafft habt, fragt ihr euch vielleicht: Was ist mit der Position des Popovers auf der Seite? Um den eingeblendeten Inhalt relativ zu einem anderen Element zu positionieren, benötigen wir eine weitere neue, experimentelle Funktion: Anker-Positionierung.

Dieses Feature ist im CSS-Modul CSS Anchor Positioning definiert. Im Moment ist das Dokument noch ein „Working Draft“ , aber Chrome bietet die Funktion bereits hinter dem Flag für experimentelle Web-Plattform-Funktionen an. Das Dokument besagt:

This specification defines ‘anchor positioning’, where a positioned element can size and position itself relative to one or more “anchor elements” elsewhere on the page.

In meinen Demos habe ich die Anker-Positionierung verwendet, um den Tooltip und die Menüfelder neben ihren Toggle-Schaltflächen zu platzieren. Sehen wir uns an, wie wir Anker definieren und sie im CSS-Code referenzieren können.

Wie ihr ein Anker-Element definiert

Es gibt zwei verschiedene Wege, um Anker zu definieren. Ihr könnt ein HTML-Element in einen Anker verwandeln, indem ihr dem Element eine id zuweist, und dann das anchor Attribut verwendet, um ein anderes Element an diesen Anker zu binden. Hier ist ein Beispiel in Kombination mit einem Popover:

<button id="toggle-btn-1" popovertarget="popover-1" class="toggle-btn">
    Info
</button>
<div id="popover-1" popover anchor="toggle-btn-1">
    Hi, I'm a popover!
</div>

Alternativ könnt ihr die CSS-Eigenschaft anchor-name verwenden, um einen Anker zu definieren. Diese Eigenschaft akzeptiert einen dashed-ident Wert wie etwa —toggle-btn . Anschließend nutzt ihr die Eigenschaft position-anchor , um ein anderes Element an den Anker zu binden.

button.toggle-btn {
    anchor-name: --toggle-btn;
}
div[popover] {
    position-anchor: --toggle-btn;
}

Inhalte mit der `anchor()` Funktion positionieren

Gut, ihr habt jetzt ein HTML-Element als Anker definiert und ein Popover daran gebunden. Jetzt könnt ihr die Funktion anchor() verwenden, um das Popover zu positionieren. Die Funktion akzeptiert drei Argumente:

Anker-Element: Dieser Wert gibt an, wo sich das Anker-Element befindet. Ihr könnt einen expliziten Ankernamen angeben. Oder ihr lasst den Wert weg, um den impliziten Anker zu verwenden, der über das Attribut anchor oder die CSS-Eigenschaft position-anchor definiert wurde.
Verankerungs-Seite: Dieser Wert bezieht sich auf die Position der entsprechenden Seite des Anker-Elements. Zum Beispiel: bottom oder left .
Fallback (optional): Ein Längen- oder prozentualer Wert, der als Fallback im Falle einer ungültigen Ankerfunktion dient.

Das folgende Beispiel zeigt, wie ihr einen Tooltip unterhalb der Toggle-Schaltfläche platzieren und horizontal zentrieren könnt:

[role="tooltip"][popover] {
    position: absolute;
    position-anchor: --toggle-btn;
    top: anchor(bottom);
    left: anchor(center);
    translate: -50% 0;
}

Die Spezifikation enthält noch weitere Funktionen wie die Eigenschaft anchor-scroll und die Funktion anchor-size() . Aber der Blog-Beitrag ist schon lang genug, daher bin ich mal so frech und lasse sie aus.

Barrierefreiheit von Popovers

Sind Popovers barrierefrei? Wie meine Beispiele oben zeigen, könnt ihr mit der neuen Popover-API nutzerfreundliche, barrierefreie Komponenten erstellen. Aber das passiert nicht von selbst.

Definiert die passende semantische Rolle

Das popover Attribut kann die Barrierefreiheit eurer Website auf jeden Fall verbessern. Zum Beispiel durch die Möglichkeit, das Popover mit der ESC Taste zu schließen. Oder durch die semantische Beziehung zwischen dem Toggle-Button und dem Popover, die durch das Attribut popovertarget erzeugt wird.

Andererseits definiert das popover Attribut keine implizite Rolle für das HTML-Element, dem es hinzugefügt wird. Das bedeutet: Denkt über euren konkreten Anwendungsfall nach und verwendet dann das passende native HTML-Element oder die angemessene ARIA-Rolle (wie zum Beispiel tooltip oder menu ).

Screenreader-Unterstützung

Wie erleben Nutzer:innen von Screenreadern die Interaktion mit Webinhalten, die mit der Popover-API erstellt wurden? Aufgrund der begrenzten Browser-Unterstützung für die neuen Features habe ich meine Demos nur in den folgenden Szenarien getestet:

NVDA 2023.1, Windows 11, Google Chrome Chanary 117.0.5876.0
TalkBack, Samsung Galaxy S20, Android 13, Google Chrome Chanary 117.0.5876.0

Beide Demos haben super funktioniert: Ich konnte mit der Tastatur durch den Tooltip und die Menüs navigieren, während NVDA die semantischen Rollen und den aktuellen Status der Steuerelemente vorlas.

Auch die Interaktion auf meinem Smartphone verlief reibungslos: Bei aktiviertem TalkBack navigierte ich mit Wischgesten durch die Seiten, während der Screenreader mich über den Inhalt, die semantischen Rollen und den aktuellen Status der Bedienelemente informierte.

Das stimmt mich wirklich optimistisch für die Zukunft des Webs! Ich werde noch weitere Tests mit anderen Browsern und Screenreadern durchführen, sobald die Popover-API besser unterstützt wird.

Browser-Unterstützung

Wann können wir die Popover-API und CSS Anchor Positioning produktiv einsetzen? Leider wird es noch einige Zeit dauern, bis es eine browserübergreifende Unterstützung für diese Features geben wird.

Laut caniuse.com wird das popover Attribut bereits von Chrome und Edge unterstützt. In der Safari 17 Technology Preview wird das Attribut angekündigt, während Firefox es nur als experimentelles Feature anführt (ihr müsst das dom.element.popover.enabled Flag setzen).

Die browserübergreifende Unterstützung für CSS Anchor Positioning wird wohl noch länger dauern. Soweit ich weiß hat bisher nur Chrome das experimentelle Feature implementiert. Aufgrund des Status als „First Public Working Draft“ kann sich die aktuelle Spezifikation in Zukunft noch ändern. Wir müssen einfach abwarten und sehen was passiert.

Fazit

Die neue Popover-API in Kombination mit CSS Anchor Positioning wird unser Leben als Web-Entwickler:innen einfacher machen und zu mehr Barrierefreiheit im Web beitragen.

Trotz des noch experimentellen Status der neuen APIs solltet ihr sie selbst ausprobieren und euch mit den neuen Attributen und Eigenschaften vertraut machen. Auf diese Weise seid ihr dann schon startklar, wenn die Features endlich von allen modernen Browsern unterstützt werden. 😎

Nützliche Links

Update am 05.04.2024

Code-Beispiele und Erläuterungen überarbeitet, um der aktualisierten CSS Anchor Positioning Spezifikation (W3C Working Draft, 26. März 2024) sowie der Implementierung in Chrome Canary zu entsprechen.

Update am 18.04.2025

CSS Anchor Positioning ist Teil von Interop 2025. Deshalb bin ich mir ziemlich sicher, dass wir bis zum Ende des Jahres eine browserübergreifende Unterstützung haben werden.

Wie ihr das volle Potential von Inline-SVG-Bildern entfaltet

Thu, 22 Jun 2023 00:00:00 GMT

SVG-Bilder sind ein integraler Bestandteil des modernen Webdesigns. SVG, kurz für Scalable Vector Graphics , sind hoch skalierbar und haben eine geringe Dateigröße. Ihr könnt sie sogar mit CSS stylen, wie ich euch zeigen werde.

Ein SVG-Bild kann mit dem <img> Tag oder der CSS-Eigenschaft background-image in eine Website eingebettet werden. In diesem Fall könnt ihr aber das Styling des Bildes nicht ändern. Ich verwende lieber Inline-SVG-Bilder. Diese können mit CSS angepasst und sogar animiert werden.

Foto: © Andrea Piacquadio / pexels.com

Wie kann man Inline-SVG-Bilder einbetten? Was sind die besten Methoden, um sie mit CSS-Eigenschaften und Variablen anzupassen? Lest weiter, um die Antworten darauf zu erfahren.

Wie ihr ein Inline-SVG einbettet

SVG-Bilder können mit dem <svg> Tag direkt in ein HTML-Dokument eingebettet werden. Öffnet einfach die Bilddatei in einem Code-Editor, kopiert den Code und fügt ihn in euer HTML-Template ein. Hier ist ein Beispiel:

<svg height="48" width="48" viewBox="0 -960 960 960" xmlns="http://www.w3.org/2000/svg">
    <path d="m393-165 279-335H492l36-286-253 366h154l-36 255Zm-73 85 40-280H160l360-520h80l-40 320h240L400-80h-80Zm153-395Z"></path>
</svg>

Websites werden oft mithilfe komponentenbasierter JavaScript-Frameworks wie Angular oder React erstellt. Damit könnt ihr ein Inline-SVG in einer eigenen Komponente verpacken, die ihr dann an verschiedenen Stellen eurer Website wiederverwenden könnt. Ein Beispiel dafür ist die Material UI Icon-Bibliothek.

Die UI-Bibliothek Angular Material geht sogar noch einen Schritt weiter: Damit könnt ihr SVG-Dateien als Assets der Website hinzufügen. Die Anwendung lädt die Bilder später vom Server, sodass der SVG-Code über die <mat-icon> Komponente in das HTML-Dokument eingebettet werden kann.

Demo: Flexibles Styling von SVG-Icon-Buttons

Ich habe eine Demo mit Anwendungsfällen für Inline-SVGs erstellt. Ihr könnt die Farbe der Icons über ein Farbwahlelement anpassen:

Wie das funktioniert? Indem ihr den fill des SVG-Bildes mit der CSS-Eigenschaft color verknüpft.

SVG-Bilder mit CSS stylen

Als erstes setzt ihr die Eigenschaft fill des SVG-Bildes auf den Wert currentColor . Dieses spezielle Schlüsselwort steht für den Wert der color CSS-Eigenschaft eines Elements. Auf diese Weise werden die Vektoren des SVG-Bildes mit der Schriftfarbe des Elements gefüllt. Ihr könnt die Eigenschaft im SVG-Code setzen:

<svg fill="currentColor" height="48" width="48" viewBox="0 -960 960 960" xmlns="http://www.w3.org/2000/svg">
    <path d="..."></path>
</svg>

Oder ihr definiert die Eigenschaft im CSS-Code:

.icon svg {
    fill: currentColor;
}

Jetzt könnt ihr das Aussehen des SVG-Bildes über die CSS-Eigenschaft color steuern. Das erleichtert die Verwaltung von Farbthemen und verschiedenen Zuständen von Steuerelementen.

Sagen wir, ihr verwendet eine Schaltfläche mit Icon und Text, wie in meiner Demo oben: Ihr könnt alle Elemente innerhalb der Schaltfläche mit einer einzigen CSS-Regel einfärben. Verschiedene Zustände wie :hover , :focus oder :disabled sind einfach zu gestalten. Ihr könnt sogar den Farbwechsel animieren:

.primary-btn {
    color: #f118a6;
    transition: color 0.5s ease;
}
.primary-btn:hover, .primary-btn:focus {
    color: #920c64;
    outline: 2px solid currentColor;
}

CSS-Variablen für mehrfarbige Bilder verwenden

Ihr könnt sogar CSS-Variablen innerhalb von SVG-Code verwenden. Das kann nützlich sein, wenn euer SVG-Bild mehrere Farben enthält. In diesem Fall könnt ihr die Hauptfarbe weiterhin mit der CSS-Eigenschaft color verknüpfen. Für die anderen Farben solltet ihr eigene CSS-Variablen definieren:

<svg fill="currentColor" viewBox="0 0 20 20" xmlns="http://www.w3.org/2000/svg">
    <path d="..." />
    <path d="..." />
    <path fill="var(--secondary-fill)" d="..." />
</svg>

Im Beispiel oben werden das erste und zweite path Element durch die definierte Schriftfarbe eingefärbt. Die Füllung des dritten Pfades könnt ihr über die CSS-Variable —secondary-fill steuern:

.icon {
    color: darkred;
    --secondary-fill: white;
}

Der Artikel „Multi-Colored SVG Symbol Icons with CSS Variables“ gibt euch einen ausführlichen Einblick in das Konzept.

Macht eure Bilder barrierefrei

Und nicht zuletzt: Vergesst nicht auf die Barrierefreiheit! Wenn das SVG-Bild rein dekorativ ist, dann verwendet aria-hidden=“true” , um das Element vor assistiven Technologien zu verbergen.

Wenn das Bild wichtige Informationen vermittelt, solltet ihr role=“img” setzen und mit dem Attribut aria-label einen alternativen Text angeben. Lest den Artikel „Accessible SVGs“ für weitere Informationen und Anwendungsfälle.

Nutze das inert Attribut um ungewollte Interaktionen zu verhindern

Thu, 04 May 2023 00:00:00 GMT

Beim Webdesign ist es wichtig, den verfügbaren Platz effizient zu nutzen. Ihr wollt den Bildschirm nicht mit zu viel Inhalt überladen. Das ist der Grund für gängige Muster wie einblendbare Untermenüs, ausklappbare Bereiche, Popups oder Dialoge.

Häufig werden diese Elemente als benutzerdefinierte Widgets implementiert. Sie verwenden CSS-Code wie opacity: 0 oder position: absolute; left: -10000px , um den Inhalt nur visuell zu verbergen. Die Nutzer:innen können aber immer noch über die Tastatur oder mit Hilfe von assistiven Technologien auf den Inhalt zugreifen. Was können wir dagegen tun?

Foto: © Roxanne Minnish / pexels.com

Ihr könnt das HTML-Attribut inert verwenden, um jegliche Interaktion mit versteckten Inhalten zu verhindern. Eine Art digitales Faultier, sozusagen. Schauen wir uns das Attribut, das inzwischen von allen wichtigen Browsern unterstützt wird, einmal genauer an.

Wie das `inert` Attribut funktioniert

Die inert-Eigenschaft ist ein globales HTML-Attribut, das den Browser anweist, jegliche Benutzerinteraktion mit einem bestimmten Inhaltsbereich zu verhindern. Die HTML-Spezifikation dazu lautet:

The inert attribute is a boolean attribute that indicates, by its presence, that the element and all its flat tree descendants […] are to be made inert by the user agent.

Das bedeutet: Alle Nutzereingabe-Events für das Element und seine Nachkommen werden ignoriert, einschließlich der Fokus-Events und Events von assistiven Technologien.

Ein Beispiel: Ihr platziert ein Registrierungs-Formular außerhalb des Bildschirms und lasst es erst in den sichtbaren Bereich gleiten, wenn eine bestimmte Schaltfläche gedrückt wird. Durch Hinzufügen von inert zum <form> Element wird sichergestellt, dass Tastatur-Nutzer:innen nicht versehentlich mit dem Formular interagieren, während es sich außerhalb des Bildschirms befindet. Der Inhalt wird auch vor Screenreadern verborgen.

Auch das native <dialog> Element macht davon Gebrauch. Wenn ihr einen Modaldialog mit .showModal() öffnet, wird der Browser automatisch alle anderen Inhalte inaktiv machen. Mehr Infos liefert mein Blogartikel „Warum du das native Dialog-Element nutzen solltest“.

Beispiel: Animiertes Navigations-Menü

Ich habe eine Demo für ein animiertes Navigationsmenü erstellt. Dort nutze ich das inert Attribut für die versteckten Untermenüs. Das Ganze funktioniert perfekt für Tastatur- und Screenreader-Nutzer:innen.

Das Navigationsmenü ist als ungeordnete Liste innerhalb eines nav-Elements aufgebaut. Der HTML-Code für einen Menüpunkt und sein verborgenes Untermenü sieht wie folgt aus:

<button type="button" aria-expanded="false" aria-controls="sub_menu_research">
    Research
</button>
<div id="sub_menu_research" class="subMenu" inert>
    <ul>
        <li><a href="/black-holes">Black Holes</a></li>
        <li><a href="/climate-change">Climate Change</a></li>
        <li><a href="/modern-way-of-work">Modern Way of Work</a></li>
    </ul>
</div>

Im CSS-Code referenziere ich auf das inert-Attribut, um das Untermenü auch visuell auszublenden:

.subMenu {
    overflow: hidden;
}

.subMenu[inert] > ul {
    transform: translateY(-100%);
}

Wenn der Menüpunkt aktiviert wird, wird das inert Attribut entfernt und das Untermenü eingeblendet:

.subMenu:not([inert]) > ul {
    transform: translateY(0);
}

Die Gleit-Animation könnt ihr ziemlich einfach und unkompliziert mit der CSS-Eigenschaft transition erzeugen:

.subMenu > ul {
    transition: transform 0.4s ease-in-out;
}

Hier findet ihr den kompletten Quellcode.

Warum nicht mit `display: none` ?

Einige von euch denken jetzt vielleicht: „Warum sollte ich das inert-Attribut verwenden? Ich kann doch einfach alles mit display: none ausblenden!“ Ihr habt Recht. Wenn man die CSS-Eigenschaft display: none auf ein Element anwendet, wird es vom Browser nicht gerendert und wird vor assistiven Technologien verborgen. Der Nachteil: Ihr könnt das Element nicht mehr animieren.

Die Nutzung des inert Attributs bietet hingegen mehr Flexibilität. Ihr könnt euren Inhalt ein- und ausblenden, von der Seite reingleiten lassen oder jede erdenkliche anspruchsvolle Animation erstellen. Außerdem könnt ihr das Attribut für Inhalte verwenden, die zwar sichtbar sind, mit denen aber nicht interagiert werden soll. Zum Beispiel die teilweise sichtbare, vorherige bzw. nächste Folie in einem Karussell-Widget.

Browser-Unterstützung

Seit Version 112 unterstützt nun auch Firefox endlich das inert Attribut. Das bedeutet, dass nun alle modernen Browser dieses Feature unterstützen.

Na dann: Los geht’s! Lasst uns coole Sachen damit bauen.

Wie das Description List Element die Accessibility und Entwickler-Erfahrung verbessert

Sun, 02 Apr 2023 00:00:00 GMT

Listen zählen zu den grundlegenden Bausteinen des Webs. Jede:r Web-Entwickler:in kennt die HTML-Elemente <ul> und <ol> für ungeordnete und geordnete Listen. Doch wenige kennen ihren nahen Verwandten <dl> , die Beschreibungsliste.

Ein typischer Anwendungsfall ist die Implementierung eines Glossars mit Begriffen und Definitionen. Tatsächlich kann man aber noch viel mehr damit machen. Jede Liste von Schlüssel-Wert-Paaren kann als Beschreibungsliste gestaltet werden. Es verbessert die DX, also Entwickler-Erfahrung, indem es den Code besser lesbar macht. Und es verbessert die Barrierefreiheit eurer Web-Inhalte.

Foto: © Ketut Subiyanto / pexels.com

Wir werfen einen Blick auf die Geschichte des Elements, wie es funktioniert und wie es sich auf die Barrierefreiheit auswirkt.

Eine kurze Geschichte des Beschreibungsliste-Elements

Das <dl> Element gibt es seit HTML+ im Jahr 1993. Das Dokument definierte das Element noch als „Definitionsliste“:

A definition list is a list of terms and corresponding definitions. Definition lists are typically formatted with the term flush-left and the definition, formatted paragraph style, indented after the term.

Diese enge Definition ist auch heute noch in vielen Köpfen präsent. Aber sie gilt nicht mehr. Die Definition des Elements wurde in HTML5 geändert, wodurch es vielseitiger wurde:

The dl element represents an association list consisting of zero or more name-value groups (a description list). […] Name-value groups may be terms and definitions, metadata topics and values, questions and answers, or any other groups of name-value data.

Das bedeutet, dass das Element zur Kennzeichnung einer beliebigen Liste von Schlüssel-Wert-Paaren verwendet werden kann. Zum Beispiel eine Liste von Metadaten über einen Kunden: Name, Adresse, Telefonnummer usw.

Wie ihr das `<dl>` Element verwendet

Die Beschreibungsliste umfasst eine Liste an Begriffen und Beschreibungen, die mit den HTML-Elementen <dt> und <dd> definiert werden. Hier ein Beispiel einer Liste an Metadaten:

<dl>
    <dt>Account Owner</dt>
    <dd>Martina Musterfrau</dd>
    <dt>Banking Institute</dt>
    <dd>Musterbank</dd>
    <dt>IBAN</dt>
    <dd>AT12 3456 7891 2345 6789</dd>
    <dt>Telephone</dt>
    <dd>+43 1234 56 78</dd>
</dl>

Die semantischen HTML-Tags vermitteln wichtige Informationen an assistive Technologien. Screenreader können in der Liste navigieren und die Beziehung zwischen Begriff und Beschreibung vermitteln. Aber auch Web-Entwickler:innen profitieren von dem semantischen Markup. Stellt euch vor, das Beispiel oben würde als Abfolge von <div> Elementen implementiert:

<div class="metadata">
    <div class="term">Account Owner</div>
    <div class="description">Martina Musterfrau</div>
    <div class="term">Banking Institute</div>
    <div class="description">Musterbank</div>
    <div class="term">IBAN</div>
    <div class="description">AT12 3456 7891 2345 6789</div>
    <div class="term">Telephone</div>
    <div class="description">+43 1234 56 78</div>
</div>

Ich hoffe, ihr stimmt mir zu: Semantisches HTML ist eindeutig leichter zu verstehen und ihr könnt damit besser arbeiten. Ihr könnt die semantischen Tag-Namen auch für aussagekräftige und leicht verständliche CSS-Selektoren nutzen. Lest meinen Artikel „3 Gründe, warum auch Web-Entwickler:innen von Barrierefreiheit profitieren“.

Styling der Description List

Das Standard-Design von Beschreibungslisten ist eher fad. Aber keine Sorge! Ihr könnt das Element frei mit CSS gestalten. Die HTML-Spezifikation erlaubt es, jedes Schlüssel-Wert-Paar in ein <div> Element zu verpacken.

<dl>
    <div>
        <dt>Account Owner</dt>
        <dd>Martina Musterfrau</dd>
    </div>
    <div>
        <dt>Banking Institute</dt>
        <dd>Musterbank</dd>
    </div>
    <div>
        <dt>IBAN</dt>
        <dd>AT12 3456 7891 2345 6789</dd>
    </div>
</dl>

Diese Struktur des Inhalts erlaubt uns, ein responsives, horizontales Layout mit CSS-Flexbox zu gestalten:

dl {
    display: flex;
    flex-wrap: wrap;
    gap: 1rem;
}

dl > div {
    flex-grow: 1;
}

dt {
    color: #6e2755;
    font-size: 0.9rem;
    font-weight: bold;
}

dd {
    font-size: 1rem;
    margin-inline-start: 0;
}

So sieht die Liste am Ende aus:

See the Pen Flexbox styled Description List by Alexander Lehner (@alexlehner86) on CodePen.

Screenreader-Unterstützung

Das Beschreibungsliste-Element macht eure Inhalte besser zugänglich, insbesondere für Screenreader-Nutzer:innen. Es gibt kleine Unterschiede zwischen Browsern und Screenreadern, aber insgesamt ist die Unterstützung ziemlich gut. Adrian Roselli hat für seinen Artikel „Updated Brief Note on Description List Support“ ausführliche Screenreader-Tests durchgeführt.

Ich will seiner Analyse nur einen Gedanken hinzufügen: Screenreader sind auch nur Software. Programme können Bugs haben oder Features nicht vollständig implementieren (wie etwa den korrekten Umgang mit dem <dl> Element). Aber das sollte uns nicht davon abhalten, dieses Feature in der Web-Entwicklung einzusetzen. Vor allem dann, wenn absehbar ist, dass die Screenreader-Hersteller die Fehler in naher Zukunft beheben werden.

Update am 18.04.2025

Link zum aktualisierten Blogartikel von Adrian Roselli eingefügt.

Checkliste für barrierefreie UI-Komponenten-Bibliotheken

Wed, 22 Mar 2023 00:00:00 GMT

Barrierefreiheit ist eine Entscheidung. Designer:innen können Farben mit ausreichendem Kontrast verwenden oder Farben aus rein ästhetischen Gründen wählen. Web-Entwickler:innen können eine Schaltfläche mit dem nativen button Tag implementieren oder stattdessen das generische div Tag verwenden.

Idealerweise wird Barrierefreiheit von Anfang an berücksichtigt. In den Anforderungen sind die Bedürfnisse von Menschen mit Behinderungen klar formuliert. Designer:innen erstellen Mockups, die diese Anforderungen erfüllen. Die Entwickler:innen implementieren die Funktionen mit semantischem Markup. Tester:innen überprüfen, ob die Webinhalte die Anforderungen erfüllen.

In der Realität wird Barrierefreiheit oft zu spät berücksichtigt. Dies kann besonders problematisch sein, wenn es um UI-Komponenten-Bibliotheken geht. Ich zeige euch, wie ihr die Barrierefreiheit der Bibliothek prüft, bevor ihr die erste Codezeile schreibt. Und was ihr bei der Arbeit mit UI-Komponenten beachten solltet.

Foto: © Alena Darmel / pexels.com

Die Vorteile von UI-Bibliotheken

HTML-Elemente sind die Grundbausteine einer jeden Website. Sie decken aber nicht alle Arten von Inhalten und möglichen Anwendungsfällen ab. Komplexe UI-Muster wie Akkordeons, Karussells oder Tabs erfordern ohnehin individuelle Implementierungen.

Um die Entwicklung zu beschleunigen und ein einheitliches Erscheinungsbild zu gewährleisten, verwendet eine moderne Webanwendung meist eine UI-Komponenten-Bibliothek. Diese besteht aus einer Reihe von Design-Elementen, die ihr in eurer Anwendung verwenden könnt. Meistens könnt ihr auch ein Farbthema anwenden und die Funktionalität der Komponenten anpassen.

Es gibt hunderte verschiedene Bibliotheken für die großen Web-Frameworks wie Angular, React oder Vue.js. Zum Beispiel, wenn euch das Material-Designsystem gefällt, könnt ihr Angular Material, Material UI oder Material Components Vue verwenden.

Die Barrierefreiheit der Bibliothek prüfen

Hier ist eine Checkliste für die Auswahl einer barrierefreien UI-Komponenten-Bibliothek:

Wird Barrierefreiheit auf der Website oder in der Dokumentation der Bibliothek erwähnt? Auf der Homepage von Angular Material heißt es zum Beispiel: „Internationalisierte und barrierefreie Komponenten für alle.“
Wird in der Dokumentation erklärt, ob und wie die Komponenten barrierefrei implementiert wurden? Die Dokumentation von Angular Material enthält eigene Abschnitte zur Barrierefreiheit für jede Komponente.
Die Dokumentation enthält in der Regel Demoseiten und Beispiele für die verschiedenen Komponenten. Überprüft das Markup und die Barrierefreiheits-Eigenschaften mithilfe der Entwicklertools des Browsers. Testet mit assistiven Technologien wie der Tastatur und verschiedenen Desktop- und mobilen Screenreadern.

Keine Garantie für komplette Barrierefreiheit!

Die Auswahl einer barrierefreien UI-Komponenten-Bibliothek ist ein wichtiger erster Schritt, um eure Web-Applikation barrierefrei zu gestalten. Aber sie ist keine Garantie dafür. Jedes Mal, wenn ihr eine Komponente auf einer Seite verwendet, solltet ihr die folgenden Fragen beantworten:

Wo und wie wird die Komponente verwendet? Denkt über den Kontext und die Reihenfolge der Inhalte nach.
Steht die Art der Verwendung im Einklang mit dem eigentlichen Zweck der Komponente? Oder wollt ihr nur ein bestimmtes Erscheinungsbild erreichen?

Die visuelle Darstellung des Inhalts sollte nicht bestimmen, welche Komponente ihr verwendet. Es ist einfach, ein bestimmtes Design mit CSS anzuwenden. Aber es ist fast unmöglich oder zumindest sehr mühsam, das semantische Markup einer Komponente und die implementierte Tastaturinteraktion zu überschreiben.

Hier ein Beispiel: Die Komponente <mat-chip-listbox> von Angular Material bietet eine Mehrfach-Auswahlliste, die das Listbox-Pattern anwendet. Das semantische Markup vermittelt den assistiven Technologien, dass das Element mehrere Optionen bietet, von denen eine oder mehrere ausgewählt werden können. Die gesamte Auswahlliste erhält den Tastaturfokus über die TAB Taste. Mit den Pfeiltasten wird der Fokus auf die nächste oder vorherige Option gesetzt.

Stellt euch nun vor, euer Kunde sagt: „Mir gefällt das Design der Chips-Komponente. Ich möchte, dass diese Auflistung von Links genauso gestaltet wird!“ Glaubst du, dass diese Komponente wirklich für diesen Anwendungsfall geeignet ist?

Es liegt in unserer Verantwortung als Web-Entwickler:innen, die jeweils passende Komponente auszuwählen. Und dem vermeintlich einfachen Weg zu widerstehen, der zum Desaster werden würde! 😉

Responsives Komponenten-Design mit CSS Container Queries

Fri, 17 Feb 2023 00:00:00 GMT

Alles ist im Fluss. Modernes Webdesign muss eine scheinbar unendliche Vielfalt an Bildschirmgrößen berücksichtigen. Mit @media Queries können wir Elemente auf der Grundlage von Merkmalen des Browser-Viewports (Bildschirm-Breite etc.) gestalten.

Was aber, wenn wir wiederverwendbare Komponenten erstellen möchten, die sich an ihren Container anpassen? Etwa eine News-Karte, die sich über die gesamte Breite der Webseite erstrecken oder in eine schmale Spalte an der Seite passen kann. Das geht jetzt!

Mit CSS Container Queries können wir responsive, wiederverwendbare Komponenten entwerfen, die sich an den verfügbaren Platz anpassen. Seit dem Release von Firefox 110 wird das Feature nun von allen wichtigen Browsern unterstützt. Das ändert alles! Schauen wir uns an, wie es funktioniert.

Foto: © Pixabay / pexels.com

Die Größe eines Containers abfragen

Dank Container Queries können wir Styles auf Elemente anwenden, die auf der Größe ihres Containers und nicht auf dem Viewport basieren. Das Feature ist im CSS-Modul CSS Containment Module Level 3 definiert:

While media queries provide a method to query aspects of the user agent or device environment that a document is being displayed in (such as viewport dimensions or user preferences), container queries allow testing aspects of elements within the document (such as box dimensions or computed styles).

Wir können verschiedene Größenmerkmale von Containern wie width , height oder inline-size abfragen. Die Spezifikation umfasst auch Container Style Queries, die jedoch von den Browsern noch nicht unterstützt werden.

Um eine Komponente auf Basis ihrer Container-Größe zu stylen, müssen wir das übergeordnete Element mit der CSS-Eigenschaft container-type ausweisen. Es wird empfohlen, den Container auch mit container-name zu benennen. Hier ist ein Beispiel:

.news-card {
    container-type: inline-size;
    container-name: news-card;
}

Ihr könnt den Container-Typ und -Namen auch auf einmal mit der CSS-Kurzform container setzen:

.news-card {
    container: news-card / inline-size;
}

Jetzt können wir den Container mit der @container Deklaration abfragen und konditionale Styles definieren. Zum Beispiel, wenn die Breite des Containers unter einem bestimmten Schwellenwert liegt:

@container news-card (max-width: 25rem) {
    .card-image {
        flex-basis: 100%;
    }
}

Demo: Responsive News-Karte

Ich habe eine Demo auf CodePen erstellt, die eine News-Karten-Komponente zeigt. Wenn genügend Platz vorhanden ist, legt die Karte ihren Inhalt horizontal aus. Wenn die Breite des Containers unter einen bestimmten Schwellenwert fällt, wird der Text unter das Bild verschoben.

Öffne das Code-Beispiel CSS Container Queries Demo von Alexander Lehner (@alexlehner86) auf CodePen.

Weitere Lektüre

Es gibt noch viel mehr über Container Queries zu lernen. Seht euch die folgenden Anleitungen und Beispiele an:

Fazit

Ich bin total begeistert von CSS Container Queries! Dabei habe ich bisher kaum an der Oberfläche aller möglichen Anwendungsfälle gekratzt. Mein Ziel ist es, das Feature in mehr und mehr Projekten zu verwenden und mein Verständnis dafür laufend zu verbessern.

Eines ist aus meiner Sicht fix: Container Queries werden die Art und Weise wie wir CSS schreiben nachhaltig verändern. Welche Ideen und Anwendungsfälle habt ihr bereits mit dem Feature umgesetzt?

Bringe deine Layouts auf Linie mit CSS Subgrid

Sun, 29 Jan 2023 00:00:00 GMT

CSS Grid Layout ist ein zweidimensionales, rasterbasiertes Layout-System für Websites. Es erleichtert die Anordnung von Inhalten in Zeilen und Spalten sowie die Erstellung responsiver Layouts.

Wer mit Grid-Layouts vertraut ist, kennt wahrscheinlich das folgende Problem: Ein Grid-Container kann in einem anderen Grid platziert werden, um ein verschachteltes Grid-Layout zu erzeugen. Leider passt sich der Inhalt des untergeordneten Grids nicht automatisch an das übergeordnete Grid an. Aber keine Sorge! Wir können dieses Problem mit dem subgrid Feature lösen!

Foto: © RODNAE Productions / pexels.com

Die Subgrid-Funktion macht das Grid-Layout noch mächtiger und ermöglicht es, perfekt ausgerichtete Layouts zu erstellen. Ich habe eine Demo für einen typischen Anwendungsfall vorbereitet. Schauen wir uns an, wie das Ganze funktioniert.

Die Grundlagen des Grid-Layouts

Das Grid-Layout-System ist in der Spezifikation des CSS Grid Layout Moduls definiert:

A two-dimensional grid-based layout system, optimized for user interface design. In the grid layout model, the children of a grid container can be positioned into arbitrary slots in a predefined flexible or fixed-size layout grid.

Ihr könnt ein HTML-Element mit der CSS-Eigenschaft display: grid in einen Grid-Container verwandeln. Mit den Eigenschaften grid-template-rows und grid-template-columns könnt ihr die Zeilen und Spalten definieren.

Es gibt zahlreiche Möglichkeiten, ein Raster zu definieren und es mit Inhalten zu füllen. Alle möglichen Einstellungen und Szenarien aufzulisten, würde den Rahmen dieses Artikels sprengen. Wenn ihr mehr erfahren möchtet, kann ich die Tutorials „A Complete Guide to CSS Grid“ und „Learn CSS Grid“ empfehlen.

Was ist ein Subgrid und wozu ist es gut?

Das Subgrid-Feature wurde im CSS Grid Layout Modul Level 2 hinzugefügt. Die Spezifikation besagt:

A nested grid can defer the definition of its rows and/or columns to its parent grid container, making it a subgrid. In this case, the grid items of the subgrid participate in sizing the parent grid, allowing the contents of both grids to align.

Um ein Subgrid zu definieren, setzt ihr einfach den Wert subgrid für die Eigenschaft grid-template-rows oder grid-template-columns . Das war’s! Das verschachtelte Grid verwendet nun die vom übergeordneten Grid definierten Spalten und/oder Zeilen und richtet seinen Inhalt entsprechend aus.

Demo: Punk API Bier-Liste

Ich habe eine React-Demo erstellt, die eine Liste von Bieren in einem Raster mit drei gleichgroßen Spalten anzeigt. Jede Zelle enthält Informationen über ein bestimmtes Bier. Seht euch die Live-Version hier an (am besten auf einem Desktop-Bildschirm).

Der übergeordnete Grid-Container

Die Demo verwendet eine ungeordnete Liste als übergeordneten Grid-Container. Hier ist der JSX-Code:

<ul className={styles.beerGrid}>
    {items.map(item => (
        <li key={item.id}>
            <BeerItemDetails item={item} />
        </li>
    ))}
</ul>

In meinem CSS-Code verwende ich die Funktionen repeat und minmax , um ein Raster mit drei Spalten und einer variablen Anzahl von Zeilen zu erstellen. Jede Spalte ist gleich groß und hat eine Mindestbreite von 15rem .

ul.beerGrid {
    display: grid;
    gap: 2.5rem;
    grid-template-columns: repeat(3, minmax(15rem, 1fr));
    grid-template-rows: auto;
    list-style: none;
}

Die Bier-Infokarten zu Subgrids machen

Jedes Listenelement wird mit der React-Komponente BeerItemDetails gerendert. Diese Komponente besteht aus einem Kopfbereich (hgroup Element) und einem Detailbereich (div Element):

<hgroup className={styles.heading}>
    <h2>{item.name}</h2>
    <p>{item.tagline}</p>
</hgroup>
<div className={styles.flexRow}>
    <!-- details -->
</div>

In meinem CSS-Code definiere ich die Listenelemente als Grid-Container mit zwei Zeilen (grid-row: span 2 ). Die Deklaration grid-template-rows: subgrid weist den Browser an, die Kopfzeile und den Detailbereich jeder Bier-Infokarte aufeinander auszurichten, wenn diese in derselben Zeile platziert werden.

ul.beerGrid li {
    display: grid;
    grid-template-rows: subgrid;
    grid-row: span 2;
    gap: 0;
}

Einfache Entwicklung mit CSS Grid Inspector

Ich habe den CSS Grid Inspector (Firefox DevTools) intensiv genutzt. Dieses geniale Werkzeug hebt die Zeilen und Spalten eures Rasters hervor und macht es einfacher zu verstehen, wie das übergeordnete Grid und seine Subgrids zusammenpassen.

Die Chrome DevTools enthalten ein ähnliches Tool. Aber als leidenschaftlicher Firefox-Nutzer musste ich natürlich das Firefox-Tool als erstes nennen. 😉

Browser-Unterstützung und progressive Verbesserung

Zum Zeitpunkt der Veröffentlichung dieses Beitrags unterstützen nur Safari und Firefox das Subgrid-Feature. Aber keine Sorge! Ihr müsst nicht warten, bis Chrome und Edge aufholen.

Wendet das Prinzip der progressiven Verbesserung an, um ein Basis-Layout bereitzustellen und gleichzeitig die Vorteile des Subgrid-Features in unterstützenden Browsern zu nutzen. Dazu verwenden wir @supports , um die Browserunterstützung zu prüfen, bevor wir den Wert subgrid setzen:

@supports (grid-template-rows: subgrid) {
    ul.beerGrid li {
        display: grid;
        grid-template-rows: subgrid;
    }
}

Nützliche Links

Gestalte ein barrierefreies News-Karussell als Angular Standalone Component

Sun, 15 Jan 2023 00:00:00 GMT

Ich liebe Karussells! Die bunten Freizeitpark-Attraktionen mit Tierfiguren und Wägelchen sind oft wunderschön gestaltet. Kinder können Stunden über Stunden damit verbringen und sich im Kreis drehen. Die pure Freude!

Kann ich dasselbe über Karussell-UI-Komponenten sagen? Nicht wirklich. Ich mag die meisten Web-Karussells nicht. Vor allem, wenn sie automatisch den Inhalt wechseln. Außerdem sind die meisten von ihnen ein Accessibility-Albtraum. Also habe ich mir gedacht: Das geht doch besser!

Foto: © Alexander Nadrilyanski / pexels.com

Ich habe ein News-Karussell als eigenständige Angular-Komponente erstellt. Die Komponente ist barrierefrei, responsiv und bietet flüssige Animationen. Werfen wir einen Blick darauf, wie es aufgebaut ist und funktioniert.

Demo: Barrierefreies News-Karussell

Meine Demo-Anwendung zeigt eine Liste von Nachrichten an, jede mit Überschrift, einem Textausschnitt und einem Hintergrundbild. Die Nutzer:innen können sich mit Wischgesten oder den Navigations-Schaltflächen von Nachricht zu Nachricht bewegen.

Anforderungen an Design und Barrierefreiheit

Es gibt kein natives HTML-Element für Web-Karussells. Deshalb gibt es so viele verschiedene Implementierungen. Zumindest hat das W3C in seinem „ARIA Authoring Practices Guide“ grundlegende Anforderungen definiert. Das Karussell-Pattern lautet:

A carousel presents a set of items, referred to as slides, by sequentially displaying a subset of one or more slides. Typically, one slide is displayed at a time, and users can activate a next or previous slide control that hides the current slide and “rotates” the next or previous slide into view.

Diese abstrakte Definition gilt sowohl für einfache Bild-Rotatoren als auch für Diashows mit komplexem Inhalt. Im Allgemeinen sollten Web-Karussells die folgenden Anforderungen erfüllen:

Es sollte assistiven Technologien seine Struktur vermitteln.
Es sollte den aktuell aktiven Inhalt anzeigen, sowohl visuell als auch für assistive Technologien.
Die Nutzer:innen sollten nicht gezwungen sein, das Karussell mit Wischgesten zu bedienen. Es sollte simple Steuerelemente bieten, die man anklicken oder mit der Tastatur bedienen kann.
Screenreader-Nutzer:innen sollten über dynamische Inhaltsänderungen (z.B. der Wechsel zur nächsten Slide) mittels Statusmeldung informiert werden.
Wenn das Karussell den angezeigten Inhalt automatisch wechselt, sollte es auch eine Schaltfläche zum Anhalten und erneuten Starten der Rotation haben.

Ich hasse Bewegungen und Animationen, die automatisch starten. Deshalb wechselt der angezeigte Inhalt in meinem News-Karussell nicht von selbst. Somit braucht es auch keine Pausentaste.

Struktur und semantische Auszeichnung

Der Karussell-Container

Die ARIA-Spezifikation enthält keine carousel Rolle. Daher müsst ihr role=“region” definieren und die benutzerdefinierte Beschreibung aria-roledescription=“Karussell” bereitstellen. Ein verständliches Label wird durch das Attribut aria-label bereitgestellt.

In meiner NewsCarouselComponent nutze ich HostBinding, um diese Werte für den Container der Karussell-Komponente zu setzen:

/**
* The aria label for the carousel container.
* It should convey to screenreader users what the carousel is about.
*/
@HostBinding('attr.aria-label') @Input() public carouselLabel!: string;
@HostBinding('attr.role') role = 'region';
@HostBinding('attr.aria-roledescription') get carouselDescription() { return this.config.carouselDescription; }

Das Karussell enthält zwei Icon-Schaltflächen, um zur vorherigen oder nächsten Slide zu navigieren. Programmatisch ermittelbare Labels werden mit dem Attribut aria-label für die button Tags definiert.

Der Slide-Container

Für jeden Slide-Container ist role=“group” und aria-roledescription=“Slide” gesetzt. Das Attribut aria-label des Containers gibt die Nummer der Slide und die Gesamtanzahl an (z.B. „2 von 5“).

<div
    *ngFor="let item of newsItems; let i = index"
    class="news-item"
    role="group"
    [attr.aria-roledescription]="config.slideDescription"
    [attr.aria-label]="(i + 1) + ' ' + config.slideLabel + ' ' + newsItems.length"
>
    <!-- slide content -->
</div>

Der Nachteil von benutzerdefinierten Rollenbeschreibungen ist, dass sie nicht automatisch von Screenreadern übersetzt werden. Wenn ihr eine mehrsprachige Website erstellt, müsst ihr dies berücksichtigen. Meine NewsCarouselComponent hat einen Input-Wert config mit Standardwerten in Englisch, die überschrieben werden können.

@Input() public config: NewsCarouselConfig = {
    carouselDescription: 'carousel',
    slideDescription: 'slide',
    slideLabel: 'of',
    nextButtonLabel: 'Next slide',
    previousButtonLabel: 'Previous slide',
}

Vermeide Listen-Elemente

Häufig werden Slides als Liste ausgezeichnet. Screenreader lesen die Anzahl der Elemente in einer Liste vor, ignorieren aber ausgeblendete Listenelemente. In meiner Komponente ist nur die sichtbare Slide auch für assistive Technologien zugänglich. Die anderen Slides werden visuell und programmatisch mit der CSS-Eigenschaft visibility: hidden verborgen.

Wenn ich alle Slides als <li> Elemente innerhalb einer ungeordneten Liste (<ul> ) implementiert hätte, würde der Screenreader das Vorhandensein einer Liste mit nur einem Element verkünden. Das entspricht nicht der tatsächlichen Anzahl an Slides und wäre für die Nutzer:innen verwirrend.

ARIA Live-Region

Das Karussell sollte dynamische Inhaltsänderungen über Statusmeldungen an Screenreader-Nutzer:innen kommunizieren. Zunächst habe ich versucht, das Container-Element für alle Slides zur ARIA Live-Region zu machen. Das Ergebnis war nicht optimal.

Aufgrund der Implementierung der Slide-Animation mit Hilfe der CSS-Eigenschaft visibility las der Screenreader die Überschrift der neuen Slide mehrmals vor oder las die ausgeblendete Slide erneut vor.

Ich habe verschiedene Ansätze mit Eigenschaften wie aria-busy und aria-relevant ausprobiert. Sie funktionierten immer nur bei einigen Browser- und Screenreader-Kombinationen. Daher entschied ich mich schließlich für den einfachen Ansatz, eine visuell verborgene ARIA Live-Region an das Ende des Karussell-Containers zu setzen. Das ist zwar ein bisschen redundant, aber es funktioniert!

<div
    class="active-slide-live-region"
    aria-live="polite"
>
    {{config.slideDescription + ' ' + (activeSlideIndex + 1) + ' ' + config.slideLabel + ' ' + newsItems.length + ':'}}
    {{newsItems[activeSlideIndex].heading}}
</div>

Tastaturbedienung und Swipe-Gesten

Ich liebe wischen! Wenn ich online auf ein Karussell stoße, versuche ich instinktiv, über den Bildschirm zu wischen. Swipe-Gesten an sich sind nicht böse. Aber ein Web-Karussell, das nur durch Wischgesten bedienbar ist, schon!

Für viele Menschen mit motorischer Beeinträchtigung sind Wischgesten nicht barrierefrei. Sie bevorzugen einfach klickbare Alternativen wie eine Schaltfläche. Außerdem benötigen Tastatur-Nutzer:innen Steuerelemente, die sie mit der Tabulatortaste ansteuern und mit der Leer- oder Eingabetaste aktivieren können.

Deshalb versuche ich, alle glücklich zu machen! Meine Angular-Komponente implementiert Wischgesten mit der Hammer.js-Bibliothek und enthält auch Schaltflächen, um zur vorherigen oder nächsten Slide zu navigieren.

<div class="news-carousel-controls">
    <button
        type="button"
        [attr.aria-label]="config.previousButtonLabel"
        (click)="this.showPreviousSlide()"
    >
        <!-- arrow icon -->
    </button>
    <button
        type="button"
        [attr.aria-label]="config.nextButtonLabel"
        (click)="this.showNextSlide()"
    >
        <!-- arrow icon -->
    </button>
</div>

Slide-Übergänge mit CSS-Animationen

Ich wollte schöne Übergänge zwischen den Slides mit sanften Ein- und Ausblend-Animationen erstellen. Angular bietet ein eigenes Animationsmodul. Mir war jedoch wichtig, die Build-Größe klein zu halten und gleichzeitig effizient zu sein. Deshalb habe ich mich für CSS-Animationen entschieden.

Das Erstellen von Animationen mit CSS ist super einfach und elegant. Zuerst definiert ihr Keyframes für eure benannten Animationen. Jeder Keyframe beschreibt, wie das animierte Element zu einem bestimmten Zeitpunkt während der Animationssequenz dargestellt werden soll.

// Keyframes for slide animation from left to right
@keyframes slide-in-from-left {
    0% {
        transform: translateX(-100%);
    }
    100% {
        transform: translateX(0%);
    }
}

@keyframes slide-out-to-right {
    0% {
        transform: translateX(0%);
        visibility: visible;
    }
    100% {
        transform: translateX(100%);
        visibility: hidden;
    }
}

Dann wendet ihr diese Animationen mithilfe der CSS-Eigenschaft animation auf bestimmte Slides an. Auf diese Weise könnt ihr eine Vielzahl von Animations-Eigenschaften (z.B. Name, Dauer, Richtung) in einer einzigen CSS-Regel definieren.

app-news-carousel .news-carousel-items.animate-from-left .news-item {
    &.active {
        animation: slide-in-from-left 0.5s forwards;
    }

    &.moved-out {
        animation: slide-out-to-right 0.5s forwards;
        border-left: 0.125rem solid white;
    }
}

In dem obigen Beispiel werden zwei HTML-Elemente animiert: Das Element mit der Klasse active gleitet von links ins Bild, während das andere Element mit der Klasse moved-out nach rechts aus dem Bild gleitet.

Responsives Design und benutzerdefiniertes Styling

Flexibles Layout mit `max-width` und Container Queries

Wenn ihr die Karussell-Komponente verwendet, könnt ihr die CSS-Variable —news-carousel-max-width setzen, um eine Basisbreite für den Karussell-Container zu definieren. Wenn keine Variable gesetzt ist, wird der Fallback-Wert der var() Funktion verwendet.

app-news-carousel {
    height: var(--news-carousel-height, 25rem);
    width: var(--news-carousel-max-width, 50rem);
    max-width: 100%;
}

Mithilfe von max-width: 100% stellen wir sicher, dass die Breite des Containers durch den verfügbaren Raum seines übergeordneten Elements begrenzt wird. Auf diese Weise beansprucht das Karussell nie mehr Platz als die Viewport-Breite des Geräts.

Außerdem verwende ich CSS Container Queries, um das Styling des Karussells anzupassen, wenn die Breite des Containers unter einem bestimmten Schwellenwert liegt. Dieses neue, mächtige Feature wird bald von allen modernen Browsern unterstützt werden. Ich werde in einem separaten Blog-Beitrag näher darauf eingehen.

@container news-carousel (max-width: 28rem) {
    app-news-carousel .news-item .slide-text {
        bottom: 0.5rem;
        border-radius: 0.5rem;
        width: calc(100% - 1rem);

        p {
            display: none;
        }
    }
}

Eigenes Styling mit CSS-Variablen

CSS-Variablen sind ideal für Komponenten-Bibliotheken. Sie können ein Standard-Styling definieren und den Nutzer:innen erlauben, bestimmte Werte mit den entsprechenden Variable zu überschreiben. Eine Applikation kann die folgenden Styles meiner NewsCarouselComponent über CSS-Variablen anpassen:

—news-carousel-height : Die Höhe des Karussells.
—news-carousel-max-width : Legt die maximale Breite des Karussells fest. Die tatsächliche Breite des Karussells ist abhängig von seinem Container.
—news-carousel-button-background : Der Hintergrund (Farbe) der Navigations-Schaltflächen.
—news-carousel-button-color : Die Farbe des Pfeilsymbols in den Navigations-Schaltflächen.
—carousel-text-background : Der Hintergrund (Farbe) des Textcontainers der Slides.
—carousel-text-color : Die Schriftfarbe des Textcontainers der Slides.
—news-carousel-slide-focus-color : Die Farbe des Fokusindikators der Slides.

Was es noch zu sagen gibt

Ich möchte eines klarstellen: Meine Karussell-Komponente stellt nur eine von mehreren Möglichkeiten dar, ein barrierefreies, responsives Karussell zu implementieren. Natürlich bin ich davon überzeugt, dass meine Implementierung einfach großartig ist. Aber natürlich gibt es auch andere valide Ansätze.

Web-Standards, Browser und assistive Technologien entwickeln sich ständig weiter. In ein paar Jahren oder vielleicht sogar in ein paar Monaten könnte es also eine bessere Lösung geben. Ich kann es kaum erwarten, sie zu sehen! 😊

Nützliche Links

Ein Rückblick auf 2022 — Mein erstes Jahr als Blogger

Thu, 29 Dec 2022 00:00:00 GMT

Vor einem Jahr machte ich den Kurs „Full Stack for Front-End Engineers” von Frontend Masters. Ich richtete meinen eigenen Webserver ein, kaufte eine Domain und startete mithilfe von Gatsby einen Blog über Webentwicklung. 12 Monate und 18 Blogartikel später möchte ich das Jahr Revue passieren lassen und mir Ziele für 2023 setzen.

Foto: © cottonbro studio / pexels.com

Das regelmäßige Schreiben macht mir großen Spaß. Tatsächlich bin ich 2006 nach Wien übersiedelt, um Journalismus zu studieren. Ich habe auch für Medienunternehmen gearbeitet, aber es war nicht das Richtige für mich. Also bin ich zum Coden zurückgekehrt. Jedenfalls fühlt es sich gut an, meine beiden Leidenschaften irgendwie vereinen zu können.

Was ich dieses Jahr gelernt habe

Erstens, wie ich meinen eigenen Webserver einrichte, eine Domain verwalte, ein SSL-Zertifikat erstelle und so weiter. Es war ein gutes Gefühl, meine Komfortzone zu verlassen und etwas Neues auszuprobieren!
Wie ich meinen Build/Deployment-Workflow mit GitHub Actions automatisieren kann.
Dass ich gerne mit neuen Features wie etwa dem nativen <dialog> HTML-Element oder der :focus-visible CSS-Pseudo-Klasse experimentiere. Ich liebe die Herausforderung, das Konzept und die Funktionalität möglichst einfach zu erklären und mit einer Demo zu veranschaulichen.
Ich habe mich mit RSS vertraut gemacht und gelernt, einen eigenen RSS-Feed bereitzustellen. Ihr könnt meinen Blog hier abonnieren.

Meine Lieblings-Blogartikel

Es ist schwer, aus den 18 Blogartikeln, die ich in diesem Jahr geschrieben habe, meine Favoriten auszuwählen. Deshalb habe ich einfach drei Beiträge ausgewählt, die ich für besonders relevant und spannend halte:

„Häufige Probleme mit ARIA und wie ihr diese vermeidet”: Ich finde es toll, dass mehr und mehr Unternehmen die Bedeutung von Barrierefreiheit erkennen. Leider übertreiben es einige mit ARIA-Attributen und verschlimmern oft die Barrierefreiheit ihrer Website. Ich hoffe, mein Blogbeitrag hilft Entwickler:innen, ARIA besser zu verstehen und schlechte Praktiken zu vermeiden.
„CSS Cascade Layers in Angular verwenden”: 2022 war ein fantastisches Jahr für CSS. Zu den neuen, von modernen Browsern unterstützten Features zählen CSS Cascade Layers. Sie sind ein mächtiges Werkzeug zur Ordnung von CSS-Styles und helfen, nervige Konflikte aufgrund der Spezifität oder Reihenfolge der Deklaration zu vermeiden.
„Licht aus! Wie blinde Menschen im Internet surfen”: Vor ein paar Wochen habe ich für einen neuen Kunden einen Workshop zum Thema Barrierefreiheit gehalten. Ich öffnete meine Demo-Seite, färbte alles schwarz und benutzte einen Screenreader, um auf der Website zu navigieren. Die Teilnehmer waren wirklich erstaunt. Einer von ihnen sagte: „Ich wusste gar nicht, dass blinde Menschen das Internet überhaupt nutzen können!” Das hat mir wieder einmal gezeigt: Die Menschen müssen die Auswirkungen von Behinderungen selbst erfahren, um Barrierefreiheit wirklich zu schätzen.

Ziele und Erwartungen für 2023

Als Web-Entwickler bin ich schon sehr gespannt auf das neue Jahr. Es kommen eine Menge neuer Features auf uns zu, die uns das Leben leichter machen sollten. Als ein Mensch auf diesem Planeten hoffe ich einfach nur, dass der schreckliche Krieg in der Ukraine endet. Und dass die Menschheit endlich den Klimawandel ernsthaft bekämpft.

Wie auch immer, hier ist meine Liste an Zielen für 2023 sowie Themen, über die ich im kommenden Jahr schreiben möchte:

Ich will Interaktionen in sozialen Netzwerken in Webmentions umwandeln und in meinem Blog anzeigen.
Flexbox oder Grid? Ich möchte mein Wissen über CSS-Layouts vertiefen und mit neuen Features wie CSS Subgrid experimentieren.
Ich möchte mich als Requirements Engineer und Software Architekt weiterentwickeln und über meine Erfahrungen schreiben.
An Entwickler-Konferenzen teilnehmen und vielleicht mal einen Vortrag halten. Lokale Events veranstalten wäre auch cool.
Zu guter Letzt: Weiter über Barrierefreiheit schreiben.

Ein Gespräch mit ChatGPT über Web-Barrierefreiheit und populäre Mythen

Sat, 10 Dec 2022 00:00:00 GMT

Künstliche Intelligenz ist auf dem Vormarsch. Ob selbstfahrende Autos, Bilderzeugung oder Chatbots – KI wird immer mehr Teil unseres Alltags. Der Gesprächsagent ChatGPT zeigt, wie hochentwickelt und menschenähnlich KI sein kann.

Viele Menschen haben bereits Gespräche mit der KI geführt. Sie beeindruckt mit durchdachten und gut formulierten Antworten. Aber wie reagiert der Chatbot auf eher zugespitzte Fragen und vorgefasste Meinungen? Um diese Frage zu beantworten, habe ich mich mit ChatGPT über einige weit verbreitete Barrierefreiheits-Mythen unterhalten.

Ich habe das Gespräch auf Englisch geführt und danach vom KI-Übersetzungsdienst Deepl.com ins Deutsche übertragen lassen (die KI gendert leider nicht). Die Unterhaltung ist in mehrere Abschnitte unterteilt, beginnend mit allgemeinen Fragen, gefolgt von vier weit verbreiteten Mythen über Barrierefreiheit. Am Ende des Artikels werde ich meine Gedanken zu ChatGPT mit euch teilen.

Mein Gespräch mit ChatGPT

Ich: Hallo ChatGPT! Alle reden über Barrierefreiheit im Internet. Können Sie das Konzept in einfachen Worten erklären?

ChatGPT: Klar! Unter Barrierefreiheit im Web versteht man die Praxis, Websites und Webanwendungen für Menschen mit Behinderungen nutzbar zu machen. Dazu gehören unter anderem Menschen mit visuellen, auditiven, motorischen und kognitiven Beeinträchtigungen. Ziel der Barrierefreiheit im Internet ist es, allen Nutzern den Zugang zu den Inhalten und Funktionen einer Website zu ermöglichen, unabhängig von ihren jeweiligen Behinderungen.

Dies kann erreicht werden, indem eine Reihe von Richtlinien und Standards befolgt werden, wie z. B. die Web Content Accessibility Guidelines (WCAG), die vom World Wide Web Consortium (W3C) entwickelt wurden. Diese Leitlinien enthalten eine Reihe spezifischer Kriterien, die Websites und Webanwendungen erfüllen sollten, um als zugänglich zu gelten. Durch die Einhaltung dieser Leitlinien können Website-Entwickler und -Designer sicherstellen, dass ihre Websites von einer Vielzahl von Nutzern verwendet werden können.

Ich: Ich befürchte, dass die Webentwicklung dadurch teurer und übermäßig kompliziert wird. Was ist Ihre Meinung?

ChatGPT: Die Einbeziehung der Barrierefreiheit in die Gestaltung und Entwicklung einer Website oder Webanwendung muss nicht teuer oder übermäßig kompliziert sein. In der Tat kann die Einhaltung der Richtlinien für Barrierefreiheit im Internet oft die allgemeine Benutzerfreundlichkeit für alle Benutzer verbessern, nicht nur für Menschen mit Behinderungen. So kann beispielsweise die Verwendung klarer und anschaulicher Überschriften und Beschriftungen auf Formularen die Navigation und Nutzung der Website für alle erleichtern, nicht nur für Menschen mit Sehbehinderungen. Darüber hinaus kann die Verwendung einer geeigneten Formatierung und Struktur die Interpretation und das Lesen des Seiteninhalts durch Bildschirmlesesoftware erleichtern, was wiederum blinden oder sehbehinderten Nutzern zugute kommt.

Mythos #1: Barrierefreiheit betrifft nur eine kleine Gruppe von Nutzer:innen

Ich: Ok, das hört sich gut an. Was sind die wichtigsten Vorteile einer barrierefrei gestalteten Website?

ChatGPT: Eine barrierefrei gestaltete Website hat mehrere Vorteile. Für Nutzer mit Behinderungen ist der offensichtlichste Vorteil die Möglichkeit, auf die Inhalte und Funktionen der Website zuzugreifen und sie zu nutzen. Dies kann ihre allgemeine Erfahrung bei der Nutzung des Internets verbessern und es ihnen ermöglichen, an Online-Aktivitäten teilzunehmen, die ihnen vorher vielleicht nicht möglich waren.

Eine barrierefreie Website ist nicht nur für Menschen mit Behinderungen von Vorteil, sondern kann auch für Unternehmen und Organisationen von Nutzen sein. Eine barrierefreie Website kann zum Beispiel die Suchmaschinenoptimierung (SEO) der Website verbessern, so dass sie für Suchmaschinen besser sichtbar wird und möglicherweise mehr Besucher auf die Website gelangen. Eine barrierefreie Website kann auch das potenzielle Publikum für die Website vergrößern, da sie von einer größeren Anzahl von Nutzern verwendet werden kann. Dies kann besonders für Unternehmen und Organisationen von Vorteil sein, die sich an eine vielfältige Bevölkerung wenden oder gesetzlich verpflichtet sind, barrierefreie Dienstleistungen anzubieten.

Schließlich kann die Einbeziehung der Barrierefreiheit in die Gestaltung einer Website auch die allgemeine Benutzererfahrung für alle Benutzer verbessern, unabhängig von deren Behinderung. Dies kann zu einer höheren Kundenzufriedenheit und -treue sowie zu potenziellen Kosteneinsparungen führen, da der Bedarf an Kundensupport sinkt.

Ich: Ich bin mir nicht sicher. Ist Barrierefreiheit nicht nur für eine kleine Gruppe von Menschen von Vorteil?

ChatGPT: Es stimmt zwar, dass die Barrierefreiheit im Internet in erster Linie Nutzern mit Behinderungen zugute kommt, aber die potenzielle Zielgruppe für barrierefreie Websites ist eigentlich recht groß. Nach Angaben der Weltgesundheitsorganisation leben etwa 15 % der Weltbevölkerung mit irgendeiner Form von Behinderung. Das bedeutet, dass die potenzielle Zielgruppe für barrierefreie Websites, gemessen an der reinen Anzahl, sehr groß ist.

Darüber hinaus kann die Barrierefreiheit von Websites einer Vielzahl von Nutzern mit unterschiedlichen Behinderungen zugute kommen, z. B. mit Seh-, Hör-, Bewegungs- und kognitiven Beeinträchtigungen sowie Nutzern, die zwar keine dauerhafte, aber eine vorübergehende Beeinträchtigung (z. B. einen gebrochenen Arm) oder situationsbedingte Einschränkungen (z. B. die Nutzung einer Website auf einem mobilen Gerät von unterwegs) haben. Insgesamt ist die potenzielle Zielgruppe für barrierefreie Websites viel größer, als viele Menschen denken.

Ich: Sie sagten, dass die potenzielle Zielgruppe für barrierefreie Websites sehr groß ist. Aber nutzen Menschen mit Behinderungen das Internet wirklich so häufig?

ChatGPT: Ja, Menschen mit Behinderungen nutzen das Internet in ähnlichem Maße wie Menschen ohne Behinderungen. Eine Studie des Pew Research Center ergab, dass in den Vereinigten Staaten etwa 88 % der Erwachsenen mit Behinderungen das Internet nutzen, verglichen mit 91 % der Erwachsenen ohne Behinderungen. Dies zeigt, dass Menschen mit Behinderungen das Internet genauso häufig nutzen wie Menschen ohne Behinderungen, und unterstreicht, wie wichtig es ist, dafür zu sorgen, dass Websites für alle Nutzer zugänglich sind.

Darüber hinaus wird die Nutzung des Internets durch Menschen mit Behinderungen in den kommenden Jahren wahrscheinlich zunehmen, da Fortschritte bei unterstützenden Technologien und die Verbreitung mobiler Geräte den Internetzugang für Menschen mit Behinderungen erleichtern. Dies bedeutet, dass die potenzielle Zielgruppe für barrierefreie Websites weiter wachsen wird, so dass die Barrierefreiheit des Internets für Unternehmen und Organisationen immer wichtiger wird.

Mythos #2: Barrierefreiheit ist einfach und sollte der letzte Schritt sein

Ich: Also gut, sagen wir, ich möchte barrierefreie Websites erstellen. Wie schwer kann das sein? Ich denke, Barrierefreiheit kann bis zum Ende des Entwicklungsprozesses warten, nachdem alle anderen Arbeiten erledigt sind.

ChatGPT: Es ist zwar durchaus möglich, eine Website nachträglich barrierefrei zu gestalten, aber im Allgemeinen ist es viel einfacher und effektiver, die Barrierefreiheit von Anfang an in den Design- und Entwicklungsprozess einzubeziehen. Der Grund dafür ist, dass Barrierefreiheit nicht nur eine Frage des Hinzufügens von ein paar Barrierefreiheitsmerkmalen am Ende des Entwicklungsprozesses ist, sondern dass Barrierefreiheit in jeder Phase des Design- und Entwicklungsprozesses berücksichtigt werden muss.

Bei der Gestaltung des Layouts und des Inhalts einer Website ist es beispielsweise wichtig zu berücksichtigen, wie die Website von Menschen mit Behinderungen genutzt wird, und sicherzustellen, dass das Design von einer Vielzahl von Nutzern verwendet werden kann. Dies kann die Verwendung klarer und anschaulicher Überschriften und Beschriftungen, die Bereitstellung von Alternativtexten für Bilder und die Verwendung einer geeigneten Formatierung und Strukturierung beinhalten, um den Inhalt für Bildschirmlesesoftware leicht lesbar zu machen.

Während des Entwicklungsprozesses ist es auch wichtig, die Website zu testen, um sicherzustellen, dass sie den Normen und Richtlinien für Barrierefreiheit entspricht. Dies kann mit einer Kombination aus automatisierten Testwerkzeugen und manuellen Tests durch Personen mit Behinderungen oder anderen Fachkenntnissen erfolgen. Wenn die Barrierefreiheit von Anfang an in den Entwurfs- und Entwicklungsprozess einbezogen wird, ist es viel wahrscheinlicher, dass die endgültige Website für alle Benutzer zugänglich ist.

Insgesamt ist es zwar möglich, eine Website nachträglich zugänglich zu machen, aber es ist viel einfacher und effektiver, die Barrierefreiheit von Anfang an zu berücksichtigen. So kann sichergestellt werden, dass die Website von einem breiten Spektrum von Nutzern verwendet werden kann und den einschlägigen Normen und Richtlinien für Barrierefreiheit entspricht.

Ich: Aber die Barrierefreiheit ist so restriktiv. Würde dies nicht die Kreativität von Webdesignern und -entwicklern einschränken?

ChatGPT: Barrierefreiheit im Web muss die Kreativität von Webdesignern und -entwicklern nicht einschränken. Tatsächlich kann die Einbeziehung der Barrierefreiheit in den Design- und Entwicklungsprozess oft zu kreativeren und effektiveren Lösungen führen. Denn bei der Barrierefreiheit geht es nicht nur darum, einer Website ein paar Barrierefreiheitsmerkmale hinzuzufügen, sondern vielmehr darum, die Bedürfnisse aller Nutzer, einschließlich derer mit Behinderungen, zu berücksichtigen und Wege zu finden, die Website für alle nutzbar und angenehm zu machen.

Bei der Gestaltung von Layout und Inhalt einer Website können Webdesigner und -entwickler beispielsweise berücksichtigen, wie die Website von Menschen mit Behinderungen genutzt wird, und nach kreativen Möglichkeiten suchen, um die Website zugänglich und nutzbar zu machen. Dazu kann die Verwendung innovativer Designtechniken gehören, wie z. B. Responsive Design, um die Website auf einer Vielzahl von Geräten zugänglich zu machen, oder die Einbeziehung von Multimedia-Elementen, wie z. B. Videos oder Audioaufnahmen, um den Inhalt für Nutzer mit Seh- oder Hörbehinderungen besser zugänglich zu machen.

Außerdem können Webdesigner und -entwickler durch die Einbeziehung der Barrierefreiheit in den Entwurfs- und Entwicklungsprozess oft die allgemeine Benutzerfreundlichkeit der Website für alle Benutzer verbessern. Dies kann zu kreativeren und effektiveren Lösungen führen, die nicht nur barrierefrei, sondern auch ansprechend und angenehm für alle Nutzer sind.

Insgesamt muss die Barrierefreiheit im Web die Kreativität von Webdesignern und -entwicklern nicht einschränken. Indem sie die Bedürfnisse aller Nutzer berücksichtigen und die Barrierefreiheit in den Design- und Entwicklungsprozess einbeziehen, können Webdesigner und -entwickler Websites erstellen, die nicht nur barrierefrei, sondern auch innovativ und effektiv sind.

Mythos #3: Barrierefreiheit ist zu schwierig und teuer

Ich: Dennoch gibt es so viele verschiedene Behinderungen und unterstützende Technologien zu berücksichtigen. Die Schulung von Mitarbeitern und die Integration der Barrierefreiheit in den gesamten Entwicklungsprozess ist einfach zu teuer. Was meinen Sie dazu?

ChatGPT: Es stimmt zwar, dass die Schulung der Mitarbeiter und die Einbeziehung der Barrierefreiheit in den Design- und Entwicklungsprozess einige Anfangsinvestitionen erfordern, aber die langfristigen Vorteile der Barrierefreiheit im Internet können die Kosten überwiegen. Für Unternehmen und Organisationen kann eine barrierefreie Website das potenzielle Publikum für die Website vergrößern, die Suchmaschinenoptimierung (SEO) der Website verbessern und zu einer höheren Kundenzufriedenheit und -treue führen. Dies kann zu erheblichen finanziellen Vorteilen führen, z. B. zu höheren Umsätzen oder Spenden, und dazu beitragen, die anfänglichen Kosten für die Umsetzung der Barrierefreiheit im Internet auszugleichen.

Darüber hinaus stehen zahlreiche Ressourcen zur Verfügung, die Unternehmen und Organisationen bei der Umsetzung der Barrierefreiheit im Internet unterstützen, darunter Schulungsmaterial, Richtlinien und Standards sowie automatische Testwerkzeuge. Diese Ressourcen können dazu beitragen, den Prozess der Umsetzung der Barrierefreiheit im Internet effizienter und kostengünstiger zu gestalten.

Insgesamt kann die Umsetzung der Barrierefreiheit im Internet zwar einige Anfangsinvestitionen erfordern, aber die langfristigen Vorteile einer barrierefreien Website können die Kosten aufwiegen. Durch die Berücksichtigung der Bedürfnisse aller Nutzer und die Einbeziehung der Barrierefreiheit in den Design- und Entwicklungsprozess können Unternehmen und Organisationen Websites erstellen, die von einer Vielzahl von Nutzern verwendet werden können und die erhebliche finanzielle Vorteile bieten.

Ich: Wäre es nicht viel billiger, einfach ein Overlay für die Barrierefreiheit zu verwenden?

ChatGPT: Ein Accessibility-Overlay ist ein Tool, das einer bestehenden Website hinzugefügt werden kann, um sie für Nutzer mit Behinderungen besser zugänglich zu machen. Ein Accessibility-Overlay kann zwar einige Vorteile bieten, ist aber in der Regel nicht so effektiv und effizient wie die Einbeziehung der Barrierefreiheit in den Design- und Entwicklungsprozess von Anfang an.

Ein großer Nachteil der Verwendung eines Overlays für die Barrierefreiheit besteht darin, dass es sich nur auf die Zugänglichkeit der Benutzeroberfläche (UI) der Website bezieht, nicht aber auf den zugrunde liegenden Inhalt oder die Struktur. Das bedeutet, dass die Benutzeroberfläche mit einem Overlay zwar zugänglicher sein kann, der Inhalt der Website für Benutzer mit Behinderungen aber immer noch schwer oder gar nicht zugänglich ist. Ein Overlay kann zum Beispiel Bilder mit alternativem Text versehen, aber wenn die Bilder nicht richtig beschriftet oder organisiert sind, können sie für Benutzer mit Sehbehinderungen immer noch schwer zu verstehen sein.

Außerdem kann die Verwendung eines Overlays für die Barrierefreiheit weniger effizient und teurer sein als die Integration der Barrierefreiheit in den Design- und Entwicklungsprozess. Dies liegt daran, dass ein Overlay für die Barrierefreiheit erst nach der Entwicklung der Website hinzugefügt werden muss, was zusätzliche Zeit und Ressourcen erfordern kann. Im Gegensatz dazu kann die Einbeziehung der Barrierefreiheit in den Design- und Entwicklungsprozess von Anfang an effizienter und kostengünstiger sein, da die Barrierefreiheit in jeder Phase des Prozesses berücksichtigt werden muss.

Insgesamt kann ein Overlay für Barrierefreiheit zwar einige Vorteile bieten, ist aber im Allgemeinen nicht so effektiv und effizient wie die Einbeziehung der Barrierefreiheit in den Design- und Entwicklungsprozess von Anfang an. Durch die Berücksichtigung der Bedürfnisse aller Benutzer und die Einbeziehung der Barrierefreiheit in den Design- und Entwicklungsprozess können Unternehmen und Organisationen Websites erstellen, die für alle Benutzer wirklich zugänglich sind.

Mythos #4: Barrierefreie Websites sind hässlich

Ich: Vielleicht haben Sie Recht und wir sollten von Anfang an auf Barrierefreiheit achten. Es ist einfach so schwer, barrierefreie Websites zu erstellen, die gut aussehen. Die meisten barrierefreien Websites sind hässlich und haben ein schlechtes visuelles Design.

ChatGPT: Es stimmt zwar, dass einige barrierefreie Websites nicht den gleichen visuellen Reiz haben wie andere Websites, aber das muss nicht der Fall sein. Barrierefreiheit und visuelle Gestaltung schließen sich nicht gegenseitig aus, und es ist möglich, Websites zu erstellen, die sowohl barrierefrei als auch ästhetisch ansprechend sind.

Eine Möglichkeit, dies zu erreichen, ist die Einhaltung von Leitlinien und Standards für die Barrierefreiheit im Internet, wie z. B. die vom World Wide Web Consortium (W3C) entwickelten Web Content Accessibility Guidelines (WCAG). Diese Leitlinien enthalten spezifische Kriterien, die Websites erfüllen sollten, um als zugänglich zu gelten, lassen aber auch Flexibilität bei der Gestaltung und dem Layout der Website zu. Das bedeutet, dass Webdesigner und -entwickler ihre Kreativität und ihr Fachwissen einsetzen können, um optisch ansprechende Websites zu erstellen, die auch für Benutzer mit Behinderungen zugänglich sind.

Wenn Webdesigner und -entwickler die Bedürfnisse aller Nutzer, einschließlich derer mit Behinderungen, berücksichtigen, können sie Websites erstellen, die nicht nur zugänglich und optisch ansprechend, sondern auch benutzerfreundlich und für eine Vielzahl von Nutzern ansprechend sind. Dies kann zu effektiveren und erfolgreicheren Websites führen, die von allen Nutzern geschätzt werden, unabhängig davon, ob sie eine Behinderung haben oder nicht.

Auch wenn einige barrierefreie Websites nicht den gleichen visuellen Reiz haben wie andere Websites, ist es möglich, Websites zu erstellen, die sowohl barrierefrei als auch ästhetisch ansprechend sind. Indem sie die Richtlinien und Standards für Barrierefreiheit befolgen und die Bedürfnisse aller Nutzer berücksichtigen, können Webdesigner und -entwickler Websites erstellen, die zugänglich, optisch ansprechend und benutzerfreundlich sind.

Ich: Was ist mit unterstrichenen Links? Das WCAG-Erfolgskriterium 1.4.1 zwingt Sie im Grunde dazu, Links zu unterstreichen, auch wenn dies die Ästhetik einer Website beeinträchtigt.

ChatGPT: Das Erfolgskriterium 1.4.1 der Web Content Accessibility Guidelines (WCAG) besagt, dass „Informationen und Beziehungen, die durch die Darstellung vermittelt werden, programmatisch ermittelt werden können oder als Text verfügbar sind“. Das bedeutet, dass alle Informationen oder Beziehungen, die durch die Präsentation einer Website visuell vermittelt werden, wie z. B. die Position eines Links, auch in Textform verfügbar sein sollten, damit sie von Nutzern mit Sehbehinderungen verstanden werden können, die die visuelle Präsentation der Website möglicherweise nicht sehen können.

Im Falle von Links verlangt das WCAG-Erfolgskriterium 1.4.1 nicht unbedingt, dass Links unterstrichen werden, aber es verlangt, dass die Position des Links deutlich im Text angegeben wird. Dies kann auf verschiedene Weise erreicht werden, z. B. durch die Verwendung einer anderen Farbe für Links, durch die Verwendung eines eigenen Stils oder einer eigenen Schriftart für Links oder durch Unterstreichung von Links. Die spezifische Methode zur Angabe der Position eines Links bleibt dem Webdesigner oder Entwickler überlassen, solange sie die Anforderungen des WCAG-Erfolgskriteriums 1.4.1 erfüllt.

Letztendlich besteht das Ziel des WCAG-Erfolgskriteriums 1.4.1 darin, sicherzustellen, dass die Informationen und Beziehungen, die durch die Präsentation einer Website vermittelt werden, in Textform vorliegen, so dass sie von Nutzern mit Sehbehinderungen verstanden werden können. Das Unterstreichen von Links ist zwar eine Möglichkeit, dieses Kriterium zu erfüllen, aber es gibt auch andere Optionen, die ein gutes visuelles Design bieten und gleichzeitig die Zugänglichkeit gewährleisten können.

Ich: Sie haben die Kriterien 1.3.1 und 1.4.1 verwechselt. Das Erfolgskriterium 1.4.1 besagt eigentlich, dass „Farbe nicht als einziges visuelles Mittel zur Übermittlung von Informationen, zur Angabe einer Aktion, zur Aufforderung einer Reaktion oder zur Unterscheidung eines visuellen Elements verwendet wird.“

ChatGPT: Ich entschuldige mich, wenn ich die WCAG-Erfolgskriterien verwechselt habe. Das Erfolgskriterium 1.4.1, das ich erwähnt habe, besagt in der Tat, dass „Farbe nicht als einziges visuelles Mittel zur Übermittlung von Informationen, zur Anzeige einer Aktion, zur Aufforderung einer Reaktion oder zur Unterscheidung eines visuellen Elements verwendet wird.“ Das bedeutet, dass Websites nicht ausschließlich Farbe verwenden sollten, um Informationen zu vermitteln oder eine Aktion anzuzeigen, da dies das Verständnis des Inhalts für Benutzer mit Sehbehinderungen erschweren oder unmöglich machen kann, die nicht sehen können…

Fazit

Am Ende brach ChatGPT plötzlich mitten im Satz ab und reagierte nicht mehr. Vielleicht habe ich die künstlichen Synapsen der KI überhitzt, wer weiß.

Insgesamt bin ich sehr beeindruckt von den detaillierten und meist korrekten Antworten von ChatGPT. Wenn man mit der KI spricht, fühlt es sich tatsächlich so an, als würde man ein Gespräch mit einem Menschen führen. Es ist fast schon unheimlich.

Natürlich ist die KI nicht perfekt. Nach einiger Zeit scheinen sich gewisse Formulierungen und Aussagen zu wiederholen. Als ich eine konkrete Frage zum WCAG-Erfolgskriterium 1.4.1 stellte, antwortete ChatGPT mit fehlerhaften Informationen. Ich vermute, dass diese Fehler mit mehr Training weniger werden.

Habt ihr schon selbst ein Gespräch mit ChatGPT geführt? Welche Erfahrungen habt ihr gemacht?

3 Gründe, warum auch Web-Entwickler:innen von Barrierefreiheit profitieren

Sun, 27 Nov 2022 00:00:00 GMT

Web-Barrierefreiheit ist ein ethisches Gebot und wirtschaftlich sinnvoll. Ihr unterstützt die Inklusion von Menschen mit Behinderung und erreicht damit potenziell mehr Kund:innen. Dennoch, als Web-Entwickler:in denkt ihr euch vielleicht: „Das ist super für meine Firma und die ganze Gesellschaft. Aber für mich heißt es noch mehr Arbeit!“

Ich kann euch verstehen! Das Thema Barrierefreiheit kann am Anfang ganz schön überwältigen. Und ich gebe zu, manche Sachen wie ARIA Live-Regionen bereiten tatsächlich etwas mehr Arbeit. Doch ich verrate euch ein kleines Geheimnis: Barrierefreier Code wird euer Leben als Web-Entwickler:in einfacher machen und euch langfristig viel Zeit sparen!

Ihr glaubt mir nicht? Dann lest einfach die folgenden drei Gründe, warum mit Barrierefreiheit alles besser ist.

1. Semantisches Markup ist leicht lesbar und wartbar

Semantisches Markup vermittelt Informationen über die Bedeutung von Elementen nicht nur an assistive Technologien. Es vermittelt diese Bedeutung auch den Entwickler:innen, die den Code lesen, bearbeiten und umgestalten.

Stellt euch vor, ihr seid neu im Team und wollt euch in die Code-Basis einlesen. Würdet ihr vor Freude Luftsprünge machen, wenn ihr solchen Code vorfindet?

<div class="fixed-header" role="banner">
    <div id="header-logo" role="img" aria-label="Logo Example Page"></div>
    <div role="navigation" aria-label="Main Navigation">
        <div role="list">
            <div role="listitem"><a href="/">Home</a></div>
            <div role="listitem"><a href="/about">About</a></div>
        </div>
    </div>
</div>
<div role="main">
    <div role="heading" aria-level="1">Best Pizza in Town</div>
    <div role="heading" aria-level="2">Pizza Salami</div>
    <div id="pizza-salami" role="img" aria-label="Pizza with salami slices"></div>
    <div>Some text</div>
    <div role="heading" aria-level="2">Pizza Capricciosa</div>
    <div id="pizza-capri" role="img" aria-label="Pizza with baked ham, mushroom and artichoke"></div>
    <div>Some text</div>
</div>

Puh, das sind schon verdammt viele div Tags! Irgendwie schwer zu verstehen. Tja, dann würdet ihr euch über folgenden Code wohl mehr freuen:

<header>
    <img src="/header-logo.svg" alt="Logo Example Page">
    <nav aria-label="Main Navigation">
        <ul>
            <li><a href="/">Home</a></li>
            <li><a href="/about">About</a></li>
        </ul>
    </nav>
</header>
<main>
    <h1>Best Pizza in Town</h1>
    <h2>Pizza Salami</h2>
    <img src="/pizza-salami.jpg" alt="Pizza with salami slices">
    <p>Some text</p>
    <h2>Pizza Capricciosa</h2>
    <img src="/pizza-capri.jpg" alt="Pizza with baked ham, mushroom and artichoke">
    <p>Some text</p>
</main>

Ah, das ist besser! Auf dieser Basis könnt ihr euch im Team sinnvoll über den HTML-Code austauschen. Notiz am Rande: Beide Code-Beispiele bereiten den Inhalt barrierefrei für Screenreader-Nutzer:innen auf. Aber nur das zweite Beispiel ist vorteilhaft für Entwickler:innen.

Wenn ihr jetzt denkt: „Boah, der übertreibt ja völlig mit dieser Spaghetti-Code-Hölle!“ Dann kann ich nur antworten, dass ich Variationen davon schon auf unzähligen Websites gesehen habe. Einfach nur traurig.

2. Native Bedienelemente sind standardmäßig tastaturbedienbar

HTML-Elemente wie a , button , input type=“checkbox” oder input type=“radio” sind alle von Haus aus barrierefrei. Zum Beispiel können Nutzer:innen mit der Tab-Taste von Schaltfläche zu Schaltfläche springen und diese mit der Enter- oder Leertaste aktivieren.

Stellt euch vor, ihr wollt eine Schaltfläche mit dem div Element implementieren – warum auch immer. Damit dieses Monstrum mit der Tastatur bedienbar wird, müsstet ihr folgende Schritte unternehmen:

tabindex=“0” setzen, um das Div in die Tab-Reihenfolge aufzunehmen.
Einen gut sichtbaren Fokus-Indikator setzen, der vermittelt wann das Div den Fokus hat.
Mit einem keydown Event-Handler die Aktivierung des „Buttons“ mit Enter- und Leertaste ermöglichen.

Das Folgende ist zu tun, wenn ihr stattdessen das native button Element verwendet:

Nichts!

Buttons sind standardmäßig tastaturbedienbar und lösen automatisch das click Event aus, wenn die Enter- oder Leertaste gedrückt wird. Weiters könnt ihr das Styling sehr einfach mit CSS anpassen. Das trifft auch auf die meisten Formularelemente zu. Lest dazu meinen Artikel über Web-Formulare.

3. Zustandsbezogene, semantische CSS-Selektoren sind aussagekräftiger und robuster

Ihr könnt die semantischen Tag-Namen und ARIA-Attribute für aussagekräftige und leicht verständliche CSS-Selektoren nutzen. Zum Beispiel: header nav > ul { … } oder button[aria-expanded=“true” ] { … } .

Indem die CSS-Regeln alleine auf HTML-Tags und -Attributen aufbauen, braucht ihr keine zusätzlichen CSS-Klassen, die dynamisch mit JavaScript gesetzt werden. Stattdessen könnt ihr euch darauf konzentrieren, die Geschäftslogik alleine im HTML-Code abzubilden (etwa indem aria-expanded auf „true“ oder „false“ gesetzt wird).

Weitere Beispiele und eine ausführliche Auseinandersetzung mit dem Konzept bietet der Artikel „Style with Stateful, Semantic Selectors“ von Ben Myers.

Nützliche Links

Update am 16.12.2022

Abschnitt über zustandsbezogene, semantische CSS-Selektoren wurde überarbeitet.

Gestalte barrierefreie Toggle-Buttons in React

Fri, 18 Nov 2022 00:00:00 GMT

Ob Filter-Optionen, System-Einstellungen oder ein Dark-Mode-Schalter – wahrscheinlich seid ihr im Internet schon mal auf einen Toggle-Button gestoßen. Diese erscheinen zunächst recht simpel: Sie erlauben den Nutzer:innen zwischen zwei Zuständen zu wechseln, meistens „ein“ und „aus“.

Leider gibt es kein natives HTML-Element für Toggle-Buttons. Aus diesem Grund geistern zahlreiche, selbstgebaute Implementierungen im Internet herum. Einige davon, ihr ahnt es schon, völlig unzugängliche Ungetüme.

Ich habe eine Demo-Applikation in React mit barrierefreien Toggle-Buttons erstellt, die ich euch zeigen möchte. Ich bin mir nicht sicher, ob meine Lösung optimal ist. Daher würde ich mich über euer Feedback freuen.

Demo: Bier-Liste mit Toggle-Buttons

Meine Demo zeigt eine Liste verschiedener Biere. Nutzer:innen können über Toggle-Buttons zwischen schwachen und starken Bieren wechseln. Probiert es aus:

Wenn ihr den Code betrachtet, werdet ihr eine Gruppe von Buttons vorfinden, denen ich die switch Rolle zugewiesen habe. Bevor wir uns auf die technischen Details stürzen, möchte ich noch erklären, was ich mit dem Bedienelement erreichen möchte.

Ziele und Anforderungen

Das Bedienelement soll seine Funktionalität klar vermitteln, sowohl visuell als auch für assistive Technologien.
Es soll seinen aktuellen Zustand vermitteln, sowohl visuell als auch für assistive Technologien.
Nutzer:innen sollen das Bedienelement allein mit der Tastatur bedienen können.
Nur eine Option („schwach“ oder „stark“) kann gleichzeitig aktiv sein. Wenn eine Option aktiviert wird, wird die andere deaktiviert.
Der Wechsel zwischen den beiden Optionen soll ein bewusster Akt der Nutzer:innen sein und nicht aus Versehen passieren.

Semantische Auszeichnung und Tastaturbedienung

Man könnte auch Radio-Buttons verwenden und ihr Styling mit CSS anpassen. Ich habe mich bewusst dagegen entschieden, weil diese bei Fokussierung automatisch aktiviert werden (was ich nicht will!) und zu den Standard-Formularelementen zählen. Web-Formulare sollen aber keinen Kontext-Wechsel auslösen, solange Nutzer:innen das Formular nicht bewusst abschicken.

Also habe ich mich dafür entschieden, ein button Element für jede auswählbare Option („schwach“ und „stark“) zu verwenden und ihnen die switch Rolle zuzuweisen. Die Spezifikation dieser Rolle lautet:

A type of checkbox that represents on/off values, as opposed to checked/unchecked values.

Meine React-Komponente beinhaltet einen Toggle-Button für jede Option. Auf diese Weisekann ich sie individuell beschriften und ihren Zustand (ein oder aus) eindeutig vermitteln. Weiters gruppiere ich die beiden Buttons in einem section Element mit group Rolle. Seht euch meinen JSX-Code an:

<section className={styles.container} role="group" aria-label={switchLabel}>
    <p>{switchLabel}:</p>
    <div className={styles.switchWrapper}>
        <button
            type="button"
            role="switch"
            aria-checked={selectedState === stateValues[0]}
            onClick={toggleSwitch}
        >
            {stateLabels[0]}
        </button>
        <button
            type="button"
            role="switch"
            aria-checked={selectedState === stateValues[1]}
            onClick={toggleSwitch}
        >
            {stateLabels[1]}
        </button>
    </div>
</section>

Nutzer:innen können die Buttons mit der Tab-Taste fokussieren und sie mit der Enter- oder Leertaste ein- bzw. ausschalten.

Individuelles Styling mit CSS

Das Styling der Toggle-Buttons sorgt für die visuelle Vermittlung ihrer Funktionalität und ihres aktuellen Zustands. Wenn eine Option ausgewählt ist, invertiere ich ihre Farben und füge eine vertikale Linie mithilfe des ::after Pseudo-elements hinzu. Hier ein Auszug aus der SCSS-Datei meiner Komponente:

/* Invert background and text colors */
button[aria-checked="true"] {
    background: var(--light-black);
    color: white;
}
/* Add vertical line to highlight selected option */
button[aria-checked="true"]:after {
    content: "";
    position: absolute;
    bottom: 0.2em;
    top: 0.2em;
}
button[aria-checked="true"]:first-of-type:after {
    right: 0.2em;
    border-right: 0.3em solid var(--primary-color);
}
button[aria-checked="true"]:last-of-type:after {
    left: 0.2em;
    border-left: 0.3em solid var(--primary-color);
}

Feedback

Das war’s. Mein Vorschlag für barrierefreie Toggle-Buttons. Was sagt ihr dazu? Genial oder einfach furchtbar? Sagt mir eure Meinung auf Twitter, Mastodon oder GitHub!

Nützliche Links

Häufige Probleme mit ARIA und wie ihr diese vermeidet

Mon, 17 Oct 2022 00:00:00 GMT

Du willst also deine Website barrierefrei machen? Sehr gut! Und du hast bereits von ARIA gehört, also Accessible Rich Internet Applications. Na, dann pflastern wir doch einfach alles mit ARIA-Attributen zu und die Website ist barrierefrei, oder? Falsch!

Wenn du nicht weißt, was du tust, wird deine Website am Ende weniger barrierefrei sein! Es gibt einen guten Grund, warum die erste Regel von ARIA lautet: No ARIA is better than Bad ARIA! Ihr solltet grundsätzlich native HTML-Elemente und -Attribute mit der gewünschten Semantik und Funktionalität verwenden.

Sehen wir uns gemeinsam an, welche Anwendungsfälle es für ARIA gibt und welche verbreiteten Fehler ihr vermeiden solltet.

ARIA, wozu ist das gut?

ARIA besteht aus einer Reihe von Rollen und Attributen, die euch dabei helfen können, Web-Inhalte barrierefrei für Menschen mit Beeinträchtigung aufzubereiten. Die aktuelle Version WAI-ARIA 1.2 wurde im Dezember 2021 vom W3C veröffentlicht.

Personen mit Beeinträchtigungen oder Behinderungen nutzen assistive Technologien, um mit Web-Inhalten zu interagieren. Zum Beispiel surfen blinde Menschen mithilfe von Screenreadern im Internet. Personen mit motorischer Beeinträchtigung können Spracheingabe-Software verwenden, um mit einer Website zu interagieren.

Web-Entwickler:innen können ARIA-Rollen und -Attribute verwenden, um Nutzer:innen assistiver Technologien die Semantik der Inhalte zu vermitteln. Ihr könnt aria-expanded auf ein Element setzen, um anzuzeigen, ob der verknüpfte Bereich ein- oder ausgeklappt ist. Das Attribut aria-selected vermittelt, ob zum Beispiel ein Tab aktuell ausgewählt ist oder nicht.

<h3>
    <button type="button" aria-expanded="false" aria-controls="section1" id="header1">
        Personal Information
    </button>
</h3>
<div id="section1" role="region" aria-labelledby="header1">
    <!-- Panel content that is shown/hidden via button -->
</div>

Grundsätzlich solltet ihr ARIA nur für Custom Widgets wie etwa einen ausklappbaren Bereich verwenden. Seht euch den ARIA Authoring Practices Guide an. Dieser beschreibt detailliert, wie ihr semantische Informationen bei üblichen Design-Mustern und Widgets vermitteln solltet.

Häufige Fehler bei der Nutzung von ARIA

Ich habe bereits hunderte Websites auf Barrierefreiheit überprüft. Dabei ist mir aufgefallen: Viele Web-Entwickler:innen haben offensichtlich keine Ahnung was sie tun! Sie verstopfen das DOM mit ARIA-Rollen und -Attributen als ob es kein Morgen gäbe. Ich zeige euch einige der häufigsten Fehler, auf die ich gestoßen bin.

Mit `aria-hidden=“true”` ein fokussierbares Element verbergen

ARIA gibt euch die volle Kontrolle über den Accessibility Tree. Dieser stellt eine angepasste Version des DOM für assistive Technologien dar. Das Attribut aria-hidden ermöglicht euch, ein Element aus dem Accessibility Tree zu entfernen und es somit vor Screenreader-Nutzer:innen zu verbergen.

<a href="https://www.stuff.com" aria-hidden="true">Interesting Stuff</a>

Das Problem dabei: Wenn ihr ein fokussierbares Element, wie etwa einen Link, aus dem Accessibility Tree entfernt, dann verbleibt das Element dennoch in der Tab-Reihenfolge. Wenn ein:e Screenreader-Nutzer:in mit der Tab-Taste navigiert und damit den Link fokussiert, wird der Screenreader „leer“ oder etwas ähnliches vorlesen. Bitte tut ihnen das nicht an!

Ein `aria-label` definieren, das nicht dem sichtbaren Label entspricht

Stellt euch vor, ihr seid ein Uni-Student in Wien und wollt euch online für eine Vorlesung anmelden. Wegen eines Handtremors wollt ihr die Website mit eurer Spracheingabe-Software bedienen. Ihr findet folgendes Web-Formular vor:

<form action="">
    <div class="form-field">
        <label for="firstname">Vorname</label>
        <input type="text" aria-label="First Name" name="firstname" id="firstname">
    </div>
    <div class="form-field">
        <label for="lastname">Nachname</label>
        <input type="text" aria-label="Last Name" name="lastname" id="lastname">
    </div>
    <!-- Other fields -->
</form>

Um das Formular auszufüllen, wollt ihr das erste Eingabefeld mit der sichtbaren Beschriftung „Vorname“ auswählen. Also sagt ihr den Sprachbefehl „Vorname klicken“, doch nichts passiert. Was ist hier los?

Wie der Code oben zeigt, ist das label Element programmatisch mit dem Eingabefeld über das for Attribut verknüpft. Allerdings überschreibt das aria-label Attribut den programmatischen Namen des input Elements mit „First Name“. Das heißt, der Name des Bedienelements enthält nicht die sichtbare Beschriftung.

Das Formular ist somit für Nutzer:innen von Spracheingabe-Software schwer bedienbar und es liegt ein klarer WCAG-Verstoß vor. Übrigens: Es handelt sich um ein echtes Beispiel eines Web-Formulars auf der Website einer großen Universität in Wien.

Das `aria-labelledby` Attribut verweist auf eine ID, die nicht existiert

Mit dem aria-labelledby Attribut könnt ihr ein HTML-Element programmatisch beschriften, indem ihr auf ein anderes Element verweist. Der Wert sollte eine Liste von einer oder mehreren IDs sein, die auf das Element verweisen, mit dem ihr das aktuelle Element beschriften möchtet. Ein Beispiel.

<nav aria-labelledby="sidenav-title">
    <h2 id="sidenav-title">Related Content</h2>
    <ul>
        <!-- List of links -->
    </ul>
</nav>

Falls kein Element mit der ID „sidenav-title“ im DOM vorhanden wäre, würde das nav Element keine programmatische Beschriftung erhalten. Die Folge wäre eine suboptimale Erfahrung für Screenreader-Nutzer:innen. Deshalb prüft bitte genau, ob das mit aria-labelledby referenzierte Element tatsächlich vorhanden ist.

Navigations-Menü mit `role=“menubar”` oder `role=“menu”`

Viele Websites enthalten eine Seitennavigation, die wie eine Menüleiste mit ausklappbaren Untermenüs gestylt ist. Aufgrund dieser visuellen Darstellung denken viele Web-Entwickler:innen, dass sie die folgenden semantischen Rollen setzen sollten:

<ul role="menubar">
    <li role="none">
        <a role="menuitem" href="/">Home</a>
    </li>
    <li role="none">
        <a role="menuitem" aria-haspopup="true" aria-expanded="false" href="#">About</a>
        <ul role="menu" aria-label="About">
            <li role="none">
                <a role="menuitem" href="/overview">Overview</a>
            </li>
            <li role="none">
                <a role="menuitem" href="/administration">Administration</a>
            </li>
        </ul>
    </li>
</ul>

Allerdings wecken diese semantischen Rollen eine gewisse Erwartungshaltung bei den Nutzer:innen. Die Rollen menubar und menu sind für Menü-Widgets gedacht, die den Nutzer:innen eine Liste an Aktionen anbieten und wie Menüs von Betriebssystemen bedienbar sind. Das heißt: Sie sollten ein konkretes Set an Tastatur-Interaktionen implementieren.

Wenn ihr zum Beispiel eine Seitennavigation mit role=“menubar” definiert, dann erwarten Screenreader-Nutzer:innen, das Menü mit den Pfeiltasten bedienen zu können. Wenn das nicht funktioniert, dann sorgt das für Verwirrung. Eine bessere Alternative ist die Anwendung des Disclosure Pattern für die Seitennavigation.

Grundregeln für den Einsatz von ARIA

Wie wir gesehen haben, kann bei ARIA sehr viel schiefgehen. Diese Liste an Grundregeln wird euer Leben einfacher machen:

Verwendet immer native HTML-Elemente, wenn möglich.
Verändert nicht die Semantik von nativen Elementen, außer es ist wirklich notwendig.
Setzt ARIA bei Custom Widgets ein und befolgt die Vorgaben im Authoring Practices Guide.
Alle interaktiven ARIA-Bedienelemente müssen auch mit der Tastatur bedienbar sein.
Testet euren Code mit assistiven Technologien wie Screenreadern und Spracheingabe-Software.

Nützliche Links

CSS-Tricks für bessere Sichtbarkeit im Forced Colors Modus

Tue, 27 Sep 2022 00:00:00 GMT

Ein deutlicher Kontrast zwischen Text und Hintergrund hilft allen. Sowohl Menschen mit Sehschwäche als auch jenen, die bei grellem Sonnenlicht auf ihr Display starren. Aus diesem Grund enthalten die WCAG diverse Mindest-Anforderungen für das Kontrastverhältnis von Text bzw. UI-Komponenten zum Hintergrund.

Für Menschen mit Sehbeeinträchtigung ist das aber nicht immer ausreichend. Sie brauchen spezifische Farbkombinationen mit hohem Kontrast zur Verbesserung der Lesbarkeit. Assistive Technologien wie der High Contrast Mode in Windows überschreiben aktiv die Farben einer Website, um Nutzer:innen mit Sehschwäche zu helfen.

Ich zeige euch wie der Forced Colors Modus bei Websites funktioniert und wie ihr eure Inhalte mit einfachen CSS-Tricks optimieren könnt.

Wie funktioniert der Forced Colors Modus?

Der Forced Colors Modus ist ein allgemeiner Browser-Standard, der in CSS Color Adjustment Module Level 1 definiert wurde. Betriebssysteme sollen vordefinierte Farb-Paletten anbieten und es Nutzer:innen ermöglichen, ihre eigenen Farbkombinationen zu definieren.

In der Spezifikation heißt es:

When forced colors mode is active (…), colors on the element are force-adjusted to the user’s preferred color palette.

Das bedeutet, dass Farbwerte durch System-Farben ersetzt werden, welche der definierten Farbpalette entsprechen. Zu den betroffen CSS-Eigenschaften zählen:

color
background-color
border-color
outline-color
fill

Andere Eigenschaften wie box-shadow und text-shadow werden auf none gesetzt. Um euch ein Beispiel zu geben, so sieht mein Blog im Forced Colors Modus mit dunkler Farbpalette aus:

Wie ihr den Forced Colors Modus testet

Mithilfe der Entwicklertools in Chrome und Edge könnt ihr den Forced Colors Modus emulieren und die Sichtbarkeit eurer Inhalte prüfen:

Öffnet den Rendering-Tab.
Unter “CSS-Medienfunktion forced-colors emulieren” wählt ihr “forced-colors: active” aus.

Die Medienfunktion `forced-colors`

Passt das Styling eurer Website explizit mit der Medienfunktion forced-colors an. Zum Beispiel habe ich in meinem Blog ein SVG-Muster mithilfe der Eigenschaft background-image eingebunden:

#___gatsby {
    background-image: url("data:image/svg+xml...");
    background-attachment: fixed;
    background-size: cover;
}

Mit der Media-Query entferne ich das Hintergrundbild, wenn der Forced Colors Modus aktiv ist:

@media (forced-colors: active) {
    #___gatsby {
        background-image: none;
    }
}

Eine weitere nützliche CSS-Eigenschaft ist forced-color-adjust . Diese ermöglicht euch, einzelne Elemente vor dem Zugriff des Forced Colors Modus zu schützen und selbst das Styling zu optimieren.

Transparente Rahmen und Umrisse

Web-Layouts vermitteln die Grenze eines Elements häufig über eine andere background-color oder mit einem box-shadow . Im Forced Colors Modus haben jedoch alle Elemente dieselbe Hintergrundfarbe und alle Schatten werden entfernt. Die fehlende Begrenzung von Elementen kann für Nutzer:innen verwirrend sein.

Kein Grund zu verzweifeln! Es gibt eine geniale Lösung für das Problem: Definiert eine Rahmenlinie mit transparenter Farbe. Bei aktivem Forced Colors Modus wird die Rahmenlinie sichtbar und vermittelt eindeutig die Grenze des Elements:

section.info-card {
    border: 1px solid transparent;
}

Auf dieselbe Weise könnt ihr für sichtbare Fokus-Indikatoren im Forced Colors Modus sorgen. Normalerweise setzen Browser einen Umriss für fokussierte Links und Buttons. Es ist ok diesen mit outline: none zu entfernen, wenn ihr den Fokus auf andere Weise (Hintergrundfarbe etc.) vermittelt. Da dieser Fokus-Indikator im Forced Colors Modus verloren gehen würde, solltet ihr aber besser eine transparente outline setzen.

a:focus {
    background: var(--primary);
    color: var(--white);
    /* Provide visible focus indicator in forced colors mode */
    outline: 2px solid transparent;
}

Es gibt noch viele weitere CSS-Tricks, mit denen ihr verschiedene Probleme im Forced Colors Modus beheben könnt. Bitte schaut euch das tolle Video „Practical Styling in Forced Colors Mode“ von Mike Herchel an.

Nützliche Links

CSS Cascade Layers in Angular verwenden

Mon, 05 Sep 2022 00:00:00 GMT

Wer kennt das nicht: Ihr definiert eine neue CSS-Regel, kompiliert eure Web-Applikation und werft einen Blick auf die Seite im Browser. Was? Warum wurde das Styling nicht angewandt?

Sehr oft ist der Übeltäter eine andere CSS-Regel mit höherer Spezifität. Vielleicht hab ihr die Bibliothek eines Drittanbieters eingebunden, deren Styles in Konflikt mit euren stehen.

Doch Rettung naht in Form eines neuen CSS-Features: CSS Cascade Layer . Diese ermöglichen uns die Aufteilung unserer Styles in streng getrennte Schichten, um Konflikte zu vermeiden. Ich zeige euch, wie ihr das neue Feature in einer Angular-Applikation mit SCSS anwenden könnt.

Was sind Cascade Layer?

CSS Cascade Layer geben Autoren mehr Kontrolle über die Kaskade in CSS. Also über die Art und Weise wie Browser entscheiden, welche Styling-Regeln auf ein HTML-Element angewandt werden.

Das neue Feature ist im CSS-Modul Cascading and Inheritance Level 5 definiert. Obwohl das Dokument erst den Entwurf-Status hat, werden Cascade Layer bereits von allen modernen Browsern unterstützt. Das Dokument besagt:

Cascade layers provide a structured way to organize and balance concerns within a single origin. Rules within a single cascade layer cascade together, without interleaving with style rules outside the layer.

Das heißt, wir können mehrere Layer definieren – beginnend bei Styles mit niedriger Priorität (z.B. Bibliotheken von Drittanbietern) bis zu hochprioritären Styles von Komponenten. Konflikte zwischen einzelnen Schichten werden immer so aufgelöst, dass die CSS-Regeln der Schicht mit höchster Priorität angewandt werden.

Wenn wir uns die Schritte in der Kaskade ansehen, dann sehen wir dass die Zugehörigkeit zu einem gewissen Layer geprüft wird bevor die Spezifität und Reihenfolge der Deklaration geprüft wird.

Ursprung und Wichtigkeit (!important )
Kontext
CSS-Regeln im HTML-Element
Layer
Spezifität
Reihenfolge der Deklaration

Bitte schaut euch das Video „The CSS Cascade, a deep dive“ von Bramus Van Damme an, um eine detaillierte Einführung in die CSS-Kaskade zu erhalten.

Die `@layer` Deklaration

Grundsätzlich deklarieren wir einen neuen Layer inklusive zugehöriger CSS-Regeln mit der @layer Deklaration:

@layer my-layer {
    // CSS rules
}

Ihr könnt auch einen benannten Cascade Layer definieren, ohne diesem CSS-Regeln zuzuweisen. Auf diese Weise könnt ihr die Hierarchie eurer Layer bestimmen. Als Best Practice wird empfohlen, zunächst die Hierarchie der Layer mit @layer zu definieren und danach erst die konkreten CSS-Regeln den Layern hinzuzufügen:

@layer my-layer-1, my-layer-2;

@layer my-layer-1 {
    // CSS rules
}

@layer my-layer-2 {
    // CSS rules
}

Alle Styles, die nicht innerhalb eines Layers deklariert wurden, werden automatisch als Teil eines anonymen Layers erfasst. Dieser anonyme Layer hat eine höhere Priorität als die explizit definierten Layer. Das bedeutet, dass alle CSS-Regeln, die außerhalb von Layern definiert wurden, Vorrang vor den Styles innerhalb von Layern haben.

Ich gehe hier nicht auf alle Details der Cascade Layer ein. Bitte lest dazu den großartigen Artikel „A Complete Guide to CSS Cascade Layers“.

Demo-Applikation mit Angular und SCSS

Ich habe eine Applikation mit Angular 14 und Leaflet erstellt, welche eine interaktive Karte anzeigt. Im Projekt verwende ich SCSS, da es tolle Features wie Placeholders und Mixins bietet. Seht euch meinen Quellcode hier an.

Mein Ziel ist einfach: Ich will sicherstellen, dass mein Styling für individuelle Komponenten immer angewandt wird. Es sollte Vorrang vor meinem Styling-Reset sowie den CSS-Regeln von Drittanbieter-Bibliotheken haben. Zu diesem Zweck habe ich mehrere Layer in der zentralen CSS-Datei styles.scss definiert:

@use "sass:meta";

@layer reset, thirdparty, overrides;

@layer reset {
    @include meta.load-css("layers/reset/normalize");
}

@layer thirdparty {
    @include meta.load-css("node_modules/leaflet/dist/leaflet.css");
}

@layer overrides {
    @include meta.load-css("layers/overrides/leaflet");
}

Ich verwende die SASS-Funktion load-css , um das CSS aus anderen SCSS-Dateien zu laden und es als Teil eines Cascade Layers zu definieren. Das Reset für User Agent Styles gebe ich in den Layer mit der niedrigsten Priorität. Darauf folgt ein Layer für das Standard-Styling der Leaflet-Karte und ein Layer für das globale Überschreiben von Styles.

Ich definiere keinen Layer für die Styles von einzelnen Komponenten, welche in eigenen SCSS-Dateien deklariert werden. Diese CSS-Regeln werden daher automatisch in einem anonymen Layer gesammelt und erhalten die höchste Priorität. Sehen wir uns ein konkretes Beispiel an.

Styling eines Karten-Popups

In meiner Demo-App liste ich meine 5 Lieblingsplätze in Wien auf. Dieses werden auf einer interaktiven Leaflet-Karte markiert. Beim Klick auf einen Marker öffnet sich ein Popup. Das HTML-Template fav-place-popup.component.html des Popups sieht so aus:

<h2>{{data.name}}</h2>
<p *ngFor="let desc of data.description">{{desc}}</p>

In fav-place-popup.component.scss habe ich folgende Styles definiert:

p {
    font-size: 0.8rem;
    margin: 0.5em 0;
}

Darüber hinaus definiert die Leaflet-Bibliothek folgendes Styling für Textabsätze innerhalb von Karten-Popups:

.leaflet-popup-content p {
    margin: 18px 0;
}

Dank meiner etablierten Layer-Struktur muss ich keine Angst davor haben, dass Leaflets Styling für .leaflet-popup-content p mit meinen Komponenten-Styles für p in Konflikt geraten könnten. Gleichzeitig sorgt Angulars View Encapsulation dafür, dass meine Komponenten-Styles nicht auf alle Textabsätze in meiner Applikation angewandt werden. Genial!

Fazit

Ich liebe Cascade Layer! Sie sind ein mächtiges Werkzeug zur Ordnung von CSS-Styles und helfen, nervige Konflikte aufgrund der Spezifität oder Reihenfolge der Deklaration zu vermeiden.

Ein Problem konnte ich noch nicht lösen: Manche Angular-Bibliotheken (z.B. Angular Material) fügen automatisch Styles im head Tag des HTML-Dokuments ein. Bisher habe ich leider keinen Weg gefunden, um diese Styles innerhalb eines Layers meiner Wahl zu deklarieren. Ich hoffe, dass es in Zukunft eine Lösung für dieses Problem geben wird.

Warum du das native Dialog-Element nutzen solltest

Tue, 19 Jul 2022 00:00:00 GMT

Wir sind alle mit Dialogboxen im Web vertraut. Von einfachen Aufforderungen, eine Aktion zu bestätigen, bis hin zu Fenstern mit komplexen Inhalten — Dialoge sind ein integraler Bestandteil moderner Benutzeroberflächen im Web.

Leider gab es lange Zeit kein natives Dialog-Element in HTML, weshalb zahlreiche eigene Implementierungen mit schweren Barrierefreiheits-Problemen entwickelt wurden. Das änderte sich mit der Einführung des <dialog> Elements in HTML 5.2 vor ein paar Jahren. Nachdem auch Safari endlich mit Version 15.4 das Element unterstützt, können nun alle modernen Browser damit umgehen.

Ich zeige euch, wie einfach ihr einen barrierefreien Modal-Dialog mit dem nativen Element erstellen könnt. Bei gewissen Browsern und Screenreadern gibt es noch kleinere Probleme, worauf ich am Ende des Artikels eingehen werde.

Was macht das `<dialog>` Element?

Das Dialog-Element erzeugt eine Popup-Box auf der Webseite, welche die Aufmerksamkeit der Nutzer:innen auf sich zieht. Die HTML-Spezifikation beschreibt das Element so:

The dialog element represents a part of an application that a user interacts with to perform a task, for example a dialog box, inspector, or window.

Ein typischer Anwendungsfall ist ein Modal-Dialog, der den Rest der Seite verdeckt und die Nutzer:innen zur Eingabe von Daten auffordert. Ich habe eine Demo mit dem React-Framework erstellt (Quellcode):

Aufbau und Interaktion mit dem Dialog

Der grundlegende JSX-Code meines Modal-Dialogs sieht so aus:

<dialog
    aria-labelledby='dialog-personal-info-heading'
    ref={formDialogRef}
    onClick={onFormDialogContainerClick}
>
    <h3 id="dialog-personal-info-heading">
        Personal Information
    </h3>
    <p>...</p>
    <form
        method="dialog"
        onClick={event => event.stopPropagation()}
    >
        // form elements
    </form>
</dialog>

Standardmäßig rendert der Browser den Dialog erst dann, wenn ihr die Eigenschaft open setzt, um den Dialog sichtbar zu machen. Empfohlen wird jedoch, die Methode .show() oder .showModal() zu verwenden, um den Dialog anzuzeigen.

In meinem Fall will ich einen Modal-Dialog anzeigen, der den Rest der Seite verdeckt. In meiner funktionellen React-Komponente erzeuge ich eine Referenz auf das HTML-Element mithilfe des useRef Hooks und öffne den Dialog beim Klick auf eine Schaltfläche:

const formDialogRef = useRef<HTMLDialogElement>(null);

const onOpenFormDialogClick = () => {
    formDialogRef.current?.showModal();
}

Um den Dialog zu schließen, verwende ich die Methode .close() . Wie meine Demo zeigt, kann auch ein <form> Element den Dialog mithilfe des Attributs method=“dialog” schließen. Beim Abschicken des Formulars wird der Dialog geschlossen und für die Eigenschaft returnValue der Wert der Schaltfläche gesetzt, mit der das Formular abgeschickt wurde.

<form method="dialog">
    <div className={styles.formField}>
        <label htmlFor="favMovie">Favorite movie:</label>
        <input id="favMovie" type="text" />
    </div>
    <button
        type="submit"
        value={DIALOG_CONFIRM_VALUE}
    >
        Confirm
    </button>
</form>

Ihr könnt einen Event Listener für das close Ereignis des Dialogs hinzufügen und somit eine Aktion abhängig vom returnValue ausführen.

Den Dialog und seinen Hintergrund stylen

Der Modal-Dialog wird standardmäßig zentriert und über dem restlichen Inhalt der Seite platziert. Browser wenden jeweils ein eigenes Styling auf das dialog Element an, meist einen dicken schwarzen Rahmen. Mit CSS könnt ihr das Aussehen des Dialogs individuell gestalten. Definiert zum Beispiel einen Schattenwurf und runde Ecken:

dialog {
    border: 0.125rem solid var(--border-color);
    border-radius: 4px;
    box-shadow:
        0 11px 15px -7px #0003,
        0 24px 38px 3px #00000024,
        0 9px 46px 8px #0000001f;
    font-size: 1rem;
    max-width: min(18rem, 90vw);
}

Ein geniales Feature des nativen Dialogs ist das CSS Pseudo-Element ::backdrop . Damit könnt ihr den Bereich hinter dem Modal-Dialog gestalten, etwa indem ihr die restliche Seite abdunkelt und verschwommen macht:

dialog::backdrop {
    background: rgba(36, 32, 20, 0.5);
    backdrop-filter: blur(0.25rem);
}

Tastatur- und Mausbedienung

Beim Öffnen des Modal-Dialogs setzt der Browser automatisch den Fokus auf das erste, interaktive Element im Dialog. Diese Verhaltensweise ist für die meisten Anwendungsfälle passend, etwa bei meinem Formular-Dialog. In manchen Fällen wäre es jedoch besser, wenn man den Fokus auf den gesamten Dialog oder ein Textelement am Anfang setzen könnte. Mehr dazu im Vorschlag für initiale Fokus-Platzierung

Solange der Modal-Dialog geöffnet ist, können Nutzer:innen mit dem restlichen Inhalt der Seite nicht interagieren. Das bedeutet, dass Tastaturnutzer:innen den Dialog nicht mit der TAB Taste verlassen können. Auch der virtuelle Cursor des Screenreaders (Pfeiltasten oder Swiping) kann sich nur innerhalb des Dialogs bewegen.

Der Modal-Dialog kann standardmäßig mit der ESC Taste geschlossen werden. Nach dem Schließen wird der Fokus automatisch zurück auf das Bedienelement gesetzt, mit dem der Dialog geöffnet wurde. Davon profitieren Tastatur- und Screenreader-Nutzer:innen, die sofort an der Stelle weitermachen können, wo sie aufgehört hatten.

Leider wird das dialog Element nicht automatisch geschlossen, wenn Nutzer:innen außerhalb des Dialogs klicken. Um dieses Light-Dismiss-Verhalten zu implementieren, können wir die Koordinaten des Klicks mit dem gerenderten Rechteck des Dialogs vergleichen (danke für die tolle Idee, Amit Merchant):

const isClickOutsideOfDialog = (dialogEl: HTMLDialogElement, event: React.MouseEvent): boolean => {
    const rect = dialogEl.getBoundingClientRect();
    return (event.clientY < rect.top
            || event.clientY > rect.bottom
            || event.clientX < rect.left
            || event.clientX > rect.right);
}

const onFormDialogContainerClick = (event: React.MouseEvent) => {
    const formDialogEl = formDialogRef.current;
    if (formDialogEl &&
        isClickOutsideOfDialog(formDialogEl, event)
    ){
        formDialogEl.close(DIALOG_CANCEL_VALUE);
    }
}

Das funktioniert meistens sehr gut. Ein Problem habe ich bei meiner Demo festgestellt: Wenn Nutzer:innen die native Auswahlliste öffnen, würde der Algorithmus dies als Klick außerhalb des Dialogs werten. Aus diesem Grund habe ich einen Click Event Listener für das form Element registriert und nutze die Methode .stopPropagation() .

Probleme mit der Barrierefreiheit bei manchen Screenreadern

Das native dialog Element funktioniert super mit den meisten Screenreadern und Browsern. Leider gibt es noch ein paar kleine Probleme, wie die Barrierefreiheits-Tests meiner Demo aufzeigen:

Windows 10, Google Chrome 103.0.5060.114, NVDA 2022.1: Wenn der Dialog geöffnet wird und Fokus erhält, liest der Screenreader die Dialog-Rolle, die Überschrift (dank aria-labelledby ), den ersten Textabsatz und die fokussierte Auswahlliste vor. Die Fokus-Reihenfolge und der virtuelle Cursor des Screenreaders wird auf die Inhalte im Dialog beschränkt.
Windows 10, Firefox 102.0.1, NVDA 2022.1: Identisch zu Google Chrome, mit der Ausnahme dass die Schaltfläche, mit welcher der Dialog geöffnet wurde, Teil der Fokus-Reihenfolge ist. Wahrscheinlich ein Firefox-Bug, der in Zukunft behoben wird.
Samsung Galaxy S20, Android 12, Google Chrome 103.0.5060.71, TalkBack: Der Screenreader liest nur die fokussierte Auswahlliste vor. Der virtuelle Cursor (z.B. nach rechts wischen) wird auf die Inhalte im Dialog beschränkt.
Samsung Galaxy S20, Android 12, Firefox 102.2.1, TalkBack: Der Screenreader liest nur die fokussierte Auswahlliste vor. Der virtuelle Cursor wird nicht auf die Inhalte im Dialog beschränkt. Das hat wahrscheinlich damit zu tun, dass Firefox immer noch nicht die Eigenschaft aria-modal unterstützt.
iPhone 8, iOS 15.5, Safari, VoiceOver: Der Screenreader liest nur die fokussierte Auswahlliste vor. Der virtuelle Cursor kann auf die Inhalte im Header gesetzt werden, jedoch nicht auf die Inhalte im Hauptinhaltsbereich, der direkt unter dem Dialog liegt.

Fazit

Das <dialog> Element ist einfach zu handhaben und standardmäßig barrierefrei, abgesehen von kleineren Problemen. Für manche Anwendungsfälle dürfte daher aktuell ein robuster, selbst gebauter Dialog wie a11y-dialog besser geeignet sind. Ich bin aber optimistisch was die Zukunft des nativen Elements betrifft.

Nützliche Links

Update am 07.03.2023

Die HTML-Spezifikation hat eine wichtige Aktualisierung hinsichtlich des initialen Fokus-Managements erhalten. Es wird möglich sein, dem dialog Element selbst den Fokus zu geben, wenn es das Attribut autofocus gesetzt hat.

Sicher, es wird einige Zeit dauern, bis die Browser-Hersteller diese Änderungen umsetzen. Aber es gibt keinen Grund, noch länger zu warten! Ich sehe es wie Scott O’Hara: Es ist an der Zeit, von benutzerdefinierten Dialogen wegzukommen und stattdessen das native Dialog-Element zu verwenden.

Update am 28.03.2026

Ein Bild sagt mehr als tausend Worte – außer du bist blind!

Sun, 03 Jul 2022 00:00:00 GMT

Visuelle Inhalte sind großartig! Bilder vermitteln Emotionen, beflügeln unsere Fantasie und machen eine Website ästhetisch ansprechend. Allerdings können viele Menschen Web-Inhalte nicht visuell wahrnehmen. Blinde und sehbeeinträchtigte Nutzer:innen sind darauf angewiesen, dass Web-Entwickler:innen und Content-Editor:innen einen Alternativtext bereitstellen.

Leider gibt es immer noch sehr viele Websites mit Bildern, für die kein Alternativtext gesetzt ist oder deren Alternativtext irreführend ist. Stellt euch vor, ihr besucht eine Website und statt Fotos und Grafiken seht ihr nur leere Flächen und verschwommene Bilder. Nervig, oder?

In diesem Artikel werde ich einige Beispiele für schlechten Alternativtext teilen, auf die ich regelmäßig bei Barrierefreiheits-Prüfungen stoße. Doch als erstes sehen wir uns die Grundlagen an.

Die Grundlagen barrierefreier Bilder

Meistens verwenden wir das HTML-Element img um Bilder auf einer Website anzuzeigen. Mit dem Attribut alt können wir einen Alternativtext für das Bild definieren. Die HTML-Spezifikation beschreibt das Attribut so:

alt — Replacement text for use when images are not available

Das bedeutet, dass der Alternativtext auf der Seite angezeigt wird, wenn das Bild z.B. wegen Netzwerkfehlern nicht geladen werden kann. Natürlich ist der Text noch wichtiger für die Barrierefreiheit. Screenreader lesen den Alternativtext ihren Nutzer:innen vor, so dass sie wissen, was auf dem Bild zu sehen ist.

Es gibt noch andere Wege, um Bilder in einer Webseite einzubinden: Etwa mit dem HTML-Element svg oder den CSS-Pseudo-Elementen :before und :after . Um mehr über die barrierefreie Aufbereitung dieser Elemente zu erfahren, folgt den Links im Abschnitt „Nützliche Links“ unten.

Den passenden Alternativtext formulieren

Bei allen Bild-Elementen stellt sich dieselbe Frage: Welcher Alternativtext ist für das Bild angemessen? Das hängt vom Typ des Bildes ab:

Informative Bilder: Bilder, die relevante Informationen vermitteln. Die Textalternative sollte die Bedeutung bzw. die relevanten Details des visuell wahrnehmbaren Inhalts vermitteln.
- Es gibt verschiedene Meinungen darüber, ob der Alternativtext aus einem kurzen, prägnanten Satz oder einer detaillierten Beschreibung in mehreren Sätzen bestehen soll.
- Bei komplexen Bildinhalten (z.B. Diagramme) sollte der Alternativtext kurz gehalten werden und auf eine lange Beschreibung verweisen, die auf das Bild folgt.
Dekorative Bilder: Bilder, die dem Inhalt einer Seite keine relevanten Informationen hinzufügen. Dies ist etwa bei Bildern der Fall, die eine Seite nur optisch attraktiver machen sollen. Oder wenn der Informationsgehalt eines Bildes bereits durch nebenstehenden Text vermittelt wird. Diese Bilder solltet ihr vor assistiven Technologien verbergen, z.B. indem ihr einen leeren Alternativtext setzt (alt="" ).
Funktionale Bilder: Bilder, die in Schaltflächen, Links und anderen interaktiven Elementen verwendet werden. In diesem Fall sollte der Alternativtext den Zweck des interaktiven Elements vermitteln und nicht das Bild selbst beschreiben.

Meine persönlichen Top 5 schlechter Alternativtexte

Bei Barrierefreiheits-Prüfungen von Websites stoße ich regelmäßig auf die immer gleichen Fehler. Hier ist meine persönliche Liste an Beispielen für miserablen Alternativtext:

Titel in Dauerschleife: Eine Artikelvorschau (z.B. im Nachrichten-Karussell) beinhaltet meistens ein Vorschau-Bild, um den Artikel zu illustrieren. Sehr oft finde ich Alternativtext vor, der nicht den Inhalt des Bildes beschreibt, sondern den Titel des Artikels wiederholt. Das ist völlig redundant und eine Zeitverschwendung für Screenreader-Nutzer:innen. Bitte nehmt euch die Zeit, den tatsächlichen Inhalt des Bildes zu beschreiben!
Hat der Fotograf ein Selfie gemacht? Oft treffe ich auf Fotos, deren Alternativtext die Copyright-Information beinhaltet. Hat die Fotografin ein Selfie gemacht und ist auf dem Foto zu sehen? Nein? Dann schmeiß den Namen aus dem Alternativtext raus! Du kannst das Copyright in die sichtbare Bildbeschreibung geben.
Was tut das Ding? Ein weiterer häufiger Fehler ist deskriptiver Alternativtext für funktionale Bilder. Stellt euch eine Icon-Schaltfläche vor, die visuell als nach unten zeigender Pfeil dargestellt wird. Die Schaltfläche ermöglicht das Herunterladen eines Dokuments, aber der Alternativtext lautet „Pfeil nach unten“. Nicht der beste Weg, um den Zweck der Schaltfläche zu vermitteln.
Ich bin gar nicht da: Man nehme ein div Element und packe ein Bild darauf mithilfe der CSS-Eigenschaft background-image . Et voilà! Ihr könnt das Bild sehen. Aber es gibt keine Informationen für assistive Technologien. Screenreader-Nutzer:innen werden gar nicht bemerken, dass ein Bild zu sehen ist. Oder noch schlimmer: Sie navigieren zu einem Bildlink oder einer Icon-Schaltfläche und erhalten keine Info über deren Zweck. Danke für nichts!
Reine Faulheit: Traurig, aber wahr. Ich treffe immer wieder auf img Tags, für die gar kein alt Attribut definiert ist. Es gibt einfach keine Beschreibung des Bildes. In diesem Fall lesen Screenreader häufig den Dateinamen des Bildes vor. Nicht gerade hilfreich, wenn das Bild als „wdkmm12xpY5.png“ beschrieben wird.

Fazit

Wenn ihr visuelle Inhalte in eine Webseite einbaut, dann stellt euch folgende Fragen: Welchen Zweck erfüllt das Bild? Ist es rein dekorativ? Falls nicht, definiert einen sinnvollen Alternativtext, der das Bild beschreibt oder den Zweck des Links oder der Schaltfläche vermittelt.

Nützliche Links

Erstelle eine stylishe, barrierefreie Datei-Auswahl in 3 Schritten

Tue, 24 May 2022 00:00:00 GMT

Native HMTL-Elemente sind von Haus aus barrierefrei. Die meisten lassen sich auch beliebig mit CSS stylen – wie ich in meinem Artikel über Web-Formulare gezeigt habe. Das Element zur Datei-Auswahl zählt leider nicht dazu.

Das <input type=“file”> Element wird vom Browser als Schaltfläche dargestellt, welche den Datei-Auswahldialog des Betriebssystems öffnet. Diese Schaltfläche lässt sich gar nicht mit CSS stylen – weder die Größe und Farbe noch die Schriftart. Aber, kein Grund zu verzweifeln! Ich zeige euch wie es geht.

Schritt 1: Native HTML-Elemente verwenden

Wenn ich ein Web-Formular mit Datei-Auswahl baue, dann sollen alle Nutzer:innen Dateien auswählen und hochladen können. Dazu zählen auch Menschen, die auf Screenreader oder die Tastaturbedienung angewiesen sind. Aus diesem Grund verwende ich das native, barrierefreie <input type=“file”> Element. Ich habe eine Demo mit dem React-Framework erstellt. So sieht mein JSX-Code aus:

<label htmlFor="filepicker" className={styles.filePicker}>
    <span>Upload PDF</span>
    <input
        id="filepicker"
        type="file"
        accept=".pdf"
        aria-describedby="selected-file"
        onChange={event => onFilePickerChange(event)}
    />
</label>
<p id="selected-file">{selectedFile}</p>

Ich verwende ein label Element, das die sichtbare Beschriftung meiner Datei-Auswahl (“Upload PDF”) sowie das visuell verborgene input Element enthält. Auf diese Weise fungiert das label Element als sichtbare UI-Komponente, das sich beliebig stylen lässt (mehr dazu in Schritt 2).

Das p Element zeigt den Hinweis an, dass noch keine Datei ausgewählt wurde. Nach der Auswahl einer Datei zeigt es den Dateinamen (siehe Schritt 3). Dank des Attributs aria-describedby wird der Text auch von Screenreadern vorgelesen, wenn die Nutzer:innen mit der Datei-Auswahl interagieren.

Ich habe auch versucht, mithilfe von aria-hidden=“true” den Absatz selbst vor assistiven Technologien zu verbergen. Da dies bei bestimmten Browser- und Screenreader-Kombinationen zu Problemen führte, habe ich das Attribut wieder entfernt. Jetzt hören Screenreader-Nutzer:innen den Hinweis möglicherweise zweimal. Das ist immer noch besser, als ihn gar nicht zu hören.

Schritt 2: Etwas CSS-Magie anwenden

Als nächstes mache ich das input Element mit CSS unsichtbar und positioniere es über dem label Element. Das erlaubt mir, die sichtbare Beschriftung benutzerdefiniert zu gestalten:

form label[for].filePicker {
    position: relative;
    background-color: rgb(49, 4, 92);
    color: white;
    font-size: 1rem;
    // ... more custom styling
}

form label[for].filePicker input[type=file] {
    position: absolute;
    top: 0;
    left: 0;
    height: 100%;
    width: 100%;
    opacity: 0;
}

Achtet bitte darauf, das <input type=“file”> Element nicht vor assistiven Technologien zu verbergen. Die Nutzung von display: none oder das Setzen einer Größe von null Pixel würde dazu führen, dass Screenreader das Element nicht mehr auffinden können.

Damit auch sehende Nutzer:innen ein visuelles Feedback erhalten, zeichne ich eine Outline für das label Element ein, wenn der Mauszeiger darüber bewegt wird oder wenn das darin verschachtelte input Element fokussiert wird.

form label[for].filePicker:focus-within,
form label[for].filePicker:hover {
    outline: 2px solid black;
    outline-offset: 2px;
}

Schritt 3: Eine Prise JavaScript

Als letzten Schritt möchte ich den Dateinamen anzeigen, wenn Nutzer:innen eine Datei ausgewählt haben. Zu diesem Zweck nutz ich das change Event, das ausgelöst wird, wenn der Eingabewert verändert wird.

const FileUpload: React.FunctionComponent = () => {
    const [selectedFile, setSelectedFile] = useState('No file selected');

    const onFilePickerChange = (event: React.ChangeEvent<HTMLInputElement>) => {
        const files = Array.from(event.target.files ?? []);
        if (files.length > 0) {
            setSelectedFile(files[0].name);
        }
    }

    return (
        // Only the relevant sections of the JSX code
        <input type="file"
            // ...
            onChange={event => onFilePickerChange(event)}
        />
        <p id="selected-file">{selectedFile}</p>
        // ...
    );
};

Natürlich könnt ihr das auch in reinem JavaScript umsetzen – oder irgendeinem Framework eurer Wahl. Ich liefere euch nur ein Beispiel für eine Implementierung als React-Komponente. Seht euch den kompletten Quellcode auf GitHub an.

Die perfekte Datei-Auswahl, oder?

Hier seht ihr meine gestylte Datei-Auswahl in Aktion. Probiert es aus! Zum Vergleich habe ich auch ein unverändertes <input type=“file”> Element eingebaut.

Ich bin mit dem Resultat an sich sehr glücklich. Allerdings geht es immer besser. Die Datei-Auswahl lässt sich super mit der Tastatur bedienen. Auch Screenreader-Nutzer:innen können mit dem Element gut interagieren, wobei es in Kombination mit gewissen Browsern und Plattformen kleinere Probleme gibt (siehe englische Version des Artikels).

Vielleicht werden diese Probleme durch zukünftige Updates gelöst. Oder ich finde noch eine bessere Lösung. Jedenfalls zeigt meine Demo, dass eine barrierefreie, gestylte Datei-Auswahl für Web-Formulare keine Hexerei ist.

Update am 26.03.2023

Ich habe mich geirrt: Es gibt tatsächlich eine Möglichkeit, das native <input type=“file”> HTML-Element anzupassen. Ihr könnt das ::file-selector-button CSS-Pseudoelement verwenden, um die gerenderte Schaltfläche zu gestalten. Leider könnt ihr den Text, der innerhalb der Schaltfläche gerendert wird, nicht ändern. Hier findet ihr eine Demo mit weiteren Informationen dazu.

Update am 10.12.2023

Ich habe den HTML-Code in meinem Beispiel überarbeitet und die Screenreader-Tests mit den aktuellen Browserversionen erneut durchgeführt.

Wie du ein Gespür für digitale Barrierefreiheit entwickelst

Sun, 03 Apr 2022 00:00:00 GMT

„Ich würde gerne einen Entwurf für eine Website betrachten können und sofort spüren: Das ist nicht barrierefrei!“ – Diesen Wunsch äußerte ein Kollege vor ein paar Tagen. Er arbeitet bereits seit vielen Jahren als Web-Entwickler, hat aber noch wenig Erfahrung mit digitaler Barrierefreiheit gesammelt.

Seine Frage brachte mich zum Nachdenken: Was können Neulinge tun, um möglichst schnell ein gutes Gespür für das Thema zu entwickeln?

Responsives Design? Wozu soll das gut sein?

Jüngere Kolleg:innen können sich das wohl schwer vorstellen: Es war nicht immer selbstverständlich, dass sich Web-Inhalte fließend an verschiedene Bildschirmgrößen anpassen. Noch in den Nullerjahren war es üblich, Websites nur für konkrete Bildschirmgrößen zu optimieren. Eine gute Zusammenfassung bietet der Artikel „A Brief History of Responsive Web Design“.

Erst der Siegeszug des Smartphones brachte ein Umdenken. Nutzer:innen erwarten heute, dass Websites auf allen Geräten gut aussehen und bedienbar sind. Responsives Design wird explizit als Anforderung für Web-Projekte definiert. UI/UX-Expert:innen gestalten Entwürfe und Prototypen für verschiedene Bildschirmgrößen. Entwickler:innen testen implementierte Features ganz selbstverständlich auf Desktop- und Mobilgeräten.

Was hat das jetzt mit Barrierefreiheit zu tun? Für mich zeigt der Siegeszug von responsivem Design deutlich: Je mehr Menschen Websites auf eine bestimmte Weise nutzen, desto stärker werden diese Bedürfnisse in der Web-Entwicklung berücksichtigt.

Barrierefreies Design? Wozu soll das gut sein?

Die Mehrheit der Web-Nutzer:innen greift zum Smartphone oder zur Maus, um im Internet zu surfen. Sie klicken auf eine Schaltfläche und registrieren das visuelle Feedback der Seite. Sie sind nicht darauf angewiesen, dass ein Screenreader den Web-Inhalt sinnvoll vorlesen kann oder interaktive Elemente mit der Tastatur erreichbar sind.

Auch Web-Entwickler:innen sind im Grunde nur Nutzer:innen. Ihre alltäglichen Erfahrungen beeinflussen ihre Wahrnehmung, was eine gute, bedienbare Website ausmacht. Ein Beispiel: Wer noch nie einen Screenreader genutzt hat, kann sich schwer vorstellen, warum die semantische Auszeichnung von Web-Inhalten so wichtig ist.

Das bringt mich zur zentralen Frage zurück: Was können Neulinge tun, um möglichst schnell ein gutes Gespür für das Thema zu entwickeln? Ganz einfach: Die Perspektive wechseln!

Perspektive von Menschen mit Behinderung einnehmen

Wenn ihr die Bedürfnisse von Menschen mit Behinderung verstehen wollt, dann fragt sie am besten selbst, wie sie digitale Inhalte nutzen. Lasst euch von einer blinden oder sehbeeinträchtigten Person zeigen, wie sie mithilfe eines Screenreaders online einkauft. Sprecht mit einer gehörlosen Person darüber, wie sie Nachrichten mit Untertiteln oder in Gebärdensprache schaut.

Falls ihr keine Menschen mit Behinderung kennt, könnt ihr z.B. in eurer Firma einen Workshop organisieren. Hier kann etwa der Blinden- und Sehbehindertenverband Österreich ein Ansprechpartner sein. Manche Organisationen bieten auch konkrete Trainings an (Beispiel: Sensing Journey von myAbility).

Übung macht den Meister

Als Web-Entwickler:in ist man laufend mit neuen Anforderungen konfrontiert, die aus der rasanten, technischen Entwicklung resultieren. Deshalb haben wir das Prinzip „Learning by Doing“ verinnerlicht. Diese Herangehensweise hilft uns auch beim Thema digitale Barrierefreiheit: Einfach mal machen!

Ein guter Startpunkt sind aus meiner Sicht die „Web Content Accessibility Guidelines“ (WCAG), die für den öffentlichen Bereich in allen EU-Mitgliedsstaaten bereits rechtlich vorgeschrieben sind. Die WCAG decken eine große Bandbreite an Bedürfnissen verschiedener Nutzer:innengruppen ab. Sie bieten sehr ausführliche Online-Ressourcen, mit konkreten Beispielen für barrierefreie Implementierungen sowie häufige Fehler.

Mein Tipp: Die meisten Web-Inhalte können allein mit semantischem HTML und CSS barrierefrei aufbereitet werden. Oft stoße ich auf Websites, die exzessiv ARIA-Attribute einsetzen und damit mehr Barrieren erzeugen als sie beseitigen. Sinnvoll ist der Einsatz von ARIA bei komplexen UI-Komponenten, wie die WAI-ARIA Authoring Practices veranschaulichen.

Lass dir Zeit

Das Thema digitale Barrierefreiheit ist komplex und vielschichtig. Das bedeutet für Neulinge eine steile Lernkurve und viel Frustpotential. Ihr solltet euch Schritt für Schritt dem Thema annähern und offen für neue Perspektiven sein. Dann entwickelt ihr das richtige Gespür mit der Zeit ganz von allein.

Barrierefreie und interaktive Diagramme mit Angular und Highcharts

Sun, 13 Mar 2022 00:00:00 GMT

Säulen- und Liniendiagramme müssen nicht langweilig und statisch sein. Moderne JavaScript-Bibliotheken ermöglichen das Erstellen von animierten, interaktiven und barrierefreien Diagrammen.

Ich bin ein großer Fan von Highcharts, einer JavaScript-Bibliothek für SVG-basierte Diagramme. Es gibt mehrere Bibliotheken, welche Highcharts in die auf Komponenten basierte Architektur von React und Angular integrieren. In meiner Demo-App zeige ich dir, wie du auch das Event-Handling von Highcharts mit Angular-Komponenten verbinden kannst.

Demo App: Auswahl eines Tabs, wenn eine Säule im Diagramm geklickt wird

Meine Demo-App basiert auf Angular 13, Highcharts und highcharts-angular, einer minimalen Bibliothek, die Highcharts für Angular kapselt. Ein Säulendiagramm zeigt die Nutzung primärer Desktop-Screenreader. Mehrere Tabs bieten zusätzliche Informationen zu den Screenreadern. Wenn eine Säule im Diagramm geklickt wird, wird das zugehörige Tab ausgewählt. Probiere es aus:

Also, wie habe ich das geschafft?

Schritt 1: Diagramm-Optionen definieren und das Diagramm rendern

Die Highcharts-Bibliothek ist extrem praktisch. Du definierst einfach deine Diagramm-Optionen und Highcharts erledigt den Rest. In meiner Demo-App habe ich ein Diagramm mit zwei Säulenreihen definiert:

export const EXAMPLE_CHART: Highcharts.Options = {
    series: [
        {
            data: [
                [ScreenreaderName.Jaws, 53.7],
                [ScreenreaderName.Nvda, 30.7],
                [ScreenreaderName.VoiceOver, 6.5],
                [ScreenreaderName.ZoomTextFusion, 4.7],
                [ScreenreaderName.Other, 4.4],
            ],
            name: 'Worldwide',
            type: 'column',
        },
        {
            data: [
                [ScreenreaderName.Jaws, 40.2],
                [ScreenreaderName.Nvda, 41.6],
            ],
            name: 'Europe',
            type: 'column',
        }
    ],
    subtitle: {
        text: '',
    },
    title: {
        text: 'Primary desktop/laptop screen reader (2021)',
    },
    xAxis: {
        categories: [
            ScreenreaderName.Jaws,
            ScreenreaderName.Nvda,
            ScreenreaderName.VoiceOver,
            ScreenreaderName.ZoomTextFusion,
            ScreenreaderName.Other,
        ],
    },
    yAxis: {
        title: {
            text: 'Usage in percent',
        }
    }
}

Dann stelle ich in der AppComponent die Diagramm-Optionen und die Highcharts-Bibliothek bereit:

import * as Highcharts from 'highcharts';

@Component({
    selector: 'app-root',
    templateUrl: './app.component.html',
    styleUrls: ['./app.component.scss']
})
export class AppComponent {
    public chartOptions = EXAMPLE_CHART;
    public highchartsLib = Highcharts;
}

Als letztes übergebe ich im HTML-Template die Bibliothek und die Diagramm-Optionen an die <highcharts-chart> Komponente:

<highcharts-chart
    [Highcharts]="highchartsLib"
    [options]="chartOptions"
    (chartInstance)="addCustomPropertiesToChart($event)"
></highcharts-chart>

Schritt 2: Benutzerdefinierte Eigenschaften der Diagramm-Instanz hinzufügen

Die <highcharts-chart> Komponente stellt die Ausgabe-Eigenschaft chartInstance bereit. Über diese erhalten wir die Instanz des Diagramms, nachdem dieses erstellt wurde. Dieser Instanz fügen wir eine Funktion als benutzerdefinierte Eigenschaft hinzu:

public addCustomPropertiesToChart(chartInstance: Highcharts.Chart): void {
    (chartInstance as MyExampleChart).onSeriesPointClick =
        (name) => this.selectScreenreaderTab(name);
}

Das Chart Interface von Highcharts kennt keine Methode namens onSeriesPointClick . Deshalb definieren wir ein eigenes Interface, welches diese benutzerdefinierte Eigenschaft hinzufügt:

export interface MyExampleChart extends Highcharts.Chart {
    onSeriesPointClick: (name: ScreenreaderName) => void;
}

Nun bietet unsere Diagramm-Instanz eine Methode an, die direkt mit der Eltern-Komponente des Diagramms verknüpft ist. Ein Event Handler des Diagramms kann diese Methode aufrufen, um zum Beispiel zu kommunizieren, dass ein konkreter Datenpunkt angeklickt worden ist.

Schritt 3: Die benutzerdefinierte Methode in einem Event Handler aufrufen

Mithilfe der Eigenschaft plotOptions in den Diagramm-Optionen definieren wir einen Click Event Handler für alle Datenpunkte:

click: function(this) {
    const chart = this.series.chart as MyExampleChart;
    chart.onSeriesPointClick(this.name as ScreenreaderName);
}

Der Event Handler holt sich die Diagramm-Instanz, die unserem benutzerdefinierten Interface MyExampleChart entspricht. Nun können wir die benutzerdefinierte Methode onSeriesPointClick aufrufen und somit das zum Datenpunkt gehörige Screenreader-Tab in der Applikation auswählen.

Schritt 4: Mache dein Diagramm barrierefrei

Highcharts bietet großartige Features für mehr Barrierefreiheit an. Du kannst etwa Farben als Musterfüllungen definieren. Das hilft besonders Menschen mit eingeschränktem Farbsehen. Diese profitieren davon, wenn durch Farbe vermittelte Informationen auch auf andere visuelle Weise verfügbar sind.

color: {
    pattern: {
        backgroundColor: '#96dbe7',
        color: '#080e38',
        height: 10,
        path: 'M 0 0 L 10 10 M 9 - 1 L 11 1 M - 1 9 L 1 11',
        width: 10,
    }
},

Mithilfe der Eigenschaft linkedDescription kannst du das Diagramm mit einem HTML-Element verknüpfen, das den Inhalt des Diagramms beschreibt:

accessibility: {
    enabled: true,
    linkedDescription: '#highcharts-description-1',
},

Fazit

Kombiniere Angular und Highcharts, um wunderschöne, barrierefreie Diagramme mit minimalem Aufwand zu gestalten. Mithilfe von benutzerdefinierten Eigenschaften kannst du das Event Handling von Highcharts mit der auf Komponenten basierten Architektur von Angular verbinden, um noch interaktivere Nutzer:innen-Erlebnisse zu erschaffen.

Ressourcen

Barrierefreie Web-Formulare mit individuellem Design gestalten

Sat, 26 Feb 2022 00:00:00 GMT

HTML ist von Haus aus barrierefrei. Zumindest wenn du native Elemente verwendest. Sehr oft implementieren Entwickler:innen benutzerdefinierte UI-Komponenten für Formulare, um Design-Anforderungen zu erfüllen. Dabei bleibt die Barrierefreiheit meist auf der Strecke.

In diesem Artikel zeige ich dir, wie du native Formularelemente mit CSS individuell stylen kannst. Auf diese Weise kannst du barrierefreie Web-Formulare mit einem konsistenten Look über alle Plattformen gestalten.

Wenn Design-Anforderungen die Barrierefreiheit zerstören

Native Formularelemente wie input oder select sind grundsätzlich barrierefrei. Sie erhalten den Fokus, wenn Nutzer:innen die Tab-Taste drücken. Sie ermöglichen die Interaktion mit der Enter- oder Leertaste, z.B. um eine Checkbox anzuhaken. Und sie kommunizieren ihre Rolle und ihren aktuellen Status an Screenreader.

Klingt super! Wer würde jemals auf die verrückte Idee kommen, statt der nativen Formularelemente eigene UI-Komponenten mit nicht-semantischem Spaghetti-Code zu implementieren? Wie wir leider alle wissen, sind benutzerdefinierte Formularelemente weit verbreitet. Meistens sind sie nicht barrierefrei. Sehen wir uns folgendes Beispiel für eine selbstgebaute Auswahlliste an:

<div class="custom-select">
    <div class="select-trigger">
        <span>PlayStation 5</span>
        <div class="arrow"></div>
    </div>
    <div class="custom-options">
        <span class="option selected">
            PlayStation 5
        </span>
        <span class="option">Nintendo Switch</span>
        <span class="option">Xbox Series X</span>
    </div>
</div>

Dieser wilde Haufen von div und span Tags ist an sich nicht barrierefrei für Tastatur- und Screenreader-Nutzer:innen. Natürlich lässt sich das mit ARIA-Attributen und Keydown Event Listeners beheben. Doch vielen Entwickler:innen fehlt entweder dieses Wissen oder es ist ihnen schlichtweg egal. Für sie zählt vor allem eines: Die Formularelemente entsprechend der Design-Anforderungen der Kund:innen zu gestalten.

Warum das Styling von nativen Elementen herausfordernd sein kann

Das Styling von Formularelementen mit CSS war in der Vergangenheit oft schwierig. Browser wenden jeweils ihr eigenes Standard-Styling an. Formularelemente unterscheiden sich stark darin, wie einfach ihr Aussehen mit CSS angepasst werden kann. Glücklicherweise werden immer mehr veraltete Browser ausgemustert (Stichwort: IE11), weshalb man ohne Probleme auf neue Features moderner Browser zurückgreifen kann.

Mozilla hat einen tollen Artikel über das Styling von Web-Formularen verfasst, den ihr unbedingt lesen solltet. Sie unterteilen native Formularelemente in drei Gruppen: „Die Guten“, „Die Bösen“ und „Das Hässliche“. Ich stimme großteils mit dem Artikel überein, mit Ausnahme der Einschätzung, dass Checkboxen und Radio-Buttons schwer zu stylen wären. Das war vielleicht in der Vergangenheit so, trifft aber heute nicht mehr zu. Mit modernem CSS sind der Fantasie keine Grenzen gesetzt.

Styling-Beispiel 1: Radio-Buttons

Um Radio-Buttons mit CSS umzugestalten, müsst ihr zuerst für die CSS-Eigenschaft appearance den Wert none setzen. Damit entfernt ihr das Standard-Styling des Browsers bzw. Betriebssystems. Nun könnt ihr euch kreativ austoben und sogar Zustands-Änderungen animieren:

input[type="radio"] {
    -webkit-appearance: none;
    appearance: none;
    box-sizing: border-box;
    position: relative;
    width: 1.4em;
    height: 1.4em;
    border: 0.15rem solid darkred;
    border-radius: 50%;
}

input[type="radio"]::before {
    position: absolute;
    top: 50%;
    left: 50%;
    content: "";
    width: 0.7em;
    height: 0.7em;
    border-radius: 50%;
    background-color: darkred;
    /* scale(0) hides the dot in unchecked state */
    transform: translate(-50%, -50%) scale(0);
    transform-origin: center;
    transition: all 0.3s ease-in;
}

input[type="radio"]:checked::before {
    transform: translate(-50%, -50%) scale(1);
    transition: all 0.3s cubic-bezier(0.25, 0.25, 0.56, 2);
}

In meinem Beispiel werden Radio-Buttons im nicht ausgewählten Zustand als dunkelroter Kreis dargestellt. Mithilfe des Pseudo-Elements ::before und der Pseudo-Klasse :checked wird ein dunkelroter Punkt angezeigt, wenn der Radio-Button ausgewählt wird. Probiere es selbst in meiner Demo auf CodePen aus.

Styling-Beispiel 2: Select

Das HTML-Element select zählt zur Kategorie „Das Hässliche“. Die Formularelemente in dieser Gruppe sind problematisch, da sie von Browsern auf sehr unterschiedliche Weise dargestellt werden. Du kannst sie zu einem gewissen Grad gestalten, doch einzelne Bestandteile entziehen sich völlig dem Zugriff von CSS.

Mit der CSS-Eigenschaft appearance kannst du das Standard-Styling des select Elements grundsätzlich überschreiben. Das hat jedoch keine Auswirkungen auf die Optionen-Liste, die beim Klick auf das Element eingeblendet wird. Das Styling des HTML-Elements option mit CSS ist stark eingeschränkt und wird nur von wenigen Browsern unterstützt.

Meiner Meinung nach sind die Styling-Möglichkeiten aber ausreichend, um grundlegende Design-Anforderungen (Farbe, Schriftart etc.) zu erfüllen. In meiner Demo auf CodePen habe ich folgendes Styling angewandt:

select {
    -webkit-appearance: none;
    appearance: none;
    box-sizing: border-box;
    background-color: white;
    background-image:
        url('/assets/custom_arrow_for_select.svg');
    background-position: right;
    background-repeat: no-repeat;
    background-size: contain;
    border: 0.25rem solid darkred;
    padding: 0.25em;
    /* Leave enough space for the arrow on the right */
    padding-right: 2em;
}

Natives HTML ist immer besser

Mit diesem Artikel wollte ich folgendes zeigen: Wenn du die Wahl zwischen nativem HTML und benutzerdefinierten Formularelementen hast, dann entscheide dich für native HTML-Elemente. Sie sind von Haus aus barrierefrei und können ausreichend mit CSS gestylt werden.

Raus mit der Sprache! Bestimme wie Screenreader Text vorlesen sollen

Sun, 13 Feb 2022 00:00:00 GMT

Zahlen, Abkürzungen und Gleichungen können für Screenreader-Nutzer:innen eine Herausforderung darstellen. Mit der CSS-Eigenschaft speak-as kannst du bestimmen, wie Text vorgelesen werden soll.

Buchstabieren oder nicht buchstabieren, das ist hier die Frage

Vor einigen Tagen habe ich einen Kunden aus der Bankenbranche beraten. Sie möchten ihre Website für Screenreader-Nutzer:innen optimieren. Eine Frage lautete: Wie können wir den Screenreader dazu bringen, eine Zahl immer Ziffer für Ziffer vorzulesen? Zum Beispiel eine Kontonummer mit 12 oder mehr Stellen?

In vielen Fällen sagen Screenreader statt der einzelnen Ziffern die ganze Zahl an. Beispielsweise wird 9100 als „neuntausend einhundert“ anstelle von „neun eins null null“ vorgelesen. Ähnliche Probleme können bei Abkürzungen oder Gleichungen auftreten. Es läuft alles auf die inhärente Heuristik des Screenreaders hinaus. Diese bestimmt, wie gewisse Abfolgen von Buchstaben und Satzzeichen vorgelesen werden.

Wäre es nicht großartig, wenn wir dem Screenreader einfach sagen könnten, wie er bestimmte Inhalte lesen soll? Die Antwort lautet: Ja, das geht! Aber die Browserunterstützung ist leider schlecht.

Die CSS-Eigenschaft speak-as

Das CSS Speech Module definiert die Eigenschaft speak-as . Sie bestimmt, auf welche Weise Text akustisch wiedergegeben wird, basierend auf einer vordefinierten Liste von Möglichkeiten:

normal: Verwendet die sprachabhängigen Ausspracheregeln des Browsers (Standard).
spell-out: Weist den Browser an, den Text zu buchstabieren (nützlich für Akronyme und Abkürzungen).
digits: Zahlen werden Ziffer für Ziffer vorgelesen. Zum Beispiel: 9100 als „neun eins null null“.
literal-punctuation: Satzzeichen (wie Semikolons, Klammern usw.) werden vorgelesen anstatt sie wie Pausen zu behandeln.
no-punctuation: Satzzeichen werden ignoriert.

Mithilfe dieser CSS-Eigenschaft könnten wir etwa eine Klasse für Kontonummern wie folgt definieren:

.bank-account-number {
    speak-as: digits;
}

Browser- und Screenreader-Unterstützung

In der Theorie klingt das alles großartig. Leider funktioniert es mit den meisten Browsern und Screenreadern nicht. Ich habe eine Demo auf CodePen zusammengestellt und die folgenden Szenarien getestet:

NVDA 2021.3.1, Google Chrome 98.0.4758.82, Windows 10
TalkBack, Firefox 97.1.0, Android 12
VoiceOver, Safari 15, iOS 15.1

Von den dreien leistet nur VoiceOver tolle Arbeit und liest den Inhalt gemäß dem Wert der speak-as Eigenschaft vor. NVDA und TalkBack ignorieren es vollständig.

In Anbetracht der Tatsache, dass das CSS Speech Module vor über 10 Jahren geschrieben wurde, bin ich von der aktuellen Situation sehr enttäuscht. Ich hoffe, dass in Zukunft weitere Browser und Screenreader dieses Feature unterstützen werden!

3 unterschätzte HTML-Elemente, die einfach großartig sind

Sat, 05 Feb 2022 00:00:00 GMT

Wusstest du, dass es über 100 verschiedene HTML-Elemente gibt? Einige davon wie <h1> , <p> oder <img> sind uns allen geläufig. Doch viele Elemente fristen ein Nischendasein. Manche Web-Entwickler:innen wissen nicht mal von ihrer Existenz.

Aus diesem Grund möchte ich in diesem Artikel drei unterschätzte HTML-Elemente vor den Vorhang holen: <time> , <picture> und <dl> .

Das time-Element: Maschinenlesbare Datum- und Zeitangaben

Das HTML-Element <time> repräsentiert einen konkreten Zeitpunkt, Datum oder Zeitraum. Zusammen mit dem Attribut datetime wird die Zeitangabe maschinenlesbar. Wozu das gut ist? Hier ein Beispiel:

Öffne das Code-Beispiel time element German von Alexander Lehner (@alexlehner86) auf CodePen.

Das Beispiel enthält drei Termine, deren Datum jeweils im Stil eines Abreißkalenders dargestellt wird. Vielleicht denkst du jetzt: Oida, das erklärt sich eh von selbst! Zusammen mit der Überschrift „Termine 2022“ ist doch klar, welches Datum gemeint ist.

Sehende werden wohl tatsächlich kein Problem mit dieser Darstellung des Datums haben. Anders die Situation für blinde oder sehbeeinträchtigte Nutzer:innen. Wenn der Screenreader “mär vier” oder “jul acht” vorliest, wird das verwirrend sein. Das <time> Element sorgt hier für Klarheit.

Leider unterstützen noch nicht alle gängigen Screenreader das Element. VoiceOver liest das im datetime Attribut definierte Datum korrekt vor (getestet mit einem iPhone 8, iOS 15, Safari). Mit den Screenreadern NVDA und TalkBack funktioniert das leider derzeit nicht.

Das picture-Element: Bilder in der passenden Größe laden

Das HTML-Element <picture> ist ein Container, der zur Angabe mehrerer Quellen für ein Bild dient. Es muss ein <img> Element und kann mehrere <source> Elemente enthalten. Damit kannst du das Bild für verschiedene Bildschirmauflösungen und Browser optimieren. Schauen wir uns ein Beispiel an:

<picture>
    <source srcset="cat_lg.avif" type="image/avif" media="(min-width: 60rem)">
    <source srcset="cat_md.avif" type="image/avif">
    <source srcset="cat_lg.webp" type="image/webp" media="(min-width: 60rem)">
    <source srcset="cat_md.webp" type="image/webp">
    <source srcset="cat_lg.jpg" media="(min-width: 60rem)">
    <img src="cat_md.jpg" alt="An adorable cat" loading="lazy" decoding="async">
</picture>

Das Attribut type erlaubt die Angabe des MIME-Typs der im Attribut srcset angegebenen Ressource. Das erste <source> Element im Beispiel oben verweist auf ein Bild im neuen AVIF-Format. Wenn der Browser AVIF-Bilder wiedergeben kann, wählt er diese Bilddatei. Andernfalls geht es weiter zum nächsten <source> Element.

Auf diese Weise können moderne Browser, die das AVIF- oder WebP-Format unterstützen, ein stark komprimiertes Bild in hoher Qualität laden. Ältere Browser können hingegen auf die JPG-Version des Bildes zurückgreifen.

Das Attribut media erlaubt die Angabe einer Media-Query, die der Browser auswertet. Im Beispiel sagen wir dem Browser, das größere Bild zu verwenden, wenn die Bildschirmbreite mindestens 60 rem beträgt. Wenn eine Media-Query nicht zutrifft, geht es ebenfalls weiter zum nächsten <source> Element.

Eine weitere Möglichkeit zur Bildoptimierung bietet das Attribut srcset . Dieses kannst du auch direkt mit dem <img> Element verwenden, wie das süße Katzenfoto oben zeigt. Dessen HTML-Code sieht ungefähr so aus:

<img
    srcset="cat-480w.jpg 480w, cat-800w.jpg 800w"
    sizes="(max-width: 600px) 480px, 800px"
    src="cat-800w.jpg"
    alt="Eine schlafende Katze mit schwarz-grauem Fell."
>

Das srcset Attribut definiert eine Reihe von Bildern, aus denen der Browser wählen kann, sowie die Größe der Bilder. Das sizes Attribut definiert eine Reihe von Bedingungen (z.B. Bildschirmbreite) und gibt an, welche Bildgröße der Browser wählen sollte, wenn eine bestimmte Media-Query zutrifft.

Wenn ihr noch tiefer in das Thema einsteigen wollt, kann ich folgende Artikel empfehlen:

Schlüssel-Wert-Paare mit dl, dt und dd auszeichnen

Listen zählen zu den grundlegenden Bausteinen in HTML. Jede:r Web-Entwickler:in kennt die HTML-Elemente <ul> und <ol> für ungeordnete und geordnete Listen. Doch wenige sind mit ihrem nahen Verwandten <dl> vertraut.

Diese sogenannte Description List umfasst eine Liste an Begriffen und Beschreibungen, die mit den HTML-Elementen <dt> und <dd> definiert werden. Üblicherweise wird es zur Anzeige eines Glossars oder von Metadaten (also einer Liste von Schlüssel-Wert-Paaren) genutzt.

<dl>
    <dt>Kontoinhaber</dt>
    <dd>Martina Musterfrau</dd>
    <dt>Bankinstitut</dt>
    <dd>Musterbank</dd>
    <dt>IBAN</dt>
    <dd>AT12 3456 7891 2345 6789</dd>
</dl>

Was macht das Element in meinen Augen so großartig? Erraten! Es macht den Inhalt barrierefrei für Screenreader zugänglich. Doch auch Web-Entwickler:innen profitieren davon. Stell dir das Beispiel oben als eine Abfolge von <div> Elementen vor und überlege, in welchen Code du dich schneller einlesen und zurechtfinden könntest. Semantisches HTML macht Code lesbarer!

Licht aus! Wie blinde Menschen im Internet surfen

Sat, 29 Jan 2022 00:00:00 GMT

Wie fühlt es sich an, blind zu sein? Wie kann man auf einer Website navigieren und den Inhalt lesen? Meine Demo-Seite „Komm auf die dunkle Seite“ ermöglicht es, alles schwarz zu färben und das Web wie blinde Nutzer:innen zu erleben.

2,2 Milliarden Menschen sind sehbeeinträchtigt

Laut dem „World report on vision 2019“ sind weltweit etwa 2,2 Milliarden Menschen blind oder sehbeeinträchtigt. Viele von ihnen verwenden einen Screenreader, um im Internet zu surfen.

Sehenden Menschen fällt es oft schwer, wirklich zu verstehen, was das bedeutet: Kein visueller Input, sich nur auf das auditive Feedback des Screenreaders verlassen müssen.

Da ich ein neugieriger Mensch bin, habe ich eine Demo-Seite zusammengestellt, auf der du erleben kannst, wie sich das Web für blinde Nutzer:innen anfühlt. Mein Ziel ist es, dass Menschen selbst nachvollziehen können, wie wichtig barrierefreie Web-Inhalte für blinde Menschen sind.

Komm auf die dunkle Seite

Ich habe meine Demo-Seite unten eingebunden. Aktiviere einfach deinen Screenreader und färbe über den „Licht aus“-Schalter in der Kopfzeile alles schwarz.

Ich freue mich auf dein Feedback! Schreib mir einfach auf Mastodon.

Update am 09.04.2022

Ich habe meine Demo-Seite nun zweisprachig gestaltet und die deutschsprachige Version hier im Artikel eingebunden und verlinkt.

Gestalte deutlich sichtbaren Tastaturfokus mit :focus-visible

Sat, 22 Jan 2022 00:00:00 GMT

Schickes Design oder Barrierefreiheit? Mit der CSS-Pseudoklasse :focus-visible könnt ihr sowohl Tastaturnutzer:innen unterstützen als auch ästhetisch anspruchsvolle Kund:innen zufriedenstellen.

Die Bedeutung des Tastaturfokus

Ein zentrales Merkmal von barrierefreien Websites ist die Möglichkeit, sie alleine mit der Tastatur zu bedienen. Davon profitieren etwa Nutzer:innen mit motorischen Einschränkungen, die keine Maus verwenden können. Damit sie sinnvoll durch den Inhalt navigieren können, muss das aktuell fokussierte Element einen deutlich erkennbaren, visuellen Fokus-Indikator erhalten.

Browser definieren einen Standard-Fokusrahmen, um die Sichtbarkeit des Tastaturfokus zu gewährleisten. Das Aussehen des Fokus-Indikators kann mithilfe der CSS-Pseudoklasse :focus geändert werden. Zum Beispiel:

button:focus {
    outline: 2px solid purple;
}

Design versus Barrierefreiheit

Nun wird der Fokus-Indikator nicht nur bei der Navigation mit der Tastatur eingeblendet, sondern auch dann, wenn Nutzer:innen ein fokussierbares Element mit der Maus anklicken oder am Handy mit dem Finger berühren. Für manche Nutzer:innen ist diese visuelle Änderung unerwartet und irritierend. Ihnen ist nicht bewusst, dass der Fokus-Indikator zur Barrierefreiheit beiträgt.

Oft sind Web-Entwickler:innen daher mit Kund:innen oder Grafik-Designer:innen konfrontiert, welche die Entfernung des Fokus-Indikators aus ästhetischen Gründen fordern. Zahlreiche Websites enthalten daher CSS-Regeln wie diese:

button:focus {
    outline: none;
}

Bitte tut das nicht! Ihr würdet damit Nutzer:innen, die auf die Tastaturbedienung angewiesen sind, von der Nutzung eurer Website ausschließen.

Die Lösung heißt :focus-visible

Es gibt eine Möglichkeit, Design und Barrierefreiheit zu versöhnen: Die Pseudoklasse :focus-visible . Die Spezifikation dazu lautet:

The :focus-visible pseudo-class applies while an element matches the :focus pseudo-class and the user agent determines via heuristics that the focus should be made evident on the element.

Das bedeutet: Der Fokus-Indikator wird nur eingeblendet, wenn er gebraucht wird. Also wenn ein Element fokussiert wird und der Browser den visuellen Indikator für notwendig erachtet (z.B. bei Navigation mit der Tastatur).

/* Fokus-Indikator verbergen, wenn dieser nicht benötigt wird. */
button:focus:not(:focus-visible) {
    outline: none;
}

/* Fokus-Indikator bei Navigation mit Tastatur einblenden. */
button:focus-visible {
    outline: 2px solid purple;
}

Auf diese Weise könnt ihr das Fokus-Verhalten etwa für Schaltflächen und Links präzise steuern. Manche Elemente wie Eingabefelder erhalten jedoch weiterhin bei einem Mausklick den Fokus-Indikator, da das Anklicken die Eingabe per Tastatur aktiviert und somit eine Tastaturbedienung gegeben ist. Mit meiner Demo könnt ihr selbst das Verhalten testen.

Browser-Unterstützung

Das Feature wird bereits von den meisten modernen Browsern unterstützt. Auch Safari unterstützt :focus-visible seit der Version 15.4. Wer auf Nummer sicher gehen will, kann einen regulären Fokus-Indikator definieren und diesen für Browser, die :focus-visible unterstützen, überschreiben.

/* Regulärer Fokus-Indikator für ältere Browser */
button:focus {
    outline: 2px solid purple;
}

/* Für Browser, die :focus-visible unterstützen */
@supports (:focus-visible) {
    button:focus:not(:focus-visible) {
        outline: none;
    }

    button:focus-visible {
        outline: 2px solid purple;
    }
}

Nützliche Links

Update am 14.04.2022

Artikel wurde hinsichtlich Safari 15.4 aktualisiert.

5 Tipps für den Einstieg in Barrierefreiheits-Prüfungen mit dem Screenreader

Sat, 15 Jan 2022 00:00:00 GMT

Aller Anfang ist schwer: Wie dir der Einstieg in die Prüfung mit Screenreadern gelingt und welche Tastaturbefehle und Gesten dir das Leben leichter machen.

Mein erstes Mal

Als ich vor drei Jahren das erste Mal einen Screenreader am Laptop aktivierte, wurde ich kurz panisch. Eine roboterhafte Stimme begann in hohem Tempo auf mich einzureden. Intuitiv versuchte ich das Gehörte mit dem, was ich am Bildschirm sah, abzugleichen – und scheiterte kläglich. Stress pur!

Gerade für sehende Menschen kann die Nutzung eines Screenreaders zu Beginn verwirrend sein. Etwa für Web-Entwickler:innen, die ein frisch implementiertes Feature auf Barrierefreiheit prüfen möchten. Oder für Tester:innen, die eine Applikation aus der Perspekte von Blinden und stark Sehbeeinträchtigten testen. Daher möchte ich ein paar Tipps teilen, wie der Einstieg leichter fallen kann.

Tipps für den Einstieg

Für Desktop-Geräte unter Windows kann ich den kostenfreien Screenreader NVDA empfehlen. Auf Apple-Geräten wie z.B. einem iPhone ist der Screenreader VoiceOver bereits vorinstalliert. Das Pendant auf Android-Geräten heißt TalkBack.

Wo ist die Stopp-Taste? Jeder Screenreader bietet eine Möglichkeit, das Vorlesen zu unterbrechen. Zum Beispiel, bei VoiceOver einfach mit zwei Fingern auf eine beliebige Stelle am Bildschirm tippen.
Nicht so schnell! Geübte Screenreader-Nutzer:innen lassen sich Text in doppelter oder noch höherer Geschwindigkeit vorlesen. Gerade zu Beginn solltet ihr das Sprechtempo drosseln und euren individuellen Bedürfnissen anpassen. Bei NVDA kann man z.B. in den Optionen unter „Sprachausgabe“ die Geschwindigkeit mit einem Schieberegler einstellen.
Passende Stimme wählen: Wählt in den Einstellungen des Screenreaders eine Stimme aus, die ihr als möglichst angenehm empfindet. Meistens gibt es mehrere männliche und weibliche Stimmen zur Auswahl.
Gesten und Tastaturbefehle: Alle gängigen Screenreader bieten eine Vielzahl an Gesten und Tastaturbefehlen, mit denen man konkrete Aktionen schneller ausführen kann. Wenn ihr etwa bei aktiviertem TalkBack mit drei Fingern nach links oder rechts wischt, könnt ihr einen Navigationsmodus auswählen (z.B. Überschriften). Dann mit einem Finger nach oben oder unten wischen, um zum vorherigen oder nächsten Element dieser Art zu springen. Damit kannst du u.a. schnell überprüfen, ob Elemente semantisch korrekt implementiert wurden.
Zu Befehl! Findet heraus, wie ihr den Screenreader am schnellsten ein- und ausschaltet. NVDA lässt sich standardmäßig mit der Tastenkombination STRG + ALT + N starten und mit EINFG + Q ausschalten. Am iPhone müsst ihr in den Einstellungen unter „Bedienungshilfen“ explizit VoiceOver als Kurzbefehl festlegen. Dann könnt ihr durch dreifaches Drücken der Home-Taste den Screenreader ein- und ausschalten.

Am wichtigsten ist, dass du dir ausreichend Zeit lässt. Immer daran denken: Übung macht den Meister.

Nützliche Links

Erste Schritte zu mehr Barrierefreiheit

Fri, 14 Jan 2022 00:00:00 GMT

Ja ich weiß, das Thema Barrierefreiheit kann abschreckend wirken. Vor allem, wenn du den ersten Blick auf die Fülle an WCAG-Kriterien und verfügbaren Ressourcen wirfst.

Mein Rat: Erstmal tief durchatmen! Wähle ein Thema, das dich interessiert (z. B. semantisches Markup), und verbessere zumindest eine Sache auf deiner Website oder App. Barrierefreiheit ist kein „Alles-oder-Nichts“-Thema! Jede einzelne Verbesserung zählt.

Wo anfangen?

Hier ist eine Liste an Verbesserungen, die du zuerst bei deiner Website oder App vornehmen kannst:

Überprüfe den Farbkontrast von Text, grafischen Elementen und UI-Komponenten. Ein hoher Farbkontrast hilft vor allem älteren Menschen, die Muster mit niedrigem Kontrast schlechter erkennen können. Beachte folgende WCAG-Kriterien: 1.4.3 Kontrast (Minimum) und 1.4.11: Nicht-Text-Kontrast.
Bediene deine Website nur mithilfe der Tastatur. Kannst du über die Tab-Taste zu allen interaktiven Elementen navigieren? Prüfe, ob die Elemente mit dem richtigen semantischen Markup (z. B. Schaltflächen- und Link-Tags) implementiert wurden. Navigiere auf dem Smartphone mit dem Screenreader per Wischbewegung und prüfe, ob interaktive Elemente richtig erkannt und aktiviert werden können. Beachte folgende WCAG-Kriterien: 2.1.1: Tastatur and 4.1.2: Name, Rolle, Wert.
Haben deine Videos eine Untertitelspur? Untertitel ermöglichen gehörlosen und schwerhörigen Personen das Ansehen von Videos. Gleichzeitig profitieren alle, die sich in einer Situation befinden, in der sie den Ton nicht anhören können (z. B. in einer überfüllten U-Bahn ohne Kopfhörer). Beachte folgende WCAG-Kriterien: 1.2.2: Untertitel (aufgezeichnet)

Alexander Lehner – Oida, is des org!

Dialoge mit dem closedby-Attribut aufwerten

So funktioniert es

Anwendungsfälle

Light-Dismiss für Informations-Dialoge

Versehentliches Schließen verhindern

Browser-Unterstützung

Nützliche Links

Best Practices für CSS Scope in Angular-Applikationen

Demo-Projekt: CSS Scope Sandbox

Best Practice 1: Effiziente Donut Scopes

Best Practice 2: Ohne ::ng-deep in den Untiefen des DOMs wühlen

Best Practice 3: Geteilte Styles als globale CSS-Klassen definieren

Fazit

Nutze die Temporal API in Angular ohne Einbindung eines Polyfills

Schritt 1: Den Temporal Polyfill installieren

Schritt 2: Ein globales Temporal Objekt deklarieren

Schritt 3: Typen aus dem Temporal Namespace verwenden

Demo-Anwendung

Meine ersten Schritte als Astronaut

Warum nicht länger Gatsby?

Was mir an Anstro gefällt

Die Zukunft sieht rosig aus

Flexible Menü-Animation mit verankerten Container Queries

Die Grundlagen verankerter Container Queries

Demo: Barrierefreies Menü mit reiner CSS-Animation

Wie ihr flexible Animationen mit verankerten Container Queries baut

Schritt 1: Die grundlegende HTML-Struktur

Schritt 2: Animation des Menüfelds

Schritt 3: Positions-Fallbacks

Schritt 4: Progressive Verbesserung

Nützliche Links

Lasst uns Akkordeon spielen: Das HTML details-Element im Fokus

Das <details> HTML-Element

Neue Features

Exklusive Akkordeons mit dem name Attribut

Inhalte mit ::details-content stylen

Benutzerdefinierter Indikator für offen/geschlossen

Flexbox und Grid-Layouts

Fazit

Eine barrierefreie Tabelle mit anklickbaren Zeilen bauen

Demo: Tabelle mit anklickbaren Zeilen

Der Aufbau der barrierefreien Tabelle

Die ideale Lösung

Die Safari-kompatible Version

Fazit

Wir bauen ein barrierefreies Menü mit modernen Web-Features

Was wir erreichen wollen

Demo: Barrierefreies Menü

Aufbau des Menüelements Schritt für Schritt

Schritt 1: Die grundlegende HTML-Struktur

Schritt 2: Die Popover API für das Menüfeld nutzen

Schritt 3: Menü-Platzierung mit CSS Anchor Positioning

Schritt 4: Tastaturbedienbarkeit mit JavaScript

Schritt 5: Flüssige Animationen hinzufügen

Bonus: Benutzerdefiniertes Menü in Angular

Fazit

» Update am 23.11.2025

Bringe Screen Reader mit der ARIA Notify API zum Sprechen

Wie funktioniert ARIA Notify?

Demo: Online-Shop mit Warenkorb

Erste Eindrücke

Datums- und Zeitverwaltung mit der Temporal API

Grober Überblick

Code-Beispiele

Ein einfaches Datumsobjekt erstellen und auf Teile davon zugreifen

Hinzufügen einer Dauer zu einem unveränderlichen einfachen Zeitobjekt

Sprachabhängige Formatierung eines Datum/Zeit-Objekts mit Zeitzone

Zwei Zeitpunkte vergleichen

Runden einer Dauer auf eine bestimmte Einheit

Browser-Unterstützung

Meine Lieblings-Tools zum Testen von Web-Accessibility

Struktur und Semantik

Tastaturbedienung

Responsive Inhalte

Zielgröße von interaktiven Elementen

Mindestkontrast

Weitere Links

Accessibility Engineering — Lass die Web-Plattform die Arbeit machen

Die grundlegenden Werkzeuge des Accessibility Engineering

Best Practice 2: Ohne `::ng-deep` in den Untiefen des DOMs wühlen

Schritt 2: Ein globales `Temporal` Objekt deklarieren

Schritt 3: Typen aus dem `Temporal` Namespace verwenden

Das `<details>` HTML-Element

Exklusive Akkordeons mit dem `name` Attribut

Inhalte mit `::details-content` stylen

Update am 23.11.2025

Das `button` Element: Ein mächtiger Allrounder

Das `dialog` Element: Immer oben auf

Vermeidet die `menu` Rolle

Update am 28.03.2026

Update am 24.02.2026