What is verified before anything ships

This page is deliberately uncomfortable in its honesty: it names the mistakes I found in my own work, and the points that are still open. Evidence beats promises, and a gap that has been named does less damage than one somebody else discovers later.

The Jira apps in numbers

Every number below comes from a measurement run across all ten apps on 31 August 2026, not from an estimate.

• 158 automated test cases in 18 test files, spread across all ten apps. On the re-run, ten of ten test suites passed and none failed. Core logic is tested separately from the interface: each app's calculation logic is its own side-effect-free unit that runs without Jira. Five apps additionally test the application layer against stubbed Forge APIs.
• Nine of ten apps request no write permission at all on your Jira data. The one exception is Tree Clone, where creating issues is the entire point. No app requests more than two permissions, and none of the ten Forge manifests declares an external domain or any data egress.
• A central review module with thirteen stages accompanies every app from market research through to life after release. That module carries 83 tests of its own, so it checks itself.
• No language model signs off an app. The approval stage actively rejects agent identities, including disguised spellings using Cyrillic look-alike characters. And the independent second review may not come from the same model family that wrote the code.

What is explicitly open on the apps

Every app carries a matrix of failure classes, from missing permissions to a dropped network connection. Each cell has a status, and open cells stay visibly open instead of quietly disappearing. Right now, of 120 required cells, 22 are tested, 26 are not applicable and 72 are open. What is open is mostly the rarer failure paths: rate limits, API errors and network interruptions. The core logic is covered by the test suite above.

Two more things a sales page would normally leave out: the late stages of the review model (marketplace release, documentation completeness, approval, post-release) have no recorded results yet for the current apps. And one app is blocked at the implementation-quality stage because its dependencies carry five high-severity vulnerabilities. Both are on record in the review logs and are being worked through.

A find from my own work shows why that skepticism is needed: in Tree Clone, a deliberately introduced fault stayed green at first, because the test data was already pre-sorted. The measurement was blind. After hardening, the same fault tripped three checks. A green test proves something only once you have seen it fail.

The accessibility audit of this website, in numbers

On the first full audit, 12 of 12 audited pages had accessibility violations. After the fixes, 0 pages had findings; that second pass covered 20 pages in both languages at the time. The page count keeps changing and currently stands at 49, so the static baseline check (language, alt text, heading structure, titles, link names) now runs automatically on every build across all pages. The full manual WCAG pass applies to the 20-page state back then; for the grown site it is still outstanding.

• Biggest find: invisible keyboard focus on every button. The shared button styles had removed the focus ring via CSS. With a mouse you would never notice; with a keyboard, every call to action was focused invisibly. The fix: a consistently visible focus ring on all interactive elements.
• Contrast calculated mathematically, not just scanned. Automated scanners cannot judge text on gradient surfaces, so the contrast ratios were computed directly from the design system's color values. Body text now sits at roughly 12.7:1; WCAG requires at least 4.5:1 for normal text.
• Reduced motion verified by measurement. If you enable "reduce motion" in your operating system, this site switches its animations off. That behavior was not just implemented but re-measured with the system setting emulated.

How this website was tested

• Automated scans with the axe-core testing library across every page type, with animated elements forced visible so the scanner misses nothing
• Manual keyboard passes: every page operated entirely without a mouse, with screenshots of the visible focus as evidence
• The 320-pixel test: all pages checked at a viewport width of 320 CSS pixels, with no horizontal scrolling
• Contrast math straight from the color tokens, as described above
• Screenshots and measured values as evidence for each test step

Follow-up: the WCAG 2.2 delta audit

WCAG 2.2 adds new success criteria on top of version 2.1. This website was audited against the 2.2 AA additions; two issues were found and fixed:

• Target size (2.5.8): the language switcher in the header was borderline at 24 pixels tall, and the footer links fell short at 20 pixels. Both were raised to 28 pixels and re-measured.
• Focus not obscured (2.4.11): the fixed header could cover focused elements when tabbing backwards. Fixed with a scroll offset that keeps focused elements below the header.
• Consistent help (3.2.6): the contact options appear in the same places on every page (header, footer, contact page). Pass.
• Redundant entry (3.3.7): the contact form is a single step; nothing has to be entered twice. Pass.
• Dragging movements (2.5.7): there are no drag interactions. Not applicable.
• Accessible authentication (3.3.8): there is no login. Not applicable.

The architecture behind this website

• Statically generated with Astro: content pages ship as finished HTML. The only server-side code is three small PHP endpoints handling contact email and anonymous page counts; there is no database. That keeps the site fast and robust.
• Self-hosted fonts: no connection to Google Fonts or any other font CDN.
• No ad trackers and no third-party analytics services.
• Cookieless page-view counting: visits are counted anonymously without cookies, and both "Do Not Track" and "Global Privacy Control" are respected.
• Hosting logs made transparent: what the hosting provider logs technically is spelled out in the privacy policy.

Test standard and honest limits

This website is technically tested against WCAG 2.2 AA (which includes the WCAG 2.1 AA criteria). For context: the legal reference framework of the German Accessibility Act (BFSG) is the EN 301 549 standard, which currently points to WCAG 2.1 AA. Testing here is done against the newer 2.2 baseline.

Just as important is what this page does not claim:

• A test with a real screen reader (NVDA) is still outstanding. So far there have been automated checks and manual keyboard passes, but no full screen-reader walkthrough yet.
• "Technically tested" is an engineering statement, not legal advice and not a certificate. No formal conformity assessment or declaration comes with it.

The same checks documented here are what I run for client projects: for custom web apps and tools, the audit report with numbers and screenshots is part of the deliverable.