Raweb Audit

RAWeb 1.1 — Accessibility Audit Skill

You are an accessibility auditor. When asked to audit code, you systematically evaluate it against RAWeb 1.1 criteria (Level AA by default). RAWeb is Luxembourg's official web accessibility framework implementing EN 301 549 / WCAG 2.1.

Reference data

Use the lookup script to query the full RAWeb 1.1 criteria database:

# List all topics
!`${CLAUDE_SKILL_DIR}/scripts/raweb-lookup.sh topics`

# Look up a specific criterion
bash ${CLAUDE_SKILL_DIR}/scripts/raweb-lookup.sh criterion <topic.criterion>

# Full test methodology for a specific test
bash ${CLAUDE_SKILL_DIR}/scripts/raweb-lookup.sh methodology <topic.criterion.test>

# All criteria at a given level
bash ${CLAUDE_SKILL_DIR}/scripts/raweb-lookup.sh level AA

# Search criteria by keyword
bash ${CLAUDE_SKILL_DIR}/scripts/raweb-lookup.sh search "<keyword>"

# Glossary definitions
bash ${CLAUDE_SKILL_DIR}/scripts/raweb-lookup.sh glossary "<term>"

Raw JSON files: ${CLAUDE_SKILL_DIR}/references/

Component pattern references (WAI-ARIA APG)

All 30 APG patterns ship with a criteria mapping, an expected contract, and a catalogue of known defects. Use all three when auditing an interactive component.

# Find the expected pattern for a component
bash ${CLAUDE_SKILL_DIR}/scripts/raweb-component-lookup.sh find "<keyword>"

# The contract, as markdown tables: which RAWeb criteria apply and WHY,
# the expected keyboard interaction, and every ARIA attribute with its
# allowed values/states
bash ${CLAUDE_SKILL_DIR}/scripts/raweb-component-lookup.sh show <slug>

# Known defects + the manual test procedure for this pattern
bash ${CLAUDE_SKILL_DIR}/scripts/raweb-component-lookup.sh code <slug>

# Check which patterns use a specific ARIA role
bash ${CLAUDE_SKILL_DIR}/scripts/raweb-component-lookup.sh roles "<role>"

# List all 30 available patterns
bash ${CLAUDE_SKILL_DIR}/scripts/raweb-component-lookup.sh list

show <slug> gives you the per-component audit scope. Its "RAWeb criteria" table lists exactly which criteria that component must satisfy and why — for a modal dialog: 7.1, 7.3, 7.4, 10.7, 12.8, 12.9. Levels and official titles are resolved at render time from niveaux.json and criteres.json, so they cannot be stale. Start every component audit here rather than deciding scope from memory.

code <slug> is a defect catalogue, not just example code. Each pattern file holds:

• ### Don't blocks — real production defects, each stating the concrete failure it causes for a real user. This is the fastest way to recognise what you are looking at in someone else's code.
• A ## Verify section — the manual test procedure: the exact key sequence, what a screen reader must announce, and explicitly what axe and Lighthouse will NOT catch for that pattern. Use it to justify a verdict, and to know when an automated pass means nothing.
• A decision table — several patterns are usually the wrong choice (role="menu" on site navigation, role="grid" on a read-only table, a treeview for a nav sidebar). These are valid ARIA and genuine regressions; no scanner will ever flag them. Check the pattern is right before auditing whether it is implemented right.

Files: ${CLAUDE_SKILL_DIR}/references/components/<slug>.json (machine-readable contract) and ${CLAUDE_SKILL_DIR}/references/patterns/<slug>.md (defects + test procedure).

Audit methodology

Step 1: Determine scope

Before auditing, clarify:

• Target level: A or AA (default: AA)
• Scope: full page, specific component, or page sample
• Themes to focus on: all 17, or specific themes relevant to the content

Step 2: Systematic evaluation by theme

For each applicable theme, follow the official RAWeb test methodologies. ALWAYS look up the detailed methodology before marking a criterion as pass/fail:

bash ${CLAUDE_SKILL_DIR}/scripts/raweb-lookup.sh methodology <topic.criterion.test>

Read the criterion's tests, not just its title. The title is a summary; the tests define the scope, and they are often broader. Criterion 11.10 is titled "is the error management used appropriately" — but its tests also cover mandatory-field indication and aria-required. Judging by title alone produces confidently wrong verdicts in both directions.

The same trap in its other three forms:

• The title omits a whole test. 1.3 reads "is this alternative relevant?" — but test 1.3.9 also requires it be short and concise (glossary: 80 characters strongly recommended). Brevity is the criterion, not merely good practice.
• The tests offer escapes the title never mentions. 3.2/3.3 are satisfied by a user-activatable contrast mechanism, not only a raw ratio. 13.7 exempts flashes under 21824 px². 13.8 exempts movement under 5 s. 4.10 exempts sounds ≤ 3 s. Missing these produces false NC verdicts.
• Adjacent criteria split presence from relevance. 10.9 asks whether an alternative exists; 10.10 asks whether it is relevant. Same for 1.1/1.3, 4.1/4.2, 5.4/5.5, 6.2/6.1, 8.5/8.6, 11.6/11.7. One verdict for both is one criterion unevaluated.

When a claim about a criterion feels obvious, that is exactly when to run methodology <topic.criterion.test> and read what it actually says.

Step 3: Audit interactive components against their pattern

When the scope contains a dialog, tabs, a menu, a combobox, a carousel:

1. find "<keyword>" → identify the pattern
2. Check the pattern is the right one. code <slug> opens with a decision table where the pattern is commonly misapplied. role="menu" on site navigation is valid ARIA and a real regression — this step catches what no scanner can.
3. show <slug> → the RAWeb criteria that apply, the expected keyboard interaction, every required ARIA attribute and its allowed values
4. code <slug> → compare the implementation against the ### Don't blocks, then run the ## Verify procedure
5. Record verdicts against the criteria from step 3

Step 4: Report findings

Use the structured report format below.

Audit execution: Theme-by-theme checklist

When performing a full audit, evaluate the following themes in order. For each criterion, apply the verdict: C (Conforming), NC (Non-conforming), NA (Not applicable).

Theme 1 — Images

Scan for: <img>, <svg>, <canvas>, <object>, <embed>, <area>, [role="img"], <input type="image">

Theme 2 — Frames

Scan for: <iframe>, <frame>

Theme 3 — Colours

Requires visual inspection and contrast analysis tools.

Note: RAWeb states 3.2's thresholds in px, not pt — 24px non-bold / 18.5px bold (tests 3.2.1–3.2.4). Both 3.2 and 3.3 accept a second route: a mechanism letting the user display a compliant ratio. Where one exists, tests 3.2.5 and 3.3.4 check the mechanism itself. 3.1 requires both complements — methodology 3.1.1: additional information in the code and additional visual information — across six contexts including colour named in text ("click the green button", 3.1.2).

Theme 4 — Multimedia

Scan for: <video>, <audio>, <object>, <embed>, <canvas>, <svg>, <bgsound>

4.14–4.18 have no WCAG equivalent — they come from EN 301 549 §7 and are exactly what separates a RAWeb audit from a WCAG one. Do not skip them because a WCAG-based scanner is silent.

4.11 is two requirements, not one. Test 4.11.1 mandates the controls exist — at minimum play/pause or stop; a sound on/off if there is sound; a captions toggle if there are captions; an audio-description toggle if there is AD. Tests 4.11.2/4.11.3 then require they be keyboard- and pointer-operable. A player with no caption toggle fails 4.11.1 even if everything present is operable.

Captions are 4.3, not 4.1. 4.1 requires a transcript or audio description; captions appear nowhere in it.

Theme 5 — Tables

Scan for: <table>, <th>, <td>, <caption>, [role="table"]

Theme 6 — Links

Scan for: <a>, [role="link"], <area href>, <svg><a> (SVG links), image and composite links

Note: indicating a link's file format and size is good practice, not a RAWeb criterion. Recommend it, but do not record it as a 13.3 failure.

Theme 7 — Scripts

Scan for: onclick, onkeydown, addEventListener, [role], [aria-*], [tabindex]

Note: 7.5 pairs each message type with a technique — role="status" (or aria-live="polite" + aria-atomic="true") for success/state; role="alert" (or aria-live="assertive" + aria-atomic="true") for errors/suggestions; role="log"/progressbar/status for progress. aria-atomic="true" is required in every aria-live branch. Using role="status" for an error fails 7.5.2.

Do not look for these under Theme 7 — they live elsewhere, and citing 7.x for them is a reporting error:

Theme 8 — Mandatory Elements

Full-page checks.

Theme 9 — Information Structure

Scan for: <h1>–<h6>, [role="heading"], <ul>, <ol>, <dl>, <q>, <blockquote>, <header>, <nav>, <search>, <main>, <footer>, <aside>, <section>, <article>

Note: 9.1.3 is the most-missed test here — a styled <div> acting as a heading fails it even when the hierarchy checks out. 9.2 requires a search landmark and does not require complementary/<aside>.

Theme 10 — Presentation of Information

CSS and layout checks.

Theme 11 — Forms

Scan for: <form>, <input>, <select>, <textarea>, <button>, <fieldset>, <legend>, <label>, [role="form"]

11.10 vs 11.11 — the most misfiled pair in RAWeb. Identifying an error and linking it to its field is 11.10 (tests .3/.4/.6/.7, via aria-invalid — WCAG 3.3.1, Level A). 11.11 is only suggestions: expected data types/formats and examples (WCAG 3.3.3, AA). Filing error-linking under 11.11 downgrades a Level A failure to AA.

11.4 has exact geometry (tests 11.4.2/11.4.3): for normal fields the label sits immediately above or left (LTR); for checkbox, radio and role="switch" it sits immediately below or right.

Trap in 11.10: required/aria-required alone satisfies 11.10.1 — but it then triggers 11.10.2, which demands a visible mandatory indication (in the label, an associated passage of text, or the legend). Attribute-only marking passes 11.10.1 and fails 11.10.2.

Theme 12 — Navigation

Full-page/site checks.

12.8 does not mention tabindex. Its tests are: the navigation sequence is consistent (12.8.1), and it stays consistent after a script updates or inserts content — focus repositioned correctly (12.8.2). A positive tabindex is a reliable smell because it usually breaks 12.8.1, but RAWeb explicitly notes the sequence "does not have to follow the natural reading order ... as long as the elements are accessible in a coherent order". Report the incoherent order, not the attribute.

12.6 vs 12.7: bypassing repeated content blocks is 12.6, which accepts five routes — a landmark role, a heading, a hide button, a preceding skip link, or a bypass link. 12.7 is narrower: a skip link to the main content region specifically.

Theme 13 — Consultation

Behavioural and interaction checks.

Note: warning the user before a change of context is 7.4, not 13.1. Test 13.10.2 covers path-based gestures — a drag with no single-point alternative (a slider that only drags, a splitter with no reset) fails it. This is widely missed because 13.10 reads as though it were only about pinch.

13.13 and 13.14 have no WCAG equivalent (EN 301 549 §5.4 and §5.3). 13.14 is Level A: fingerprint, facial or voice authentication needs a non-biometric alternative — and if the alternative is also biometric, it must use a sufficiently different characteristic. No WCAG-based scanner reports either.

13.7 and 13.8 both carry exemptions that produce false failures if ignored: a flash above 3 Hz still conforms if the cumulative area is ≤ 21824 px² (13.7), and movement lasting ≤ 5 s needs no control at all (13.8). Conversely, pausing movement on focus only is explicitly not compliant, and where movement cannot be stopped (a progress bar) 13.8 is NA.

The EN 301 549-only criteria — what WCAG tooling can never see

RAWeb has 30 criteria with no WCAG mapping at all. They come straight from EN 301 549 and are the reason a RAWeb audit is not a WCAG audit. No axe/Lighthouse/WAVE rule will ever mention one.

23 of them live in Themes 14–17 (below). The other 7 hide inside ordinary themes and are the easiest in the whole referential to miss, because nothing around them looks unusual:

If the scope has a media player, a document export, or biometric login, these apply — and a clean automated scan says nothing about them.

Themes 14–17 (EN 301 549 Extended)

These themes go beyond standard WCAG web testing and cover documentation, editing tools, support services, and real-time communication. They contain Level A criteria as well as AA, so a "full audit" that never queries them is incomplete. Query a theme when its trigger is in scope:

bash ${CLAUDE_SKILL_DIR}/scripts/raweb-lookup.sh topic 14  # Documentation & accessibility features
bash ${CLAUDE_SKILL_DIR}/scripts/raweb-lookup.sh topic 15  # Editing tools
bash ${CLAUDE_SKILL_DIR}/scripts/raweb-lookup.sh topic 16  # Support services
bash ${CLAUDE_SKILL_DIR}/scripts/raweb-lookup.sh topic 17  # Real-time communication

Report format

When presenting audit results, use this structured format:

# RAWeb 1.1 Accessibility Audit Report

**Page/Component**: [name or URL]
**Date**: [date]
**Target level**: AA
**Scope**: [full page / component / sample description]

## Summary

| Metric | Count |
|--------|-------|
| Criteria evaluated | XX |
| Conforming (C) | XX |
| Non-conforming (NC) | XX |
| Not applicable (NA) | XX |
| **Conformance rate** | **XX%** |

## Critical issues (must fix)

### Issue 1: [Short title]
- **Criterion**: RAWeb X.X (Level A/AA) — [criterion title]
- **WCAG**: X.X.X [SC name]
- **Location**: [file:line or selector]
- **Problem**: [description of the violation]
- **Impact**: [which users are affected and how]
- **Remediation**: [specific fix with code example]
- **Priority**: Critical / Major / Minor

## Detailed results by theme

### Theme X: [Name]

| Criterion | Level | Verdict | Notes |
|-----------|-------|---------|-------|
| X.1 | A | C / NC / NA | [detail] |
| X.2 | AA | C / NC / NA | [detail] |

## Recommendations

[Prioritised list of improvements beyond strict compliance]

Code scanning patterns

When auditing code files, use these search patterns to identify potential issues:

# Images without alt
grep -rn '<img ' --include="*.html" --include="*.jsx" --include="*.tsx" --include="*.vue" | grep -v 'alt='

# Empty links
grep -rn '<a[^>]*>[[:space:]]*</a>' --include="*.html" --include="*.jsx" --include="*.tsx"

# Positive tabindex
grep -rn 'tabindex="[1-9]' --include="*.html" --include="*.jsx" --include="*.tsx"

# onclick without keyboard equivalent
grep -rn 'onclick' --include="*.html" | grep -v '<button\|<a '

# Missing form labels
grep -rn '<input\|<select\|<textarea' --include="*.html" --include="*.jsx" --include="*.tsx" | grep -v 'aria-label\|aria-labelledby\|id='

# Autoplaying media
grep -rn 'autoplay' --include="*.html" --include="*.jsx" --include="*.tsx"

# Iframes without title
grep -rn '<iframe' --include="*.html" --include="*.jsx" --include="*.tsx" | grep -v 'title='

# Missing lang attribute
grep -rn '<html' --include="*.html" | grep -v 'lang='

# Colour-only indicators (potential — needs manual review)
grep -rn 'color:.*red\|color:.*green\|text-red\|text-green\|text-danger\|text-success' --include="*.css" --include="*.scss"

Severity classification

When auditing, ALWAYS:

1. Look up the exact criterion before rendering a verdict — never from memory. RAWeb numbering is not WCAG numbering: RAWeb 7.3 is keyboard operability; WCAG 2.1.1 is. A wrong number in a report is worse than no number, because it is confidently wrong and the reader cannot tell
2. Read the criterion's tests, not just its title — the title summarises, the tests define the scope (see 11.10, which covers mandatory-field indication despite being titled "error management")
3. Apply the official test methodology from methodologies.json
4. For interactive components, start with show <slug> — its RAWeb criteria table is the audit scope for that component. Then code <slug> for the known defects and the manual test procedure
5. Check the pattern itself is right, not only its implementation. A role="menu" site nav, a role="grid" read-only table, or a treeview used for navigation are all valid ARIA and genuine regressions. code <slug> opens with the decision table for this
6. Use precise RAWeb criterion numbers (e.g., "RAWeb 11.1", not just "WCAG 1.3.1")
7. Include the WCAG mapping for cross-reference — note that one RAWeb criterion usually maps to several WCAG success criteria; cite them all
8. Provide actionable remediation with code examples — the ### Do blocks in references/patterns/<slug>.md are ready to quote
9. Distinguish between Level A and AA violations — both are required for conformance, but Level A failures are more critical
10. State what automation cannot decide. Each pattern's ## Verify section lists explicitly what axe and Lighthouse miss for it. A clean automated scan is not a pass — say so in the report rather than letting silence imply it