Practical guide · AI & interfaces
7 min read
Updated
Verify a readable, keyboard-accessible interface
Run a bounded review of semantics, keyboard, focus, contrast, and reflow, with reproducible evidence.
Direct answer
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.
01
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.
Prerequisites: a known build, browser, keyboard, contrast measurement tool, and test data. Pick a journey such as opening a settings dialog, editing a value, correcting an error, saving, and returning to the page. Record URL, build, viewport, zoom, operating system, and any assistive technology used. Include empty, loading, and error states in the scope.
02
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.
Compare the spoken or exposed name with visible wording. Check required, invalid, selected, expanded, and disabled states where relevant. An error needs text and a relationship to its field; color alone is insufficient. For custom controls, use the documented pattern and test it in the real interface.
03
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.
Open and close each temporary surface. In a modal dialog, confirm focus enters, remains inside while open, and returns to a sensible control after closing; test Escape when dismissal is supported. Other surfaces need their own behavior contract. If focus disappears or gets trapped, record the last key and control, fix the cause, then repeat the entire route.
04
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.
Test text resizing to 200% and reflow at 320 CSS pixels wide, for example 400% zoom from a 1280 CSS-pixel viewport. Confirm content and actions remain available without two-dimensional scrolling, except content that inherently needs it, such as a data table. Inspect long labels, validation text, and sticky bars; fix clipping and replay the task.
05
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.
For each defect, record steps, expected result, observed result, affected control, and a screenshot or measurement where useful. After correction, rerun the failed step and its neighboring transitions. Report passed, failed, and untested checks separately. This bounded review does not cover every WCAG criterion, device, disability, or task; a broader evaluation remains separate.
- A scan flags a missing name: inspect the affected control and verify the corrected accessible name.
- A keyboard pass finds a trap: capture the key sequence and replay it after correction.
- A combination was not exercised: mark it untested and identify the next manual check.
Keep this
Evidence to keep
- 01The whole task is completed using the keyboard with visible focus.
- 02Contrast measurements and zoom/reflow observations identify their states.
- 03Automated results, manual observations, and untested scope stay distinct.
- 04Controls expose names and states that match their visible purpose.
- 05Closing a temporary surface restores focus according to its behavior contract.
- 06Each corrected defect is retested with its neighboring transitions on the identified build.
Primary sources
Technical claims in this guide connect to first-party specifications and documentation.
- Easy Checks: a first review (opens in a new tab)W3C WAI · Primary reference supporting the procedure; examples and workflow are original editorial guidance.
- How to Meet WCAG 2.2 (opens in a new tab)W3C WAI · Primary reference supporting the procedure; examples and workflow are original editorial guidance.
- Contrast minimum (opens in a new tab)W3C WAI · Primary reference supporting the procedure; examples and workflow are original editorial guidance.
- Reflow (opens in a new tab)W3C WAI · Primary reference supporting the procedure; examples and workflow are original editorial guidance.
Continue
Related guides and tools
Understand → Recognize → Choose → Compare
Pack for your agent
Pre-written instruction by SkillCodex — your request is neither sent nor used to adapt this text; no content is generated, and copying executes nothing.
Implement correctly
Apply “Verify a readable, keyboard-accessible interface” step by step
# Apply the “Verify a readable, keyboard-accessible interface” 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: Run a bounded review of semantics, keyboard, 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. ## 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
Why it works
- The steps come from a published, sourced guide, not improvisation.
- The checklist turns advice into verifiable criteria.
- The declared scope keeps the guide within its evidence.
Try next
Anchor the guide in the project
# 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:29c6f6b32c6f34b64270bcd8f1de127db060b4069de7d066f1cdd752307e7e18
Diagnose a problem
Diagnose a “Verify a readable, keyboard-accessible interface” guide gap
# Diagnose a failed application of the “Verify a readable, keyboard-accessible interface” 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. ## 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
Why it works
- The diagnosis replays ordered steps instead of searching at random.
- Fixes stay bounded to the first real divergence.
- The checklist serves as a reproducible final verification.
Try next
Prevent the next drift
# 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:16fedf043717172ec421889a66a4958226cccb96d6d9e10f8dba821924c62ea2
Pack digest: sha256:81cc459e985c489a8acbdc44e12fdb01e668577d63b7f7ae8a385cf57396e2fd