Keyboard accessibility testing checklist for event websites

Choose tasks across the complete event route

Write down the paths a guest actually takes: open the event page, find date and venue, browse a session schedule, use a filter or accordion, inspect access details, follow the ticket button, choose a ticket, fill a form and read confirmation. Include overlays, cookie controls, maps, video players and any external ticketing or checkout domain. A component can pass on a static page yet fail when opened or after validation. The leading checklist recommends testing dynamic states and whole journeys; record the platform owner for each step.[1]

Check reachability, operation and meaningful order

Move forward and backward with Tab and Shift+Tab. Use Enter, Space, arrow keys or Escape where the control’s documented behavior calls for them. Can you open the navigation, activate ticket buttons, change schedule filters, dismiss overlays and leave embedded tools? Watch the sequence after each change. W3C says focus order should preserve meaning and operability; it need not exactly mirror the visual layout. A true keyboard trap leaves a user unable to move away by keyboard, or without instructions for a nonstandard exit.[3][5]

For a session card, ask whether the session title, time, details link and booking action appear in a sensible sequence. For a map embed, check there is an accessible way to find the venue information without being stuck in the map. For a dialog, confirm focus enters a useful control and returns to a logical place after closing. Record what actually happens rather than declaring a pass from the presence of a Tab stop alone.[1]

Watch visible focus on every screen size

The focused link or control should be apparent to a sighted keyboard user. Inspect sticky headers, fixed ticket bars, cookie banners and chat bubbles at desktop and narrow widths, and at zoom. W3C’s Focus Not Obscured (Minimum) criterion says author-created content must not entirely hide the focused component; the stronger editorial goal is to keep it clearly visible. Capture a screenshot of the failing focus state and the exact action that produced it.[4]

Recover from errors and finish the guest task

Test a required-field error and a realistic invalid input using keyboard only. Can you find the message, return to the affected field, correct it and resubmit? Check custom date and ticket-quantity controls, sign-in steps, payment widgets and final confirmation on the actual external platform if one is used. A form that can be reached but cannot be completed is still a blocker. The related full registration accessibility audit also covers labels, requests and screen-reader feedback; use both records rather than treating a keyboard pass as a complete accessibility review.[1][2]

Log evidence, fix and retest

Use one worksheet row per task or failing state. Include keyboard sequence, expected and actual result, guest impact, screenshot or recording reference, provider owner and retest outcome. If a blocker lives on an external ticket platform, assign an owner to contact that provider and offer an accurate alternative support route while it is unresolved. Re-run the complete guest path after a fix, because changed focus behavior may affect nearby controls. W3C describes its easy checks as preliminary, not a comprehensive evaluation.[2]

Download the original event website keyboard test record (CSV)