@salesforce/afv-skills 1.55.0 → 1.56.0

package/skills/dx-org-analyze/scripts/introspect_org.py

@@ -24,7 +24,7 @@ PERM_CATEGORIES = [
     ("Einstein/AI",  ["einstein", "ai", "predict", "ml", "copilot", "agent"]),
     ("Service",      ["service", "case", "knowledge", "chat", "messaging", "omni", "entitlement"]),
     ("Data",         ["data", "record", "report", "dashboard", "analytics", "tableau"]),
-    ("Trialforce",   ["trial", "trialforce", "tso", "tmo", "signup", "template", "edition"]),
+    ("Trialforce",   ["trialforce", "tso", "tmo", "signup", "template"]),
     ("Sales",        ["sales", "opportunity", "lead", "forecast", "quote", "contract"]),
     ("Work/HR",      ["work", "hr", "employee", "shift", "wellness"]),
 ]
@@ -32,8 +32,8 @@ PERM_CATEGORIES = [
 VALUE_CATEGORIES = [
     ("Identity",       ["name", "edition", "org", "domain", "id", "type", "instance", "locale"]),
     ("Storage",        ["storage", "file", "size", "space", "quota"]),
-    ("Feature Limits", ["max", "limit", "count", "num", "enable"]),
-    ("API",            ["api", "call", "request", "bandwidth"]),
+    ("API",            ["api", "request", "daily", "hourly", "concurrent", "streaming", "bulk"]),
+    ("Feature Limits", ["custom", "rule", "flow", "process", "workflow", "approval", "limit", "max"]),
 ]
 
 
@@ -84,23 +84,10 @@ def analyze_metadata(data):
     for mtype, items in sorted(components.items()):
         org_native = [c for c in items if not c.get("namespace")]
         namespaced = [c for c in items if c.get("namespace")]
-        org_native_names = sorted(
-            c.get("fullName") or c.get("name", "") for c in org_native
-        )
-        namespaced_by_ns = {}
-        for c in namespaced:
-            ns = c.get("namespace", "unknown")
-            namespaced_by_ns.setdefault(ns, []).append(
-                c.get("fullName") or c.get("name", "")
-            )
-        for ns in namespaced_by_ns:
-            namespaced_by_ns[ns] = sorted(namespaced_by_ns[ns])
         by_type[mtype] = {
             "total": len(items),
             "org_native": len(org_native),
             "namespaced": len(namespaced),
-            "org_native_names": org_native_names,
-            "namespaced_by_ns": namespaced_by_ns,
         }
         total += len(org_native)
         namespaced_total += len(namespaced)
@@ -246,24 +233,6 @@ def render_markdown(data, meta, perms, vals, pkgs, lics, sys_perms, deep, label)
     lines.append(f"| **Total** | **{meta['total_org_native']}** | **{meta['total_namespaced']}** | **{meta['total_org_native'] + meta['total_namespaced']}** |")
     lines.append("")
 
-    # Detailed metadata listing
-    lines.append("---\n")
-    lines.append("## Metadata Components by Type\n")
-    for mtype, counts in sorted(meta["by_type"].items()):
-        if counts["total"] == 0:
-            continue
-        lines.append(f"#### {mtype} ({counts['org_native']} org-native, {counts['namespaced']} namespaced)\n")
-        if counts["org_native_names"]:
-            lines.append(f"**Org-native ({counts['org_native']}):** " +
-                         ", ".join(f"`{n}`" for n in counts["org_native_names"]))
-            lines.append("")
-        if counts["namespaced_by_ns"]:
-            for ns, names in sorted(counts["namespaced_by_ns"].items()):
-                lines.append(f"**Namespaced — `{ns}` ({len(names)}):** " +
-                             ", ".join(f"`{n}`" for n in names))
-                lines.append("")
-    lines.append("")
-
     # Installed packages
     lines.append("---\n")
     lines.append("## Installed Packages\n")
@@ -314,12 +283,7 @@ def render_markdown(data, meta, perms, vals, pkgs, lics, sys_perms, deep, label)
                     lines.append("| " + " | ".join(keys) + " |")
                     lines.append("| " + " | ".join(["---"] * len(keys)) + " |")
                     for item in info["items"]:
-                        vals_row = []
-                        for k in keys:
-                            v = item.get(k, "")
-                            if k in ("AllowedLicenses", "TotalLicenses") and v == -1:
-                                v = "-1 (unlimited)"
-                            vals_row.append(str(v))
+                        vals_row = [str(item.get(k, "")) for k in keys]
                         lines.append("| " + " | ".join(vals_row) + " |")
             else:
                 for item in info["items"]:

package/skills/dx-org-manage/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: dx-org-manage
-description: "INVOKE this skill to execute Salesforce org operations: create scratch orgs, list/display/resume/delete scratch orgs, create org snapshots, open orgs in browser. This skill EXECUTES operations immediately - it does NOT generate scripts or code files. ALWAYS invoke this skill (do not execute SF CLI commands directly) when user requests to: create a scratch org (from edition, definition file (.json), snapshot, or org shape), list/display/resume/delete scratch orgs, create an org snapshot, or open a Salesforce org. Trigger phrases include: 'create a snapshot', 'take a snapshot', 'create scratch org', 'new scratch org', 'spin up an org', 'create 5 scratch orgs', 'create org from snapshot', 'scratch-def.json', 'project-scratch-def.json', 'list scratch orgs', 'display org', 'delete scratch org', 'resume scratch org', 'open my Salesforce org', 'open org in browser'. Do NOT use for switching default org (use dx-org-switch) or deploying metadata (use platform-metadata-deploy)."
+description: "Use to EXECUTE Salesforce org operations immediately via the sf CLI (this skill runs them, it does NOT generate scripts): create scratch orgs (from edition, definition file, snapshot, or org shape), list/display/resume/delete scratch orgs, open orgs in browser. Trigger: 'create scratch org', 'create org from snapshot', 'delete scratch org', 'open my org'. Do NOT use for switching the default org (use dx-org-switch), deploying metadata (use platform-metadata-deploy), or creating/checking/listing/deleting org snapshots (use dx-org-snapshot-manage)."
 metadata:
-  version: "1.2"
+  version: "1.3"
   domains: ["Developer Experience"]
   minApiVersion: "60.0"
   relatedSkills:
@@ -19,7 +19,7 @@ metadata:
 
 **Tool constraint:** Use the Bash tool for all `sf` CLI commands. Always include `--json` for structured output. Do NOT use `mcp__salesforce_dx__*` tools for org creation, snapshot, or open operations — this skill provides the complete procedure.
 
-**Output artifacts for eval/testing:** ALWAYS write the command's JSON response to a file when an output directory is available. Do NOT ask the user what file to write — this skill defines the filenames. After executing the command: (1) if the user specified an output path (e.g. "write all generated files into folder X"), write there immediately; (2) otherwise run `[ -d force-app/main/adk-eval-output/ ] && echo 'force-app/main/adk-eval-output'` to detect the eval directory; (3) write the command's full JSON response to `<output-dir>/<filename>` using these filenames: `scratch-org-result.json` for org creation (for a batch of N orgs, `scratch-org-result-1.json` … `scratch-org-result-N.json`), `scratch-org-list-result.json` for list, `org-display-result.json` for display, `scratch-org-resume-result.json` for resume, `scratch-org-delete-result.json` for delete, or `snapshot-result.json` for snapshot creation. This is the generated output — write it without asking. (Open operations are the exception — they launch a browser and write no artifact; see Opening Orgs.)
+**Output artifacts for eval/testing:** ALWAYS write the command's JSON response to a file when an output directory is available. Do NOT ask the user what file to write — this skill defines the filenames. After executing the command: (1) if the user specified an output path (e.g. "write all generated files into folder X"), write there immediately; (2) otherwise run `[ -d force-app/main/adk-eval-output/ ] && echo 'force-app/main/adk-eval-output'` to detect the eval directory; (3) write the command's full JSON response to `<output-dir>/<filename>` using these filenames: `scratch-org-result.json` for org creation (for a batch of N orgs, `scratch-org-result-1.json` … `scratch-org-result-N.json`), `scratch-org-list-result.json` for list, `org-display-result.json` for display, `scratch-org-resume-result.json` for resume, or `scratch-org-delete-result.json` for delete. This is the generated output — write it without asking. (Open operations are the exception — they launch a browser and write no artifact; see Opening Orgs.)
 
 ---
 
@@ -118,7 +118,7 @@ Write the extracted org-list entry (the resolved org record), NOT the raw creati
 - For the complete creation workflow (AUTO MODE, STATE A/B, batch, definition-file authoring) → load `references/scratch-org-create.md`; for list/display/resume/delete → load `references/scratch-org-operations.md`
 - For available features, settings, and definition file structure → load `references/definition_file_options.md`
 - For edition selection guidance and comparison → load `references/edition_types.md`
-- For snapshot workflow and post-creation usage → load `references/snapshot_usage.md`
+- To create/check/list/delete the snapshot itself before referencing it here → use the `dx-org-snapshot-manage` skill
 
 ---
 
@@ -182,47 +182,6 @@ sf org delete scratch --target-org <alias> --no-prompt --json
 
 ---
 
-## Creating Snapshots
-
-**REQUIRED steps — execute in order:**
-
-**Step 1. Get inputs:**
-- Source org: scratch org ID or alias (from user)
-- Snapshot name: unique name (from user)
-- Description: optional (from user)
-
-**Step 2. Determine Dev Hub:** resolve to a concrete value and pass it explicitly via `--target-dev-hub` in Step 3 (same order as scratch-org creation — never guess a name):
-1. A Dev Hub the user named → use it verbatim.
-2. Else the default: non-empty `result[0].value` from `sf config get target-dev-hub --json`.
-3. Else the single authenticated Dev Hub — run **this exact all-bucket command** (do NOT hand-write a single-bucket filter, which misses hubs that land in `devHubs`/`nonScratchOrgs`):
-   ```bash
-   sf org list --json | jq -r '[.result.devHubs[]?, .result.nonScratchOrgs[]?, .result.other[]?, .result.sandboxes[]?, .result.scratchOrgs[]?] | map(select(.isDevHub == true).username) | unique | .[]'
-   ```
-   Exactly one → use it. Zero → **do NOT run the snapshot command at all**; advise `sf org login web --set-default-dev-hub` and stop. Two or more → ask the user which.
-
-Never fabricate a placeholder alias (e.g. `eval-target`, `my-dev-hub`) and never run the command with no `--target-dev-hub` flag — the CLI rejects a bad name with `NotADevHubError` and a missing default with `NoDefaultDevHubError`. If no hub resolves, that is a hard stop, not a value to guess.
-
-**Step 3. Execute:**
-```bash
-sf org create snapshot --source-org <orgId-or-alias> --name <SnapshotName> --target-dev-hub <devHub> --json
-```
-
-With description:
-```bash
-sf org create snapshot --source-org <orgId-or-alias> --name <SnapshotName> --description "<desc>" --target-dev-hub <devHub> --json
-```
-
-**Step 4. Report result:** Returns JSON with SnapshotId and Status. If an output directory is available (per the output artifacts rule above), write the JSON response to `<output-dir>/snapshot-result.json`.
-
-**Error handling:** surface the CLI's own error unchanged. For example:
-- "Snapshot name already exists" → use a different unique name
-
-**When you need more detail:**
-- For complete snapshot creation workflow and flag reference → load `references/creating-snapshot.md`
-- For CLI flag reference → load `references/cli_flags.md`
-
----
-
 ## Opening Orgs
 
 **REQUIRED steps — execute in order:**
@@ -264,11 +223,10 @@ Load these reference files for detailed guidance:
 | `references/scratch-org-operations.md` | Operating on existing orgs: list, display, resume, delete — plus shared lifecycle rules and troubleshooting |
 | `references/definition_file_options.md` | User needs to configure org features, settings, or advanced definition file options beyond basic org creation |
 | `references/edition_types.md` | User asks which edition to choose or needs to understand edition differences |
-| `references/snapshot_usage.md` | User wants to use snapshots in definition files or needs post-snapshot workflow guidance |
-| `references/cli_flags.md` | User needs complete snapshot CLI flag reference |
-| `references/creating-snapshot.md` | Troubleshooting snapshot creation failures or need detailed snapshot workflow |
 | `references/opening-org.md` | User needs to navigate to specific setup paths, open metadata files, or use advanced open flags |
 
+To create/check/list/delete a snapshot itself (rather than just consuming one), use the `dx-org-snapshot-manage` skill.
+
 ## Example Files
 
 Example command outputs for testing and troubleshooting:
@@ -285,5 +243,3 @@ Example command outputs for testing and troubleshooting:
 | `examples/scratch-orgs/display_output.json` | `sf org display --json` output (wrapped, tokens redacted) |
 | `examples/scratch-orgs/resume_output.json` | `sf org resume scratch --json` output (completed org) |
 | `examples/scratch-orgs/delete_output.json` | `sf org delete scratch --json` output |
-| `examples/snapshots/success_output.json` | Successful snapshot creation |
-| `examples/snapshots/error_output.json` | Common snapshot error scenario (duplicate name) |

package/skills/dx-org-manage/examples/README.md

@@ -1,20 +1,21 @@
 # Examples Directory
 
-This directory contains example outputs for the three workflows supported by the `dx-org-manage` skill.
+This directory contains example outputs for the workflows supported by the `dx-org-manage` skill.
+
+Snapshot lifecycle examples (create/get/list/delete the snapshot itself) live in the `dx-org-snapshot-manage` skill's `examples/` directory — this skill only *consumes* an existing snapshot (see `success_snapshot.json` below).
 
 ## Structure
 
 ```text
 examples/
 ├── README.md                          # This file
-├── scratch-orgs/                      # Scratch org creation examples
-│   ├── success_definition_file.json
-│   ├── success_edition.json
-│   ├── error_no_devhub.json
-│   └── error_timeout.json
-└── snapshots/                         # Snapshot creation examples
-    ├── success_output.json
-    └── error_output.json
+└── scratch-orgs/                      # Scratch org creation examples
+    ├── success_definition_file.json
+    ├── success_edition.json
+    ├── success_snapshot.json
+    ├── success_shape.json
+    ├── error_no_devhub.json
+    └── error_timeout.json
 ```
 
 ## scratch-orgs/
@@ -27,13 +28,6 @@ Examples of `sf org create scratch` command outputs for all four creation method
 - **error_no_devhub.json** - Error when Dev Hub not authenticated
 - **error_timeout.json** - Timeout error (exit code 69)
 
-## snapshots/
-
-Examples of `sf org create snapshot` command outputs.
-
-- **success_output.json** - Successful snapshot creation
-- **error_output.json** - Common error scenario (duplicate snapshot name)
-
 ## Usage
 
 These examples help illustrate:

package/skills/dx-org-manage/references/scratch-org-create.md

@@ -300,4 +300,4 @@ user-supplied name — the CLI auto-populates the org name.
 - `scratch-org-operations.md` — list, display, resume, delete
 - `definition_file_options.md` — features, settings, and definition-file schema
 - `edition_types.md` — edition selection and the CLI-flag-vs-definition-file format distinction
-- `snapshot_usage.md` — using snapshots in definition files and post-snapshot workflow
+- `dx-org-snapshot-manage` skill — create/check/list/delete a snapshot before referencing it here; this file only covers consuming an existing, `Active` snapshot via `--snapshot`/the `snapshot` definition-file field

package/skills/dx-org-manage/references/scratch-org-operations.md

@@ -132,4 +132,4 @@ sf org delete scratch --target-org <alias> --no-prompt --json
   AUTO MODE, STATE A/B, batch create, and definition-file authoring
 - `definition_file_options.md` — features, settings, and definition-file schema
 - `edition_types.md` — edition selection and the CLI-flag-vs-definition-file format distinction
-- `snapshot_usage.md` — using snapshots in definition files and post-snapshot workflow
+- `dx-org-snapshot-manage` skill — create/check/list/delete a snapshot before referencing it here; this file only covers consuming an existing, `Active` snapshot via `--snapshot`/the `snapshot` definition-file field

package/skills/dx-org-shape-manage/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: dx-org-shape-manage
-description: "ALWAYS USE THIS SKILL to create, list, or delete org shapes. An org shape is a captured baseline configuration (features, limits, edition, and Metadata API settings) of a source org, without its data or metadata. Use when the user asks to create/make/take an org shape, capture or replicate an org's configuration/edition/limits, list/show/view existing org shapes (including INACTIVE/superseded ones) or their IDs and status, or delete/remove org shapes for a source org. Requires a source org with Dev Hub and Org Shape for Scratch Orgs enabled. DO NOT TRIGGER for creating snapshots or scratch orgs (use dx-org-manage)."
+description: "ALWAYS USE THIS SKILL to create, list, or delete org shapes. An org shape is a captured baseline configuration (features, limits, edition, and Metadata API settings) of a source org, without its data or metadata. Use when the user asks to create/make/take an org shape, capture or replicate an org's configuration/edition/limits, list/show/view existing org shapes (including INACTIVE/superseded ones) or their IDs and status, or delete/remove org shapes for a source org. Requires a source org with Dev Hub and Org Shape for Scratch Orgs enabled. DO NOT TRIGGER for creating/checking/listing/deleting snapshots (use dx-org-snapshot-manage) or for creating scratch orgs (use dx-org-manage)."
 metadata:
   version: "1.0"
   domains: ["Developer Experience"]
@@ -33,7 +33,7 @@ Coordinates the full lifecycle of Salesforce org shapes — **create**, **list**
 ## Scope
 
 - **In scope**: Creating (`sf org create shape`), listing (`sf org list shape`), listing including inactive shapes for a specific source org (SOQL against `ShapeRepresentation`), and deleting (`sf org delete shape`) org shapes
-- **Out of scope**: Creating snapshots, creating scratch orgs (use `dx-org-manage`)
+- **Out of scope**: Creating/checking/listing/deleting snapshots (use `dx-org-snapshot-manage`), creating scratch orgs (use `dx-org-manage`)
 
 ---
 
@@ -136,7 +136,8 @@ See the example files referenced below for full response structures.
 
 | Need | Delegate to |
 |------|-------------|
-| Create a scratch org, or create/use a snapshot | `dx-org-manage` skill |
+| Create a scratch org, or create/use a snapshot to make one | `dx-org-manage` skill |
+| Create, check status of, list, or delete a snapshot itself | `dx-org-snapshot-manage` skill |
 
 ---
 

package/skills/education-cloud-domain-configure/references/gotchas-extended.md

@@ -21,3 +21,4 @@ Lower-frequency gotchas and toggle-write failure classes, split out of `SKILL.md
 | **Failure class — settings type invisible to Tooling/EntityDefinition but still MDAPI-writable** (e.g. Omnistudio Metadata, `OmniStudioSettings`, `fullName: OmniStudio`) | Metadata PUT write succeeds, but no GET/verify path exists via Tooling API — UI-confirmed only; if you encounter one of these, note it as write-succeeds-zero-verify-path rather than assuming failure |
 | **Failure class — type-level UPDATE block** (e.g. Timeline `TimelineSettings`, Video Calls `VideoCallsSettings`) | PUT returns HTTP 400 `UNSUPPORTED_OPERATION: "MetadataCrud does not support UPDATE on type: X"` — block is on the whole type, no `fullName` variant fixes it; manual UI only |
 | **Pattern — org preference API, not `IndustriesSettings`** (confirmed on Einstein Generative AI, `EinsteinGPTCopilotEnabled`) | Some toggles are Setup-Connect org preferences, not `IndustriesSettings` metadata fields — no `type`/`fullName`/`xmlRep`. Shape: `GET /services/data/v68.0/setup/org/preferences/<PrefName>` → `{"isPreferenceEnabled": bool}`; `PATCH` same path with `{"desiredState": true}` → response echoes post-write state. If a metadata PUT returns `FIELD_INTEGRITY_EXCEPTION: invalid at this location` for a plausible-looking element name, the field may not be on `IndustriesSettings` at all — try this org-preference path next before assuming manual-UI-only |
+| **Failure class — write-enabled `dispatch` MCP tool not connected/loaded** | Fall back to the `sf api request rest` CLI (via Bash) for the exact same READ/WRITE/cold-VERIFY calls before giving up to manual Setup UI — confirmed working in the same run where other datasets hit this identical MCP gap. Never report a toggle's state as "assumed default" or "pending admin confirmation" without trying this fallback first |

package/skills/experience-accessibility-validate/SKILL.md

@@ -11,7 +11,7 @@ metadata:
     - "design-systems-slds-validate"
     - "experience-lwc-generate"
 ---
-<!-- adk-managed-skill -->
+<!-- a11y-expert-managed-skill -->
 
 # Web Component Accessibility
 
@@ -47,16 +47,19 @@ Key Review Criteria:
 4. Component Library Usage
 
 - Assume that well-known component libraries (e.g., Salesforce Lightning, Material UI, Chakra UI) are accessible out of the box when correctly implemented. Unless they are used specifically in conflict with WCAG, library-provided components can be ignored for this review, as they are implemented in an accessible way beneath the abstraction.
+- Lightning base components (`lightning-input`, `lightning-combobox`, `lightning-textarea`, `lightning-icon`, and similar components) provide accessible labeling, ARIA, and error handling through dedicated attributes such as `label` and `alternative-text`. A `label` remains programmatic even with `variant="label-hidden"`; do not require a sibling or wrapper `<label>` to target the component. Navigation, button-icon, and other self-labeling base components likewise expose supplied label text as their accessible name and treat their internal icon as decorative. Do not report a missing association merely because that implementation is hidden inside the component.
+- The same self-labeling logic applies to **imported or custom control components in any framework** (React/JSX, Angular, Vue, Web Components), not only Lightning. A capitalized or imported component tag (`<Input>`, `<TextField>`, `<Button>`, `<Select>`, `<Checkbox>`, `<SearchField>`, and design-system wrappers from Material UI, Chakra, Radix, or an internal library) is **not** a bare HTML element — assume it renders its own accessible label, ARIA, and error handling beneath the abstraction (see the component-library grounding rule). When such a component is given a labeling prop — `label`, `aria-label`, `aria-labelledby`, `title`, or visible child text/`children` — treat it as already programmatically labeled and do **not** flag it for a missing `<label>`, a missing `for`/`id` association, or a missing accessible name. Only flag when **no** labeling prop or text is supplied, or the supplied value is clearly empty or nonsensical. Do not demand a native `<label for>` for a component whose internal control you cannot see.
+- Resolve dynamic `id` / `htmlFor` / `for` expressions before judging a label association. When a `<label htmlFor={X}>` (or `for={X}`) and its control's `id={X}` are bound to the **same expression** — the same variable, prop, `useId()` value, or template literal (e.g. both `htmlFor` and `id` set to the same interpolation such as `${id}-email`) — treat the association as **matching**, even though the literal string cannot be resolved at review time. A dynamic `id`/`htmlFor` pair is a mismatch only when the two expressions are demonstrably different. Do **not** flag identical dynamic `id`/`htmlFor` expressions as unmatched or mismatched labels.
 
-**Focus**: Provide actionable feedback to ensure the component meets the necessary WCAG accessibility requirements, avoiding extraneous feedback unrelated to the prompt's scope. Identify issues in code only if there is an immediate fix. You MUST conduct the review, and subsequently suggest the code fix that solves this issue.
+5. Source Interpretation
 
+- Resolve expressions according to the framework's binding semantics before judging them. Trace a dynamic value to every source available in that context. In React/JSX, an expression may reference local variables, props, hook results, or imported bindings; Vue, Svelte, and Astro expose their own template or script scopes. In an LWC template specifically, `{someValue}` resolves to a field, property, or getter on the component class (`.js` or `.ts`), including `@api` properties; module-level imported constants are not directly bindable. In Aura markup, follow the expression's value provider, such as `v.` or `c.`, to the corresponding component attribute or controller logic. Do not conclude that a value is undefined, empty, or missing until you have inspected the applicable source. In a diff, verify which side contains the corrected code rather than assuming that the change introduced the problem.
 
+**Focus**: Provide actionable feedback to ensure the component meets the necessary WCAG accessibility requirements, avoiding extraneous feedback unrelated to the prompt's scope. Identify issues in code only if there is an immediate fix. You MUST conduct the review, and subsequently suggest the code fix that solves this issue.
 
 ## Success Criteria Reviewers
 
-Identify which Success Criteria apply to the code under review, then open the reference files relevant to that code. Each reference is a
-self-contained reviewer with analysis framework, examples, and remediation
-guidance.
+Identify which Success Criteria apply to the code under review, then open the reference files relevant to that code. Each reference supplies criterion-specific analysis, examples, and remediation guidance; the review-wide rules above continue to apply.
 
 ### Perceivable
 

package/skills/experience-accessibility-validate/references/reviewers/sc-1-1-1-non-text-content.md

@@ -77,12 +77,9 @@ Rules to follow:
 - Flag missing or generic alt text on informative images
 - Flag overly descriptive alt text on clearly decorative images
 - Consider the context and purpose of each image
+- **This reviewer covers `<img>` elements only.** Do **not** flag non-image content: an `aria-hidden="true"` `<span>`, icon-font glyph, emoji, or decorative `<svg>` is intentionally removed from the accessibility tree and is correctly handled — it is not an `<img>` missing alt text. A decorative `<span aria-hidden="true">` is correct, not a violation.
 
 - For each issue found, provide a separate, detailed report.
 - Keep issues concise, avoid duplicated issues or unnecessary or non-applicable problems.
 - Assume that any imported functionality works as expected and was already analyzed.
 - Components do not supplement or provide global functionalities.
-- Lightning base components (`lightning-input`, `lightning-combobox`, `lightning-textarea`, `lightning-icon`, etc.) provide their own accessible labeling, ARIA, and error handling in shadow DOM via their dedicated attributes (`label`, `alternative-text`, field-level validation). When such a component is given a `label` attribute it is already programmatically labeled — even with `variant="label-hidden"`, which hides the label visually but keeps it for assistive technology. Do **not** flag a sibling/wrapper `<label>` or `<span>` for a missing `for`/`id` when the actual control is a self-labeling Lightning component, and do not treat a visible heading as if it were the control's only label. This also covers navigation and icon base components (`lightning-vertical-navigation-item`, `lightning-vertical-navigation-item-icon`, `lightning-button-icon`, etc.): when a `label` (or `alternative-text`) attribute is supplied, the base component renders it as the visible link/control text **and** exposes it as the accessible name, and any `icon-name` is decorative — do not emit a 4.1.2 "verify the label is associated with the icon" warning, even a hedged one. The presence of the `label` attribute is the association.
-- Resolve template bindings before judging them. A template expression like `{someValue}` refers to a property or getter on the component's controller (`.js`/`.ts`) — including `@api` properties and `get someValue()` getters — not to a module-level imported constant (which LWC templates cannot bind to). Check the controller for the binding's definition before concluding a value is undefined, empty, or missing. When reviewing a diff, verify which side is the corrected code; do not assume the change introduced the problem.
-- Prefer a real `<button>` for actions; for a link, `href="#"` with `event.preventDefault()` (the canonical SLDS pattern). Don't recommend `href="javascript:void(0)"` as a first-line remediation — it's a no-op-anchor anti-pattern. It is acceptable only as a last resort when moving `<a>` → `<button>` is genuinely impossible, and even then only when paired with the full set of attributes that make the anchor behave as an accessible button (`role="button"`, keyboard activation, etc.) — `void(0)` on its own is an incomplete fix. Don't flag existing `javascript:void(0)` as a violation.
-- ARIA attribute spelling depends on the element type. On a **plain HTML element** (`div`, `span`, `button`, `input`, `a`, `img`, `iframe`, …) the only valid spelling is the W3C form `aria-labelledby` / `aria-describedby`; the hyphen-split `aria-labelled-by` / `aria-described-by` there **is** a real bug — keep flagging it. But on an **LWC component tag** (`lightning-*` or a custom `ns-name` element), the hyphen-split form is the kebab-case binding of the component's `@api ariaLabelledBy` / `ariaDescribedBy` property (each capital letter maps to `-` + lowercase), and LWC reflects it to the spec-correct `aria-labelledby` in the rendered DOM. Do **not** flag `aria-labelled-by` on a component tag as a misspelling, and do not claim it "breaks the accessible name computation" — you cannot determine that from the attribute name alone, because both `aria-labelled-by` (via `@api` property kebab-casing) and `aria-labelledby` (via LWC's ARIA reflection) can wire to the same property depending on the component. Treat a hyphen-split ARIA attribute on a component tag as a valid binding, not a violation.

package/skills/experience-accessibility-validate/references/reviewers/sc-1-3-1-i-lists.md

@@ -46,7 +46,3 @@ Rules to follow:
 - Keep issues concise, avoid duplicated issues or unnecessary or non-applicable problems.
 - Assume that any imported functionality works as expected and was already analyzed.
 - Components do not supplement or provide global functionalities.
-- Lightning base components (`lightning-input`, `lightning-combobox`, `lightning-textarea`, `lightning-icon`, etc.) provide their own accessible labeling, ARIA, and error handling in shadow DOM via their dedicated attributes (`label`, `alternative-text`, field-level validation). When such a component is given a `label` attribute it is already programmatically labeled — even with `variant="label-hidden"`, which hides the label visually but keeps it for assistive technology. Do **not** flag a sibling/wrapper `<label>` or `<span>` for a missing `for`/`id` when the actual control is a self-labeling Lightning component, and do not treat a visible heading as if it were the control's only label. This also covers navigation and icon base components (`lightning-vertical-navigation-item`, `lightning-vertical-navigation-item-icon`, `lightning-button-icon`, etc.): when a `label` (or `alternative-text`) attribute is supplied, the base component renders it as the visible link/control text **and** exposes it as the accessible name, and any `icon-name` is decorative — do not emit a 4.1.2 "verify the label is associated with the icon" warning, even a hedged one. The presence of the `label` attribute is the association.
-- Resolve template bindings before judging them. A template expression like `{someValue}` refers to a property or getter on the component's controller (`.js`/`.ts`) — including `@api` properties and `get someValue()` getters — not to a module-level imported constant (which LWC templates cannot bind to). Check the controller for the binding's definition before concluding a value is undefined, empty, or missing. When reviewing a diff, verify which side is the corrected code; do not assume the change introduced the problem.
-- Prefer a real `<button>` for actions; for a link, `href="#"` with `event.preventDefault()` (the canonical SLDS pattern). Don't recommend `href="javascript:void(0)"` as a first-line remediation — it's a no-op-anchor anti-pattern. It is acceptable only as a last resort when moving `<a>` → `<button>` is genuinely impossible, and even then only when paired with the full set of attributes that make the anchor behave as an accessible button (`role="button"`, keyboard activation, etc.) — `void(0)` on its own is an incomplete fix. Don't flag existing `javascript:void(0)` as a violation.
-- ARIA attribute spelling depends on the element type. On a **plain HTML element** (`div`, `span`, `button`, `input`, `a`, `img`, `iframe`, …) the only valid spelling is the W3C form `aria-labelledby` / `aria-describedby`; the hyphen-split `aria-labelled-by` / `aria-described-by` there **is** a real bug — keep flagging it. But on an **LWC component tag** (`lightning-*` or a custom `ns-name` element), the hyphen-split form is the kebab-case binding of the component's `@api ariaLabelledBy` / `ariaDescribedBy` property (each capital letter maps to `-` + lowercase), and LWC reflects it to the spec-correct `aria-labelledby` in the rendered DOM. Do **not** flag `aria-labelled-by` on a component tag as a misspelling, and do not claim it "breaks the accessible name computation" — you cannot determine that from the attribute name alone, because both `aria-labelled-by` (via `@api` property kebab-casing) and `aria-labelledby` (via LWC's ARIA reflection) can wire to the same property depending on the component. Treat a hyphen-split ARIA attribute on a component tag as a valid binding, not a violation.

package/skills/experience-accessibility-validate/references/reviewers/sc-1-3-1-ii-tables.md

@@ -4,103 +4,38 @@ Information, structure, and relationships conveyed through presentation can be p
 
 ## SC: 1.3.1 (ii) - Tables Only
 
-Analyze the given files using the following framework:
+For every `<table>` element in the source, apply the criteria below and produce one fix entry per violation. Other SC 1.3.1 concerns (lists, regions, form-labels, groups) are out of scope — they are owned by sibling reviewers.
 
-Review the provided HTML and JS files for accessibility violations per WCAG 2.2 SC 1.3.1 (ii), 'Tables'.
-(Only tables from this rule should be considered). For all tables on the components, ensure that any information conveyed through presentation is programmatically determinable in order to determine if they meet SC 1.3.1 (ii).
+### Structural criteria
 
-For each of these elements, check if any of the following conditions of WCAG 2.2 SC 1.3.1 (ii), 'Tables' are true:
+For each `<table>`, verify:
 
-- The objective of this technique is to present tabular information in a way that preserves relationships within the information even when users cannot see the table or the presentation format is changed. Information is considered tabular when logical relationships among text, numbers, images, or other data exist in two dimensions (vertical and horizontal). These relationships are represented in columns and rows, and the columns and rows must be recognizable in order for the logical relationships to be perceived.
-  Check for the presence of tabular information.
-  For each instance of the `<table>` element found, perform the following checks:
-- Verify the presence of table rows (`<tr>`): Ensure that each `<table>` element contains at least one `<tr>` element
-- Verify the presence of table data cells (`<td>`) within rows (`<tr>`): For each `<tr>` element within a `<table>`, confirm that it contains one or more `<td>` elements representing the data cells
-- Verify the presence of table header cells (`<th>`) when applicable: If the table includes headers, ensure that the header information is marked up using `<th>` elements, typically within the first `<tr>` element or within `<thead>` elements
-- Check that all data content within the table is enclosed within `<td>` cell elements and that header content (if present) is within `<th>` elements
-- For every `<table>` element identified, verify that it contains at least the following elements: `<tr>`, `<th>` (if headers are present, otherwise `<td>`), and `<td>`
-- Providing an accessible name for a table is considered a best practice that significantly enhances usability for all users, especially those relying on assistive technologies.The accessible name can be provided in various ways:
-- By either using a `aria-label` or `aria-labelledby` attributes or `<caption>` element in the table. Its a best practice and absence of accessible name is acceptable but not a violation.
-- The objective of this technique is to associate header cells with data cells in simple data tables using the `scope` attribute.
-- The `scope` attribute identifies whether the cell is a header for a row, column, or group of rows or columns
-- Valid `scope` values: `row`, `col`, `rowgroup`, `colgroup`
+- Contains at least one `<tr>` element.
+- Each `<tr>` contains one or more cells appropriate to its content: `<th>` for headers and `<td>` for data. A header-only row containing only `<th>` cells is valid.
+- Header content (if present) is marked up with `<th>` (typically in the first `<tr>` or inside `<thead>`).
+- All data content is inside `<td>` cells; all header content is inside `<th>` cells.
+- The table is either a recognizable data table (`<tr>`, `<td>`, plus `<th>` when headers exist) or a layout table (no relationships across rows and columns).
 
-For simple data tables:
+### Header-association criteria
 
-- If headers are in the first row or column:
-  - `th` elements without `scope` are sufficient
-- If headers are not in the first row or column:
-  - Check that all `th` elements have a `scope` attribute
-  - Verify `scope` values match the header's role (`row`/`col`/`rowgroup`/`colgroup`)
-    Note: For complex tables (multiple levels of headers, headers spanning rows/columns), use id and headers attributes instead (see H43)
-- The objective of this technique is to associate each data cell (in a data table) with the appropriate headers.
-  Check for layout tables and data tables:
-- For layout tables:
-  - Determine if content has a relationship with other content in both its column and row
-  - If "no", the table is a layout table
-- For data tables:
-  - Check that any cell associated with multiple row/column headers contains a headers attribute listing all associated header IDs
-  - For cells with id or headers attributes:
-    - Verify each id in headers attribute matches a header element's id
-    - Verify headers attribute contains all associated header IDs
-    - Ensure all IDs are unique within the component
+- **Simple data tables** with headers in the first row or column: `<th>` without `scope` is sufficient.
+- **Simple data tables** with headers NOT in the first row or column: every `<th>` must carry a valid `scope` (`row` / `col` / `rowgroup` / `colgroup`) matching the header's role.
+- **Irregular tables** with headers spanning rows or columns may use explicitly defined row or column groups with `scope="rowgroup"` or `scope="colgroup"`. Do not require `id` + `headers` solely because a table uses `rowspan`, `colspan`, or multiple header levels when groups and `scope` express the relationships.
+- **Complex tables** whose data-cell relationships are too complex to identify using `<th>` alone or `<th>` with `scope` must provide programmatically determinable header-to-cell associations. Use `id` + `headers` attributes (see H43), or simplify the table so `<th>` and `scope` can express the relationships. Complex cases include tables whose headers repeat or change partway through the table or whose data cells are associated with three or more headers. When `id` + `headers` is used, verify that every `<th>` `id` is unique within the component and every id in a cell's `headers` attribute resolves to an actual `<th>`.
 
-In order to fix a violation for a given element, you must examine the given component code and apply the most logical fix available such that the element satisfies one of the following conditions of WCAG 2.2 SC 1.3.1 (ii), 'Tables':
+### Accessible-name criterion
 
-- The objective of this technique is to present tabular information in a way that preserves relationships within the information even when users cannot see the table or the presentation format is changed. Information is considered tabular when logical relationships among text, numbers, images, or other data exist in two dimensions (vertical and horizontal). These relationships are represented in columns and rows, and the columns and rows must be recognizable in order for the logical relationships to be perceived.
-  Check for the presence of tabular information.
-  For each instance of the `<table>` element found, perform the following checks:
-- Verify the presence of table rows (`<tr>`): Ensure that each `<table>` element contains at least one `<tr>` element
-- Verify the presence of table data cells (`<td>`) within rows (`<tr>`): For each `<tr>` element within a `<table>`, confirm that it contains one or more `<td>` elements representing the data cells
-- Verify the presence of table header cells (`<th>`) when applicable: If the table includes headers, ensure that the header information is marked up using `<th>` elements, typically within the first `<tr>` element or within `<thead>` elements
-- Check that all data content within the table is enclosed within `<td>` cell elements and that header content (if present) is within `<th>` elements
-- For every `<table>` element identified, verify that it contains at least the following elements: `<tr>`, `<th>` (if headers are present, otherwise `<td>`), and `<td>`
-- Providing an accessible name for a table is considered a best practice that significantly enhances usability for all users, especially those relying on assistive technologies.The accessible name can be provided in various ways:
-- By either using a `aria-label` or `aria-labelledby` attributes or `<caption>` element in the table. Its a best practice and absence of accessible name is acceptable but not a violation.
-- The objective of this technique is to associate header cells with data cells in simple data tables using the `scope` attribute.
-- The `scope` attribute identifies whether the cell is a header for a row, column, or group of rows or columns
-- Valid `scope` values: `row`, `col`, `rowgroup`, `colgroup`
+Providing an accessible name (via `aria-label`, `aria-labelledby`, or `<caption>`) is a best practice but not a violation when absent. Do not produce a fix entry purely for a missing accessible name.
 
-For simple data tables:
+### Layout-table criterion
 
-- If headers are in the first row or column:
-  - `th` elements without `scope` are sufficient
-- If headers are not in the first row or column:
-  - Check that all `th` elements have a `scope` attribute
-  - Verify `scope` values match the header's role (`row`/`col`/`rowgroup`/`colgroup`)
-    Note: For complex tables (multiple levels of headers, headers spanning rows/columns), use id and headers attributes instead (see H43)
-- The objective of this technique is to associate each data cell (in a data table) with the appropriate headers.
-  Check for layout tables and data tables:
-- For layout tables:
-  - Determine if content has a relationship with other content in both its column and row
-  - If "no", the table is a layout table
-- For data tables:
-  - Check that any cell associated with multiple row/column headers contains a headers attribute listing all associated header IDs
-  - For cells with id or headers attributes:
-    - Verify each id in headers attribute matches a header element's id
-    - Verify headers attribute contains all associated header IDs
-    - Ensure all IDs are unique within the component
+When a table's content has no row/column relationships, classify it as a layout table. Layout tables should not use `<th>` or `scope`; emit a fix entry if they do.
 
-Note: A complex table is one where:
+### Output contract
 
-- Headers span multiple rows or columns
-- Headers are not in the first row or column
-- Multiple levels of headers exist
-- Cells are associated with multiple headers
-- The table structure requires additional context to understand relationships between data
+For each violation, produce one entry with: file + line number, which criterion above failed, and the corrected markup snippet. If every table satisfies the criteria, produce an empty list.
 
-If they do not meet this success criterion, then flag this as a violation.
-
-Rules to follow:
-
-- Find all violations of SC 1.3.1 (ii) 'Tables' in the provided HTML and JS files
-- Do not worry about violations of SC 1.3.1 that are not specific to tables (handled by other reviewers)
-- If no changes are needed, then produce an empty list
-  - For each issue found, provide a separate, detailed report.
+- For each issue found, provide a separate, detailed report.
 - Keep issues concise, avoid duplicated issues or unnecessary or non-applicable problems.
 - Assume that any imported functionality works as expected and was already analyzed.
 - Components do not supplement or provide global functionalities.
-- Lightning base components (`lightning-input`, `lightning-combobox`, `lightning-textarea`, `lightning-icon`, etc.) provide their own accessible labeling, ARIA, and error handling in shadow DOM via their dedicated attributes (`label`, `alternative-text`, field-level validation). When such a component is given a `label` attribute it is already programmatically labeled — even with `variant="label-hidden"`, which hides the label visually but keeps it for assistive technology. Do **not** flag a sibling/wrapper `<label>` or `<span>` for a missing `for`/`id` when the actual control is a self-labeling Lightning component, and do not treat a visible heading as if it were the control's only label. This also covers navigation and icon base components (`lightning-vertical-navigation-item`, `lightning-vertical-navigation-item-icon`, `lightning-button-icon`, etc.): when a `label` (or `alternative-text`) attribute is supplied, the base component renders it as the visible link/control text **and** exposes it as the accessible name, and any `icon-name` is decorative — do not emit a 4.1.2 "verify the label is associated with the icon" warning, even a hedged one. The presence of the `label` attribute is the association.
-- Resolve template bindings before judging them. A template expression like `{someValue}` refers to a property or getter on the component's controller (`.js`/`.ts`) — including `@api` properties and `get someValue()` getters — not to a module-level imported constant (which LWC templates cannot bind to). Check the controller for the binding's definition before concluding a value is undefined, empty, or missing. When reviewing a diff, verify which side is the corrected code; do not assume the change introduced the problem.
-- Prefer a real `<button>` for actions; for a link, `href="#"` with `event.preventDefault()` (the canonical SLDS pattern). Don't recommend `href="javascript:void(0)"` as a first-line remediation — it's a no-op-anchor anti-pattern. It is acceptable only as a last resort when moving `<a>` → `<button>` is genuinely impossible, and even then only when paired with the full set of attributes that make the anchor behave as an accessible button (`role="button"`, keyboard activation, etc.) — `void(0)` on its own is an incomplete fix. Don't flag existing `javascript:void(0)` as a violation.
-- ARIA attribute spelling depends on the element type. On a **plain HTML element** (`div`, `span`, `button`, `input`, `a`, `img`, `iframe`, …) the only valid spelling is the W3C form `aria-labelledby` / `aria-describedby`; the hyphen-split `aria-labelled-by` / `aria-described-by` there **is** a real bug — keep flagging it. But on an **LWC component tag** (`lightning-*` or a custom `ns-name` element), the hyphen-split form is the kebab-case binding of the component's `@api ariaLabelledBy` / `ariaDescribedBy` property (each capital letter maps to `-` + lowercase), and LWC reflects it to the spec-correct `aria-labelledby` in the rendered DOM. Do **not** flag `aria-labelled-by` on a component tag as a misspelling, and do not claim it "breaks the accessible name computation" — you cannot determine that from the attribute name alone, because both `aria-labelled-by` (via `@api` property kebab-casing) and `aria-labelledby` (via LWC's ARIA reflection) can wire to the same property depending on the component. Treat a hyphen-split ARIA attribute on a component tag as a valid binding, not a violation.

package/skills/experience-accessibility-validate/references/reviewers/sc-1-3-1-iii-form-labels.md

@@ -61,6 +61,8 @@ Exceptions (No Label Required):
 
 If they do not meet this success criterion, then flag this as a violation.
 
+Trace how the control's own accessible name is provided in the source before flagging a missing or unassociated label. Valid sources include a `<label>` that contains the control, a `<label for>` / `<label htmlFor>` whose value matches the control's `id`, an `aria-label`, an `aria-labelledby` target, or a self-labeling component prop on an imported/custom control such as `<Input>` or `<TextField>` (see the general rules). An adjacent `<label>` is not sufficient unless it contains the control or has a matching `for` / `htmlFor` association. A `<fieldset><legend>` or named `role="group"` / `role="radiogroup"` supplies group context but does **not** name each descendant control. A dynamic `for` / `htmlFor` and its control's `id` bound to the **same expression** are matched, even when the literal value cannot be resolved at review time (see the general rules). Only flag when none of the valid control-level naming mechanisms supplies the name.
+
 Rules to follow:
 
 - Find all violations of SC 1.3.1 (iii) 'Form Labels' in the provided HTML and JS files
@@ -72,7 +74,5 @@ Rules to follow:
 - Keep issues concise, avoid duplicated issues or unnecessary or non-applicable problems.
 - Assume that any imported functionality works as expected and was already analyzed.
 - Components do not supplement or provide global functionalities.
-- Lightning base components (`lightning-input`, `lightning-combobox`, `lightning-textarea`, `lightning-icon`, etc.) provide their own accessible labeling, ARIA, and error handling in shadow DOM via their dedicated attributes (`label`, `alternative-text`, field-level validation). When such a component is given a `label` attribute it is already programmatically labeled — even with `variant="label-hidden"`, which hides the label visually but keeps it for assistive technology. Do **not** flag a sibling/wrapper `<label>` or `<span>` for a missing `for`/`id` when the actual control is a self-labeling Lightning component, and do not treat a visible heading as if it were the control's only label. This also covers navigation and icon base components (`lightning-vertical-navigation-item`, `lightning-vertical-navigation-item-icon`, `lightning-button-icon`, etc.): when a `label` (or `alternative-text`) attribute is supplied, the base component renders it as the visible link/control text **and** exposes it as the accessible name, and any `icon-name` is decorative — do not emit a 4.1.2 "verify the label is associated with the icon" warning, even a hedged one. The presence of the `label` attribute is the association.
-- Resolve template bindings before judging them. A template expression like `{someValue}` refers to a property or getter on the component's controller (`.js`/`.ts`) — including `@api` properties and `get someValue()` getters — not to a module-level imported constant (which LWC templates cannot bind to). Check the controller for the binding's definition before concluding a value is undefined, empty, or missing. When reviewing a diff, verify which side is the corrected code; do not assume the change introduced the problem.
-- Prefer a real `<button>` for actions; for a link, `href="#"` with `event.preventDefault()` (the canonical SLDS pattern). Don't recommend `href="javascript:void(0)"` as a first-line remediation — it's a no-op-anchor anti-pattern. It is acceptable only as a last resort when moving `<a>` → `<button>` is genuinely impossible, and even then only when paired with the full set of attributes that make the anchor behave as an accessible button (`role="button"`, keyboard activation, etc.) — `void(0)` on its own is an incomplete fix. Don't flag existing `javascript:void(0)` as a violation.
-- ARIA attribute spelling depends on the element type. On a **plain HTML element** (`div`, `span`, `button`, `input`, `a`, `img`, `iframe`, …) the only valid spelling is the W3C form `aria-labelledby` / `aria-describedby`; the hyphen-split `aria-labelled-by` / `aria-described-by` there **is** a real bug — keep flagging it. But on an **LWC component tag** (`lightning-*` or a custom `ns-name` element), the hyphen-split form is the kebab-case binding of the component's `@api ariaLabelledBy` / `ariaDescribedBy` property (each capital letter maps to `-` + lowercase), and LWC reflects it to the spec-correct `aria-labelledby` in the rendered DOM. Do **not** flag `aria-labelled-by` on a component tag as a misspelling, and do not claim it "breaks the accessible name computation" — you cannot determine that from the attribute name alone, because both `aria-labelled-by` (via `@api` property kebab-casing) and `aria-labelledby` (via LWC's ARIA reflection) can wire to the same property depending on the component. Treat a hyphen-split ARIA attribute on a component tag as a valid binding, not a violation.
+- ARIA attribute spelling depends on the element type. Plain HTML elements use `aria-labelledby` and `aria-describedby`; `aria-labelled-by` or `aria-described-by` is invalid there. On an LWC component tag, however, the hyphen-split spelling can be the kebab-case binding for an `@api ariaLabelledBy` or `ariaDescribedBy` property. Do not report the component spelling as a broken association without evidence that the component fails to forward it.
+- Attach label associations to the actual focusable control. A `for`, `htmlFor`, or ARIA relationship on a non-focusable wrapper around a composite editor does not label the internal control unless the wrapper forwards it. Recommend extending the control to accept or forward the association, or using its supported labeling prop.

package/skills/experience-accessibility-validate/references/reviewers/sc-1-3-1-iv-regions.md

@@ -20,7 +20,3 @@ Rules to follow:
 - Keep issues concise, avoid duplicated issues or unnecessary or non-applicable problems.
 - Assume that any imported functionality works as expected and was already analyzed.
 - Components do not supplement or provide global functionalities.
-- Lightning base components (`lightning-input`, `lightning-combobox`, `lightning-textarea`, `lightning-icon`, etc.) provide their own accessible labeling, ARIA, and error handling in shadow DOM via their dedicated attributes (`label`, `alternative-text`, field-level validation). When such a component is given a `label` attribute it is already programmatically labeled — even with `variant="label-hidden"`, which hides the label visually but keeps it for assistive technology. Do **not** flag a sibling/wrapper `<label>` or `<span>` for a missing `for`/`id` when the actual control is a self-labeling Lightning component, and do not treat a visible heading as if it were the control's only label. This also covers navigation and icon base components (`lightning-vertical-navigation-item`, `lightning-vertical-navigation-item-icon`, `lightning-button-icon`, etc.): when a `label` (or `alternative-text`) attribute is supplied, the base component renders it as the visible link/control text **and** exposes it as the accessible name, and any `icon-name` is decorative — do not emit a 4.1.2 "verify the label is associated with the icon" warning, even a hedged one. The presence of the `label` attribute is the association.
-- Resolve template bindings before judging them. A template expression like `{someValue}` refers to a property or getter on the component's controller (`.js`/`.ts`) — including `@api` properties and `get someValue()` getters — not to a module-level imported constant (which LWC templates cannot bind to). Check the controller for the binding's definition before concluding a value is undefined, empty, or missing. When reviewing a diff, verify which side is the corrected code; do not assume the change introduced the problem.
-- Prefer a real `<button>` for actions; for a link, `href="#"` with `event.preventDefault()` (the canonical SLDS pattern). Don't recommend `href="javascript:void(0)"` as a first-line remediation — it's a no-op-anchor anti-pattern. It is acceptable only as a last resort when moving `<a>` → `<button>` is genuinely impossible, and even then only when paired with the full set of attributes that make the anchor behave as an accessible button (`role="button"`, keyboard activation, etc.) — `void(0)` on its own is an incomplete fix. Don't flag existing `javascript:void(0)` as a violation.
-- ARIA attribute spelling depends on the element type. On a **plain HTML element** (`div`, `span`, `button`, `input`, `a`, `img`, `iframe`, …) the only valid spelling is the W3C form `aria-labelledby` / `aria-describedby`; the hyphen-split `aria-labelled-by` / `aria-described-by` there **is** a real bug — keep flagging it. But on an **LWC component tag** (`lightning-*` or a custom `ns-name` element), the hyphen-split form is the kebab-case binding of the component's `@api ariaLabelledBy` / `ariaDescribedBy` property (each capital letter maps to `-` + lowercase), and LWC reflects it to the spec-correct `aria-labelledby` in the rendered DOM. Do **not** flag `aria-labelled-by` on a component tag as a misspelling, and do not claim it "breaks the accessible name computation" — you cannot determine that from the attribute name alone, because both `aria-labelled-by` (via `@api` property kebab-casing) and `aria-labelledby` (via LWC's ARIA reflection) can wire to the same property depending on the component. Treat a hyphen-split ARIA attribute on a component tag as a valid binding, not a violation.

package/skills/experience-accessibility-validate/references/reviewers/sc-1-3-1-v-groups.md

@@ -52,6 +52,8 @@ For each selection list:
 
 - Check that links that are grouped and represent a section of page, are enclosed in a `nav` element or similar semantics.
 
+Before flagging a group as unlabeled or improperly structured, resolve how the group is named. A `role="group"` / `role="radiogroup"` container with `aria-label` or `aria-labelledby` is a **valid and sufficient** grouping-and-naming technique (ARIA17) — it does **not** additionally require a `<fieldset>` / `<legend>`. Treat `<div role="group" aria-label={...}>` (including a dynamic `aria-label` / `aria-labelledby` expression such as `aria-label={section.title}`) as a properly labeled group; do **not** flag it for a missing `<legend>`, a missing `aria-label`, or a missing group name when an `aria-label` / `aria-labelledby` is present. Only flag a group that has **neither** a `fieldset` / `legend` **nor** a `role="group"` / `role="radiogroup"` carrying an accessible name.
+
 _Rules to follow_:
 
 - Require code to reinforce structure, relationships and information conveyed through presentation for groups of related elements, per this WCAG 2.2 SC 1.3.1 'Info and Relationships - Groups only' success criterion, in the provided HTML and JS files.
@@ -60,7 +62,3 @@ _Rules to follow_:
 - Keep issues concise, avoid duplicated issues or unnecessary or non-applicable problems.
 - Assume that any imported functionality works as expected and was already analyzed.
 - Components do not supplement or provide global functionalities.
-- Lightning base components (`lightning-input`, `lightning-combobox`, `lightning-textarea`, `lightning-icon`, etc.) provide their own accessible labeling, ARIA, and error handling in shadow DOM via their dedicated attributes (`label`, `alternative-text`, field-level validation). When such a component is given a `label` attribute it is already programmatically labeled — even with `variant="label-hidden"`, which hides the label visually but keeps it for assistive technology. Do **not** flag a sibling/wrapper `<label>` or `<span>` for a missing `for`/`id` when the actual control is a self-labeling Lightning component, and do not treat a visible heading as if it were the control's only label. This also covers navigation and icon base components (`lightning-vertical-navigation-item`, `lightning-vertical-navigation-item-icon`, `lightning-button-icon`, etc.): when a `label` (or `alternative-text`) attribute is supplied, the base component renders it as the visible link/control text **and** exposes it as the accessible name, and any `icon-name` is decorative — do not emit a 4.1.2 "verify the label is associated with the icon" warning, even a hedged one. The presence of the `label` attribute is the association.
-- Resolve template bindings before judging them. A template expression like `{someValue}` refers to a property or getter on the component's controller (`.js`/`.ts`) — including `@api` properties and `get someValue()` getters — not to a module-level imported constant (which LWC templates cannot bind to). Check the controller for the binding's definition before concluding a value is undefined, empty, or missing. When reviewing a diff, verify which side is the corrected code; do not assume the change introduced the problem.
-- Prefer a real `<button>` for actions; for a link, `href="#"` with `event.preventDefault()` (the canonical SLDS pattern). Don't recommend `href="javascript:void(0)"` as a first-line remediation — it's a no-op-anchor anti-pattern. It is acceptable only as a last resort when moving `<a>` → `<button>` is genuinely impossible, and even then only when paired with the full set of attributes that make the anchor behave as an accessible button (`role="button"`, keyboard activation, etc.) — `void(0)` on its own is an incomplete fix. Don't flag existing `javascript:void(0)` as a violation.
-- ARIA attribute spelling depends on the element type. On a **plain HTML element** (`div`, `span`, `button`, `input`, `a`, `img`, `iframe`, …) the only valid spelling is the W3C form `aria-labelledby` / `aria-describedby`; the hyphen-split `aria-labelled-by` / `aria-described-by` there **is** a real bug — keep flagging it. But on an **LWC component tag** (`lightning-*` or a custom `ns-name` element), the hyphen-split form is the kebab-case binding of the component's `@api ariaLabelledBy` / `ariaDescribedBy` property (each capital letter maps to `-` + lowercase), and LWC reflects it to the spec-correct `aria-labelledby` in the rendered DOM. Do **not** flag `aria-labelled-by` on a component tag as a misspelling, and do not claim it "breaks the accessible name computation" — you cannot determine that from the attribute name alone, because both `aria-labelled-by` (via `@api` property kebab-casing) and `aria-labelledby` (via LWC's ARIA reflection) can wire to the same property depending on the component. Treat a hyphen-split ARIA attribute on a component tag as a valid binding, not a violation.

package/skills/experience-accessibility-validate/references/reviewers/sc-1-3-5-identify-input.md

@@ -64,7 +64,3 @@ Rules to follow:
 - Keep issues concise, avoid duplicated issues or unnecessary or non-applicable problems.
 - Assume that any imported functionality works as expected and was already analyzed.
 - Components do not supplement or provide global functionalities.
-- Lightning base components (`lightning-input`, `lightning-combobox`, `lightning-textarea`, `lightning-icon`, etc.) provide their own accessible labeling, ARIA, and error handling in shadow DOM via their dedicated attributes (`label`, `alternative-text`, field-level validation). When such a component is given a `label` attribute it is already programmatically labeled — even with `variant="label-hidden"`, which hides the label visually but keeps it for assistive technology. Do **not** flag a sibling/wrapper `<label>` or `<span>` for a missing `for`/`id` when the actual control is a self-labeling Lightning component, and do not treat a visible heading as if it were the control's only label. This also covers navigation and icon base components (`lightning-vertical-navigation-item`, `lightning-vertical-navigation-item-icon`, `lightning-button-icon`, etc.): when a `label` (or `alternative-text`) attribute is supplied, the base component renders it as the visible link/control text **and** exposes it as the accessible name, and any `icon-name` is decorative — do not emit a 4.1.2 "verify the label is associated with the icon" warning, even a hedged one. The presence of the `label` attribute is the association.
-- Resolve template bindings before judging them. A template expression like `{someValue}` refers to a property or getter on the component's controller (`.js`/`.ts`) — including `@api` properties and `get someValue()` getters — not to a module-level imported constant (which LWC templates cannot bind to). Check the controller for the binding's definition before concluding a value is undefined, empty, or missing. When reviewing a diff, verify which side is the corrected code; do not assume the change introduced the problem.
-- Prefer a real `<button>` for actions; for a link, `href="#"` with `event.preventDefault()` (the canonical SLDS pattern). Don't recommend `href="javascript:void(0)"` as a first-line remediation — it's a no-op-anchor anti-pattern. It is acceptable only as a last resort when moving `<a>` → `<button>` is genuinely impossible, and even then only when paired with the full set of attributes that make the anchor behave as an accessible button (`role="button"`, keyboard activation, etc.) — `void(0)` on its own is an incomplete fix. Don't flag existing `javascript:void(0)` as a violation.
-- ARIA attribute spelling depends on the element type. On a **plain HTML element** (`div`, `span`, `button`, `input`, `a`, `img`, `iframe`, …) the only valid spelling is the W3C form `aria-labelledby` / `aria-describedby`; the hyphen-split `aria-labelled-by` / `aria-described-by` there **is** a real bug — keep flagging it. But on an **LWC component tag** (`lightning-*` or a custom `ns-name` element), the hyphen-split form is the kebab-case binding of the component's `@api ariaLabelledBy` / `ariaDescribedBy` property (each capital letter maps to `-` + lowercase), and LWC reflects it to the spec-correct `aria-labelledby` in the rendered DOM. Do **not** flag `aria-labelled-by` on a component tag as a misspelling, and do not claim it "breaks the accessible name computation" — you cannot determine that from the attribute name alone, because both `aria-labelled-by` (via `@api` property kebab-casing) and `aria-labelledby` (via LWC's ARIA reflection) can wire to the same property depending on the component. Treat a hyphen-split ARIA attribute on a component tag as a valid binding, not a violation.