Ihr Weg zum VPAT beginnt im Editor. Verbinden Sie unser MCP

Etwas, das wir in den Plattformdaten immer wieder sehen: Ein Kunde führt ein Audit durch, liest die Ergebnisse, stimmt ihnen zu – und ein erheblicher Teil dieser Probleme ist Monate später noch offen. Niemand hat etwas bestritten. Die Arbeit wurde einfach nicht erledigt.

Lange Zeit dachte ich, das sei ein Priorisierungsproblem und die Lösung eine bessere Bewertung des Schweregrads. Meist ist es aber ein logistisches Problem. Das Problem steht im DevAlly-Dashboard, die Person, die es beheben kann, sitzt in ihrem Editor, und um von einem zum anderen zu kommen, muss man innehalten, den Tab finden, das Produkt finden, das Problem finden und genug davon lesen, um zu rekonstruieren, was der Checker eigentlich gemeint hat. Sagen wir drei Minuten. Drei Minuten sind nichts – nur fallen sie genau dann an, wenn jemand in der Entwicklung gerade im Flow ist und diesen Schwung nicht opfern will. Also wandert das Problem ins Backlog und das Backlog ins nächste Quartal.

Warum sich der ACR vom Produkt entfernt

Richtig teuer wird das irgendwann bei Ihrem ACR.

Sie erstellen einen, das Einkaufsteam eines Kunden gibt ihn frei, er wird abgelegt. Dann liefern Sie weiter aus. Jemand fügt ein Modal hinzu, das den Fokus einfängt, oder ein Design-Refresh senkt den Kontrast sekundärer Buttons unter 4,5:1 – und das Dokument, das Sie im März unterzeichnet haben, beschreibt ein Produkt, das es nicht mehr gibt. Sie merken es beim nächsten Audit oder weil ein Kunde einen aktualisierten ACR anfordert und der Vertrieb die Anfrage an Sie weiterleitet.

Keiner der zugrunde liegenden Fehler ist schwierig. Es geht um Kontrastverhältnisse, Formularfelder ohne Labels, Buttons ohne Accessible Name und Fokusreihenfolgen, die dem DOM statt dem visuellen Layout folgen. Wer kompetent entwickelt, behebt jeden davon in zehn Minuten, wenn Element und Kontext direkt vorliegen – und braucht eine Stunde, wenn das Ticket sechs Wochen später ohne jeden Kontext wieder auftaucht.

Was das DevAlly MCP leistet

MCP ist ein Standard, um KI-Assistenten mit externen Tools zu verbinden. Sie verbinden DevAlly einmal, und Ihr Assistent kann Ihre Barrierefreiheitsdaten direkt abfragen. Die Audit-Ergebnisse landen also im Editor, statt in einem Dashboard darauf zu warten, dass jemand sie abholt.

Im Entwicklungsteam fragt jemand zum Beispiel:

„Zeig mir alle kritischen Probleme im Checkout-Produkt.“

„Wie lautet die Lösung für DEV-2487, und welche Seiten sind betroffen?“

„Was ist noch offen, bevor wir den ACR für das Login-Produkt aktualisieren können?“

„Welche Elemente fallen unter das Kontrastproblem auf der Preisseite, und welche Kontrastverhältnisse erreichen sie?“

Zurück kommen das WCAG-Erfolgskriterium, das fehlerhafte Element, die empfohlene Lösung und die betroffenen Seiten. Dieselben Daten wie im Dashboard, geliefert an den Ort, an dem jemand in den nächsten dreißig Sekunden handeln kann statt im nächsten Sprint.

Wie Authentifizierung und Zugriff funktionieren

Bei der Authentifizierung steht OAuth 2.1 an erster Stelle. Sie melden sich mit Ihrem DevAlly-Konto an, wählen Ihre Organisation aus – und die Einrichtung ist abgeschlossen. Dass wir OAuth zum Standard gemacht haben statt zu einer von zwei gleichwertigen Optionen, liegt am Offboarding. Ein API-Schlüssel ist ein langlebiges Secret, das irgendwann im Klartext in einer Konfigurationsdatei auf irgendeinem Laptop landet, und seine Rotation wird zu einer Aufgabe, für die niemand zuständig ist. Am Ende pflegen Sie zwei Systeme und zwei Offboarding-Checklisten und vergessen irgendwann eine davon. Mit OAuth verliert der Assistent einer Person seinen Zugriff in genau dem Moment, in dem Sie ihr den DevAlly-Zugang entziehen.

Die Authentifizierung per Schlüssel ist ebenfalls verfügbar und nutzt dieselben Schlüssel wie unsere öffentliche API, denn manche Setups können keine interaktive Anmeldung durchführen. Vor allem CI-Pipelines und Headless-Agents. Wenn das auf Sie zutrifft: Die Schlüssel verhalten sich genau wie überall sonst auf der Plattform, Sie müssen sich also in nichts Neues hineindenken. Die meisten Teams werden sie nicht brauchen.

Es läuft als Remote-Server, Ihr Team hostet also nichts, und niemand installiert etwas, das anschließend aktualisiert werden muss. Alle nutzen dieselbe Version – und das ist wichtiger, als es klingt, wenn Sie je ein lokal installiertes Tool in einem Team von dreißig Leuten betreut haben.

Ein zweites Berechtigungsmodell gibt es ebenfalls nicht, und das ist Absicht. Über OAuth sieht das MCP genau das, was das angemeldete Konto sieht: Ist ein Produkt für jemanden im Dashboard nicht sichtbar, kann auch der Assistent dieser Person es nicht abfragen. Schlüssel gelten wie in der öffentlichen API für die gesamte Organisation, ein Schlüssel kann also auf alles in der Organisation zugreifen. Das ist eine weiter reichende Berechtigung als eine Benutzersitzung, und es ist der zweite Grund, warum wir OAuth in den Vordergrund stellen, statt beide als gleichwertig zu behandeln. In keinem der beiden Fälle kommt ein Berechtigungsmodell hinzu, das Ihr Team nicht ohnehin schon verwaltet.

Wir hätten eigene MCP-Scopes bauen können, und in einem Sicherheitsfragebogen hätte das gründlicher gewirkt. Es hätte aber bedeutet, zwei Dinge zu pflegen, die für immer miteinander übereinstimmen sollen.

Das MCP schreibt nicht in Ihr Repository und sagt Ihnen nicht, ob Sie konform sind. Es meldet, was fehlschlägt und was wir dagegen vorschlagen. Eine Konformitätsaussage ist etwas, wofür Ihre Organisation mit ihrem Namen einsteht, und sie sollte bei einer Person bleiben, die man bitten kann, sie zu begründen.

Warum Konformität im Workflow für EAA, ADA und Section 508 wichtig ist

Der European Accessibility Act gilt seit dem 28. Juni 2025. In den USA legt die Regelung des Department of Justice zu Title II des ADA Fristen für die Einhaltung fest: April 2026 für größere öffentliche Stellen und April 2027 für kleinere. Section 508 regelt weiterhin die Beschaffung auf Bundesebene.

Allen gemeinsam ist: Das Dokument ist nur so viel wert wie das Produkt dahinter. Ein ACR in einem Beschaffungsordner bedeutet wenig, wenn sich der Build seit der Unterzeichnung weiterentwickelt hat. Die Teams, die hier die Nase vorn behalten, prüfen Barrierefreiheit als Teil ihrer normalen Arbeit und nicht erst in den zwei Wochen vor einem Audit.

So starten Sie mit dem DevAlly MCP

Das MCP ist in unseren Plänen Growth und Compliance enthalten, und die Verbindung dauert etwa eine Minute. Registrieren Sie sich, fügen Sie den Connector hinzu, melden Sie sich an und stellen Sie ihm eine Frage.

Wir nutzen es jeden Tag. Die Tools sind aus dem entstanden, was wir beim Beheben echter Barrierefreiheitsprobleme in unseren eigenen Produkten tatsächlich vor uns haben wollten, nicht aus einer Spezifikation – deshalb sind wir überzeugt, dass sie funktionieren. Aber Workflows sind individuell, und es wird Wege geben, an die wir nicht gedacht haben. Wenn Sie etwas fragen, das es Ihrer Meinung nach beantworten können sollte, und es kann es nicht, melden Sie sich bei uns. Wir möchten davon hören.

Richten Sie Ihr erstes Produkt ein und legen Sie los → https://app.devally.com/auth/sign-up