Task
A fictional settings form silently rejects an empty project name. Add an accessible inline error while preserving entered data. The fixture contains no personal or production data.
Selected assets
- Shared kernel:
docs/template-library/GOVERNANCE-KERNEL.md - Prompt:
prompts/27-accessibility-remediation-prompt.md - Skill:
skills/10-keyboard-testing-skill.md - Contract:
contracts/07-accessibility-contract-plus.md
Scoped work
Inspect the form submit handler, field markup, error renderer, focus management, styles, and tests. Change only the project-name validation path. Do not redesign the form, add a dependency, or claim overall conformance.
Implementation evidence
The hypothetical patch adds a persistent error element, connects it with aria-describedby, sets aria-invalid="true" after failed validation, preserves other values, and focuses the first invalid control. The implementation does not add redundant live regions or replace the native input.
Verification
Expected evidence for this fictional example:
- A unit test proves empty and whitespace-only values are rejected.
- A browser test submits the form, observes the connected error, verifies focus, and confirms other input remains.
- A keyboard pass confirms focus remains visible and the correction path works.
- An axe scan reports no serious violations in the tested form state.
No command is reported as passed here because this is a teaching example rather than an executed repository change.
Limitations
The evidence would cover one validation state in the tested browser. It would not establish WCAG conformance, screen-reader usability across platforms, or correctness of unrelated form states.
Final status
not verified — the example defines the required evidence but intentionally contains no fabricated execution result.