yknothing Accessibility
Accessibility is not a polish pass. It is a product requirement that must survive design, implementation, and QA.
Context
Use this skill when UI work, interaction design, content structure, or acceptance criteria need explicit accessibility treatment.
See context and anti-pattern notes.
Inputs
I/O contract notes define required inputs and authority.
Process
Step 1: Identify the user-facing surface
List the screens, controls, content blocks, and interaction states affected by the change.
Step 2: Define the accessibility contract
Specify the expected behavior for:
- keyboard access
- focus order and visible focus
- semantic structure and labels
- contrast and status communication
- error handling and announcements
Step 3: Turn requirements into checks
Translate the contract into reviewable checks that implementation and QA can execute without guesswork.
Step 4: Record the remediation path
If gaps already exist, document the minimum remediation sequence and who owns each part.
Outputs
Produce only declared outputs at their documented quality boundary.
Quality Gate
- Affected UI surfaces are named explicitly
- Keyboard, semantics, feedback, and contrast expectations are documented
- Reviewers can verify the result without inventing extra rules