Zum Inhalt springen
megapromotingLassen Sie uns sprechen

Expertise · UI/UX Design

Ein Designsystem, in dem der Kontrast berechnet wird, Bewegung eine Stopp-Taste hat und das, was die Prüfung nicht besteht, offen aufgeschrieben wird.

Wir arbeiten mit Farb-Token mit berechnetem Kontrastverhältnis, einzeln geprüften Tastaturmustern und Animationen, die bei den Systemeinstellungen stoppen. Wir prüfen mit Werkzeugen auf echten Seiten und veröffentlichen auch, was durchgefallen ist.

Bereits gebautDas System läuft auf dieser Website und kann inspiziert werden. Das Token `--muted: #666b65` erreicht auf den sieben Hintergründen der Website zwischen 4,72:1 und 5,45:1 — von uns mit der WCAG-Luminanzformel neu berechnet, nicht aus einem Tool übernommen. Acht direkt im Stylesheet geschriebene Farben ergaben 2,88–4,49:1; wir haben sie mit axe-core 4.10.2 gefunden, das auf zehn Live-Seiten ausgeführt wurde, und durch das Token ersetzt, und die Korrektur ist bereits im produktiv ausgelieferten Stylesheet. Die zweite überprüfbare Implementierung: der Mechanismus zum Stoppen der Animationen — 38 unendlich animierte Elemente auf der Startseite, alle durch eine Pausentaste abgedeckt, plus die globale Regel, die Animationen bei `prefers-reduced-motion: reduce` aufhebt.

Die meisten „Designsysteme“ sind eine Palette und eine Komponentenliste. Unseres beginnt mit etwas Langweiligerem und Nützlicherem: Jede Textfarbe hat ein berechnetes Kontrastverhältnis zu jedem Hintergrund, auf dem sie tatsächlich erscheint. Nicht „sieht gut aus“, sondern eine Zahl. Das sekundäre Text-Token dieser Website, `--muted: #666b65`, erreicht zwischen 4,72:1 und 5,45:1 auf den sieben verwendeten Hintergründen. Die erforderliche Schwelle für kleinen Text ist 4,5:1.

Diese Zahl ist nicht aus Höflichkeit entstanden. Wir haben axe-core 4.10.2 auf zehn Seiten der eigenen Website ausgeführt, und die einzige WCAG-Regel, die systematisch verletzt wurde, war der Kontrast: 31 bis 43 Knoten pro Seite, davon 31 aus Kopf- und Fußbereich, also über alle 147 Adressen hinweg vervielfacht. Acht direkt im Stylesheet geschriebene Farben ergaben 2,88:1 bis 4,49:1. Die schlimmste, bei 10 px und 3,72:1, war genau die Zeile mit den Rechtslinks — der Weg, den jemand nimmt, wenn er ein Recht ausüben will.

Der zweite Teil des Systems ist Bewegung, als Funktion behandelt, nicht als Dekor. Auf der Startseite gibt es 38 Elemente, die endlos animiert werden. Alle werden von einer Pause-Schaltfläche abgedeckt: Beim Drücken wechseln sie in den gestoppten Zustand, die Beschriftung ändert sich und der Zustand wird für Bildschirmleser angekündigt. Separat hebt eine globale Regel jede Animation und jeden Übergang auf, wenn das System reduzierte Bewegung verlangt, stoppt das sanfte Scrollen und blendet sogar die Pausen-Schaltfläche aus, die dann nutzlos wird. Wir haben auch die klassische Falle geprüft — eine Animation, die bei nahezu null Opazität beginnt und den Inhalt unsichtbar lässt, wenn sie aufgehoben wird: Hier gibt es sie nicht.

Der Rest ist Disziplin: sichtbarer Fokusindikator, 2 px, nur bei Tastaturnavigation angewendet; Pfeilnavigation in Tab-Gruppen nach dem empfohlenen Modell; Formulare mit als Alert angekündigten Fehlern und als Status angekündigten Bestätigungen. Und eine Regel, die wir strikt halten: Was wir nicht prüfen konnten, wird als ungeprüft geschrieben. Das eigene Audit hat einen Abschnitt zu den Grenzen des Werkzeugs, und zwei dort gefundene Defekte sind noch offen — sie stehen weiter unten, mit Namen.

Was dazugehört

Die Arbeit, nach Bestandteilen

Farben sind Tokens, und Kontrast ist eine berechnete Zahl

Die Palette steht in einem Block aus 14 Variablen, und der Sekundärtext verwendet einen einzigen Token: `--muted: #666b65`. Die Verhältnisse, neu berechnet mit der Formel der relativen Luminanz aus WCAG auf den sieben Hintergründen der Site: 5,45:1 auf Weiß, 5,15, 5,11, 5,03, 5,02, 4,79 und 4,72. Der Haupttext, `--ink: #181a19`, erreicht 17,49:1 auf Weiß; das grüne Akzent `#355c46`, 7,58:1. Wenn eine Farbe den Schwellenwert nicht erreicht, wird der Token geändert, nicht in einer Sitzung argumentiert.

Komponenten haben Tastaturmuster, nicht nur Aussehen

Die Tab-Gruppe auf der Startseite verwendet roving tabindex: Nur der aktive Tab ist mit Tab erreichbar, die anderen sind aus der Reihenfolge herausgenommen, und die Pfeile links/rechts, Home und End verschieben den Fokus, wobei das Standardverhalten der Taste aufgehoben wird. Es ist das Muster aus den empfohlenen Praktiken für zugängliche Komponenten, umgesetzt, nicht zitiert. In den Grundkomponenten der Site gibt es 21 zugängliche Beschriftungen, 7 Zustände gedrückt/nicht gedrückt, 3 Verknüpfungen zwischen Titel und Region, 2 Auswahlzustände, 2 Regionen, die Änderungen ankündigen, und 2 Verknüpfungen zwischen einem Befehl und dem Panel, das er steuert.

Bewegung hat eine Stop-Schaltfläche und schaltet sich bei der Systemeinstellung ab

Auf der Startseite gibt es 38 endlos animierte Elemente, automatisch gestartet, die länger als fünf Sekunden dauern — genau die Situation, die durch das Kriterium „Pausieren, Stoppen, Ausblenden“ geregelt ist. Alle 38 werden von Pausen-Schaltflächen abgedeckt: Beim Drücken wechseln die Animationen in den gestoppten Zustand und der Zustand der Schaltfläche ändert sich. Separat hebt bei `prefers-reduced-motion: reduce` eine globale Regel jede Animation und jeden Übergang auf, stoppt das sanfte Scrollen, entfernt die Bewegung beim Mouseover und blendet die Pausen-Schaltfläche aus. Im Haupt-Stylesheet gibt es sieben solche Blöcke, plus einen im Basis-Stylesheet.

Sichtbarer Fokusindikator, nur wo er hingehört

2 px solide Kontur, in Akzentgrün, mit 5 px Abstand, angewendet über `:focus-visible` — also erscheint sie bei Tastaturnavigation und nicht beim Klick mit der Maus. Im Browser geprüft, Element für Element, im Kopfbereich und bei den ersten Befehlen im Inhalt: vier verschiedene Elemente, dieselbe Kontur. Nirgendwo im Stylesheet gibt es eine entfernte Kontur ohne Ersatz.

Formulare, die ihre Zustände ankündigen

Im Kontaktformular der Site sind Beschriftungen implizit auf Feldern, der Fehler ist als Alert markiert und die Bestätigung als Status — so kündigen Bildschirmleser sie an, ohne dass der Benutzer suchen muss. Die Falle für Bots ist korrekt verborgen: übergeordnetes Element ohne Anzeige, als für Assistive Technologien verborgen markiert und aus der Tab-Reihenfolge entfernt. Das eigene Audit bestätigt, dass die Regeln für Beschriftung, Namen für Steuerelemente und automatische Vervollständigung alle bestehen.

Die Prüfung erfolgt mit einem Werkzeug, auf echten Seiten

Wir führen axe-core 4.10.2 auf der Live-Seite aus, nicht in einer Testumgebung, auf einer Stichprobe von zehn Seiten, die unterschiedliche Muster abdecken: Startseite, Katalog, eine Produktseite, das Service-Index, eine Serviceseite, die Lösungsmatrix, eine Kombination aus der Matrix, Kontakt, Preise, ein Artikel und ein Rechtsdokument. Das Rohresultat wird auf der Seite geschrieben, mit der Anzahl der Knoten, nicht als „konform“ zusammengefasst.

Was durchfiel, wird veröffentlicht, nicht gerundet

Aus demselben Audit: bei 320 px Breite ragen der Befehl im Kopfbereich und die Menütaste um 22 px über den Bildschirm hinaus, und die Seite scrollt horizontal — die Arithmetik ergibt 362 px Inhalt in einem 280 px breiten Container. In den Rechtsdokumenten unterscheiden sich die Links im Text vom umgebenden Text nur durch die Farbe, und das Verhältnis zwischen Akzent und Fließtext beträgt 1,01:1, also ist Unterstreichung verpflichtend. Beide sind offen, mit geschriebener Behebung. Wir veröffentlichen sie, weil ein Käufer, der Zugänglichkeit verlangt, sehen soll, wie eine echte Fehlerliste aussieht.

Kein Dark Mode — gesagt, nicht simuliert

Die Website hat kein dunkles Theme. Der Token-Block ist für drei Selektoren deklariert, die identische Werte erhalten, und im Code gibt es keine Regel für die System-Farbmoduspräferenz. Im Browser mit emulierter dunkler Farbschema getestet: Die Seite bleibt weiß. Die nützliche Folge: Alle gemessenen Kontrastverhältnisse gelten in beiden Schemas. Die unangenehme Folge: Der Theme-Schalter ist aus Sicht der Farbe toter Code. Ein echtes dunkles Theme bedeutet eine vollständige Neumessung des Kontrasts, nicht das Kopieren von Werten.

Typografie mit Regeln, nicht mit Vorlieben

Eine einzige Familie für Überschriften und Text, mit je nach Ebene angepasstem Buchstabenabstand — enger bei großen Überschriften, `-0,055em` auf den Ebenen eins und zwei, `-0,035em` auf Ebene drei — und Gewicht 500 bei Überschriften. Absätze verwenden Zeilenausgleich, damit am letzten Rand kein einzelnes Wort stehen bleibt. Der Container hat eine maximale Breite von 1240 px mit 48 px Seitenabständen, und die Schaltflächen haben überall die gleiche Zeilenhöhe. Es sind Regeln im Stylesheet, also gelten sie auch nach unserem Weggang.

Wie es aussieht

Der Weg, Schritt für Schritt.

01

Bestandsaufnahme der Aufgaben und Blocker-Punkte

Die erste Lieferung ist die Liste der Dinge, die die Menschen tatsächlich erledigen wollen, in Reihenfolge der Häufigkeit, mit dem Punkt, an dem sie heute stocken. Ohne sie ist jeder neue Bildschirm eine ästhetische Vorliebe. Mit ihr hat jede spätere Entscheidung ein Kriterium.

02

Token und Kontrastprüfung, vor den Bildschirmen

Die Farben, die Hintergründe, auf denen sie tatsächlich erscheinen, und das berechnete Verhältnis jedes Paares werden festgelegt. Wir liefern die Tabelle der Paare mit ihren Verhältnissen. Das ist viel günstiger, als am Ende festzustellen, dass die gewählte Palette für kleinen Text nicht verwendet werden kann.

03

Die Komponenten, mit dem Tastaturmuster zusammen mit dem Layout geschrieben

Jede interaktive Komponente erhält im selben Commit sowohl das Erscheinungsbild als auch das Verhalten: was bei Tab, bei den Pfeiltasten und bei Escape geschieht, was angekündigt wird und wie. Ein später hinzugefügtes Tastaturmuster ist eine Umschreibung, keine Ergänzung.

04

Der Tool-Audit auf echten Seiten, mit dem Rohresultat geliefert

Wir führen das Werkzeug auf einer Stichprobe aus, die unterschiedliche Muster abdeckt, und liefern die Roh-Ausgabe, keine Zusammenfassung. Jeder Befund erhält die Stelle im Code, das verletzte Kriterium, die vorgeschlagene Behebung und das Prüfkriterium nach der Behebung — zum Beispiel: Die Anzahl der Kontrastknoten muss auf der Seite, die nur Kopf- und Fußbereich enthält, auf null sinken.

05

Die Übergabe, mit der Liste der nicht überprüften Punkte

Wir übergeben die Tokens, die Komponenten, das Audit-Dokument und die Liste dessen, was nicht überprüft werden konnte, mit dem Grund. Auf dieser Website umfasst die Liste die Aktivierung per Tastatur und die Emulation der Präferenz für reduzierte Bewegung im Browser — beides Werkzeuggrenzen, beides unverändert so festgehalten.

Token de culoare curaport calculat1Komponente mit Mustervon der Tastatur eingegebenzusammen mit dem Erscheinungsbild2Überprüfung mit dem Werkzeugpe pagini reale, curezultatul brutpublicat3Was bei Schritt drei scheitert, geht zurück zu Schritt eins.
Ein Zyklus in 3 Schritten

Die Daten

Was wir anfassen, wo die Daten liegen und wie lange sie bleiben

Die Fragen, die jede Person mit einem Datenschutzbeauftragten stellt — hier gestellt, bevor er sie stellt.

Was wir in der Forschungsphase erfassen
Die Aufgaben, die die Menschen tatsächlich erledigen müssen, der Kontext, in dem sie sie erledigen, und der Punkt, an dem sie blockiert werden. Wenn dies Aufzeichnungen, Interviews oder die Beobachtung realer Sitzungen voraussetzt, wird vorher festgelegt, wer teilnimmt, was aufgezeichnet wird, wer Zugriff hat und wie lange es aufbewahrt wird — schriftlich, nicht durch stillschweigende Übereinkunft.
Die Ergebnisse des Accessibility-Audits
Die Roh-Ausgabe des Werkzeugs, die Gruppierung der Knoten nach dem Farbe–Hintergrund-Paar, die unabhängig neu berechneten Verhältnisse und die Stelle im Code jeder Farbe. Es wird als versioniertes Dokument neben dem Code geliefert, nicht als Präsentation — damit jeder die Messung mit den Befehlen im Anhang reproduzieren kann.
Was in den Code kommt und was im Gespräch bleibt
Tokens, Komponenten, Tastaturmuster und Bewegungsregeln landen im Stylesheet und in den Komponenten. Vorlieben, die sich nicht als Regel ausdrücken lassen — „wärmer aussehen“ — bleiben zu besprechende Entscheidungen und schleichen sich nicht als direkt in Komponenten geschriebene Werte hinein. Von dort kommen in der Regel die Farben, die die Prüfung nicht bestehen.
Die Präferenzen des Besuchers
Die Präferenz für reduzierte Bewegung wird aus dem System über die Media Query gelesen und nicht bei uns gespeichert. Es gibt kein dunkles Theme, das gespeichert werden müsste. Die Verkehrsmessung läuft über das im Projekt konfigurierte Instrument und wird nach Einwilligung aktiviert; sie gehört nicht zum Designsystem, aber zur selben Seite.
Was wir nicht voraussetzen
Wir setzen nicht voraus, dass ein automatisches Ergebnis Konformität bedeutet. Das Tool erfasst einen Teil der Kriterien; der Rest erfordert manuelle Prüfung, und manches ließ sich mit den verfügbaren Werkzeugen gar nicht prüfen — die Aktivierung per Tastatur zum Beispiel, weil das verwendete Browser-Panel keine Standardaktivierung auslöst. So steht es im Audit: ungeprüft, nicht bestanden.

Ein Fall

Acht Farben, eine Variable und die Liste, die offen geblieben ist

Die Ausgangslage

Eigene Website, kürzlich neu aufgebaut, mit einem bereits bestehenden Tokensystem. Niemand hatte etwas beanstandet. Die Frage war nicht: „Sieht es gut aus?“, sondern: „Was sagt ein Tool, das keine Meinungen hat?“

Was wir gebaut haben

Wir haben axe-core 4.10.2 in die Live-Seite injiziert und es auf zehn Seiten mit unterschiedlichen Mustern ausgeführt. Die einzige systematisch verletzte WCAG-Regel war der Kontrast. Wir gruppierten die Knoten nach Text-Hintergrund-Paaren, berechneten jedes Verhältnis erneut mit der Formel für relative Luminanz aus dem Standard — damit wir nicht von einem einzigen Tool abhängen — und suchten jede Farbe im Stylesheet. Acht direkt im Code geschriebene Werte verursachten alle dauerhaften Fehler: 3,89:1 bei den 25 Links im Footer, 2,88:1 bei den Schrittzahlen, 3,72:1 bei der Zeile mit den Rechtslinks und noch fünf zwischen 3,99 und 4,49. Das passende Token existierte bereits; das Problem war, dass acht Regeln es umgingen.

Was dabei herauskam

Die acht Werte wurden durch das Token ersetzt, und das Token so angepasst, dass es die Schwelle auf allen sieben Hintergründen der Website erreicht. Zweifach geprüft: Im Repository taucht keiner der acht Farben mehr auf, und das heute von der Produktion ausgelieferte Stylesheet enthält nur noch das Token. Unabhängig neu berechnet: 4,72:1 im ungünstigsten Fall und 5,45:1 auf Weiß. Der restliche Audit bestätigte, was bereits korrekt war — der Fokusindikator, das Tastaturmuster in den Tab-Gruppen, die Beschriftungen und Zustände im Formular, die vollständige Abdeckung der Animationen mit Pausen-Buttons.

Was der Fall nicht sagt

Zwei Feststellungen blieben offen und sind auch so festgehalten: Bei 320 px Breite ragt der Header um 22 px über den Bildschirm hinaus, und in den Rechtsdokumenten sind die Links im Text nur über die Farbe zu unterscheiden, mit einem Verhältnis von 1,01:1 zum umliegenden Text — Farbe allein reicht nicht, Unterstreichung ist nötig. Und die methodische Grenze: Ein automatisches Tool deckt nur einen Teil der Kriterien ab. Die Aktivierung per Tastatur konnte mit den verfügbaren Werkzeugen nicht getestet werden und ist als ungeprüft markiert, nicht als bestanden.

Fragen

Was uns die Leute fragen, bevor sie anrufen

Was bedeutet „barrierefreies Design“ bei Ihnen konkret?

Das bedeutet Zahlen, keine Adjektive. Der Sekundärtext auf dieser Website verwendet ein einziges Token, `#666b65`, das auf den sieben Hintergründen, auf denen es erscheint, zwischen 4,72:1 und 5,45:1 erreicht — die geforderte Schwelle für kleinen Text liegt bei 4,5:1. Der Fokus ist eine 2-px-Umrandung, die nur bei der Navigation per Tastatur erscheint. Bewegung hat einen Stopp-Button und wird bei der Präferenz für reduzierte Bewegung im System vollständig deaktiviert. Jede dieser Aussagen hat einen Platz im Code und eine Prüfmethode.

Wie prüfen Sie das? Mit welchem Tool?

axe-core 4.10.2, ausgeführt auf der Live-Seite, auf zehn Seiten, die unterschiedliche Muster abdecken — Startseite, Katalog, eine Produktseite, der Index und eine Serviceseite, die Lösungsmatrix und eine Kombination daraus, Kontakt, Preise, ein Artikel, ein Rechtsdokument. Das Rohresultat mit der Anzahl der Knoten pro Seite fließt in das Dokument ein. Darüber hinaus berechnen wir die Kontrastverhältnisse manuell mit der Formel aus dem Standard neu, damit wir nicht von einem einzigen Tool abhängen. Und wir schreiben ausdrücklich auf, was nicht geprüft werden konnte.

Was ist bei Ihnen durchgefallen?

Zum Zeitpunkt des Audits war die einzige systematisch verletzte Regel der Kontrast: 31 bis 43 Knoten pro Seite, davon 31 aus Header und Footer, also über alle 147 Adressen hinweg multipliziert. Acht direkt im Stylesheet geschriebene Farben ergaben 2,88 bis 4,49:1; die schlimmste, bei 10 px und 3,72:1, war die Zeile mit den Rechtslinks. Alle acht sind jetzt durch das Token ersetzt, und die Korrektur steht im von der Produktion ausgelieferten Stylesheet. Zwei Dinge bleiben offen: Bei 320 px ragt der Header um 22 px über den Bildschirm hinaus, und in den Rechtsdokumenten sind die Links im Text nur durch die Farbe zu unterscheiden, mit einem Verhältnis von 1,01:1 zum umliegenden Text. Für beide ist die Behebung festgehalten.

Warum veröffentlichen Sie die Fehler Ihrer eigenen Website?

Denn sonst ist „zugänglich“ ein Wort ohne Kosten. Jeder kann schreiben, dass er den Standard einhält; nur wenige zeigen die Liste der Nichtkonformitäten, mit der Anzahl der Knoten und der Zeile im Stylesheet. Wenn wir zusammenarbeiten, erhalten Sie dieselbe Art von Liste über Ihre Website — einschließlich der Teile, die uns nicht gut aussehen lassen. Es ist günstiger, es von uns zu erfahren.

Hat die Website ein dunkles Thema?

Nein, und das sage ich, weil es überprüfbar ist: Der Token-Block ist für drei Selektoren deklariert, die identische Werte erhalten, und im Code gibt es keine Regel für die Schemapräferenz. Wenn man das dunkle Schema im Browser emuliert, bleibt die Seite weiß. Das Gute ist, dass alle gemessenen Kontrastverhältnisse in beiden Schemata gültig sind. Zu beheben ist, dass ein Themenumschalter, der die Farben nicht ändert, toter Code ist. Ein echtes dunkles Thema bedeutet eine vollständige Neumessung des Kontrasts — er wird nicht aus dem hellen übernommen.

Stören Animationen die Benutzer?

Das können sie, und deshalb haben sie zwei Ausgänge. Der erste: Jedes unendlich animierte Element ist mit einer Pause-Schaltfläche abgedeckt — auf der Startseite habe ich geprüft, dass alle 38 abgedeckt sind, null nicht abgedeckt. Der zweite: Bei der Systempräferenz für reduzierte Bewegung hebt eine globale Regel jede Animation und jeden Übergang auf, stoppt das sanfte Scrollen und blendet sogar die Pause-Schaltfläche aus. Ich habe auch die klassische Falle geprüft: Wenn eine Animation von fast null Opazität startet und aufgehoben wird, kann der Inhalt unsichtbar bleiben. Hier passiert das nicht, weil die Elemente keine reduzierte Basis-Opazität haben.

Liefern Sie auch Code oder nur Mockups?

Wir liefern die Token und die Komponenten im Code. Ein Designsystem, das im Designtool verbleibt, erodiert bei der ersten Dringlichkeit: Jemand schreibt direkt eine Farbe in die Komponente, weil „es hier besser aussieht“, und nach sechs Monaten haben Sie acht parallele Farben, die die Prüfung nicht bestehen. Genau das ist auch bei uns passiert, es ist oben dokumentiert, und deshalb ist der Token die einzige Quelle der Wahrheit für die Farbe des sekundären Textes.

Was können Sie nicht überprüfen?

Einige konkrete Dinge, so wie sie im Audit geschrieben sind. Aktivierung mit der Tastatur: Das verwendete Browser-Panel erzeugt keine Standardaktivierung — das Drücken von Enter auf einer Schaltfläche erzeugt keinen Klick — daher berichten wir keine Schlussfolgerungen zu Enter und Space. Emulation der Präferenz für reduzierte Bewegung: Wir konnten sie im Browser nicht aktivieren, daher wurde die Regel in der Quelle überprüft, und ein manueller Test mit eingeschalteter Präferenz bleibt empfohlen. Und die Metriken zur wahrgenommenen Ladezeit waren im Werkzeug nicht verfügbar, daher sind sie als nicht gemessen und nicht geschätzt markiert.

Garantieren Sie WCAG-Konformität?

Nein, und niemand, der ehrlich ist, sollte das auf Grundlage eines automatischen Werkzeugs tun. Ein Werkzeug deckt einen Teil der Kriterien ab; der Rest erfordert manuelle Prüfung, und einige erfordern echte Benutzer. Was wir garantieren, ist die Methode: deklarierte Stichprobe, deklarierte Werkzeug- und Versionsangabe, veröffentlichte Rohresultate, unabhängig neu berechnete Verhältnisse, Behebung mit Prüfkriterium und die explizite Liste dessen, was nicht überprüft werden konnte. Ein Zertifikat ohne diese Liste sagt nichts.

Worauf die obigen Aussagen beruhen (15 Quellen)
  1. Die acht direkt im Stylesheet geschriebenen Farben (2,88–4,49:1) existieren weder im Repository noch im von der Produktion ausgelieferten Stylesheet mehr; an ihrer Stelle steht `var(--muted)`https://www.megapromoting.com/_next/static/chunks/0~95cl1qc44v9.css · 2026-09-06

14 davon sind Code und Dateien aus unseren Repositories. Wir veröffentlichen weder ihren Namen noch die Zeile: zusammen, auf einer einzigen Seite, würden sie zu genau beschreiben, wie Systeme gebaut sind, die nicht nur uns gehören. Wir gehen sie mit Ihnen durch, im Repository, auf Anfrage — die Überprüfung bleibt möglich, sie findet nur in einem Gespräch statt.

Was sollte bei Ihnen besser laufen?

Erzählen Sie uns von Ihrem Prozess. Gemeinsam legen wir fest, was sich zu bauen lohnt, was wir anbinden können und wie wir das Ergebnis prüfen.

Lassen Sie uns sprechen