anysurfer-audit

name: anysurfer-audit description: "Evaluate web components and Figma designs against the AnySurfer methodology, WCAG 2.2 AA, and Belgian accessibility law (EAA, Royal Decree 2019). Use this skill ONLY when AnySurfer is explicitly mentioned, when the user asks about the AnySurfer label, Belgian accessibility compliance, or EAA requirements. Do NOT trigger for generic accessibility questions, check a11y, or is this accessible — those are handled by the general accessibility-review skill. Trigger phrases: AnySurfer, AnySurfer label, Belgian accessibility, EAA compliance, does this meet AnySurfer, audit for AnySurfer."

AnySurfer Audit Skill

Evaluate digital components and designs against the AnySurfer methodology — the Belgian quality label for accessible websites, managed by Blindenzorg Licht en Liefde.

AnySurfer is based on WCAG 2.2, with level AA as the standard target and level A as the minimum threshold for the label. For Belgian public sector organisations, WCAG 2.1 AA is legally required (Royal Decree 05/09/2019 + Flemish Governance Decree 2018). From 28 June 2025, the European Accessibility Act (EAA) also applies to the private sector.

Input types

If Penpot MCP is connected: use tool_search for "penpot" to inspect designs directly for colour values, typography, and component structure. If Figma MCP is connected: use tool_search for "figma" to access get_design_context, get_variable_defs, and get_metadata for the same purpose. Figma MCP is available in the Claude connector registry but has not been formally tested against this skill — apply the same inspection approach as Penpot and report any gaps via GitHub.

AnySurfer evaluation framework

Conformance levels (per AnySurfer label)

Audit checklist per WCAG principle

1. Perceivable

2. Operable

3. Understandable

4. Robust

AnySurfer-specific considerations

Beyond WCAG, AnySurfer also checks:

• PDF accessibility: Tagged PDFs, readable form fields, alternative text in documents
• Multilingualism: Correct lang attributes for NL/FR/EN language switches (relevant for Belgian government)
• CMS editor management: Editors can publish accessible content (alt text, headings)
• Mobile accessibility: Responsive design, adequate touch target sizes
• Video subtitling: Informational programmes fully subtitled

Evaluation approach per input type

For HTML/CSS/JS components

Check in order:

1. Semantics: Correct HTML elements (<button> vs <div>, <nav>, heading structure)
2. ARIA: Roles, names, states complete and correct
3. Keyboard: Focus, tab order, Enter/Space/Escape behaviour
4. Contrast: Calculate ratios for text and UI elements
5. Responsive: Reflow at 320px, touch target sizes

For Figma/Penpot designs

Check in order:

1. Colour contrast: Extract hex values, calculate ratios
   • For solid colours: calculate ratio directly against the background
   • For gradient text (2 stops): check both endpoint stops — the lightest stop is the worst case
   • For gradient text (3+ stops): check every stop individually — a mid-stop may be lighter than both endpoints and become the actual worst case
   • For gradient backgrounds (element on top): sample the background colour at the exact position behind the element, then calculate against that single value (not the gradient endpoints)
   • For radial gradients: worst-case position depends on where the element sits relative to the gradient centre — sample accordingly
2. Typography: Font size, weight → impact on contrast threshold
3. Component names/annotations: Are ARIA labels visible in the design?
4. Focus states: Are hover and focus states designed?
5. Touch target sizes: Are buttons and links at least 24×24px (WCAG) or 44×44px (AnySurfer recommendation)?
6. Information density: Is colour used as the only distinguishing feature?

If Penpot MCP is connected: use Penpot:high_level_overview then Penpot:penpot_api_info to retrieve component data for direct inspection.

Output format

## AnySurfer Audit: [Component/page name]
**Standard:** WCAG 2.2 AA (AnySurfer methodology) | **Date:** [date]
**Input type:** [HTML / Figma / URL / Description]

### Summary
**Findings:** [X] | 🔴 Critical: [X] | 🟠 Important: [X] | 🟡 Minor: [X] | ✅ Passed: [X]

**AnySurfer label status (estimate):**
- Level A: [Passed / Failed]
- Level AA: [Passed / Failed / Partial]

---

### 🔴 Critical findings (Level A — blocks label)

| # | Finding | WCAG criterion | Element | Recommendation |
|---|---------|----------------|---------|----------------|
| 1 | [Description] | [1.4.3 Contrast] | [selector/component] | [Concrete fix] |

### 🟠 Important findings (Level AA — required for full label)

| # | Finding | WCAG criterion | Element | Recommendation |
|---|---------|----------------|---------|----------------|

### 🟡 Minor findings / improvements

| # | Finding | WCAG criterion | Element | Recommendation |
|---|---------|----------------|---------|----------------|

### ✅ Correctly implemented

- [Criterion]: [What is correct]

---

### Colour contrast check
| Element | Foreground | Background | Ratio | Required | Result |
|---------|-----------|------------|-------|----------|--------|
| [Body text] | #333 | #fff | 12.6:1 | 4.5:1 | ✅ |

### Keyboard navigation
| Element | Tab order | Enter/Space | Escape | Arrow keys |
|---------|-----------|-------------|--------|------------|

### Screen reader — predicted output
> ⚠️ **Disclaimer:** Claude cannot run a screen reader. The following is a structural prediction based on static analysis of HTML, ARIA attributes, and role assignments. It reflects what a screen reader such as NVDA or VoiceOver would *likely* announce, but cannot substitute for real testing with assistive technology. AnySurfer certification always includes human testing with an actual screen reader.

| Element | Predicted announcement | Issue |
|---------|----------------------|-------|
| [e.g. icon button] | [e.g. "button" — no name] | [Missing aria-label or visible label] |
| [e.g. error message] | [e.g. silence] | [Not in aria-live region — never read aloud] |
| [e.g. decorative image] | [e.g. filename.png] | [Missing alt="" — filename announced instead] |

### Priority fixes
1. 🔴 **[Critical fix]** — Blocks AnySurfer level A
2. 🟠 **[AA fix]** — Required for full label
3. 🟡 **[Improvement]** — Best practice

### Next steps towards the AnySurfer label
- [ ] Resolve critical findings (level A)
- [ ] Resolve AA findings
- [ ] Repeat audit (AnySurfer requires a minimum of 2 test rounds)
- [ ] Publish accessibility statement

Common JS-driven accessibility fix patterns

When a finding involves a JavaScript-driven component, point the user to the relevant pattern below. Do not generate implementation code in the audit report — the fix must be applied in context by someone who understands the specific architecture.

For complex patterns (modals, carousels, custom widgets), refer to the ARIA Authoring Practices Guide for the canonical implementation pattern.

Reference files

Read when relevant:

• references/wcag22-quick-ref.md — Full WCAG 2.2 success criteria with explanations
• references/anysurfer-context.md — Belgian legal context, EAA, label process

Tips

1. Start with contrast and keyboard — These are the most common and impactful issues.
2. Level A first — Without level A, the AnySurfer label cannot be awarded.
3. Design audit ≠ dev audit — A Figma audit checks intent; an HTML audit checks implementation. Both are needed.
4. AnySurfer always does at least 2 test rounds — Initial audit + retest after fixes.
5. EAA deadline: New products/services in the private sector must comply from 28 June 2025.