Zum Inhalt springen

Barrierefreier Checkout: der letzte Meter, auf dem Bestellungen verloren gehen

Diese Seite behandelt ausschließlich den Bestell- und Bezahlprozess: Warenkorb, Adressformular, Versand- und Zahlungsauswahl, Fehlerdialoge, Anmeldung und Bestellbestätigung. Wir prüfen jeden Schritt per Tastatur und auf die Ausgabe für Screenreader gegen die WCAG 2.2 AA und beheben die Befunde im bestehenden Code — Prüfung ab 2.480 € netto.

Checkout-Prüfung ab 2.480 € netto Bußgeld bis 100.000 € (BFSG §37) Eigene Erklärung zur Barrierefreiheit veröffentlicht

Kurz und einfach erklärt

Auf dieser Seite geht es nur um den Weg zur Bestellung. Also um Warenkorb, Adresse, Versand, Zahlung und Bestätigung.

Hier können Menschen an kleinen Dingen scheitern. Zum Beispiel an einer Fehlermeldung, die nur rot ist. Oder an einem Knopf, den man mit der Tastatur nicht erreicht.

Wir prüfen jeden Schritt mit der Tastatur. Wir prüfen auch, was Programme vorlesen können, die blinden Menschen helfen. Dabei richten wir uns nach den WCAG. Das sind Regeln für barrierefreie Webseiten.

Dann beheben wir die Fehler in dem Code, den Sie schon haben. Auch die Zahlung über fremde Anbieter sehen wir uns an.

Lassen Sie den Weg zur Bestellung prüfen. Schreiben Sie uns oder rufen Sie uns an.

Kennzahlen

3.3

WCAG-Abschnitt Eingabehilfe — der Kern des Checkouts

6

Schritte vom Warenkorb bis zur Bestellbestätigung

28.06.2025

BFSG-Pflicht in Kraft

EN 301 549

Europäische Norm, nach der wir neben WCAG 2.2 AA prüfen

Der Bestellprozess ist ein rechtlich besonders heikler Teil Ihres Shops

Das Barrierefreiheitsstärkungsgesetz (BFSG) verpflichtet Onlineshops im Verbrauchergeschäft zur Barrierefreiheit; ausgenommen sind Kleinstunternehmen, die Dienstleistungen erbringen (BFSG §3 Abs. 3). Betroffen ist ausdrücklich auch der Abschluss eines Vertrags — also genau der Checkout. Bei Verstößen drohen Anordnungen der Marktüberwachung und Bußgelder von bis zu 100.000 € (BFSG §37). Unser Prüfmaßstab ist die WCAG 2.2 AA. Er umfasst die Anforderungen der WCAG 2.1 AA, auf die sich die Norm EN 301 549 in der Fassung V3.2.1 stützt; die im September 2026 veröffentlichte Fassung V4.1.1 übernimmt bereits die WCAG 2.2. Unsere eigene Website bewerten wir selbst nach WCAG 2.2 AA; Stand und bekannte Einschränkungen stehen in unserer Erklärung zur Barrierefreiheit.

Ein Shop verdient erst Geld, wenn die Bestellung abgeschickt ist. Genau dort können Menschen, die auf assistive Technologien angewiesen sind, an Kleinigkeiten scheitern: an einer Fehlermeldung, die nur rot eingefärbt ist, an einem Zahlungsformular in einem fremden iFrame, an einem Bestell-Button, der per Tastatur nicht erreichbar ist. Diese Seite behandelt deshalb ausschließlich den Kaufabschluss — vom Warenkorb bis zur Bestellbestätigung samt Beleg. Wie wir einen kompletten Shop technisch barrierefrei machen, also auch Kategorien, Suche, Filter und Produktseiten, beschreibt die Seite zum barrierefreien Online-Shop. Welche BFSG-Pflichten für Händler, Marktplätze und den Omnichannel-Handel insgesamt gelten, ordnet die Seite barrierefreier E-Commerce ein. Den rechtlichen Rahmen liefert das Barrierefreiheitsstärkungsgesetz.

Ein Feld im Bezahlvorgang — vorher und nachher

Barrierefreier Checkout · WCAG 2.2 AA
Aus einer Checkout-Barriere wird ein bedienbarer Kaufabschluss
Genau die Stelle, an der Bestellungen abbrechen — Adressfeld im Bezahlvorgang
Vorher · Checkout3 kritische Barrieren
E-Mail
Kein Label — Screenreader liest nur „Eingabefeld“
Kontrast 2,4:1 — unter 4,5:1 (WCAG 1.4.3)
Fehler nur rot markiert, ohne Text
VS
Nachher · CheckoutWCAG 2.2 AA
E-Mail-Adresse *
Sichtbares Label, programmatisch verknüpft
Kontrast 5,1:1 — AA erfüllt
Fehlertext per aria-describedby, Fokus gesetzt
Konformität Bestellstrecke · vorher61 %
Konformität Bestellstrecke · nachher92 %
Checkout-Prüfungab 2.480 € netto
Prüfung von Tastatur und Screenreader-Ausgabepriorisierte Befundliste
Beispielhafte Gegenüberstellung eines Adressfelds im Checkout vor und nach der Behebung. Darstellung illustrativ, die Konformitätswerte stammen nicht aus einem konkreten Kundenprojekt.

Checkout und Bezahlprozess prüfen

ab 2.480 € Festpreis netto
  • Warenkorb, Adressformular, Versand, Zahlung, Prüfen, Bestätigung
  • Tastatur ohne Maus und Ausgabe für Screenreader geprüft
  • Fehlerdialoge und Validierung nach WCAG 3.3 im Detail geprüft
  • Einstieg mit dem BFSG-Quick-Check bereits für 490 €

Preis für das WCAG-2.2-AA-Audit einer KMU-Website bis 30 Seiten inklusive Bestellstrecke. Reine Bestellstrecken ohne restlichen Shop kalkulieren wir nach Zahl der Schritte und Zahlarten. Alle Zahlen im Überblick auf der Seite Preise.

Preisstand: Oktober 2026.

Die sechs Schritte der Bestellstrecke — und was in jedem zu prüfen ist

Der Checkout bündelt besonders anspruchsvolle Erfolgskriterien der WCAG 2.2, weil hier fast ausschließlich Formulare, Zustandswechsel und rechtsverbindliche Eingaben zusammenkommen. Maßgeblich ist der Abschnitt 3.3 (Eingabehilfe): Beschriftungen oder Anweisungen (3.3.2), Fehlererkennung (3.3.1), Fehlerbeschreibung mit Korrekturvorschlag (3.3.3) und Fehlervermeidung bei rechtsverbindlichen Transaktionen (3.3.4). Dazu kommen zwei Kriterien, die WCAG 2.2 neu eingeführt hat und die den Bestellprozess unmittelbar treffen: Redundant Entry (3.3.7) verbietet, bereits erfasste Daten ohne Grund erneut abzufragen, und Accessible Authentication (3.3.8) untersagt kognitive Funktionstests bei der Anmeldung, etwa Rätsel oder das Abtippen verzerrter Zeichen ohne Alternative (Quelle: W3C WCAG 2.2). Hinzu kommen die generellen Anforderungen an Tastaturbedienbarkeit (2.1.1), sichtbaren Fokus (2.4.7) und die neue Regel, dass der fokussierte Bereich nicht vollständig von Sticky-Elementen verdeckt sein darf (2.4.11).

1. Warenkorb und Mengenänderung

Mengenfelder mit eigenem Label je Position, Entfernen-Buttons mit eindeutigem Bezug zum Artikel statt „Löschen“ dreimal untereinander. Änderungen der Summe werden über eine Live-Region angekündigt, damit Screenreader-Nutzer die Neuberechnung überhaupt bemerken.

2. Adress- und Kontaktdaten

Sichtbare, programmatisch verknüpfte Labels statt Platzhaltertext. Korrekte autocomplete-Attribute, damit gespeicherte Adressen automatisch einsetzbar sind (WCAG 1.3.5). Pflichtfelder werden nicht nur mit einem Sternchen markiert, sondern auch programmatisch ausgezeichnet.

3. Versandart und Lieferoptionen

Versandarten als echte Radio-Gruppe mit Fieldset und Legend, per Pfeiltasten bedienbar. Preis- und Lieferzeitänderungen werden beim Wechsel angekündigt. Zeitfenster-Auswahlen und Kalender-Widgets müssen ohne Ziehbewegung bedienbar sein (WCAG 2.5.7).

4. Zahlungsauswahl

Zahlarten als Radio-Gruppe, nicht als klickbare Kacheln ohne Rolle. Nachgeladene Felder — etwa IBAN bei Lastschrift — werden angekündigt und erhalten den Fokus in logischer Reihenfolge. Eingebettete Anbieterformulare prüfen wir gesondert.

5. Prüfen und bestellen

Die Übersicht vor dem Absenden erfüllt WCAG 3.3.4: Alle Angaben sind prüfbar, korrigierbar und bestätigungspflichtig. Der Bestell-Button trägt eine eindeutige, aus sich heraus verständliche Beschriftung und ist per Tastatur erreichbar, ohne von einem Sticky-Footer verdeckt zu werden.

6. Bestätigung und Beleg

Die Bestätigungsseite kündigt den Erfolg über eine Statusmeldung an, nicht nur über ein grünes Häkchen. Bestellnummer und Zusammenfassung stehen als Text zur Verfügung. Rechnungs-PDFs müssen ebenfalls zugänglich sein — siehe PDF-Barrierefreiheit.

Fehlerdialoge: hier entscheidet sich Abschluss oder Abbruch

Ein sehender Nutzer orientiert sich visuell: Er sieht den roten Rahmen um ein fehlerhaft ausgefülltes Feld und den Fehlertext darunter. Ein Screenreader-Nutzer bekommt davon nichts mit, wenn das Feld nicht programmatisch mit der Fehlermeldung verknüpft ist. Ein Nutzer mit motorischen Einschränkungen, der nur die Tastatur verwendet, kann den Bestell-Button nicht erreichen, wenn er außerhalb der Tab-Reihenfolge liegt. Und wer die Seite auf 200 Prozent vergrößert, verliert die Fehlermeldung aus dem Blick, wenn sie am Seitenanfang steht, der Fokus aber am Seitenende bleibt. Fehlerbehandlung ist deshalb kein Detail des Bestellformulars, sondern seine kritischste Funktion.

Wir setzen Fehlerbehandlung im Checkout nach einem festen Muster um. Jedes Formularfeld erhält ein programmatisch verknüpftes Label. Pflichtfelder werden über aria-required und einen sichtbaren Hinweis gekennzeichnet, nicht allein über Farbe. Fehlermeldungen werden über aria-describedby mit dem jeweiligen Feld verknüpft, in Textform ausgegeben und zusätzlich in einer Fehlerzusammenfassung am Formularbeginn gebündelt, deren Einträge auf das betroffene Feld verlinken. Nach einem Validierungsfehler wandert der Fokus automatisch auf den ersten fehlerhaften Eintrag. Die Fehlermeldung benennt nicht nur das Problem, sondern auch den Korrekturweg — „Bitte geben Sie eine E-Mail-Adresse mit @ an“ statt „Ungültige Eingabe“. Wie das technisch umgesetzt wird, vertieft der Beitrag zu barrierefreien Fehlermeldungen.

Gastbestellung, Konto und barrierefreie Anmeldung

Vor dem eigentlichen Bezahlvorgang steht in vielen Shops eine Hürde, die WCAG 2.2 erstmals ausdrücklich adressiert: die Anmeldung. Erfolgskriterium 3.3.8 (Accessible Authentication, Stufe AA) verlangt, dass kein Authentifizierungsschritt einen kognitiven Funktionstest erfordert, sofern keine Alternative angeboten wird. Rätsel, Rechenaufgaben und das Abtippen verzerrter Zeichenfolgen fallen darunter; Aufgaben, bei denen nur Objekte auf Bildern zu erkennen sind, nimmt die Stufe AA aus. Ebenso problematisch ist es, das Einfügen aus der Zwischenablage im Passwortfeld zu unterbinden, weil damit Passwortmanager ausgehebelt werden. Beides lässt sich in der Regel mit überschaubarem Aufwand beheben.

Praktisch heißt das: Passwortfelder erlauben Einfügen und Autofill und tragen die passenden autocomplete-Werte. Zwei-Faktor-Codes werden ebenfalls per autocomplete unterstützt, damit sie nicht abgetippt werden müssen. Wo ein Spam-Schutz nötig ist, setzen wir auf Verfahren, die keine kognitive Leistung verlangen — etwa serverseitige Prüfungen oder unsichtbare Verfahren mit dokumentierter Alternative. Und weil die schnellste barrierefreie Anmeldung die ist, die entfällt, empfehlen wir eine vollwertige Gastbestellung ohne Kontozwang. Wo ein Konto verpflichtend ist, muss auch die Registrierung selbst den Kriterien genügen. Der Beitrag zur barrierefreien Authentifizierung beschreibt die Varianten im Detail.

Das barrierefreie Adressformular im Detail

Vier Eigenschaften, an denen ein Bestellformular hängt

Das Adressformular ist der längste zusammenhängende Eingabeblock im Checkout. Hier entscheidet sich, ob eine Bestellung ohne Maus und ohne Blick auf den Bildschirm abgeschlossen werden kann. Wir bauen es so um, dass Label, Autofill, Fehlerbezug und Fokusführung zusammenspielen, statt sich gegenseitig zu blockieren.

  • Sichtbares Label je Feld, programmatisch verknüpft (WCAG 3.3.2)
  • autocomplete-Attribute für Name, Straße, PLZ, Ort und E-Mail (WCAG 1.3.5)
  • Fehlertext am Feld plus verlinkte Fehlerzusammenfassung (WCAG 3.3.1, 3.3.3)
  • Bereits erfasste Daten werden nicht erneut abgefragt (WCAG 3.3.7)
Fehlerzusammenfassung
1 Eingabe prüfen: E-Mail-Adresse
Eintrag verlinkt direkt auf das betroffene Feld
Lieferadresse
Vorname *
Straße und Hausnummer *
E-Mail-Adresse *
„Bitte geben Sie eine E-Mail-Adresse mit @ an.“
Fokus springt nach der Prüfung auf das erste fehlerhafte Feldautocomplete aktiv

Zahlarten und ihre typischen Barrieren

Karteneingabe im fremden iFrame

Kartenfelder liegen in der Regel im iFrame eines Zahlungsdienstleisters. Typische Befunde: iFrame ohne title-Attribut, Felder ohne Label, Fehlerausgabe nur farblich. Wir prüfen jedes eingebettete Feld, dokumentieren, was außerhalb Ihres Codes liegt, und stimmen Änderungen mit dem Anbieter ab.

Rechnung und Lastschrift

Bei Auswahl werden zusätzliche Felder nachgeladen — IBAN, Kontoinhaber, Mandatstext. Diese dynamischen Blöcke müssen angekündigt werden und den Fokus in logischer Reihenfolge erhalten. Der Mandatstext gehört als lesbarer Text in die Seite, nicht als Grafik oder als nicht scrollbares Overlay.

Weiterleitungs- und Wallet-Verfahren

Bei Verfahren mit Sprung auf eine externe Seite bricht der Kontext. Der Rücksprung muss den Fokus sinnvoll setzen und den neuen Status ansagen. Öffnet sich ein Popup, braucht es einen erkennbaren Hinweis vorab und einen Weg zurück ohne Maus.

Ratenkauf und Bonitätsabfragen

Diese Strecken enthalten häufig lange Bedingungstexte, Zeitlimits und zusätzliche Identitätsprüfungen. Zeitbegrenzungen müssen sich abschalten, anpassen oder verlängern lassen (WCAG 2.2.1), Bedingungen als strukturierter Text vorliegen und Identitätsprüfungen dürfen keinen kognitiven Funktionstest verlangen.

Verantwortung für externe Zahlungsanbieter

Die Zahlungsabwicklung ist ein Bereich, in dem Shop-Betreiber besonders stark auf Dritte angewiesen sind. Eingebettete Zahlungsformulare können eigene Barrierefreiheitsprobleme mitbringen: iFrames ohne zugänglichen Titel, Kreditkartenfelder ohne Labels, Prüfverfahren, die sich mit einem Screenreader nicht lösen lassen. Rechtlich entbindet Sie das nicht: Das BFSG richtet sich an den Anbieter der Dienstleistung, und das sind gegenüber Ihren Kunden Sie. Wir prüfen deshalb die Zugänglichkeit der integrierten Anbieter, dokumentieren Barrieren, die außerhalb Ihrer Kontrolle liegen, und empfehlen bei Bedarf alternative Zahlungswege.

Wo möglich, konfigurieren wir die Zahlungsanbieter so zugänglich, wie es ihre Einstellungen zulassen: korrektes Labeling der eingebetteten Felder, barrierefreie Fehlerbehandlung und zugängliche Bestätigungsseiten. Bleibt eine Einschränkung bestehen, gehört sie transparent in die Barrierefreiheitserklärung — zusammen mit einem alternativen Weg zum Vertragsabschluss, etwa telefonisch oder per E-Mail. Die Dokumentation ersetzt die Behebung nicht: Bei Nichtkonformität verlangt BFSG §14 Korrekturmaßnahmen und eine unverzügliche Information der Marktüberwachungsbehörde. Wie eine belastbare Erklärung aufgebaut ist, steht auf der Seite zur Barrierefreiheitserklärung.

Eingebettete Zahlungsformulare unter der Lupe

Wo iFrames die Barrierefreiheit gefährden

Zahlungsformulare von Drittanbietern liegen oft in einem iFrame, dessen Zugänglichkeit Sie nicht selbst steuern. Wir prüfen jedes eingebettete Feld, dokumentieren Barrieren, die außerhalb Ihrer Kontrolle liegen, und sichern den Kaufabschluss über einen barrierefreien Alternativweg ab.

  • iFrame-Titel und Feld-Labels systematisch geprüft
  • Prüfverfahren ohne Screenreader-Alternative erkannt und benannt
  • Fehlerausgabe des Anbieters auf die Ausgabe für Screenreader geprüft
  • Transparente Dokumentation in der Barrierefreiheitserklärung
iFrame · Zahlungsanbieter (Fremdcode)Fremd-iFrame
Kartennummer — Label vorhanden
Gültig bis — Label vorhanden
Prüfziffer — Label fehlt, im Bericht notiert
Prüfverfahren ohne Screenreader-Alternative
Alternativweg: Bestellung per Telefon oder E-Mail abschließbar
Befund fließt in die Barrierefreiheitserklärung eindokumentiert

Drei Prüfmittel, mit denen wir jeden Checkout-Schritt durchgehen

Screenreader-Ausgabe je Schritt

Wir legen einen Artikel in den Warenkorb und bestellen per Tastatur bis zur Bestätigungsseite — und prüfen in jedem Schritt, was die Seite an Screenreader übergibt.

Tastatur-Durchlauf

Die gesamte Bestellstrecke wird ausschließlich per Tab-, Pfeil- und Eingabetaste durchlaufen, inklusive bewusst falscher Eingaben, um Fokusfallen und unerreichbare Buttons aufzudecken.

Vergrößerung 200 %

Formulare und Zusammenfassungen werden auf 200 Prozent vergrößert, um Überlappungen, abgeschnittene Fehlertexte und von Sticky-Leisten verdeckte Felder sichtbar zu machen (WCAG 1.4.4, 2.4.11).

Unser Prüfablauf für Bestellstrecke und Bezahlung

Wir erfassen, wie viele Schritte Ihr Checkout hat, welche Zahlarten aktiv sind, ob es einen Gastbestellweg gibt und welche Anbieter eingebettet sind. Daraus ergibt sich der Prüfumfang — nicht aus der Zahl der Produkte im Katalog.

Wir bestellen einmal komplett bei Ihnen — ohne Maus

Abbruchgründe, die nichts mit dem Preis zu tun haben

Wenn über Kaufabbrüche gesprochen wird, geht es meist um Versandkosten, Lieferzeiten oder fehlende Zahlarten. Für Menschen, die auf assistive Technologien angewiesen sind, kann der Abbruchgrund eine Ebene tiefer liegen: Das Formular sagt nicht, was falsch ist. Der Bestell-Button ist per Tastatur nicht erreichbar. Das Zeitlimit im Zahlungsschritt läuft ab, bevor die Eingabe fertig ist. In Deutschland leben gut 7,8 Millionen (Statistisches Bundesamt, Stand Ende 2025) schwerbehinderte Menschen, dazu kommen Menschen mit vorübergehenden oder altersbedingten Einschränkungen. Scheitert eine Bestellung an einer solchen Barriere, fehlt nicht der Kaufwille, sondern die Möglichkeit zu kaufen.

Der zweite Effekt ist breiter: Ein Checkout, der ohne Maus, mit vergrößerter Schrift und mit klaren Fehlermeldungen funktioniert, funktioniert in der Regel auch für alle anderen besser. Sinnvolle autocomplete-Attribute sparen Kunden Tipparbeit. Eine verständliche Fehlermeldung statt „Ungültige Eingabe“ kann Rückfragen im Support ersparen. Eine Übersicht, die vor dem Absenden alle Angaben zeigt, kann Fehlbestellungen und Retouren senken. Barrierefreiheit im Checkout ist damit selten nur eine Compliance-Ausgabe, sondern zugleich eine Investition in die Qualität der Bestellstrecke.

Damit dieser Zustand erhalten bleibt, sollte das Team wissen, worauf es ankommt. Unsere Schulungen vermitteln Entwicklung und Redaktion, wie neue Checkout-Funktionen von Anfang an zugänglich gebaut werden. Für die laufende Absicherung nach der Umsetzung gibt es das BFSG-Monitoring, das Regressionen nach Updates meldet, möglichst bevor sie Bestellungen kosten.

Weiterlesen und weiterklicken

Den Kaufabschluss im Zusammenhang beschreibt der Beitrag zum barrierefreien Checkout im E-Commerce. Wie Formulare und ihre Validierung technisch sauber aufgebaut werden, vertieft der Beitrag zu barrierefreien Formularen. Warum Anmeldeverfahren mit Rätselaufgaben nicht konform sind, klärt der Beitrag zur barrierefreien Authentifizierung. Und weil im Checkout viele Bausteine von außen kommen, lohnt der Beitrag zu Drittanbieter-Widgets und BFSG-Verantwortung. Für den Shop jenseits der Kasse — Suche, Filter, Produktseiten, Umsetzung im Code — ist die Seite barrierefreier Online-Shop der richtige Einstieg; die Pflichten für Händler insgesamt ordnet barrierefreier E-Commerce ein, eingebettet in Barrierefreiheit nach Branche.

Das Wichtigste in Kürze

  • Im Checkout treffen besonders viele WCAG-Kriterien zusammen — Abschnitt 3.3 (Eingabehilfe) plus die neuen Kriterien 3.3.7 und 3.3.8 aus WCAG 2.2
  • Fehlerdialoge entscheiden über Abbruch oder Abschluss: Fehlertext am Feld, verlinkte Zusammenfassung, Fokus auf dem ersten fehlerhaften Eintrag
  • Anmeldung ohne kognitiven Funktionstest, Passwortmanager erlaubt, Gastbestellung als einfachster barrierefreier Weg
  • Eingebettete Zahlungsformulare bleiben Ihre Verantwortung gegenüber dem Kunden — prüfen, dokumentieren, Alternativweg anbieten
  • Prüfung der Bestellstrecke im WCAG-2.2-AA-Audit ab 2.480 € netto, Einstieg über den BFSG-Quick-Check für 490 €

Häufige Fragen zum barrierefreien Checkout

So könnte das Kundenportal von Stadtwerken aussehen

Der Entwurf zeigt Aufbau und Bedienung: kurze Wege zu Zählerstand und Abschlag, ein Formular mit Fehlerhinweis am Feld, Leichte Sprache und Schriftgröße im Kopf. Der Versorger darin ist erfunden.

Entwurf
Kommunaler Versorger

Kundenportal mit Selbstbedienung und Leichter Sprache

Ein Entwurf für ein Stadtwerke-Portal: Zählerstand melden, Abschlag ändern und Umzug eintragen liegen als sechs kurze Wege nebeneinander, das Formular prüft die Eingaben und stellt den Fehler als Text direkt an das Feld. Der Meldeweg bei Störungen steht in vier Schritten da, der Tarifvergleich als Tabelle mit beschrifteten Spalten und Zeilen. Schriftgröße und Leichte Sprache lassen sich im Kopf der Seite umschalten.

Leichte SpracheSchriftgrößeFormularprüfungStörungsmeldung

Exemplarische Layoutentwürfe zur Veranschaulichung. Die gezeigten Betriebe sind erfunden; es handelt sich nicht um Kundenprojekte.

Worum geht es?

Ein Klick genügt — alles Weitere ist freiwillig.

Erzählen Sie kurz vom Projekt

Alle Angaben hier sind freiwillig.

So, wie die Adresse im Browser steht, mit oder ohne https://.

Wann soll es losgehen? (optional)
Grober Budgetrahmen (optional)

Freiwillig — festlegen müssen Sie sich damit nicht.

Stichworte genügen. Wenn Sie etwas schreiben, bitte mindestens 5 Zeichen.

Wie erreichen wir Sie?

Wir melden uns in der Regel innerhalb eines Werktages.

Ihr Name oder Ihr Nachname, mindestens 2 Zeichen.

Nur nötig, wenn Sie einen Rückruf wünschen.

Die Adresse, an die unsere Antwort gehen soll, mit @ und Domain.

Mit dem Absenden stimmen Sie der Verarbeitung Ihrer Angaben zur Bearbeitung der Anfrage zu. Details in der Datenschutzerklärung.

Passende Branchen und Regionen