Verify keyboard and screen reader accessibility of a website

# Apply the “Verify keyboard and screen reader accessibility of a website” guide in your agent

## Objective
Test a complete task using only the keyboard, inspect names and states, measure contrast, and check text resizing and reflow. Combine real interactions with automated findings, then record failures and untested combinations. This bounded procedure provides evidence for that task, not a WCAG conformance certification.

## Prerequisites
- Inspect the repository, documentation, and existing conventions.
- Confirm the need matches the guide scope: Check that an interface or website stays readable and usable with a keyboard and screen reader, then inspect semantics, focus, contrast, and reflow with reproducible evidence.
- Preserve the correct decisions already in place.

## Guide steps
- 1. 1. Select a complete task — Test whether someone can finish a concrete task while seeing and understanding each control and state. Combine manual interaction with measurements and automated checks; passing this procedure is not a WCAG conformance certification.
- 2. 2. Check what controls communicate — Inspect native semantics first: buttons perform actions, links navigate, labels name form controls, and headings organize content. Confirm accessible names in the browser accessibility tree, including icon-only buttons. ARIA roles do not implement keyboard behavior.
- 3. 3. Complete the task without a pointer — Start at the page entry and use Tab and Shift+Tab through the task. The order should follow the reading and action sequence, with a visible focus indicator that is not hidden by sticky content. Activate links with Enter and buttons with Enter or Space. Use arrow keys only where the control pattern calls for them.
- 4. 4. Measure contrast and reflow — Measure actual foreground/background pairs, including errors, placeholders, hover, and focus states in each supported theme. WCAG AA text contrast generally requires 4.5:1, or 3:1 for large text (at least 18 pt regular or 14 pt bold). Check the criterion’s exceptions; do not round a failing result up. Required visual boundaries and state indicators generally need 3:1 against adjacent colors under the non-text contrast criterion.
- 5. 5. Keep failures reproducible and limits explicit — Run an automated accessibility scan on the same states to catch detectable issues. It cannot decide whether focus order makes sense, a label is useful, or the whole journey works with assistive technology. Add a manual screen-reader pass for the chosen combinations, including announcements after save and error.
- 6. Distinguish narrow layout from missing content — At a width equivalent to 320 CSS pixels, follow the main task from its heading to its final action. Check that text, errors and controls remain available without two-dimensional scrolling, except content that genuinely requires a two-dimensional layout.

## Acceptance criteria — Evidence to keep
- The whole task is completed using the keyboard with visible focus.
- Contrast measurements and zoom/reflow observations identify their states.
- Automated results, manual observations, and untested scope stay distinct.
- Controls expose names and states that match their visible purpose.
- Closing a temporary surface restores focus according to its behavior contract.
- Each corrected defect is retested with its neighboring transitions on the identified build.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

• Requires · The real project context: repository, documentation, and existing constraints

# Anchor the guide in the project

## Objective
Turn the applied steps into durable repository conventions.

## Checks
- Link each decision made to the guide step that justifies it.
- Add the checklist to the relevant reviews.
- Record out-of-scope cases for the neighboring guides.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

sha256:b06b8500450618ded50a46db8435811470d323ed28677be0cb5880934b01ffe4

# Diagnose a failed application of the “Verify keyboard and screen reader accessibility of a website” guide

## Observed symptom
[DESCRIBE THE SYMPTOM HERE]

## Observable checks
- Replay the steps in order and note the first one that diverges:
- 1. 1. Select a complete task — Test whether someone can finish a concrete task while seeing and understanding each control and state. Combine manual interaction with measurements and automated checks; passing this procedure is not a WCAG conformance certification.
- 2. 2. Check what controls communicate — Inspect native semantics first: buttons perform actions, links navigate, labels name form controls, and headings organize content. Confirm accessible names in the browser accessibility tree, including icon-only buttons. ARIA roles do not implement keyboard behavior.
- 3. 3. Complete the task without a pointer — Start at the page entry and use Tab and Shift+Tab through the task. The order should follow the reading and action sequence, with a visible focus indicator that is not hidden by sticky content. Activate links with Enter and buttons with Enter or Space. Use arrow keys only where the control pattern calls for them.
- 4. 4. Measure contrast and reflow — Measure actual foreground/background pairs, including errors, placeholders, hover, and focus states in each supported theme. WCAG AA text contrast generally requires 4.5:1, or 3:1 for large text (at least 18 pt regular or 14 pt bold). Check the criterion’s exceptions; do not round a failing result up. Required visual boundaries and state indicators generally need 3:1 against adjacent colors under the non-text contrast criterion.
- 5. 5. Keep failures reproducible and limits explicit — Run an automated accessibility scan on the same states to catch detectable issues. It cannot decide whether focus order makes sense, a label is useful, or the whole journey works with assistive technology. Add a manual screen-reader pass for the chosen combinations, including announcements after save and error.
- 6. Distinguish narrow layout from missing content — At a width equivalent to 320 CSS pixels, follow the main task from its heading to its final action. Check that text, errors and controls remain available without two-dimensional scrolling, except content that genuinely requires a two-dimensional layout.

## Possible causes
- A step was skipped or executed out of order.
- The actual need falls outside the guide scope.
- A checklist criterion was never verified.

## Bounded fixes
- Redo only the diverging step and what depends on it.
- Document the gap if the guide scope does not cover the need.

## Final verification — Evidence to keep
- The whole task is completed using the keyboard with visible focus.
- Contrast measurements and zoom/reflow observations identify their states.
- Automated results, manual observations, and untested scope stay distinct.
- Controls expose names and states that match their visible purpose.
- Closing a temporary surface restores focus according to its behavior contract.
- Each corrected defect is retested with its neighboring transitions on the identified build.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

• Requires · The real project context: repository, documentation, and existing constraints

# Prevent the next drift

## Objective
Turn the first diverging step into an explicit project check.

## Checks
- Add a focused check on the step that diverged.
- Verify the checklist on a second real case.
- Document the scope limit you hit.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

sha256:f96175133652328997b91ca2a75f8bad1248ede365aa0f601cc7c87e82580a99