The useful result
Draft a focus-order test and record actual keyboard results without claiming a screenshot proves accessibility.
- Draft a focus-order test and record actual keyboard results without claiming a screenshot proves accessibility.
A screenshot shows arrangement, not actual keyboard behavior. Ask Sonnet to create a candidate navigation checklist from a permitted mockup, then run the checks in an application you control. The skill is distinguishing a useful test plan from an unsupported accessibility pass.
Select the named model only if it is available in your interface. API controls and consumer-app controls differ. You can practise the technique on the supplied fictional inputs with an available compatible assistant first. This lesson is documentation-based; examples are expected results, not a claim that we ran the named model.
Before you start
- A UI mockup or screenshot you are permitted to inspect.
- An owned or authorized working version for the keyboard test, if available.
Bring your own attachment
Attach the mockup in a compatible image-input interface. Remove private account details and supply intended control labels or behaviors that are not visible.
Review evidence
Documentation-based review · 2026-10-18
Provider documentation checked on 18 October 2026. Examples and checks are original illustrative exercises, not recorded platform tests. Cover artwork is conceptual and does not imply provider sponsorship.
Name visible controls and intended actions
List a simple form’s email field, terms checkbox, submit button and cancel link. Mark details such as disabled state or hidden validation messages as unknown when the image cannot establish them.
Example / expected result
Illustrative example; not a recorded model result.
Candidate route: Email → Terms → Submit → Cancel. Actual order is not yet tested.
Check your result
The inventory separates visible controls from assumed implementation.
Ask for a candidate test sequence
Request starting condition, key action, expected focus and evidence to record. Ask the model to flag ambiguous order rather than infer DOM order from visual positions.
From the attached mockup, draft a keyboard-only test plan. List visible controls, unknown semantics and a candidate Tab/Shift+Tab sequence. For each test give expected behavior and evidence to capture. Do not claim accessible names, focus order or keyboard activation were tested from the screenshot.Example / expected result
Illustrative example; not a recorded model result.
Test: start before form; Tab to Email; expected visible focus. Status NOT RUN. Test backwards navigation with Shift+Tab; inspect whether order is coherent.
Check your result
Each proposed check is actionable and labelled NOT RUN until observed.
Run the plan in the real page
Use the keyboard in the authorized application and record where focus actually goes. Check visible focus and activation for relevant controls. Keep source-code or assistive-technology checks separate; a short keyboard exercise is not a full accessibility audit.
Check your result
The result records observed focus and activation, with failures and untested semantics retained.
When it goes wrong
A visual mockup cannot establish DOM order, labels or screen-reader behavior. Do not claim compliance from an AI checklist. If no working application is available, deliver the plan with every execution status NOT RUN.
Make it your own
Move the cancel link visually while keeping the implementation unchanged. Compare the mockup-derived proposal with the actual keyboard path and explain the difference.
Useful next resources
Sources and review
Last checked Oct 18, 2026. Features and account limits can change. Verify important results against your original material.
Did this help you complete your task?
Tell us what needs improving. No account or private output required.
Report incorrect information or a broken linkGenius Forges Editorial
Practical AI lessons with checked sources, labelled examples and human verification.
