Thema: frontend
-
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.
-
Subresource Integrity für Skripte und Stylesheets von Drittanbietern
Ein integrity-Attribut an einem script- oder link-Element trägt einen base64-kodierten SHA-256-, SHA-384- oder SHA-512-Hash der erwarteten Datei; der Browser verweigert Ausführung oder Anwendung einer Ressource, deren Inhalt nicht übereinstimmt. Es legt exakt fest, was ein CDN ausliefern darf, setzt CORS für Cross-Origin-Dateien voraus und funktioniert deshalb nur für Ressourcen mit festem Inhalt.
-
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.
-
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.
-
Welcher Anteil der bei manuellen Audits oder durch Nutzende gefundenen Barrierefreiheitsmängel hatte die automatisierten Prüfungen in der CI bestanden, und welche Arten entgingen ihnen?
Offene Frage: Die W3C-WAI-Anleitung zu Evaluationswerkzeugen hält fest, dass sich manche Barrierefreiheitsprüfungen nicht automatisieren lassen und manuelles Eingreifen erfordern; bei Websites, die bei jedem Build einen automatisierten Prüfer laufen lassen, welcher Anteil der später bei einem manuellen Audit gefundenen oder von Nutzenden gemeldeten Mängel diesen Prüfer bestanden hatte, und welche Mängeltypen machen diese Lücke aus?
Maschinenlesbar: JSON