ariada.org

The EAA pipeline your CI already needed

The European Accessibility Act has been enforceable across the EU since 28 June 2025 — and your existing axe-core run does not know about EAA Annex I §I.3 checkout, §I.4 banking, EN 301 549 art. 7 accessibility statements, or Nordic-locale patterns.

@ariada-org/wcag-rules-extended is the EUPL-1.2 axe-core extension that fills exactly this gap, plus a shipped GitHub Actions workflow that turns it into a scan → PR comment → statement → evidence pipeline. One peer dependency, one uses: line. Zero cost, no telemetry, no account.

The EAA pipeline

  1. Scan — axe-core + @ariada-org/wcag-rules-extended runs against your built site on every push. shipped
  2. PR comment — violations grouped by EAA Annex I § and WCAG Success Criterion, with suggested fix and EN 301 549 cross-reference, posted to the pull request automatically. in-flight, v0.2 target
  3. Statement — EN 301 549 art. 7 accessibility statement generated from your scan results. The very page /accessibility/ you can browse on this site is generated this way. shipped
  4. Evidence — machine-readable JSON self-cert artefact deposited at /.well-known/accessibility/ for third-party re-verification. in-flight, v0.2 target
  5. Penalty exposure — per-jurisdiction monetised estimate of your administrative-fine ceiling under each EU member-state transposition. in-flight, v0.3 target

Every stop ships in the same EUPL-1.2 npm package + one reusable GitHub Actions workflow. One peer dep, one uses: line. Drop-in for any project that already runs axe-core. No SaaS account, no telemetry, no dashboard. 

# .github/workflows/eaa.yml — five lines, then your CI knows EAA
uses: ariada-org/ariada/.github/workflows/eaa-audit.yml@v1
with:
  urls: ["https://your-site.example/", "https://your-site.example/checkout"]
  locale: sv

Status: pre-release. Package page →

For developers

Frontend developer shipping a SaaS landing page

You ship a marketing site and product onboarding flows. EAA 2025 has been live since 28 June — your EU pricing page, your checkout, your contact form, your accessibility statement are all in scope today. Drop @ariada-org/wcag-rules-extended next to your existing axe-core install (one peer dep, no new test runner), add the shipped GitHub Action, and your next pull request gets a comment listing every EAA Annex I §I.3 violation in the touched files. Five lines in .github/workflows/. No SaaS account.

Backend developer shipping a public-facing API + docs site

Your docs site is the public face of your API. When a Swedish or German municipality evaluates your service for procurement, the procurement officer reads your /accessibility page first — and they reject vendors who do not have one. Run the shipped accessibility-statement generator over your built site once per release, drop the generated accessibility.html into your docs theme, and your next public-sector RFP arrives instead of bouncing on EN 301 549 art. 7.

Mobile developer shipping a webview-based app

Your webview UI inherits all the WCAG obligations of a web page. EAA Annex I §I.6 (audiovisual media) and §I.7 (telephony) apply to in-app webviews the same way they apply to your marketing site. Run the rule pack against your in-app HTML during your continuous-integration build, gate the release, and you ship the same conformance evidence as native iOS/Android accessibility audits — without buying a commercial mobile scanner.

Continuous-integration engineer setting up org-wide compliance gates

You run the compliance pipeline for fifteen product teams. You do not want fifteen different EAA implementations. Publish one shared GitHub Actions reusable workflow (ariada-org/ariada@v1, the one we ship) once at the org level, and every product team's pull request gets uniform rule-pack execution, statement generation, penalty-exposure report, and self-cert artefact upload — under one EUPL-1.2 dependency, one set of upgrade semantics, one set of release notes.

Open-source maintainer who wants the docs site to be a11y-compliant

You maintain an open-source project with a docs site (Docusaurus, Starlight, Astro, mdBook). You did not sign up to also be an accessibility specialist. Install the rule pack, copy the shipped GitHub Action into .github/workflows/, and the next release of your docs ships with a generated EN 301 549 art. 7 statement at /accessibility/, an automated pull request comment on every change, and a public self-cert JSON artefact users can verify. Zero cost, no telemetry, no account.

SaaS founder doing pre-fundraise legal due-diligence

Investors are starting to ask «what is your EAA exposure?» in the data-room checklist. «We do quarterly axe-core scans» is no longer a complete answer — Annex I §I.3 (e-commerce checkout) and §I.4 (banking) demand sector-specific rules the default ruleset does not cover. Run the rule pack against your production URLs, deposit the JSON output in your data-room, and your due-diligence section moves from «pending» to «complete» without hiring a compliance consultant.

License and Commons

Source is licensed under the European Union Public Licence v1.2 (EUPL-1.2). The EUPL is the European Commission's reciprocal-share licence, compatible with GPL-style copyleft and explicitly drafted under EU law — a good fit for accessibility tooling consumed by public-sector buyers under EAA scope.

The rule corpus maps every published expression to a WCAG 2.2 Success Criterion, an EN 301 549 v3.2.1 clause, and an EAA Annex I §. The mapping table lives in the package README and is part of the public Commons.

Get involved

The source repository is live at github.com/ariada-org/ariada. Status: v0.1 release candidate — rule pack, evidence emitter, and reusable GitHub Actions workflow are shipped; PR-comment and penalty-exposure modules are tracked on the public roadmap. Contributions arrive as GitHub pull requests under EUPL-1.2. Issue tracker, contribution guide (CONTRIBUTING.md), code of conduct, and security disclosure policy (SECURITY.md) all live in the repository root.