Start with one task a visitor must finish
An AI-built page can look finished while its menu, dialog or form fails without a mouse. Test a complete visitor task: find a workshop, open its request form, correct an error and submit a test request. A screenshot shows appearance; this exercise checks whether the journey works.
Use a preview or authorized test environment with fictional details. Record the browser, page version, screen size and zoom setting. Keep a small log with four fields: steps, expected result, observed result and a screenshot or note. W3C's preliminary checks are an entry point, not a complete accessibility evaluation.
Can you reach and activate every necessary control?
Place the pointer aside. Use Tab to move forward and Shift+Tab to move backward through interactive controls. Follow the visible focus indicator. A normal text paragraph does not need to become a Tab stop; links, inputs and actions do. If your browser skips links because of a keyboard-navigation preference, check that preference before blaming the page.
Open the main navigation, follow the workshop link and reach the request action. Test a button with both Enter and Space. A real navigation link should work with Enter; Space is not its standard activation key. The W3C button pattern distinguishes actions from navigation, so a clickable picture is not automatically an adequate replacement.
Write down the exact point where progress fails. For example: “After the agenda link, Tab moves to the footer; Request a place is never focused.” This is much more useful to a developer or AI tool than “the keyboard is broken.”
What happens when a dialog opens and closes?
If the request form opens in a modal dialog, focus should move inside it. Tab and Shift+Tab should stay within that active modal, and Escape should close it. Closing normally returns focus to its opener, unless the completed workflow has a more logical destination. These are modal-dialog expectations, not rules for every dropdown or expandable paragraph.
Repeat the sequence: open, move forward, move backward, close, reopen. Check that a visible close button is reachable. A modal that traps focus but offers no usable way out blocks the task; a modal that leaves focus behind the overlay also fails the interaction.
Watch sticky headers, cookie notices and fixed footers while moving through the page. WCAG 2.2's minimum focus-obscuring criterion requires the focused component not to be completely hidden by author-created content. Aim to keep the whole control visible rather than treating partial visibility as a design target.
Separate text enlargement from a narrow layout
First enlarge text using a supported browser scaling method to 200%. Check that labels, headings and actions remain available without clipping or lost functionality. WCAG's resize-text criterion has exceptions for captions and images of text; passing one zoom check is not proof of complete conformance.
Next check reflow. For ordinary vertically scrolling content, the reference width is 320 CSS pixels. One equivalent setup is a 1,280-CSS-pixel-wide starting viewport at 400% zoom: 1,280 ÷ 4 = 320. Browser window decorations are outside the viewport, and physical screen pixels are not interchangeable with CSS pixels.
Read a paragraph, open the menu and use the form at the narrow width. The normal text should wrap instead of requiring repeated sideways scrolling. Some material genuinely needs two dimensions, such as a data table or map; that exception does not justify making the entire article overflow.
Also try the real phone experience, including portrait and landscape. Opening the on-screen keyboard may cover an action or expose a fixed-height panel problem. A desktop zoom pass and a phone check complement each other; neither alone represents every device.
Can you understand and recover from a form error?
Look for a persistent, meaningful label on each field. Placeholder text disappears during entry and is a poor substitute. W3C's forms guidance explains that labels need a programmatic association with their controls so assistive technology can identify them.
In the test form, leave a required field empty, then enter an address missing its @ sign, such as learner.example.com. Confirm the error explains what needs correction rather than changing only a border color. Preserve valid entries when possible, make the error easy to locate and ensure the final result accurately describes whether the request succeeded.
Repeat the correction with the keyboard. A screen-reader review should also check that field names, error relationships and dynamic feedback are announced; visually spotting red text cannot verify those behaviors. Use a test inbox you control for any actual delivery, and avoid submitting repeated tests to someone else's production form.
Worked example: turn three failures into repair requests
Suppose a fictional workshop preview has three defects. The request action is skipped by Tab. Closing its dialog sends focus to the start of the document. At 320 CSS pixels, the email field extends beyond the viewport. Save these as three separate observations, with the same page version and repeatable steps.
The expected results are equally specific: the request action is keyboard reachable and operable; closing returns focus to the opener; the field and its label fit the narrow layout. Ask for the smallest relevant changes, then rerun all three checks. Repairing width should not accidentally remove the form's label.
A useful record might say: “Preview version B, keyboard check: passed; dialog focus return: passed; narrow form layout: failed.” Do not replace that with “100% accessible.” Your observations cover three behaviors, not every page, screen reader, contrast combination or interaction.
PROMPT TO ADAPT
Fix these three observed problems in this preview: the Request a place action is skipped by Tab; closing its modal loses the opener focus; the email field overflows at a 320 CSS-pixel viewport. Preserve existing content, URLs, titles, descriptions and canonical tags. Use appropriate native controls and scoped styles. Report the files changed and the specific checks actually run. Do not claim WCAG compliance or human review from automated checks.
Five-minute practice: write an acceptance log
Create a four-row log for your own preview: reach the primary action; open and close any modal; correct a required-field error; read and submit at an enlarged or narrow layout. For each row, write an observable result before testing. Mark anything you cannot test as untested rather than passed.
Answer for the fictional example: three repairs are needed, and the form-delivery result is still unknown. A correctly placed button does not prove a request reached its destination. Test that separately using the build-website guide's delivery workflow.
Automated scanning can help find additional issues, but follow it with the actual task and appropriate assistive-technology testing. After publication, repeat the task on the live version. Preserve the previous working release and keep the evidence so later design edits can be checked against the same journey.
- The main task works without a mouse and focus stays visible.
- Any modal can be entered, used and closed predictably.
- Text can be enlarged and ordinary content reflows.
- Form labels and errors remain understandable and usable.
- Untested behavior is recorded honestly, including actual delivery.
Sources & further reading
- W3C WAI: preliminary accessibility checks
- W3C APG: button keyboard behavior
- W3C APG: modal dialog behavior
- W3C: focus not obscured
- W3C: resizing text
- W3C: content reflow
- W3C WAI: form labels
- W3C WAI: form feedback and errors
Educational content. Examples are illustrative. Protocols, products and rules can change; consult the linked documentation for current details.