Unsere eigene
Website
Die erste Fallstudie ist unsere eigene, aus einem einfachen Grund: Wir dürfen jede Zahl darin veröffentlichen, ohne jemanden zu fragen. Alles hier lässt sich auf der laufenden Website nachprüfen.
Was sich geändert hat, gemessen
Alle Werte wurden auf der Produktionsseite erhoben, vorher und nachher. Keiner davon ist eine Hochrechnung.
- Kritischer Pfad
334 KB80 KB- Logo
133 KB, zwei PNGs6,1 KB, ein SVG- Fallback-Schrift
102 KB18 KB- axe-core-Verstöße
—0- Schlechtester Kontrast
1,81:15,10:1
−75%. Anfragen im kritischen Pfad von 9 auf 4.
Vektorisiert; eine Datei bedient über currentColor beide Themes.
Auf die 124 tatsächlich verwendeten Glyphen reduziert.
Auf allen Seiten, in beiden Sprachzweigen, bei jedem Deploy.
Gefordert: 4,5:1. Der Fehler lag in unserer eigenen Navigation.
Eine Website, die Technik verkaufte, ohne welche zu zeigen
Die Seite lud 334 KB, bevor sie etwas anzeigen konnte. Das Logo lag in zwei PNG-Fassungen vor, weil die Marke auf hellem und auf dunklem Grund funktionieren musste. Eine Fallback-Schrift wurde vollständig ausgeliefert — 102 KB — für acht Zeichen, die der Displayschrift fehlten.
Für Besucher mit guter Verbindung war davon nichts zu sehen, und genau deshalb blieb es so lange bestehen. Zum Problem wurde es, als wir anfingen, technische Qualität zu verkaufen: Von einer langsamen Website aus ist dieses Argument nicht glaubwürdig.
Drei Änderungen trugen den größten Teil
Aus dem Logo wurde ein Vektor. Aus dem PNG nachgezeichnet und auf eine einzige Datei reduziert, die ihre Farbe über currentColor erbt — eine Datei für beide Themes statt zweier Bitmaps. Aus 133 KB wurden 6,1 KB.
Die Fallback-Schrift wurde verkleinert. Nicht auf die acht fehlenden Zeichen — das war der naheliegende und falsche Weg, denn dieselbe Schrift ist Fließtextschrift auf Impressum, Datenschutz und 404. Die Reduktion auf alles tatsächlich Verwendete ergab 124 Glyphen und 18 KB.
Schriften werden je Seite vorgeladen. Startseite und Unterseiten verwenden unterschiedliche Schnitte; überall dasselbe Paar vorzuladen hätte mehr gekostet als gespart.
Eine Sache haben wir geprüft und verworfen: Brotli-Komprimierung. Das Modul fehlt in nginx und in apt auf diesem Server, und eine Installation über ein PPA hätte nginx für alle achtzehn Domains auf dieser Maschine aktualisiert. Der Gewinn wären 3–4 KB gewesen. Dieses Risiko geht man mit fremden Websites nicht ein.
Der Fehler in unserer eigenen Navigation
Die Prüfung der eigenen Seite ergab ein Kontrastverhältnis von 1,81:1, gefordert sind 4,5 — Beige auf Olivgrün, eine Kombination, die der Markenleitfaden ausdrücklich erlaubte. Mit bloßem Auge war das nicht zu erkennen. Verursacht haben es zwei übereinanderliegende Transparenzwerte, und es stand in der Navigation jeder Seite.
Die Behebung bestand darin zu ändern, wo eine Farbe überhaupt auftreten darf — nicht darin, eine Komponente nachzujustieren. Später fand dieselbe Prüfung die Sekundärfarbe bei 4,52:1: bestanden, aber mit 0,02 Abstand. Das ist kein Spielraum, das ist Zufall. Jetzt sind es 5,10.
Das vollständige Ergebnis samt der noch offenen Punkte steht in unserer Barrierefreiheitserklärung. Die offenen Punkte zu veröffentlichen war keine Marketingentscheidung — es ist die einzige ehrliche Art, Audits zu verkaufen.
Zeit, unverblümt
Die Performance-Arbeit dauerte etwa sechs Stunden über drei Tage. Für die Barrierefreiheit gibt es keine feste Zahl, weil sie nicht abgeschlossen ist: Die Prüfung läuft bei jedem Deploy, und die Erklärung wird angepasst, wenn sich etwas ändert. So sieht diese Arbeit aus — und wer Ihnen dafür eine einmalige Zahl nennt, nennt Ihnen die falsche.
Dasselbe für Ihre Website?
Die Methode gilt für jede Website: erst messen, dann die Zahlen veröffentlichen, dann beheben, was die Zahlen zeigen. Beginnen Sie kostenlos mit der Selbstprüfung, oder lesen Sie die Studie hinter unserer Arbeit.