A public library wants its self-service reservation kiosk to handle form errors predictably for keyboard and screen-reader users. A developer could immediately ask an AI coding agent to modify components, but the failure risk is not only a broken build: the patch might shift keyboard focus to the wrong field or display a color-only error. GitHub Copilot Plan Mode offers a safer starting point. The Plan agent can inspect code and propose work without changing files before approval. This tutorial describes a hypothetical repository and a concrete review process; it does not claim a live kiosk deployment or actual accessibility test result.
Use Plan Mode instead of an editing agent
GitHub describes Plan Mode as a read-only research and planning workflow whose draft can be reviewed before any code changes are made. It is supported in VS Code, JetBrains IDEs, Xcode and Eclipse, while the current guidance does not list Visual Studio as supported for the same mode. In the IDE’s Copilot Chat panel, choose Plan from the agents dropdown before entering the feature request. Confirm that you are in the correct repository and branch. Plan Mode is not an accessibility certification tool, and a safe plan still needs explicit human ownership and later real-device tests.
Write a narrow behavioral specification
The hypothetical request is to improve the kiosk’s reservation form when a required date is missing. Define the current behavior, desired behavior and limits. The error must be announced through accessible text, keyboard focus must move in a predictable way, and the existing valid reservation path must continue to work. A prompt such as ‘make it accessible’ is too broad for review. Instead, say which page and form are in scope, what must remain unchanged, and what keyboard interaction should be tested. Keep passwords, user records and production credentials out of the prompt.
Ask Copilot to locate code and test surfaces
Tell the Plan agent to identify components responsible for validation, focus management, field labels and status messages. Ask it to reference relevant code paths and existing test utilities rather than inventing filenames. It may discover a shared component used by several kiosk screens; that finding belongs in the draft plan because changing it affects more than the reservation flow. Verify file names yourself against the repository. If the agent mentions a nonexistent helper or asserts that a test suite covers screen readers without evidence, mark that item as unverified before any implementation is approved.
Demand an explicit error-state model
Require the plan to represent at least four states: no error, missing required date, invalid date and successful submission. For every state, specify the field value, visible message, announced message and expected focus target. For a missing date, the interface must not simply mark the border red and continue. A suitable plan identifies an accessible error summary or inline message and explains how the user returns to correct the field. These are proposed acceptance criteria, not measured behavior from a working kiosk. The diagram illustrates an incomplete draft and its editorial correction.
Look for hidden scope expansion
A plan that proposes rewriting the entire form framework, adding analytics or introducing a new account service is probably too broad for a focused keyboard fix. Ask why each proposed file needs to change. Explicitly exclude unrelated styling, collection of additional personal data and production deployment. A small shared-component change might still be appropriate, but the plan should list regression surfaces that depend on it. Compare the draft against the issue description; remove steps that solve a different problem. A reviewer should be able to name what will not change as clearly as what will.
Turn acceptance criteria into reproducible tests
Ask the plan to list unit, integration and manual tests separately. Automated tests might verify error text, field association and focus assignment where the framework supports those checks. A keyboard-only walkthrough should cover Tab, Shift+Tab, Enter, reopening an error and submitting after correction. Screen-reader review needs a real supported configuration and a human reviewer; a green CI badge cannot substitute for it. Provide expected and failure outcomes, especially the case where the error is visible but not announced. Keep test data synthetic so reservations are not accidentally created for real patrons.
Review each proposed file before implementation
Read the generated plan line by line. The component list, accessibility rules and test names should match repository reality. Flag any assumption about browser APIs, framework versions or reusable form helpers that the agent has not verified. If the plan uses an unsupported design-system pattern, ask it to propose the existing approved component instead. Plan Mode can be revised interactively, so a reviewer can resolve questions without asking an agent to edit code prematurely. Save the approved version with the issue or development notes and give it an owner.
Gate the transition to Agent Mode
GitHub documents a deliberate handoff after plan review: the reviewer can start implementation or save the plan in an editor for further work. Do not treat that transition as automatic approval to merge. Once code changes are made, inspect the diff for unexpected files, network calls, accessibility regressions and test modifications that weaken assertions. Run relevant tests and then conduct the planned keyboard and assistive-technology reviews. If the final change diverges materially from the approved plan, bring it back for scope review. A plan is a prerequisite to controlled work, not a substitute for code review.
Document the limits of the planning result
The release note should state which behaviors were tested, on which devices, and who approved the changes. It should not claim WCAG compliance solely because Copilot suggested ARIA attributes. Plan Mode is described by GitHub as a preview feature and IDE availability can change; review the current documentation before following an interface walkthrough. There were no source files, live Copilot sessions or accessibility test devices in this editorial example. Every UI state in the illustrations is schematic and intended to teach what a reviewer must check.
How We Research
We reviewed these named official developer resources: GitHub Docs — Using plan mode in your IDE; GitHub Docs — Asking Copilot questions in your IDE. We checked the documented feature entry points, eligible platforms, administrator or licensing controls, and known sharing or source limitations against the tutorial steps. Editorial examples were designed as hypothetical failure-mode checks, not reports of hands-on testing. We did not have a live account, source files from a museum or nonprofit, user interviews, access to private records, or measured model outputs. Every illustration is original explanatory artwork rather than a vendor screenshot or measured before/after result. Features and entitlements can change. A responsible editor should confirm current product documentation, applicable organizational policy, and the original evidence before putting the workflow into consequential use.
Frequently Asked Questions
No. GitHub describes it as research and planning with read-only tools until a user approves the plan and explicitly begins implementation.
GitHub’s current Plan Mode guide lists VS Code, JetBrains IDEs, Xcode and Eclipse, but says this mode is not currently available in Visual Studio.
No. The plan can define criteria and tests; qualified human review and testing of actual interactive behavior are still needed.
Check the visible message, accessible announcement, keyboard focus destination, correction path and regression behavior.
No. Use synthetic fixtures and repository context that the agent is authorized to access; keep secrets out of prompts.