Was geprüft ist, bevor etwas ausgeliefert wird

Diese Seite ist bewusst unbequem ehrlich: Sie nennt auch die Fehler, die ich in der eigenen Arbeit gefunden habe, und die Punkte, die offen sind. Ein Beleg ist mehr wert als ein Versprechen, und eine Lücke, die benannt ist, richtet weniger Schaden an als eine, die jemand später selbst findet.

Die Apps für Jira in Zahlen

Alle Zahlen unten stammen aus einem Messlauf am 31. August 2026 über alle zehn Apps, nicht aus einer Schätzung.

• 158 automatisierte Testfälle in 18 Testdateien, verteilt über alle zehn Apps. Beim Nachmessen liefen zehn von zehn Testläufen grün durch, keiner scheiterte. Geprüft wird die Kernlogik getrennt von der Oberfläche: Die Rechenlogik jeder App ist eine eigene, seiteneffektfreie Einheit, die ohne Jira testbar ist. Fünf Apps testen zusätzlich die Anwendungsschicht gegen nachgebaute Forge-Schnittstellen.
• Neun von zehn Apps fordern kein einziges Schreibrecht auf deine Jira-Daten. Die eine Ausnahme ist Tree Clone, bei der das Anlegen von Vorgängen der Zweck ist. Keine App fordert mehr als zwei Berechtigungen, und in keinem der zehn Forge-Manifeste ist eine externe Domain oder ein Datenabfluss deklariert.
• Ein zentrales Prüfmodul mit dreizehn Stufen begleitet jede App von der Marktrecherche bis nach der Veröffentlichung. Dieses Modul hat 83 eigene Tests, prüft also sich selbst.
• Kein Sprachmodell gibt eine App frei. Die Freigabestufe weist Agenten-Kennungen aktiv zurück, samt getarnter Schreibweisen mit kyrillischen Buchstaben. Und den unabhängigen Zweitreview darf nicht dieselbe Modellfamilie machen, die den Code geschrieben hat.

Was bei den Apps ausdrücklich offen ist

Zu jeder App führe ich eine Matrix von Fehlerklassen, von fehlenden Berechtigungen bis zum Netzwerkabbruch. Jede Zelle trägt einen Status, und offene Zellen bleiben sichtbar offen, statt stillschweigend zu verschwinden. Aktuell sind von 120 Pflichtzellen 22 geprüft, 26 nicht anwendbar und 72 offen. Offen sind vor allem die selteneren Fehlerpfade wie Rate-Limits, API-Fehler und Netzwerkabbrüche; die Kernlogik deckt die Testreihe oben ab.

Zwei weitere Punkte, die eine Verkaufsseite normalerweise verschweigt: Die späten Stufen des Prüfmodells (Marketplace-Release, Doku-Vollständigkeit, Freigabe, Nachlauf) haben für die aktuellen Apps noch keine hinterlegten Ergebnisse. Und eine App ist an der Stufe zur Implementierungsqualität blockiert, weil ihre Abhängigkeiten fünf hoch bewertete Schwachstellen tragen. Beides steht so in den Prüfprotokollen und wird abgearbeitet.

Wie nötig diese Skepsis ist, zeigt ein Fund aus der eigenen Arbeit: Bei Tree Clone blieb eine absichtlich eingebaute Sabotage zunächst grün, weil die Testdaten schon vorsortiert waren. Die Messung war blind. Nach der Härtung schlug dieselbe Sabotage an drei Stellen an. Ein grüner Test beweist erst dann etwas, wenn man ihn einmal hat scheitern sehen.

Das Barrierefreiheits-Audit dieser Website in Zahlen

Beim ersten vollständigen Audit hatten 12 von 12 geprüften Seiten Barrierefreiheits-Verstöße. Nach den Fixes waren es 0 Seiten mit Befund; der zweite Durchlauf umfasste damals 20 Seiten in beiden Sprachen. Der Bestand ändert sich laufend und liegt aktuell bei 49 Seiten; deshalb läuft die statische Grundprüfung (Sprache, Alternativtexte, Überschriften-Struktur, Titel, Link-Namen) inzwischen bei jedem Build automatisch über alle Seiten. Der vollständige manuelle WCAG-Durchgang gilt für den damaligen 20-Seiten-Stand; für den gewachsenen Bestand steht er noch aus.

• Größter Fund: unsichtbarer Tastatur-Fokus auf allen Buttons. Die Button-Basis hatte den Fokus-Ring per CSS entfernt. Mit der Maus fiel das nie auf, mit der Tastatur war jeder Call-to-Action unsichtbar fokussiert. Der Fix: ein durchgängig sichtbarer Fokus-Ring auf allen interaktiven Elementen.
• Kontraste mathematisch berechnet statt nur gescannt. Automatische Scanner können Text auf Verlaufs-Flächen nicht bewerten. Deshalb wurden die Kontrastverhältnisse direkt aus den Farbwerten des Design-Systems berechnet. Fließtext liegt jetzt bei etwa 12,7:1; die WCAG fordert für normalen Text mindestens 4,5:1.
• Reduzierte Bewegung nachgemessen. Wer im Betriebssystem „Bewegung reduzieren“ aktiviert hat, bekommt die Animationen dieser Seite abgeschaltet. Das wurde nicht nur implementiert, sondern mit emulierter Systemeinstellung nachgemessen.

Wie diese Website getestet wurde

• Automatisierte Scans mit der axe-core-Prüfbibliothek über alle Seitentypen, mit erzwungen sichtbaren Animations-Elementen, damit der Scanner nichts übersieht
• Manuelle Tastatur-Durchläufe: jede Seite komplett ohne Maus bedient, mit Screenshots des sichtbaren Fokus als Beweis
• 320-Pixel-Test: alle Seiten bei 320 CSS-Pixeln Breite geprüft, ohne horizontales Scrollen
• Kontrast-Mathematik direkt aus den Farb-Tokens, siehe oben
• Screenshots und Messwerte als Beleg zu jedem Prüfschritt

Nachtrag: Delta-Prüfung auf WCAG 2.2

WCAG 2.2 ergänzt Version 2.1 um neue Erfolgskriterien. Diese Website wurde gegen die 2.2-AA-Zusatzkriterien geprüft; dabei wurden zwei Punkte gefunden und behoben:

• Zielgröße (2.5.8): Der Sprachumschalter im Kopfbereich war mit 24 Pixeln Höhe grenzwertig, die Footer-Links unterschritten mit 20 Pixeln das Minimum. Beide wurden auf 28 Pixel Höhe angehoben und nachgemessen.
• Fokus nicht verdeckt (2.4.11): Der feststehende Kopfbereich konnte beim Rückwärts-Tabben fokussierte Elemente überlagern. Behoben über einen Scroll-Versatz, der fokussierte Elemente unterhalb des Kopfbereichs hält.
• Konsistente Hilfe (3.2.6): Kontaktweg auf jeder Seite an denselben Stellen (Kopfbereich, Footer, Kontaktseite). Bestanden.
• Redundante Eingaben (3.3.7): Das Kontaktformular ist einstufig, nichts muss doppelt eingegeben werden. Bestanden.
• Ziehbewegungen (2.5.7): Es gibt keine Drag-Interaktionen. Nicht anwendbar.
• Barrierefreie Authentifizierung (3.3.8): Es gibt keinen Login. Nicht anwendbar.

Die Technik hinter dieser Website

• Statisch generiert mit Astro: Die Inhaltsseiten werden als fertiges HTML ausgeliefert. Serverseitig laufen nur drei kleine PHP-Endpunkte für den Kontaktversand und die anonyme Zählung; eine Datenbank gibt es nicht. Das macht die Seite schnell und robust.
• Lokal gehostete Schriften: keine Verbindung zu Google Fonts oder anderen Font-CDNs.
• Keine Werbetracker, keine Analyse-Dienste von Drittanbietern.
• Cookieloses Zählsystem: Seitenaufrufe werden anonym und ohne Cookies gezählt; „Do Not Track“ und „Global Privacy Control“ werden respektiert.
• Hosting-Logs transparent gemacht: Was der Hoster technisch protokolliert, steht offen in der Datenschutzerklärung.

Prüfstandard und ehrliche Grenzen

Diese Website ist technisch geprüft nach WCAG 2.2 AA (schließt die Kriterien von WCAG 2.1 AA ein). Zur Einordnung: Rechtlicher Referenzrahmen des Barrierefreiheitsstärkungsgesetzes ist die Norm EN 301 549, die derzeit auf WCAG 2.1 AA verweist. Geprüft wird hier gegen den aktuelleren Stand 2.2.

Genauso wichtig ist, was diese Seite nicht behauptet:

• Ein Test mit echtem Screenreader (NVDA) steht noch aus. Bisher gab es automatisierte Prüfungen und manuelle Tastatur-Durchläufe, aber noch keinen vollständigen Screenreader-Durchgang.
• „Technisch geprüft“ ist eine Ingenieurs-Aussage, keine Rechtsberatung und kein Zertifikat. Eine formale Konformitätsbewertung oder -erklärung ist damit nicht verbunden.

Dieselben Prüfungen, die hier dokumentiert sind, fahre ich auch für Kundenprojekte: Bei individuellen Webapps und Tools gehört der Prüfbericht mit Zahlen und Screenshots zum Lieferumfang.