So funktioniert es
Im Code
Vor der Veröffentlichung prüft Briks die Schriftfarben gegen die Untergründe, auf denen sie stehen.
Auf der Live-Seite
Nach der ersten Veröffentlichung sieht es sich die Seite in Desktop- und Smartphone-Breite an.
Bei Bedarf eine Reparatur
Wo Texte schwer lesbar sind, korrigiert es sie einmal.
Was bei jedem Build geprüft wird
Zu geringer Kontrast gehört zu den häufigsten Barrierefehlern im Web: blassgrau auf Weiß, Weiß auf einem hellen Foto, eine Markenfarbe auf einem ähnlichen Farbton. Briks prüft den Farbkontrast im Code der Website, bevor etwas veröffentlicht wird, und misst jede Farbe, in der Ihre Texte gesetzt sind, gegen den Hintergrund, auf dem sie tatsächlich stehen.
Die Messlatte setzen die Richtlinien für Barrierefreiheit, WCAG AA: 4.5 zu 1 für Fließtext und 3 zu 1 für großen Text, also ab 24 Pixeln oder etwa 19 Pixeln in Fett. Wo eine Farbe nicht genügt, wird Text auf diesem Grund in einer gut lesbaren Farbe gesetzt.
Nach der ersten Veröffentlichung sieht sich Briks die Live-Seite in Desktop- und Smartphone-Breite an und prüft den Kontrast erneut, denn manche Probleme zeigen sich erst in einem Browser, etwa Text über einem Bild. Ist etwas schwer lesbar, behebt Briks es einmal. Außerdem prüft es, ob jede von Ihnen gewählte Seite im Menü steht.
Zusätzliche Prüfungen für Apps und zum Start
Apps werden vor der Veröffentlichung ein zweites Mal im Code geprüft, mit Blick auf die schwersten Fehler: geheime Schlüssel in Dateien, Schreibzugriffe auf die Datenbank ohne Limit, eine Mitgliedertabelle, die jeder lesen könnte, und Datenbankabfragen, die durch das Aneinanderhängen von Zeichenketten entstehen.
Wenn Sie eine Website in Produktion nehmen, läuft zuerst die Launch-Prüfung. Sie stoppt den Start bei allem, was ein Unternehmen am ersten Tag blamieren würde: übrig gebliebener Platzhaltertext, vom Entwurf erfundene Fakten, die Sie nicht ersetzt oder bestätigt haben, Seiten ohne eigenen Titel und eigene Beschreibung für die Suchergebnisse, Links zwischen Ihren Seiten, die ins Leere führen, und eine fehlende Seite für Adressen, die nicht existieren.
Sie liest bis zu zwölf Seiten und prüft bis zu achtzig Links. Sie nutzt kein KI-Modell und verbraucht daher keine Credits.
Die ausführlichere Prüfung und was nicht geprüft wird
Eine ausführlichere Prüfung ist in den Schritten für neue Projekte nur einen Schalter entfernt und standardmäßig aus. Sobald die erste Version veröffentlicht ist, sieht sich Briks sie in vier Bildschirmgrößen an und repariert, was fehlerhaft dargestellt wird, etwa überlappende Teile oder ein Layout, das bei einer Breite auseinanderfällt. Das dauert einige Minuten länger und kostet einige Credits; eine Prüfung reserviert 5 Credits, solange sie läuft. Dieselbe Prüfung können Sie bei jeder späteren Änderung anfordern.
Um die Grenzen klar zu benennen: Prüfungen auf Überlappungen, Bilder und Links laufen nicht bei jedem Build. Ein normaler erster Build erhält die Kontrastprüfungen, die Menüprüfung und, bei Apps, das Lesen des Codes. Links prüft die Startprüfung oder die ausführlichere Prüfung, wenn Sie sie einschalten.
Nichts davon ersetzt Ihren eigenen Blick. Öffnen Sie die Vorschau auf Ihrem Smartphone, bevor Sie in die Produktion veröffentlichen, und bitten Sie in einfachen Worten um alles, was sich nicht stimmig anfühlt.
Prüfungen vor der Veröffentlichung in der Praxis
Drei Beispielunternehmen und wie jedes davon es nutzen würde. Wo eine Website zu sehen ist, ist es ein Muster, das Briks für ein Beispielunternehmen erstellt hat, kein Kunde.
- 01Kerzenmacher
Helle Schrift über einem weichen Foto
Eine Kerzenmacherin möchte ihre Überschrift über einem nebligen Foto vom Meer platzieren. In der Breite eines Telefons liegt ein Teil der Überschrift über der hellsten Stelle des Himmels. Genau für solche Fehler gibt es die Live-Prüfung: Sie sieht sich die veröffentlichte Seite am Desktop und am Telefon an und bessert schwer lesbare Texte aus.
Saltmarsh Candles ist eine Beispiel-Website, die Briks für ein Beispiel (Kerzenmacher) gebaut hat, kein Kunde. Beispiel öffnen - 02Anwaltskanzlei
Ein helles Gold als Markenfarbe auf Weiß
Die Markenfarbe einer Kanzlei ist ein helles Gold. Als Schriftfarbe auf Weiß liegt sie weit unter 4,5 zu 1. Vor der Veröffentlichung findet die Prüfung im Code das und setzt Text auf diesem Untergrund in einer gut lesbaren Farbe, damit die Seiten der Kanzlei von der ersten Veröffentlichung an lesbar bleiben.
- 03Bauunternehmen
Die Job-App eines Handwerksbetriebs, geprüft vor der Veröffentlichung
Ein Bauunternehmen bittet um eine kleine App, in der sein Team Aufträge erfasst. Vor der Veröffentlichung wird der Code auf Schlüssel geprüft, die in Dateien geschrieben wurden, und auf Schreibvorgänge ohne Begrenzung. Als das Unternehmen die App in Produktion bringt, findet die Startprüfung außerdem einen Link zu einer Projects-Seite, die nie angelegt wurde, und stoppt den Start, bis das behoben ist.
Was Sie bekommen
- Kontrast wird vor der Veröffentlichung im Code geprüft, nach WCAG AA
- Auf der Live-Seite am Desktop und am Handy noch einmal geprüft, mit einer Reparatur
- Jede ausgewählte Seite steht im Menü, bevor sie veröffentlicht wird
- Apps werden auf in Dateien geschriebene Schlüssel, Schreibzugriffe ohne Begrenzung und unsichere Abfragen geprüft
Gut zu wissen
- Eine gründlichere Prüfung bei vier Breiten ist in den Schritten für neue Projekte nur einen Schalter entfernt.
- Die Veröffentlichung in Produktion führt eine Prüfung vor dem Start durch, auch auf Links, die ins Leere führen.