Fordern Sie vor der Auswahl eines WordPress-Chatbots Nachweise zur Barrierefreiheit für die genaue Produktoberfläche, die bewertete Version und den benötigten Besucherablauf an. Vergleichen Sie anschließend die Anbieterangabe mit Ihrem Theme, der Platzierung und Ihren dokumentierten lokalen Feststellungen. Trennen Sie unbelegte Geltungsbereiche, fehlende Nachweise und bestätigte Mängel. Ein Badge allein beantwortet diese Einkaufsfragen nicht.
Dieser Leitfaden zur Anbieterbewertung barrierefreier WordPress-Chatbots liefert eine Nachweisanfrage, eine Matrix zum Abgleich von Angaben und Versionen sowie Bedingungen für eine Kaufentscheidung. Er bewertet keine Produktkonformität und zieht keine rechtliche Schlussfolgerung. Alle ausgefüllten Beispielzeilen sind hypothetisch, keine Kundenergebnisse.
Autor: Achla AI, Organisation. Geprüft am 14. Oktober 2026. Mit KI-Unterstützung anhand offizieller Standards, Anbieterdokumentation und geprüfter Produktquellen erstellt. Das Prüfdatum ist kein Veröffentlichungsdatum.
Eine Barrierefreiheitsangabe ist der Ausgangspunkt einer Kaufentscheidung
Definieren Sie den erforderlichen Ablauf, bevor Sie Anbieter vergleichen. Bei einem öffentlichen Website-Antwortwidget könnte er das Öffnen der Oberfläche, eine Frage zu einer Leistung, das Aufrufen einer belegenden Seite und die Rückkehr zur Website umfassen. Ein Bericht über ein Agenten-Dashboard beantwortet für sich genommen nicht, ob die Besucheroberfläche Ihre Anforderungen erfüllt.
Der Nutzerbedarf ist konkret: In einer WordPress-Forumsfrage fragt eine Person aus dem Hochschulbereich, wie wesentliche Chatbot-Aktionen mit der Tastatur ausführbar sind. Diese ältere Frage ist ein Bedarfssignal, keine Feststellung über jedes heutige Plugin.
Ihre Einkaufsfrage lautet, welche Nachweise das benötigte Erlebnis in Ihrer geplanten Konfiguration stützen. Legen Sie diese Anforderung vor einer Verkaufsdemo fest. Sonst kann eine überzeugende Vorführung ein anderes Theme, eine andere Platzierung oder Produktoberfläche zeigen als diejenige, die Sie kaufen möchten.
Produkt, Version und Website-Kontext hinter der Angabe bestimmen
Lassen Sie den Anbieter die abgedeckte Komponente benennen: öffentliches Web-Widget, mobiles SDK, Verwaltungsoberfläche oder etwas anderes. Erfassen Sie nach Möglichkeit Version oder Build, Bewertungsdatum, Standardversion und angegebenes Niveau. Ein Berichtstitel und ein bekanntes Logo sind nützliche Anhaltspunkte, benötigen aber einen klaren Geltungsbereich.
Die WCAG-Anforderungen an Konformitätserklärungen nennen Erklärungsdatum, Version und URI der Richtlinien, Niveau, abgedeckte Seiten und verwendete Technologien. WCAG behandelt auch vollständige Seiten und vollständige Prozesse. Eine Komponentenerklärung belegt deshalb nicht die Konformität Ihrer gesamten WordPress-Website.
Trennen Sie Anbietermetadaten von Ihrem Installationsprotokoll. Der Anbieter bewertet möglicherweise eine gehostete Widget-Version; zusätzlich müssen Sie Theme, Editor, Platzierung, Branding und öffentliche Seiten erfassen. Diese zusätzlichen Felder gehören zum hier vorgeschlagenen Beschaffungsarbeitsblatt und sind keine neue W3C-Zertifizierungsanforderung.
| Geltungsbereich | Anbieternachweis | Ihre geplante Konfiguration |
|---|---|---|
| Produktoberfläche | Genau bewertete Komponente | Besucher-Widget oder andere benötigte Oberfläche |
| Version und Datum | Bewertete Version beziehungsweise Build und Berichtsdatum | Geplante Integration und Prüfdatum |
| Standards | Version, Niveau und Berichtsumfang | Bewertungsanforderung der Organisation |
| Website-Kontext | Annahmen, Voraussetzungen und Ausschlüsse | Theme, Editor, Platzierung und Anpassungen |
| Ablauf | Bewertete Seiten oder Aufgaben | Öffentliche URLs und vollständiger benötigter Weg |
Kann der Anbieter die Version hinter einer Angabe nicht benennen, notieren Sie „Versionsanwendbarkeit unbekannt“. Ordnen Sie den Bericht nicht stillschweigend der neuesten Version zu.
Anbieterangaben auf Daten, Ausnahmen und unterschiedliche Oberflächen prüfen
Aktuelle Kategorieseiten verdeutlichen die Bedeutung dieser Unterschiede. Die folgenden Beispiele beschreiben Anbieterangaben, die am 14. Oktober 2026 beobachtet wurden. Sie sind keine unabhängigen Konformitätsurteile und keine Rangliste.
Der LiveChat-Leitfaden zur Barrierefreiheit nennt WCAG 2.2 AA für das Chat Widget und verlinkt ein VPAT. Er unterscheidet Standardfarben von der Prüfung eigener Farben und nennt eine Einschränkung bei standardmäßigen Eye-Catchern. Fordern Sie den Bericht für Ihre geplante Konfiguration an, statt die Überschrift auf jede optionale visuelle Funktion auszudehnen.
Die Messenger-FAQ von Intercom nennt eine Bewertung des Web Messenger im Januar 2026 und beschreibt weitgehend unterstützte WCAG 2.2 AA mit teilweise unterstützten Bereichen im verlinkten VPAT. Sie grenzt diese Oberfläche von der nicht bewerteten Web-App und den mobilen SDKs ab und warnt, dass eigene Farbkombinationen die Barrierefreiheit verschlechtern können.
Die Zendesk-Seite zur Barrierefreiheit führt getrennte Berichte für unterschiedliche Produkte auf. Zum Prüfzeitpunkt trägt der Eintrag zum Messaging Web Widget das Datum September 2025, der Eintrag zum Classic Web Widget dagegen Dezember 2019. Wählen Sie den Bericht zum tatsächlich eingesetzten Produkt, nicht das zuerst angezeigte Dokument.
Eine klare Beschreibung von Ausnahmen liefert bewertbare Informationen. Sie macht einen Anbieter nicht automatisch ungeeignet. Entscheidend ist, ob eine Ausnahme den benötigten Ablauf betrifft und ob eine nachgewiesene Lösung verfügbar ist.
Vor der Widget-Auswahl eine abgegrenzte Nachweisanfrage senden
Verwenden Sie dieselbe Anfrage für alle Anbieter, einschließlich Achla. Fragen Sie nach anwendbaren Nachweisen, ohne ein einheitliches Berichtsformat vorauszusetzen oder ein fehlendes Dokument als Beweis für ein unzugängliches Produkt anzusehen.
- Benennen Sie das genaue Produkt und den vorgesehenen Besucherablauf.
- Fordern Sie die datierte Bewertung, die anwendbare Version sowie Standard, Version und Niveau an.
- Fragen Sie nach Bewertungsumfang, Methode, Angaben zu den Bewertenden und bekannten Ausnahmen.
- Fragen Sie, welche Website-Einstellungen oder Anpassungen das Ergebnis verändern können.
- Vereinbaren Sie, wer offene Fragen klärt und welche Nachweise sie abschließen.
Eine praktische Anfrage könnte lauten: „Wir möchten das öffentliche Widget auf diesen WordPress-Seiten mit diesem Theme und dieser Platzierung einsetzen. Bitte benennen Sie die Bewertung dieser Oberfläche, die betreffende Version, ihre Ausschlüsse und die für diese Aufgaben relevanten Nachweise.“
Fügen Sie dieses Arbeitsblatt bei:
| Angeforderter Nachweis | Was der Käufer unterscheiden muss |
|---|---|
| Bewertende, Daten und Methoden | Anbieterbehauptung oder dokumentierte Bewertungsergebnisse |
| Produkt, Build und Seitenumfang | Anwendbare Version oder anderes Produkt beziehungsweise historischer Bericht |
| Browser und assistive Technologien | Getestete Konfiguration oder nicht näher erläuterte Zusage |
| Annahmen zu Theme, Platzierung und Branding | Abgedeckte Standardeinstellungen oder angepasstes Website-Verhalten |
| Bekannte Ausnahmen und Voraussetzungen | Unterstützter Umfang oder ungelöste erforderliche Aufgaben |
| Anbieter- und Website-Kontakte | Zuständigkeit für Produktfragen und für Änderungen an der Website |
| Auslöser und Protokoll der Wiederholungsprüfung | Änderungen, die die Kaufentscheidung erneut öffnen |
Die W3C-Vorlage für Bewertungsberichte enthält Umfang, Bewertende, Vorgehen und Feststellungen und verweist auf aktualisierte Ressourcen zur Berichterstellung. Der Überblick zur Konformitätsbewertung erklärt das Verhältnis von Bewertung und Bericht: Die Erstellung eines Berichts führt die Bewertung nicht durch. Fragen Sie nach tatsächlichen Feststellungen hinter dem Dokument.
Angaben, Beobachtungen und fehlende Nachweise getrennt erfassen
Eine Anbieterangabe beschreibt den erklärten Geltungsbereich. Eine lokale Feststellung beschreibt, was eine bewertende Person in einer bestimmten Umgebung beobachtet hat. Eine Kaufbedingung beschreibt, was Sie vor der Auswahl oder Einführung benötigen. Halten Sie alle drei Punkte sichtbar.
| Eintrag | Anbieterangabe und Quelle | Versions- oder Konfigurationsbezug | Lokaler Nachweis | Zuständigkeit und Kaufbedingung |
|---|---|---|---|---|
| Oberflächenabdeckung | Genaue Angabe und Datum erfassen | Abdeckung des öffentlichen Widgets bestätigen | Noch nicht bewertet | Käufer fordert anwendbaren Bericht an |
| Eigenes Branding | Genannte Anpassungsgrenzen erfassen | Gewähltes Theme, Farben und Platzierung erfassen | Feststellungen oder „nicht geprüft“ erfassen | Website-Verantwortlicher liefert abgegrenzte Nachweise |
| Erforderlicher Ablauf | Unterstützten Umfang und Ausnahmen erfassen | Seiten und Produktversion erfassen | Ergebnis und Nachweisreferenz erfassen | Verantwortlicher klärt relevante Blockaden |
| Geänderte Version | Vorherige Angabe bewahren | Neue Version und geänderte Einstellungen erfassen | Wiederholungsprüfung ausstehend | Käufer öffnet betroffene Bedingungen erneut |
Diese Zeilen sind leere Entscheidungsstrukturen, keine abgeschlossenen Bewertungen. Füllen Sie sie anhand echter Dokumente und Beobachtungen aus. Aus „nicht geprüft“ darf kein bestandenes Ergebnis werden.
Verwenden Sie unterschiedliche Statuswerte. Fehlender Nachweis bedeutet, dass die benötigte Bewertung oder lokale Feststellung noch nicht vorliegt. Außerhalb des Geltungsbereichs bedeutet, dass das Material eine andere Oberfläche oder Konfiguration betrifft. Abweichung bedeutet, dass Nachweis und Angabe nicht dieselbe Version oder Anforderung beschreiben. Bestätigter Mangel setzt eine tatsächliche reproduzierbare Feststellung voraus. Jeder Status erfordert einen anderen nächsten Schritt.
Ein Verwaltungsoberflächenbericht für eine Besucher-Widget-Anforderung liegt beispielsweise außerhalb des Geltungsbereichs. Eine aktuelle Widget-Bewertung ohne lokale Nachweise zu Ihrem angepassten Theme lässt eine lokale Nachweislücke offen. Dies sind hypothetische Einordnungsbeispiele, keine Vorwürfe gegen einen bestimmten Anbieter.
Mangelzuständigkeit und Bedingung für eine Wiederholungsprüfung benennen
Machen Sie Zuständigkeiten handlungsfähig. Weisen Sie Produktverhalten einem benannten Anbieterkontakt, Template- oder Stylingänderungen dem Website-Maintainer, Bewertungsfeststellungen der bewertenden Person und das Kaufurteil dem Käufer zu. An einem gemeinsamen Mangel können mehrere Personen beteiligt sein; eine Person sollte die nächste Entscheidung koordinieren.
Erfassen Sie betroffene Aufgabe, Nachweisreferenz, relevante Version und vorgeschlagene Abnahmebedingung. „Der Anbieter verbessert die Barrierefreiheit“ ist keine überprüfbare Bedingung. Eine brauchbare Bedingung benennt den zuvor blockierten Ablauf, der in der festgelegten Umgebung nutzbar werden muss, und die Person, die das Ergebnis dokumentiert.
Die W3C-Hinweise zu Erklärungen zur Barrierefreiheit empfehlen Kontaktdaten, bekannte Einschränkungen und getestete Umgebungen. Das unterstützt transparente Kommunikation; eine solche Erklärung ist selbst keine technische Bewertung. Nutzen Sie sie, um den passenden Kontakt zu finden und offengelegte Grenzen mit dem zugrunde liegenden Bericht abzugleichen.
Öffnen Sie betroffene Matrixzeilen erneut, wenn sich eine relevante Widget-Version, das Theme, die Platzierung oder eine Anpassung ändert. Bewahren Sie die bisherigen Nachweise und ergänzen Sie das neue Ergebnis, statt die Geschichte umzuschreiben. Eine versprochene Korrektur, eine Release Note oder ein Screenshot einer unbeteiligten Seite schließt keine offene Kaufbedingung ab.
Praktische Tastatur-, Screenreader- und Viewport-Verfahren finden Sie im vorhandenen Leitfaden zur Barrierefreiheit der Suchleiste. Dieses Arbeitsblatt regelt Anbieternachweise und die Verantwortung für die Abnahme.
Bewerten, Nachweise anfordern, aussetzen oder den Umfang ablehnen
Wählen Sie ein abgegrenztes Urteil und nennen Sie den Grund:
- Bewerten: Die Nachweise betreffen die vorgesehene Oberfläche; für die verbleibende websitespezifische Arbeit ist jemand zuständig.
- Nachweise anfordern: Eine wesentliche Frage zu Umfang, Datum, Ausnahme oder Bewertung ist unbeantwortet.
- Aussetzen: Eine bestätigte Blockade betrifft einen erforderlichen Ablauf; ihre Beseitigung ist noch nicht nachgewiesen.
- Vorgeschlagenen Umfang ablehnen: Er erfüllt eine notwendige Käuferanforderung nicht, oder der Anbieter kann keine geeignete bewertbare Konfiguration anbieten.
Diese Urteile sind Beschaffungsempfehlungen, kein Konformitätsbewertungssystem. Unbekannte Unterstützung bleibt unbekannt. Ein attraktiver Preis darf einen erforderlichen Ablauf nicht stillschweigend aus der Entscheidung entfernen.
Dokumentieren Sie die für das Urteil verwendeten Seiten, die Konfiguration und die Nachweise. Eine begrenzte Bewertungsentscheidung genehmigt weder sämtliche zukünftigen Versionen noch jede Website-Seite. Lassen Sie den Käufer diesen Umfang bestätigen und bewahren Sie offene Bedingungen auf.
Dieselbe Nachweisanfrage auch an Achla richten
Prüfen Sie den WordPress-Connector und die Installationsdokumentation, um Oberfläche und Platzierung für Ihre Bewertung festzulegen. Achla dokumentiert quellenbelegte Antworten aus öffentlichen Website-Inhalten und einen Connector mit einem globalen Platzierungsmodus. Die geprüfte Dokumentation belegt weder ein WCAG-Audit von Achla noch eine Konformitätserklärung oder zertifizierte Kompatibilität mit Ihrem Theme.
Nutzen Sie die Fehlerbehebungsdokumentation für Fragen zum dokumentierten Verhalten. Prüfen Sie die aktuellen Tarife unabhängig von Barrierefreiheitsnachweisen. Der Überblick zur Websitesuche bietet den größeren Kategorie-Kontext, ersetzt aber keinen anwendbaren Bericht.
Wenn öffentliche, quellenbelegte Antworten zur Aufgabe passen, erkunden Sie das Produkt über das Onboarding innerhalb Ihrer Nachweisbedingungen. Behandeln Sie Auswahl, Bewertung und eine spätere Startfreigabe als ausdrückliche Entscheidungen mit zuständiger Person.