Put the mouse aside and try to complete the action your ChatGPT ad offers. That means more than reaching the main button. If the offer is a consultation, choose the relevant option, read its conditions, enter the required information, correct an error and reach the confirmation. A page that looks finished can still contain a control that interrupts this route.
This is a focused review of a customer task. It is not a full accessibility audit and does not establish compliance with a standard by itself. Its value is that it can reveal concrete obstacles between the advertised offer and the intended action.
Prepare a task with a known outcome
Use a realistic fictional enquiry in an approved testing environment or follow the site’s established safe test procedure. Avoid submitting an actual booking or purchase merely to see what happens. Decide in advance what a successful test should produce.
For example, a visitor to a printing consultation page might need to select a project type, choose remote consultation, enter contact details and review the request. The test should use the same page and offer linked by the ChatGPT ad, not a simplified demo of the form component.
Write down the expected steps before starting. This gives the reviewer a way to distinguish a confusing commercial process from a broken interaction. If no one can describe the intended route, clarify it before treating keyboard support as the only issue.
Follow the focus through the actual page
W3C’s keyboard-focus check explains the visible indication of the active control; the referenced page is a draft update. Begin with Tab and Shift+Tab to move forwards and backwards through ordinary links and form controls. Observe whether focus remains visible and whether the sequence follows the task. Use the relevant interaction guidance for controls that use arrow keys or other key combinations.
When a menu, panel or dialog opens, note where the interaction continues. Can the visitor understand what opened, use its controls and return to the previous task? Do not assume a component works because it can be opened. Closing it and continuing are equally important parts of the route.
If a focused control disappears behind a fixed header or contact bar, record the exact state. W3C’s Focus Not Obscured (Minimum) addresses components entirely hidden by author-created content, with stated conditions. Partial obstruction can still make the task difficult, so record that separately without presenting it as the same failure. The sticky action guide examines this layout conflict.
Test a deliberate mistake
A successful path is only one state. Leave a required field blank or enter a harmless invalid value according to the test plan. After attempting to continue, inspect whether the problem can be located and corrected without starting again.
The message should identify the relevant field and explain what is needed. A red border may be visible, but it does not by itself explain the correction. Keep valid answers intact when appropriate, and make sure the visitor can return to the affected control.
Record the difference between an error in the customer’s input and a service failure. “Enter an email address” is not an appropriate response when the network request failed. The form error recovery guide covers these messages and recovery routes in detail.
A concrete route from selection to confirmation
- Select
Reach the correct consultation using a keyboard.
- Correct
Find and fix a harmless test error.
- Confirm
Reach an understandable receipt for the enquiry.
Inspect controls that look custom
A styled dropdown, date grid, file uploader or expandable card may need more review than a simple link. Work through the actual task it supports. Can a date be selected, changed and understood? Can an uploaded file be removed? Can a chosen package be revised before submission?
Do not prescribe one universal key sequence for every custom component without checking its design and applicable guidance. The reviewer should report observed behaviour and compare it with the component’s intended interaction. A developer can then investigate the correct semantic and keyboard implementation.
For the printing consultation, a project-type card that responds only to a pointer can block the entire enquiry. The visual polish of the card is irrelevant if the task cannot continue. Replacing unnecessary custom interaction with a simpler control may be an option, depending on the requirements.
Write findings someone can reproduce
Each finding should identify the page, starting state, steps, observed behaviour and expected task outcome. Include which browser and viewport were used. A short recording or screenshot can help, but the written steps should still be understandable.
Compare these two reports. “Accessibility is bad” offers little direction. “After opening the consultation type panel, keyboard focus moves behind the overlay and the close control cannot be reached” identifies a specific interaction to investigate.
Prioritise barriers that prevent completing the advertised task, then issues that make the route confusing or difficult. Do not interpret the absence of a problem in one walkthrough as proof that all assistive technologies or user needs are covered. Broader review may still be needed.
Retest the journey after the repair
Repeat the exact failing steps, then continue to the confirmation. Fixes can change focus order or reveal a second issue later in the process. Also revisit the normal pointer path so the repair does not break another supported interaction.
Keep the outcome factual: which obstacles were found, which were corrected and which remain. For the ChatGPT advertiser, this makes the destination review concrete. The page is more ready when the advertised task can actually be completed through the reviewed route, not when a checklist has been marked complete without using the service flow.
Sources and scope
A practical keyboard walkthrough of the destination-to-enquiry path, with findings specific enough to fix and retest.
Working methods and examples are editorial suggestions. Check current platform requirements and available features before implementation.