Ein mittelständischer Maschinenbauer hatte ein Kontaktformular, das optisch sauber wirkte. Screenreader-Nutzer hörten jedoch nur „Eingabefeld“ ohne Bezug zur Frage; Tastatur-Nutzer sprangen beim Fehler nicht zum betroffenen Feld. Das Problem ist typisch: Barrierefreiheit wird oft erst am Ende eines Projekts geprüft.
Die Ursache liegt selten in fehlendem Willen. Häufig fehlen klare Komponenten, verbindliche Prüfschritte und Zeit im Redaktionsalltag. Genau an dieser Stelle setzt twindor an: Formulare werden als wiederverwendbare Bausteine gedacht, mit Labels, Fehlermeldungen und Fokusführung. Der Unterschied zeigt sich im Test mit Tastatur und Screenreader, nicht nur im Browser.
Im Mittelpunkt stehen WCAG-2.1-AA-Kriterien, die sich direkt auf Formulare auswirken. Dazu gehören sichtbare Labels, ein eindeutiger Fokusrahmen, verknüpfte Fehlermeldungen und eine logische Reihenfolge. Ein häufiger Fehler ist ein Platzhaltertext als einzige Beschriftung: Er verschwindet beim Tippen und wird von assistiven Technologien nicht zuverlässig vorgelesen.
Twindor zerlegt die Prüfung in Aufgaben: Feldbeschriftung, Fehlertext, Tastaturweg, Kontrast und Mobile-Darstellung. Jede Aufgabe bekommt eine verantwortliche Person und einen Testfall. Das klingt unspektakulär, verhindert aber, dass Barrierefreiheit nur ein PDF-Audit bleibt. Aus dem Ergebnis entsteht eine konkrete Änderungsliste für Entwicklung und Redaktion.
Ein einzelnes Formular lässt sich schnell reparieren. Nachhaltig wird es, wenn dieselbe Logik in allen Formularen steckt: Newsletter, Bewerbung, Produktanfrage. Twindor arbeitet deshalb mit einer kleinen, dokumentierten Komponentenbibliothek. Redakteure sehen, welche Variante erlaubt ist; Entwickler müssen Fehlerzustände nicht jedes Mal neu erfinden.
Für Unternehmen bedeutet das weniger Nacharbeit bei Relaunches und Updates. Ein neues Feld erbt die geprüften Eigenschaften, statt eine neue Barriere einzuführen. Die Geschichte des Maschinenbauers endet damit nicht mit einem einmaligen Fix, sondern mit einem Formularbaukasten, der auch beim nächsten Kampagnenlanding funktioniert.
Nein. Scanner finden etwa fehlende Alternativtexte, aber nicht die Sinnhaftigkeit einer Fehlermeldung. Ein manueller Test mit Tastatur und Screenreader bleibt nötig, weil er den tatsächlichen Bedienweg prüft.
Nicht jede Seite, aber jeder Komponententyp und jede kritische Vorlage. Twindor priorisiert Formulare, Navigation und Dialoge, weil dort die meisten Hürden entstehen.
Das hängt vom Bestand ab. Ein einzelnes Kontaktformular ist oft in wenigen Tagen korrigiert; ein Komponentenbaukasten braucht einen längeren, geplanten Durchlauf mit Tests und Redaktionsschulung.
