@salesforce/afv-skills 1.37.0 → 1.38.0

package/skills/experience-lds-graphql-generate/scripts/fetch-lds-graphql-schema.sh

@@ -0,0 +1,230 @@
+#!/usr/bin/env bash
+#
+# LDS GraphQL Schema Fetcher
+#
+# Fetches the Salesforce LDS GraphQL schema for a connected org by POSTing a
+# full introspection query to /services/data/vX/graphql, then renders the
+# response as SDL on disk so the skill can introspect it with targeted grep
+# calls. (LDS does not expose a /graphql/sdl endpoint — introspection is the
+# only path.)
+#
+# The schema content never enters the chat context — only the file path is
+# returned to the user.
+#
+# Usage:
+#   fetch-lds-graphql-schema.sh USERNAME_OR_ALIAS [OUTPUT_PATH] [API_VERSION]
+#
+# Arguments:
+#   $1  usernameOrAlias    SF CLI alias or username for the target org (required)
+#   $2  outputPath         File to write SDL to (default: schema.graphql)
+#   $3  apiVersion         API version (default: 62.0, matching the legacy
+#                          fetch_lds_graphql_schema MCP tool's DEFAULT_API_VERSION)
+#
+# Exit codes:
+#   0  Schema written successfully
+#   1  Argument error
+#   2  Salesforce CLI missing
+#   3  Auth or HTTP failure
+#   4  Schema response was empty, contained errors, or had no types
+
+set -euo pipefail
+
+if [ $# -lt 1 ]; then
+  echo "Usage: $0 USERNAME_OR_ALIAS [OUTPUT_PATH] [API_VERSION]" >&2
+  exit 1
+fi
+
+ALIAS="$1"
+OUTPUT_PATH="${2:-schema.graphql}"
+API_VERSION="${3:-62.0}"
+
+# Skip the fetch when a non-empty schema file is already on disk. Re-fetching
+# is a 30-90s introspection round-trip, so a deterministic short-circuit keeps
+# repeated invocations idempotent. Set LDS_FETCH_FORCE=1 to override.
+if [ -s "$OUTPUT_PATH" ] && [ "${LDS_FETCH_FORCE:-0}" != "1" ]; then
+  echo "Schema already present at ${OUTPUT_PATH} — skipping introspection." >&2
+  echo "Set LDS_FETCH_FORCE=1 to re-fetch." >&2
+  exit 0
+fi
+
+# Output-path containment: refuse paths that escape the current working
+# directory (e.g. ../../etc/passwd, /tmp/foo, symlinks pointing outside).
+# Uses python3's os.path.realpath to resolve `..`, `.`, and symlinks even
+# when intermediate directories don't exist yet — the previous bash-`pwd`
+# approach was bypassable in two ways:
+#   1. when the parent didn't exist, the fallback `$PWD/$(dirname ...)`
+#      kept `..` segments uncollapsed (e.g. `nonexistent/../../etc` would
+#      string-prefix-match `$PWD` even though it escapes);
+#   2. bash's `cd` returns the *logical* path, so a symlink under `$PWD`
+#      pointing outside would prefix-match `$PWD` while the real target
+#      sat elsewhere on disk.
+PWD_REAL=$(python3 -c 'import os; print(os.path.realpath("."))')
+OUTPUT_REAL=$(python3 -c 'import os, sys; print(os.path.realpath(sys.argv[1]))' "$OUTPUT_PATH")
+case "$OUTPUT_REAL/" in
+  "$PWD_REAL"/*) ;;
+  *)
+    echo "ERROR: refusing to write to '$OUTPUT_PATH' — resolved path '$OUTPUT_REAL' escapes \$PWD ($PWD_REAL)." >&2
+    echo "       Pass an output path that resolves under the current working directory." >&2
+    exit 1
+    ;;
+esac
+
+if ! command -v sf &>/dev/null; then
+  echo "ERROR: Salesforce CLI (sf) is not installed." >&2
+  echo "Install: https://developer.salesforce.com/tools/salesforcecli" >&2
+  exit 2
+fi
+
+GRAPHQL_PATH="/services/data/v${API_VERSION}/graphql"
+
+echo "Fetching LDS GraphQL schema for org '${ALIAS}' (api v${API_VERSION})..." >&2
+echo "Introspection can take 30-90s for large orgs." >&2
+
+INTROSPECTION_QUERY='{"query":"query IntrospectionQuery { __schema { queryType { name } mutationType { name } subscriptionType { name } types { kind name description fields(includeDeprecated: true) { name description args { name description type { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name } } } } } } } defaultValue } type { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name } } } } } } } isDeprecated deprecationReason } inputFields { name description type { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name } } } } } } } defaultValue } interfaces { kind name ofType { kind name } } enumValues(includeDeprecated: true) { name description isDeprecated deprecationReason } possibleTypes { kind name } } } }","variables":{},"operationName":"IntrospectionQuery"}'
+
+INTROSPECTION_FILE=$(mktemp)
+trap 'rm -f "$INTROSPECTION_FILE"' EXIT
+
+# Use `sf api request rest`, which authenticates internally from the CLI's
+# stored credentials — the access token never enters this script's process
+# arguments, environment, or shell history (Prizm S1). Body is passed via a
+# temp file (`--body @file`) so the query text also stays out of the argv.
+BODY_FILE=$(mktemp)
+trap 'rm -f "$INTROSPECTION_FILE" "$BODY_FILE"' EXIT
+printf '%s' "$INTROSPECTION_QUERY" >"$BODY_FILE"
+
+if ! sf api request rest "$GRAPHQL_PATH" \
+  --target-org "$ALIAS" \
+  --method POST \
+  --header "Content-Type: application/json" \
+  --header "X-Chatter-Entity-Encoding: false" \
+  --body "@${BODY_FILE}" \
+  >"$INTROSPECTION_FILE" 2>"${INTROSPECTION_FILE}.err"; then
+  # `sf api request rest` exits non-zero on auth failure or HTTP >= 400.
+  # Don't echo the response/error body — Salesforce error payloads can carry
+  # request headers or signed front-door URLs we don't want in shared logs.
+  echo "ERROR: Introspection request failed for org '${ALIAS}'." >&2
+  echo "       If authentication expired, re-authenticate: sf org login web --alias $ALIAS" >&2
+  echo "       Diagnostic output left at: ${INTROSPECTION_FILE}.err" >&2
+  echo "       Inspect with: head -c 500 \"${INTROSPECTION_FILE}.err\" (and remove when done)" >&2
+  trap 'rm -f "$BODY_FILE"' EXIT  # leave response + err in place for the user
+  exit 3
+fi
+rm -f "${INTROSPECTION_FILE}.err"
+
+if [ ! -s "$INTROSPECTION_FILE" ]; then
+  echo "ERROR: Empty introspection response." >&2
+  exit 4
+fi
+
+OUTPUT_DIR="$(dirname "$OUTPUT_PATH")"
+[ -n "$OUTPUT_DIR" ] && mkdir -p "$OUTPUT_DIR"
+
+python3 - "$INTROSPECTION_FILE" "$OUTPUT_PATH" <<'PYEOF'
+import json, sys
+
+intro_path, out_path = sys.argv[1], sys.argv[2]
+
+with open(intro_path) as f:
+    payload = json.load(f)
+
+errors = payload.get("errors") or []
+schema = (payload.get("data") or {}).get("__schema") or {}
+types = schema.get("types") or []
+
+if errors:
+    print(f"ERROR: introspection returned {len(errors)} errors. First: {errors[0]}", file=sys.stderr)
+    sys.exit(4)
+if not types:
+    print("ERROR: introspection returned zero types.", file=sys.stderr)
+    sys.exit(4)
+
+
+def render_type_ref(t):
+    """Recursively render a type reference like NonNull(List(NonNull(Account)))."""
+    if t is None:
+        return "Unknown"
+    kind = t.get("kind")
+    if kind == "NON_NULL":
+        return render_type_ref(t.get("ofType")) + "!"
+    if kind == "LIST":
+        return "[" + render_type_ref(t.get("ofType")) + "]"
+    return t.get("name") or "Unknown"
+
+
+def render_args(args):
+    if not args:
+        return ""
+    rendered = []
+    for a in args:
+        s = f"{a['name']}: {render_type_ref(a.get('type'))}"
+        if a.get("defaultValue") is not None:
+            s += f" = {a['defaultValue']}"
+        rendered.append(s)
+    return "(" + ", ".join(rendered) + ")"
+
+
+def render_fields(fields):
+    out = []
+    for f in fields or []:
+        line = f"  {f['name']}{render_args(f.get('args'))}: {render_type_ref(f.get('type'))}"
+        if f.get("isDeprecated"):
+            reason = (f.get("deprecationReason") or "").replace('"', '\\"')
+            line += f' @deprecated(reason: "{reason}")'
+        out.append(line)
+    return "\n".join(out)
+
+
+def render_input_fields(fields):
+    out = []
+    for f in fields or []:
+        line = f"  {f['name']}: {render_type_ref(f.get('type'))}"
+        if f.get("defaultValue") is not None:
+            line += f" = {f['defaultValue']}"
+        out.append(line)
+    return "\n".join(out)
+
+
+# Render in stable order; skip GraphQL builtin __ types (introspection meta-types).
+chunks = []
+for t in sorted(types, key=lambda x: (x.get("name") or "")):
+    name = t.get("name") or ""
+    kind = t.get("kind")
+    if name.startswith("__"):
+        continue
+    if kind == "OBJECT":
+        interfaces = t.get("interfaces") or []
+        impl = ""
+        if interfaces:
+            impl = " implements " + " & ".join(i["name"] for i in interfaces if i.get("name"))
+        body = render_fields(t.get("fields"))
+        chunks.append(f"type {name}{impl} {{\n{body}\n}}")
+    elif kind == "INTERFACE":
+        body = render_fields(t.get("fields"))
+        chunks.append(f"interface {name} {{\n{body}\n}}")
+    elif kind == "INPUT_OBJECT":
+        body = render_input_fields(t.get("inputFields"))
+        chunks.append(f"input {name} {{\n{body}\n}}")
+    elif kind == "ENUM":
+        values = "\n".join(f"  {v['name']}" for v in (t.get("enumValues") or []))
+        chunks.append(f"enum {name} {{\n{values}\n}}")
+    elif kind == "UNION":
+        members = " | ".join(p["name"] for p in (t.get("possibleTypes") or []) if p.get("name"))
+        chunks.append(f"union {name} = {members}")
+    elif kind == "SCALAR":
+        # Skip the standard scalars; emit only org-defined ones.
+        if name in ("String", "Int", "Float", "Boolean", "ID"):
+            continue
+        chunks.append(f"scalar {name}")
+
+with open(out_path, "w") as f:
+    f.write("\n\n".join(chunks))
+    f.write("\n")
+
+# Sanity: count Record-implementing types so the caller can sanity-check the output.
+record_count = sum(1 for t in types if any((i.get("name") == "Record") for i in (t.get("interfaces") or [])))
+print(f"types_total={len(types)} types_implementing_Record={record_count}", file=sys.stderr)
+PYEOF
+
+LINE_COUNT=$(wc -l <"$OUTPUT_PATH" | tr -d ' ')
+echo "Schema written to ${OUTPUT_PATH} (${LINE_COUNT} lines)." >&2

package/skills/experience-lds-graphql-generate/scripts/test-lds-graphql-query.sh

@@ -0,0 +1,128 @@
+#!/usr/bin/env bash
+#
+# LDS GraphQL Query Tester
+#
+# Executes a GraphQL query or mutation against the LDS endpoint of a connected
+# Salesforce org and prints the raw JSON response. Use this to validate a
+# generated query end-to-end before handing it to the developer.
+#
+# Usage:
+#   test-lds-graphql-query.sh USERNAME_OR_ALIAS 'GRAPHQL_QUERY' ['VARIABLES_JSON'] [API_VERSION] [OPERATION_NAME]
+#
+# Arguments:
+#   $1  usernameOrAlias    SF CLI alias or username for the target org (required)
+#   $2  query              Complete GraphQL query or mutation string (required)
+#   $3  variables          Variables JSON object (default: {})
+#   $4  apiVersion         API version (default: 66.0, matching the legacy
+#                          test_lds_graphql_query MCP tool's DEFAULT_API_VERSION)
+#   $5  operationName      Operation to run when the query string defines
+#                          multiple named operations (default: omitted)
+#
+# Exit codes:
+#   0  Query executed and returned HTTP 200 (the response itself may still
+#      contain a GraphQL `errors` field; the caller categorizes those)
+#   1  Argument error
+#   2  Salesforce CLI missing
+#   3  Auth or HTTP failure
+
+set -euo pipefail
+
+if [ $# -lt 2 ]; then
+  echo "Usage: $0 USERNAME_OR_ALIAS 'GRAPHQL_QUERY' ['VARIABLES_JSON'] [API_VERSION] [OPERATION_NAME]" >&2
+  exit 1
+fi
+
+ALIAS="$1"
+QUERY="$2"
+VARIABLES="${3-}"
+[ -z "$VARIABLES" ] && VARIABLES='{}'
+API_VERSION="${4:-66.0}"
+OPERATION_NAME="${5-}"
+
+# Mutation guard: this script's name says "tester" — by default we refuse to
+# execute write operations (`mutation`) since they have side effects on the
+# connected org. Set LDS_ALLOW_MUTATIONS=1 to opt in when intentionally
+# testing a mutation.
+#
+# Detection runs in python3 so we can:
+#   1. Strip line comments (`# ...`) before scanning, so a `# mutation note`
+#      comment doesn't trip the guard.
+#   2. Anchor on operation-start (`^mutation` or `}\smutation`), not bash
+#      word-class boundaries — bash's `[[:space:]]|\{|$` boundary class
+#      missed `mutation(...)` (variables), `mutation@auth` (directives),
+#      and `mutation#comment`, all of which are valid GraphQL.
+#   3. Avoid the `query { mutation: get }` field-alias false positive:
+#      `mutation` only counts when followed by name / vars / directive /
+#      `{`, not by `:` (alias) or `=` (default value).
+if [ "${LDS_ALLOW_MUTATIONS:-0}" != "1" ]; then
+  if ! printf '%s' "$QUERY" | python3 -c '
+import re, sys
+src = sys.stdin.read()
+# Strip GraphQL line comments (`# ...` to end of line) before scanning.
+src = re.sub(r"#[^\n]*", "", src)
+# Trim leading whitespace so the `^` anchor below sees the first real
+# token. Heredocs, file-read queries, and multiline shell strings often
+# carry leading newlines/spaces that would otherwise hide a top-level
+# `mutation` from the `^mutation` branch.
+src = src.lstrip()
+# Match `mutation` only at operation-start: either at the start of the
+# stripped source, or after a `}` that closes a previous operation. The
+# trailing class accepts every valid follow-up for a mutation operation:
+# identifier (name), `(` (variables), `@` (directive), `{` (anonymous
+# body), whitespace, or end-of-input. This deliberately excludes `:`
+# (field alias, e.g. `query { mutation: get }`) and `=` (default value).
+if re.search(r"(?:^|\}\s*)mutation(?:\s|$|[A-Za-z_(@{])", src):
+    sys.exit(2)
+sys.exit(0)
+'; then
+    echo "ERROR: refusing to execute a mutation — this script is a read-only tester by default." >&2
+    echo "       To intentionally run a mutation, re-invoke with LDS_ALLOW_MUTATIONS=1:" >&2
+    echo "         LDS_ALLOW_MUTATIONS=1 $0 ..." >&2
+    exit 1
+  fi
+fi
+
+if ! command -v sf &>/dev/null; then
+  echo "ERROR: Salesforce CLI (sf) is not installed." >&2
+  exit 2
+fi
+
+GRAPHQL_PATH="/services/data/v${API_VERSION}/graphql"
+
+REQUEST_BODY=$(python3 -c '
+import sys, json
+body = {"query": sys.argv[1], "variables": json.loads(sys.argv[2].strip())}
+if sys.argv[3]:
+    body["operationName"] = sys.argv[3]
+print(json.dumps(body))
+' "$QUERY" "$VARIABLES" "$OPERATION_NAME")
+
+RESPONSE_FILE=$(mktemp)
+BODY_FILE=$(mktemp)
+trap 'rm -f "$RESPONSE_FILE" "$BODY_FILE"' EXIT
+printf '%s' "$REQUEST_BODY" >"$BODY_FILE"
+
+# Use `sf api request rest`, which authenticates internally from the CLI's
+# stored credentials — the access token never enters this script's process
+# arguments, environment, or shell history (Prizm S1). Body is passed via a
+# temp file (`--body @file`) so the query text also stays out of the argv.
+if ! sf api request rest "$GRAPHQL_PATH" \
+  --target-org "$ALIAS" \
+  --method POST \
+  --header "Content-Type: application/json" \
+  --header "X-Chatter-Entity-Encoding: false" \
+  --body "@${BODY_FILE}" \
+  >"$RESPONSE_FILE" 2>"${RESPONSE_FILE}.err"; then
+  # `sf api request rest` exits non-zero on auth failure or HTTP >= 400.
+  # Don't echo the response/error body — Salesforce error payloads can carry
+  # request headers or signed URLs we don't want surfacing in shared logs.
+  echo "ERROR: GraphQL request failed for org '${ALIAS}'." >&2
+  echo "       If authentication expired, re-authenticate: sf org login web --alias $ALIAS" >&2
+  echo "       Diagnostic output left at: ${RESPONSE_FILE}.err" >&2
+  echo "       Inspect with: head -c 500 \"${RESPONSE_FILE}.err\" (and remove when done)" >&2
+  trap 'rm -f "$BODY_FILE"' EXIT  # leave response + err in place for the user
+  exit 3
+fi
+rm -f "${RESPONSE_FILE}.err"
+
+cat "$RESPONSE_FILE"

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

@@ -0,0 +1,112 @@
+---
+name: experience-lwc-accessibility-validate
+description: "Use this skill to determine whether a Lightning Web Component (LWC) is accessible and meets WCAG accessibility guidelines. TRIGGER when the user asks \"is my component accessible?\", \"does my LWC meet accessibility guidelines?\", \"is this component WCAG compliant?\", \"find accessibility problems in this LWC\", \"is this LWC keyboard accessible?\", \"does this component work with a screen reader?\", \"does this component have sufficient color contrast?\", \"check ARIA usage in this LWC\", or \"WCAG 2.2 accessibility check\". Also TRIGGER when the user wants to fix or improve accessibility (a11y, WCAG, ARIA) in an LWC's HTML, JS, or CSS — semantic markup, focus, keyboard nav, contrast, screen-reader labels, WCAG 2.2 SC. Produces `a11y-review.md` with WCAG-cited findings. DO NOT TRIGGER for general LWC generation (use `experience-lwc-generate`) or SLDS visual/design review not focused on accessibility (use `design-systems-slds-validate`)."
+metadata:
+  version: "1.1"
+  cliTools:
+    - tool: ["python3"]
+      semver: ">=3.8"
+  relatedSkills:
+    - "design-systems-slds-validate"
+    - "experience-lwc-generate"
+---
+<!-- adk-managed-skill -->
+
+# Web Component Accessibility
+
+Accessibility (a11y) patterns and remediation guidance for web components.
+Reference any time work involves the visible or interactive surface of a
+component — generating, modifying, reviewing, or styling HTML, JS, or
+CSS — to apply WCAG 2.2 standards.
+
+## Review Context
+
+Conduct a review specifically focused on enhancing web accessibility, guided by the WCAG (Web Content Accessibility Guidelines).
+
+In order to mark code as a violation, it must have a direct correlation to the WCAG rule cited such that it is a clear violation of the criteria.
+
+Key Review Criteria:
+
+1. Focus Exclusively on Accessibility:
+
+- Evaluate the component solely for accessibility.
+- Only consider compliance with the cited WCAG Success Criteria, ignoring violations that can be attributed to other criteria.
+- Avoid addressing general code style, patterns, or issues unrelated to accessibility.
+
+2. Ensure Minimum and Sufficient Accessibility:
+
+- Identify accessibility issues that prevent the component from meeting the minimum requirements outlined by WCAG.
+- Avoid suggesting enhancements that go beyond the scope of WCAG compliance unless strictly necessary.
+
+3. WAI-ARIA Usage:
+
+- Use WAI-ARIA attributes only when strictly required to achieve accessibility that cannot otherwise be addressed with semantic HTML.
+- Avoid unnecessary complexity or potential regressions caused by incorrect or overuse of ARIA attributes.
+
+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.
+
+**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.
+
+### Perceivable
+
+- [SC 1.1.1 Non-text Content](references/reviewers/sc-1-1-1-non-text-content.md)
+- [SC 1.3.1 (i) Lists](references/reviewers/sc-1-3-1-i-lists.md)
+- [SC 1.3.1 (ii) Tables](references/reviewers/sc-1-3-1-ii-tables.md)
+- [SC 1.3.1 (iii) Form Labels](references/reviewers/sc-1-3-1-iii-form-labels.md)
+- [SC 1.3.1 (iv) Regions](references/reviewers/sc-1-3-1-iv-regions.md)
+- [SC 1.3.1 (v) Groups](references/reviewers/sc-1-3-1-v-groups.md)
+- [SC 1.3.5 Identify Input Purpose](references/reviewers/sc-1-3-5-identify-input.md)
+- [SC 1.4.3 Contrast (Minimum)](references/reviewers/sc-1-4-3-contrast.md)
+
+### Operable
+
+- [SC 2.1.1 Keyboard](references/reviewers/sc-2-1-1-keyboard.md)
+- [SC 2.4.4 Link Purpose](references/reviewers/sc-2-4-4-link-purpose.md)
+- [SC 2.4.6 Headings and Labels](references/reviewers/sc-2-4-6-headings-labels.md)
+- [SC 2.5.1 Pointer Gestures](references/reviewers/sc-2-5-1-pointer-gestures.md)
+- [SC 2.5.2 Pointer Cancellation](references/reviewers/sc-2-5-2-pointer-cancellation.md)
+- [SC 2.5.3 Label in Name](references/reviewers/sc-2-5-3-label-in-name.md)
+- [SC 2.5.7 Dragging Movements](references/reviewers/sc-2-5-7-dragging-movement.md)
+
+### Understandable
+
+- [SC 3.2.1 On Focus](references/reviewers/sc-3-2-1-on-focus.md)
+- [SC 3.2.2 On Input](references/reviewers/sc-3-2-2-on-input.md)
+- [SC 3.3.1 Error Identification](references/reviewers/sc-3-3-1-error-identification.md)
+- [SC 3.3.2 Labels or Instructions](references/reviewers/sc-3-3-2-labels-instructions.md)
+- [SC 3.3.3 Error Suggestion](references/reviewers/sc-3-3-3-error-suggestion.md)
+
+### Robust
+
+- [SC 4.1.2 (i) Name](references/reviewers/sc-4-1-2-i-name.md)
+- [SC 4.1.2 (ii) Role](references/reviewers/sc-4-1-2-ii-role.md)
+- [SC 4.1.2 (iii) Value](references/reviewers/sc-4-1-2-iii-value.md)
+
+### Vision-Assisted Review
+
+When component screenshots or design mocks are available, augment the
+source-code review with these vision-level reviewers. Each reference covers
+image-based evaluation for the corresponding Success Criterion — contrast
+ratios, color dependence, resize/reflow behavior, and non-text content
+identification from pixels rather than from the DOM.
+
+- [SC 1.1.1 Non-text Content (vision)](references/vision/sc-1-1-1-non-text-content.md)
+- [SC 1.4.1 Use of Color (vision)](references/vision/sc-1-4-1-use-of-color.md)
+- [SC 1.4.3 Contrast (vision)](references/vision/sc-1-4-3-contrast.md)
+- [SC 1.4.10 Reflow (vision)](references/vision/sc-1-4-10-resize-reflow.md)
+- [SC 1.4.11 Non-text Contrast (vision)](references/vision/sc-1-4-11-non-text-contrast.md)
+
+## Review Output
+
+For each Success Criterion you evaluated, report violations found. If no
+violations exist for a criterion, return an empty list for that criterion.

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

@@ -0,0 +1,88 @@
+## SC 1.1.1 - Non-text Content (Level A)
+
+All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for specific situations such as controls or input, time-based media, test, sensory, CAPTCHA, and decoration or formatting.
+
+## SC: 1.1.1 - Non-text Content (All Images)
+
+This reviewer focuses on both decorative and informative images and their proper accessibility handling.
+
+### Definition of Decorative Image:
+
+A decorative image is one that:
+
+- Provides no information content
+- Is used for visual formatting, spacing, or decoration
+- Does not convey meaning or context
+- Is not essential to understanding the content
+
+### Definition of Informative Image:
+
+An informative image is any image that conveys information, meaning, or context that is essential to understanding the content or functionality of a webpage or application.
+
+### Analysis Framework(What to do):
+
+1. Identify all `<img>` elements in the HTML
+2. Determine if each image is decorative or informative
+3. Check if decorative images have proper `alt=""` attributes
+4. Check if informative images have meaningful descriptive alt text
+5. Look for CSS background images that should be used instead
+6. Check for ARIA hidden attributes on decorative images
+
+### Goals for Decorative Images:
+
+1. **Empty alt attribute**: Should have `alt=""` for purely decorative images
+   - Good: `<img src="decorative-border.png" alt="" />`
+   - Bad: `<img src="decorative-border.png" />`
+2. **CSS background images**: Should not have alt text as they are not in the accessibility tree
+3. **ARIA hidden**: Can use `aria-hidden="true"` for decorative images that must remain in DOM
+   - Good: `<img src="spacer.gif" alt="" aria-hidden="true" />`
+4. **No redundant text**: Avoid providing descriptive alt text for decorative images
+   - Bad: `<img src="decorative-border.png" alt="Decorative border with flowers" />`
+5. **Decorative image as link without context**: Add `aria-label` or `title` attribute to the anchor tag
+   - Bad: `<a href="/page"><img src="decorative-icon.png" alt="" /></a>`
+   - Good: `<a href="/page" aria-label="Navigate to main page"><img src="decorative-icon.png" alt="" /></a>`
+
+### Goals for Informative Images:
+
+1. **Must have alt attribute**: All informative images must have descriptive alt text
+   - Good: `<img src="company-logo.png" alt="Our Company Logo" />`
+   - Bad: `<img src="chart.png" />`
+2. **Meaningful content**: Alt text should describe the information conveyed
+   - Good: `<img src="chart.png" alt="Quarterly sales performance chart showing revenue trends" />`
+   - Bad: `<img src="chart.png" alt="chart" />`
+
+### What to Look For:
+
+- `<img>` elements without alt attributes (both decorative and informative)
+- `<img>` elements with generic alt text like "image", "picture", "photo"
+- Decorative images that are not properly marked as decorative
+- Informative images with missing or inadequate alt text
+- Background images that are incorrectly implemented as `<img>` elements
+- Decorative images used in interactive contexts without proper labeling
+
+### Common Violations for Images:
+
+- Missing alt attribute on decorative images
+- Missing alt attribute on informative images
+- Using `alt="image"` or `alt="picture"` for decorative images
+- Providing descriptive alt text for purely decorative images
+- Using decorative images as links without proper context
+- Including decorative images in the accessibility tree when they should be hidden
+
+Rules to follow:
+
+- Focus specifically on decorative or non decorative images and their alt text handling in the provided HTML and JS files
+- Flag missing alt attributes on decorative images
+- Flag generic alt text (like "image", "picture") on decorative images
+- 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
+
+- 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-lwc-accessibility-validate/references/reviewers/sc-1-3-1-i-lists.md

@@ -0,0 +1,52 @@
+## SC 1.3.1 - Info and Relationships (Level A)
+
+Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
+
+## SC: 1.3.1 (i) - Info And Relationships - Lists (A)
+
+Review the provided HTML and JS files for accessibility violations per WCAG 2.2 SC 1.3.1 (i), 'Info and Relationships'
+(Only lists from this rule should be considered). For all lists on the page, ensure that any information conveyed through presentation is programmatically determinable in order to determine if they meet SC 1.3.1 (i).
+If they do not meet this success criterion, flag it as a violation.
+
+Rules to follow:
+
+- Find all violations of SC 1.3.1 'Info and Relationships - Lists' in the provided HTML and JS files.
+- Do not worry about violations of SC 1.3.1 that are not specific to lists. These will be handled by other reviewers.
+- The preferred technique for fixing SC 1.3.1 lists violations is The objective of this technique is to create lists of related items using list elements appropriate for their purposes.
+  The ol element is used when the list is ordered and the ul element is used when the list is unordered.
+  Description lists (dl) are used to group name-value pairs of information, for example: terms and definitions or questions and answers.
+  Although the use of this markup can make lists more readable, not all lists need markup.
+  For instance, sentences that contain comma-separated lists may not need list markup.
+  When markup is used that visually formats items as a list but does not indicate the list relationship, users may have difficulty in navigating the information.
+  An example of such visual formatting is including asterisks in the content at the beginning of each list item and using br elements to separate the list items.
+  Some assistive technologies allow users to navigate from list to list or item to item.
+  Style sheets can be used to change the presentation of the lists while preserving their integrity.
+  The list structure, commonly unordered lists, is also useful to group hyperlinks.
+  When this is done, it helps screen reader users to navigate from the first item in a list to the end of the list or jump to the next list.
+  This helps them to bypass groups of links if they choose to..
+- The procedure for H48 is Check that content that has the visual appearance of a list (with or without bullets) is marked as an unordered list.
+  Check that content that has the visual appearance of a numbered list is marked as an ordered list.
+  Check that content is marked as a description list when groups of name-value pairs, for example: terms and definitions or questions and answers, are presented in the form of a list..
+- If the contents of the list are ordered, it must use the `<ol>` element.
+- When a sublist is indented, use a ul or ol inside a list item to properly communicate the new list level/position within the parent.
+- When creating description lists where the elements are iterated over with a template for:each loop ALWAYS insert a wrapper div element for each object in the array. Place the unique key attribute on the wrapper div element. Here is an example:
+
+```html
+<dl>
+  <template for:each={entries} for:item="entry">
+    <div key={entry.foo} class="entry-item">
+      <dt class="foo">{entry.foo}</dt>
+      <dd class="bar">{entry.bar}</dd>
+    </div>
+  </template>
+</dl>
+```
+
+- 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.