Thema: html
-
Responsive Bilder mit srcset, sizes und picture
srcset mit Breitenbeschreibungen zusammen mit einem sizes-Attribut lässt den Browser die kleinste Bilddatei wählen, welche die Fläche beim aktuellen Viewport und der aktuellen Pixeldichte füllt; x-Beschreibungen liefern Bilder fester Grösse in mehreren Dichten; picture mit source-Elementen behandelt Art Direction und Format-Fallback. width und height stets angeben, damit sich das Layout während des Ladens nicht verschiebt.
-
Native HTML-Formularvalidierung: required, pattern, type und die Constraint Validation API
HTML validiert Formularfelder vor dem Absenden ganz ohne Skript: required, minlength, min/max, pattern und typisierte Eingaben definieren Bedingungen, der Browser blockiert das Absenden und zeigt eine Meldung, CSS kann :user-invalid stylen, und die Constraint Validation API macht denselben Zustand für Skripte zugänglich. Das ist eine Usability-Schicht, keine Sicherheitsschicht; der Server validiert erneut.
-
Web Components: Custom Elements, Shadow DOM und wo die Kapselung endet
Custom Elements registrieren eine Klasse unter einem Tag-Namen mit Bindestrich samt Lifecycle-Callbacks; Shadow DOM gibt ihr einen abgegrenzten Teilbaum, dessen Stile in keine Richtung durchsickern; Templates und deklarative Shadow Roots liefern Markup. Jedes grenzüberschreitende Anliegen, vom Styling über Parts und Custom Properties bis zur Formularteilnahme via ElementInternals und Label-Zuordnung, muss bewusst geöffnet werden.
-
Formulare mit nativen HTML-Constraints erzeugen pro Absendung weniger serverseitige Validierungsablehnungen als Formulare, die nur per eigenem JavaScript validiert werden
Hypothese: Der Browser blockiert die interaktive Absendung eines Formulars, dessen native Constraints (required, pattern, type, min und max) nicht erfüllt sind, während MDN festhält, dass ein Aufruf von submit() dies umgeht und novalidate es abschaltet; die These lautet, dass Formulare mit nativen Constraints, die die Serverregeln spiegeln, pro Absendung weniger Ablehnungen beim Server auslösen als Formulare, deren Prüfungen nur in eigenem Skript stecken, weil die nativen Prüfungen weiterlaufen, wenn das Skript nicht lädt oder Fehler wirft; vorgeschlagen wird ein A/B-Test, ohne behauptetes Ergebnis.
-
Favicons und das Web-App-Manifest: welche Dateien ausgeliefert werden müssen und wie sie deklariert werden
Browser greifen auf /favicon.ico zurück, wenn kein link rel=icon deklariert ist, daher diese Datei bereithalten; ein skalierbares SVG oder ein PNG mit fester Grösse per link rel=icon deklarieren, dazu ein apple-touch-icon und ein Manifest, dessen icons mit sizes und einem purpose (any, maskable, monochrome) versehen sind. Suchmaschinen wollen pro Hostname ein stabiles, quadratisches Favicon.
-
Barrierefreie Formulare: Labels, Fehlermeldungen und Autocomplete
Jedem Steuerelement ein über for und id verknüpftes Label geben, Pflichtfelder im Text und über das Attribut kennzeichnen, Autocomplete-Tokens verwenden, damit Browser und assistive Technologien den Zweck eines Feldes kennen, und Fehler in einer Zusammenfassung plus feldbezogenen, über aria-describedby verknüpften Meldungen melden.
-
dialog versus popover: modales Verhalten, der Top Layer und Light Dismiss
dialog mit showModal() ist modal: Top Layer, inerte Seite, ::backdrop, Escape, closedby und form method=dialog; das popover-Attribut macht ein beliebiges Element zu einem nicht-modalen Top-Layer-Overlay, das ein Button ohne Skript umschaltet und das im auto-Zustand per Light Dismiss geschlossen wird. dialog für blockierende Eingabeaufforderungen und Formulare einsetzen, popover für Menüs, Tooltips und Toasts.
-
ARIA-Rollen: warum ein natives HTML-Element einem div mit Rolle überlegen ist
Die erste Regel des W3C für den Einsatz von ARIA lautet, ein natives HTML-Element oder -Attribut zu bevorzugen, das die benötigte Semantik und das Verhalten bereits mitbringt; ARIA ändert nur, was assistiven Technologien mitgeteilt wird, nie, was das Element tatsächlich tut. Ein div mit role=button braucht Fokussierbarkeit, Tastaturbehandlung und Zustände weiterhin von Hand hinzugefügt, und jeder Fehler dabei bleibt im visuellen Test unsichtbar.
-
Fokus-Management bei Single-Page-Interaktionen: Dialoge, Routenwechsel und entfernte Elemente
Ändert sich eine Seite ohne vollständigen Ladevorgang, muss der Tastaturfokus gezielt bewegt werden: in einen Dialog hinein, wenn er sich öffnet, und zurück zu seinem Auslöser, wenn er sich schliesst, zur Überschrift der neuen Ansicht nach einem clientseitigen Routenwechsel, und zu einem sinnvollen Nachbarn, wenn das fokussierte Element gelöscht wird. Andernfalls fällt der Fokus auf den Document Body zurück, und Screenreader-Nutzende werden an den Seitenanfang zurückgeschickt.
-
Barrierefreiheit: die vier WCAG-Grundsätze praktisch angewendet
Die WCAG 2.2 ordnen alle Erfolgskriterien vier Grundsätzen zu: wahrnehmbar, bedienbar, verständlich, robust. Wer pro Grundsatz die häufigsten Verstösse kennt (fehlende Textalternativen, Tastaturfallen, zu wenig Kontrast, unbeschriftete Felder, zu kleine Ziele), findet viele Barrieren ohne Spezialwerkzeug; Stufe AA ist das übliche Ziel.
-
details and summary: native disclosure widgets, exclusive accordions and hidden until-found
details/summary is a disclosure widget with no script: the open attribute shows the content, a shared name attribute makes a group exclusive so opening one closes the others, the toggle event reports changes, and summary is styled as display: list-item. For collapsed content that must stay searchable, hidden=until-found reveals it on find-in-page or fragment navigation.
-
Image delivery: AVIF and WebP with fallbacks, lazy loading and fetch priority
Serve modern formats through picture sources with a type attribute and a JPEG or PNG img as the fallback (or negotiate on Accept with Vary), lazy-load only images below the first viewport with width and height set, and mark the largest above-the-fold image fetchpriority=high instead of lazy.
Maschinenlesbar: JSON