Frontend State Accessibility

Skill: Frontend State Accessibility

Intent

Ensure that frontend requirements produce usable, testable, accessible UI behavior rather than decorative components.

This skill turns UI work into verifiable product behavior: state handling, user flows, accessibility, loading/error/empty states, and regression-safe frontend tests.

Use when

Use this skill when a REQ touches frontend applications, dashboards, forms, tables, workflows, charts, navigation, design profiles, operator consoles, mobile-like responsive UI, or user-facing state.

Do not use when

Do not use this skill for backend-only logic, pure infrastructure, documentation-only work, or non-visual CLI modules.

Signals

• The REQ mentions UI, UX, frontend, React, Vue, Angular, Next.js, dashboard, console, form, page, component, route, design profile, accessibility, WCAG, responsive, loading state, empty state, or error state.
• The REQ has acceptance criteria involving user interaction.
• The selected design profile is non-empty.
• The output includes .tsx, .jsx, .vue, CSS, HTML, frontend routes, or UI tests.

Required behavior

• Implement explicit UI states: loading, empty, error, success, disabled, and permission-denied when relevant.
• Keep state transitions deterministic and testable.
• Use accessible labels, semantic elements, keyboard navigation, focus behavior, and readable error messages.
• Keep generated UI aligned with the selected design profile without cloning external brands.
• Separate presentation from data-fetching and domain rules when the project structure allows it.
• Prefer a small number of strong components over many thin decorative files.
• Document how to run frontend checks in HOWTO.
• Add tests for critical interaction paths when frontend test tooling exists or is generated by the REQ.

Forbidden behavior

• Do not generate static mock UI that only looks correct.
• Do not hardcode successful data when the REQ requires real state or API integration.
• Do not ignore loading, error, or empty states.
• Do not use inaccessible clickable divs when a button or link is semantically correct.
• Do not create brand-cloned visual systems from external products.
• Do not claim accessibility compliance without evidence.
• Do not add large UI frameworks unless the repository already uses them or the REQ explicitly requires them.

Evidence required

• Source files implementing the required user flow.
• Tests or documented manual checks covering at least the primary user path and one failure/empty path.
• HOWTO commands for lint/type/test/build when available.
• Notes describing design profile adherence when a design profile is selected.
• Accessibility evidence: semantic markup, labels, keyboard path, or automated accessibility check when available.

Repair guidance

• If UI is static, introduce state inputs, fixtures, or API boundary wiring.
• If errors are invisible, add user-facing error states.
• If loading behavior is missing, add deterministic loading state.
• If components are inaccessible, replace non-semantic controls with semantic elements and labels.
• If tests cannot run because tooling is absent, document a non-blocking manual verification path and keep generated code compatible with the existing stack.

Gate implications

Gate should block promotion when:

• The REQ is UI/UX scoped and generated UI has no evidence of the required user flow.
• Required frontend checks fail.
• Accessibility-critical controls are clearly non-semantic or unlabeled.
• A selected design profile is ignored without justification.
• The generated UI is decorative only and does not implement acceptance criteria.

Gate may allow non-blocking warnings when:

• Automated accessibility tooling is not available, but semantic evidence and manual checks are documented.
• External API integration is unavailable, but the frontend boundary and local fixtures are testable.

Examples

• A dashboard REQ implements loading, empty, error, and populated states for a table and includes component tests.
• A form REQ validates required fields, announces errors, disables submit during pending state, and documents keyboard verification.
• An operator console REQ uses the industrial-control-room profile and includes evidence for status visibility and alarm readability.

Non-examples

• A dashboard with hardcoded cards and no data boundary.
• A form with placeholder-only validation and no error state.
• A page that visually resembles an external product brand without project-specific rationale.

CLike Promotable KIT Enforcement Layer

Purpose

This layer makes the skill operational for CLike /kit generation.

The goal is not to produce plausible code. The goal is to produce candidate artifacts that can be evaluated, repaired, and promoted through EVAL and GATE with minimal human rework.

Promotable Code Obligations

When this skill is selected for a REQ, the KIT must:

• respect main_module_boundary;
• respect functional_scope and technical_scope;
• generate the smallest complete implementation slice;
• prefer repository-native conventions over invented abstractions;
• produce source files only under the target KIT source root;
• produce tests only under the target KIT test root;
• keep canonical src/, test/, and tests/ read-only during candidate generation;
• document any intentional limitation instead of pretending completeness;
• avoid broad rewrites unless explicitly required by the REQ.

Required Candidate Artifacts

The KIT should produce or update:

runs/kit/<REQ-ID>/src/
runs/kit/<REQ-ID>/test/
runs/kit/<REQ-ID>/ci/LTC.json
runs/kit/<REQ-ID>/ci/HOWTO.md
runs/kit/<REQ-ID>/docs/KIT_<REQ-ID>.md

If the REQ is documentation-only or policy-only, the KIT must explicitly state why source/test artifacts are not required.

Code Shape Expectations

Generated code should favor:

• explicit boundaries;
• dependency injection or constructor/function injection where practical;
• small cohesive modules;
• deterministic local behavior;
• typed schemas/contracts when the stack supports them;
• error paths that are visible and testable;
• safe defaults;
• clear adapter seams for external systems.

Generated code must avoid:

• hidden global state;
• hardcoded environment assumptions;
• silent fallbacks;
• fake success;
• speculative framework layers;
• broad unrelated refactors;
• acceptance criteria implemented only in prose.

Test Expectations

Tests must map to acceptance criteria.

Prefer:

• deterministic unit tests;
• contract tests around adapters and payloads;
• failure-path tests;
• local fake/simulator tests for external dependencies;
• smoke checks only when deeper tests are not possible.

Avoid:

• placeholder tests;
• tests that only import modules when behavior is required;
• tests that require production credentials;
• network-dependent blocking tests unless explicitly scoped.

LTC Expectations

ci/LTC.json must be valid JSON and include enough information for EvalRunner or a local agent to execute checks.

It should include:

• target req_id;
• lane/runtime profile when known;
• blocking local commands;
• optional external commands;
• report paths when available;
• environment-blocked status for unavailable infrastructure;
• gate-relevant policy hints.

HOWTO Expectations

ci/HOWTO.md must be clear enough for a developer to run without guessing.

It should include:

• where to run commands from;
• prerequisites;
• local commands;
• expected result;
• troubleshooting;
• required environment variables;
• optional external validation steps;
• limitations and non-goals.

Gate Impact

GATE should BLOCK promotion when this selected skill is materially violated.

Blocking examples:

• source is not mapped to the target REQ;
• acceptance-critical behavior has no test or executable evidence;
• LTC/HOWTO are missing for runnable code;
• production services or credentials are required for local blocking checks;
• selected capability obligations are ignored;
• generated files modify forbidden canonical roots;
• code claims completeness without evidence.

GATE may WARN when:

• optional external validation is not available but a deterministic local contract check exists;
• documentation is thin but executable evidence is complete;
• future hardening is correctly documented as out of scope.