# Frontend State Accessibility

> Turn frontend requirements into usable, testable, accessible UI behavior with explicit loading/empty/error/success states and keyboard/a11y flows.

- Skill: `authenticfake/frontend-state-accessibility` (Agent Skill)
- Install (CLI): `npx skillmds@latest add authenticfake/frontend-state-accessibility`
- Raw SKILL.md: https://api.skillmd.com/api/skills/authenticfake/frontend-state-accessibility/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: authenticfake (https://skillmd.com/u/authenticfake)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/authenticfake/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:

```text
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.