A useful accessibility prompt does more than ask whether a page is accessible. It defines the evidence available, narrows the review, and asks for fixes you can verify. This first lap takes one HTML component from an initial model review to a tested patch without treating generated advice as proof of compliance.
1. Package the HTML with its interaction context
Start with one complete component: a navigation menu, signup form, product card, or dialog. Include its rendered HTML and the CSS and JavaScript that control visibility, focus, and interaction. Remove credentials and personal data before sharing anything.
Explain what the component does and where it appears. A button that opens a dialog needs a different review from a link that navigates to another page. If you only have static HTML, say so explicitly.
Prompt: Review this signup form for accessibility barriers. I am providing its HTML and validation script, but not its stylesheet. Separate issues supported by the supplied code from questions requiring CSS, browser inspection, or assistive technology testing. Do not assume missing context is correct or broken.
2. Define the review scope and finding format
Ask for a focused pass against relevant WCAG 2.2 Level A and AA requirements, not a blanket accessibility verdict. Require evidence for each finding so you can distinguish a genuine defect from a stylistic preference.
Prompt: For each finding, provide the affected element, quoted evidence, the user impact, a suggested fix, and a verification step. Include a WCAG success criterion only when you can justify the mapping. Label uncertain findings as needing verification. Do not claim that this review establishes conformance.
You can run this workflow through SwiftRelay with an OpenAI-compatible SDK or a supported coding tool. Sign up for SwiftRelay to try the prompts with a small gift credit, then keep the same review template across components.
3. Check native semantics and accessible names first
Begin with structural defects that are often visible in source: clickable generic elements, unnamed controls, missing form labels, and inappropriate heading structure. Ask the model to prefer native HTML over custom interaction patterns.
Prompt: Inspect landmarks, headings, links, buttons, inputs, and images. Identify controls without an appropriate accessible name. Check whether visible labels agree with accessible names. Prefer native elements, and do not add ARIA where existing HTML semantics already express the intended behavior.
For example, a clickable span usually needs a real button when it performs an action. Adding a role alone does not supply native keyboard behavior. Likewise, placeholder text should not be treated as a replacement for a persistent form label.
4. Trace keyboard focus through every interaction
Next, review behavior rather than markup alone. Ask the model to trace opening, operating, and closing interactive components, including what happens after content disappears or validation fails.
Prompt: Trace the expected keyboard path through this component. Check focus order, keyboard activation, focus visibility, and any focus trap. For a modal dialog, inspect initial focus, containment while open, Escape behavior, and focus restoration. Mark behavior that cannot be established from the supplied code as unverified.
Follow that review with a browser test using Tab, Shift+Tab, Enter, Space, and Escape where appropriate. Do not infer successful keyboard access solely from the presence of tabindex attributes.
5. Request the smallest defensible HTML patch
Once you accept a finding, request a narrow patch rather than a wholesale rewrite. Smaller changes are easier to inspect and less likely to disrupt styling or application behavior.
Prompt: Fix only the confirmed issues listed below. Preserve existing identifiers, application hooks, and visible copy unless a change is necessary for accessibility. Explain each edit and identify any CSS or JavaScript changes still required. Do not introduce positive tabindex values or redundant ARIA.
6. Verify the patch beyond the model response
Run an automated accessibility checker against the rendered page, then repeat the affected keyboard interactions. Inspect accessible names in browser developer tools. Test relevant flows with a screen reader, particularly errors and dynamic updates.
Check contrast using the actual rendered colors, including focus and error states. Automated checks and model reviews both leave gaps; neither can establish that an entire experience is accessible.
7. Record evidence before closing the issue
Finish with a short record: the original barrier, accepted patch, completed checks, and unresolved questions. Ask the model to summarize only verified outcomes. This turns a one-off prompt into a repeatable accessibility checkpoint for your next HTML change.