Use this skill to audit, fix, and document accessibility for TYPO3 websites and Fluid sitepackages. It orchestrates Playwright, axe-core, optional Deque axe MCP, TYPO3 template mapping, manual/HITL checks, CI baselines, and DACH/EAA-aware accessibility statement drafts for WCAG 2.2 AA targets.
Use this skill to audit, fix, and document accessibility for TYPO3 websites and Fluid sitepackages. It orchestrates Playwright, axe-core, optional Deque axe MCP, TYPO3 template mapping, manual/HITL checks, CI baselines, and DACH/EAA-aware accessibility statement drafts for WCAG 2.2 AA targets.
license
MIT
compatibility
Requires Node.js 20+, npm, Playwright browsers. Optional: Docker or npm axe MCP Server plus AXE_API_KEY or AXE_ACCESS_TOKEN. Designed for TYPO3 local DDEV/staging URLs and CI.
Use this skill when the user wants to check, fix, monitor, or document accessibility for a TYPO3 website, TYPO3 sitepackage, Fluid templates, CSS/SCSS, JavaScript UI components, editor-created content, or an Erklärung zur Barrierefreiheit / accessibility statement for Austria, Germany, Switzerland, or a voluntary WCAG target.
Primary goal: move a TYPO3 site toward WCAG 2.2 AA and EN 301 549 readiness with minimal but mandatory human review.
Legal examples now cover Austria, Germany, and Switzerland. The skill can generate statement drafts and audit notes for different legal profiles, but it must not give final legal advice.
Important boundary: never claim complete WCAG conformance from automated scans alone. Automated scans are evidence. Final conformance wording and legal publication require a small human review, especially for alt text, keyboard logic, screen-reader clarity, PDFs, videos, maps, and legal exceptions.
Tool model
Prefer this order:
Local filesystem/search tools for repository understanding.
Playwright plus axe-core for reproducible browser-based scans.
Template/static checks for TYPO3 Fluid, SCSS, JavaScript, RTE and TCA patterns.
Optional Deque axe MCP tools, if available:
analyze: scan the rendered page state.
remediate: request code-level fix guidance.
igt: use only when the user has a Deque subscription/credits and interactive guided testing is explicitly useful.
Code edits in the TYPO3 sitepackage.
Re-test the exact URL/state that failed.
Generate report.md, report.json, open-issues.yml, and a draft accessibility-statement-draft.de.md.
When the local Codex app is used, start with prompts/local-codex-app-prompt.md and fill in project URL, profile, and sitepackage path.
Manual review Chrome helper
This skill includes a no-build Chrome extension for manual WCAG review:
project-template/manual-review/chrome-extension/
Use it when a criterion cannot be safely decided by automation alone. The helper loads the full active WCAG 2.2 Level A + Level AA checkpoint list from:
WCAG 2.2 AA means all active Level A and Level AA success criteria. In this list that is 55 active checkpoints: 31 Level A and 24 Level AA. WCAG 2.2 removed 4.1.1 Parsing; keep it only as a legacy check when a contract or policy still references WCAG 2.0 or 2.1.
Manual helper capabilities:
side-panel checklist for every active WCAG 2.2 A/AA criterion;
page helper scan for headings, landmarks, images, forms, links, focusable elements, small targets, duplicate IDs, iframes and videos;
visual highlights for headings, landmarks, images, forms, links, focusable elements and small targets;
keyboard focus recorder for focus order, visible focus and focus-obscured checks;
structured export as manual review JSON;
structured export as an open-issues.yml fragment;
local Codex prompt for remediation from the exported evidence.
Load it in Chrome via chrome://extensions → Developer mode → Load unpacked → select manual-review/chrome-extension.
After export, merge manual findings into the project source of truth:
npm run a11y:manual:merge
# or for one file:
npm run a11y:manual:merge:file -- .a11y/manual-review/2026-07-05-page-open-issues.yml
Important: the Erklärung zur Barrierefreiheit must be generated from .a11y/open-issues.yml and documented exceptions. Do not free-write it from memory or from a chat summary.
When Deque axe MCP is available, use it as acceleration, not as the single source of truth. The local Playwright/axe suite remains the repeatable project baseline.
Project bootstrap
If the project has no accessibility setup, scaffold from the bundled project-template folder:
./Skills.sh scaffold --project /path/to/typo3-project
cd /path/to/typo3-project
cp .a11y/a11y.config.example.yml .a11y/a11y.config.yml
npm install
npx playwright install --with-deps chromium
npm run a11y:all
For DDEV, use the local HTTPS/HTTP URL from ddev describe, for example:
Use legal.profile in .a11y/a11y.config.yml to choose the statement context. Keep the technical test target as WCAG 2.2 AA unless the client explicitly asks for a lower legal baseline; a stricter internal target is acceptable, but the statement must accurately name the applicable legal reference.
Supported example profiles:
legal:# Austria# profile: "at-public-wzg" # public-sector WZG / EN 301 549 context# profile: "at-private-bafg" # Austrian BaFG / EAA context, if the service is in scope# Germany# profile: "de-public-bgg-bitv" # German public-sector BGG + BITV 2.0 context# profile: "de-private-bfsg" # German BFSG / EAA context, if the product/service is in scope# Switzerland# profile: "ch-public-behig-ech0059" # Swiss federal/public-sector BehiG/BehiV + eCH-0059 context# Voluntary / contractual# profile: "voluntary-wcag22aa" # internal or contractual WCAG 2.2 AA targettargetStandard:"WCAG 2.2 AA"enStandard:"EN 301 549"
Important jurisdiction rules:
Austria public sector: use WZG or relevant state/municipal rules and the österreichische Erklärung-zur-Barrierefreiheit structure.
Austria private sector: use BaFG/EAA only when the offered product/service is in scope; otherwise keep it as voluntary WCAG evidence.
Germany public sector: use BGG + BITV 2.0 on federal projects; for state/municipal projects verify the applicable Landesrecht and monitoring/enforcement body.
Germany private sector: use BFSG/EAA only for covered products/services; do not automatically classify every brochure website as BFSG-relevant.
Switzerland: eCH-0059 v3 is currently WCAG 2.1 AA based; the skill may still test WCAG 2.2 AA as an internal higher target, but the statement should not misrepresent the legal baseline.
Load the matching reference file when legal wording matters:
Never leak internal template paths on production unless the project intentionally allows it.
3. Run automated checks
Run:
npm run a11y:discover
npm run a11y:test:report-only
npm run a11y:report
npm run a11y:statement
Use a11y:test instead of a11y:test:report-only when the team wants CI to fail on new critical/serious findings.
Axe tags should normally include:
wcag2a, wcag2aa, wcag21a, wcag21aa, wcag22aa
Optionally include best-practice as advisory, not as a WCAG gate.
4. Fix loop
For every finding:
Identify URL and state.
Identify selector and HTML snippet.
Map to closest data-a11y-component / data-a11y-template marker.
Search relevant Fluid/SCSS/JS/TCA/RTE files.
Prefer native HTML over ARIA.
Patch the source, not only the rendered HTML.
Re-run the failing URL/state.
Update open issue status.
Do not suppress a rule unless there is a documented reason, owner, expiry date, and link to a ticket.
5. Manual/HITL gate
Use the Chrome helper and the base checkpoint list for page samples and human-only criteria. Export findings and merge them into .a11y/open-issues.yml before generating the statement.
Keep human review small, but mandatory for:
meaningful image alternative text;
keyboard interaction and logical tab/focus order;
Screenreader smoke test with VoiceOver/NVDA;
PDF, video, map, social embed and third-party content exceptions;
legal status wording: fully/partially/not compliant;
publication of the Erklärung zur Barrierefreiheit.
