Design an event website around the decisions an attendee must make: identify the event, understand its schedule and access details, register successfully and recognise any later change. Keep the event information and registration outcome consistent across the page. A visitor should be able to act without reconstructing essential details from separate posters, messages or form screens.
Start with the organiser’s approved event record. Identify who owns the event name, dates, venue, attendance instructions and registration conditions. Put unresolved details back with that owner before they become public copy. The page structure should make the next action clear while preserving enough context for someone deciding whether the event is suitable.
Which information belongs on the event’s main page?
Give the visitor a clear statement of what the event is, who it is intended for and when it takes place. Distinguish the overall event dates from session times and arrival instructions. Use an explicit timezone where the audience or format makes it relevant, and have the organiser confirm the displayed information.
Keep access details concrete. Ask which entrance or online joining route applies, what an attendee needs to bring and where questions should go. Publish the verified information that helps someone attend. If a detail is still undecided, resolve its ownership and communication route rather than filling the page with an invented commitment.
Google’s event documentation provides useful page-identity guidance within its own search-feature scope. Google’s event markup guidelines require a unique URL for each event. Google’s event experience supports pages focused on a single event. Keep the individual event page distinguishable from a programme listing that contains several events.
Google’s guidance asks for both start and end dates for an event spanning several days. Retain those boundaries in the organiser’s content record and review the visible schedule alongside any applicable markup. Search-feature applicability should be checked separately for the actual region and event; the page still needs to serve the attendee directly.
How should the schedule support a registration decision?
Show the information needed before a person commits to registering. A participant may need to choose a session, understand whether the programme spans several days or confirm which attendance route applies. Put those decisions near the relevant action rather than revealing an essential constraint only after the form is submitted.
Give schedule changes an owner and a review route. Decide which record is authoritative and which public touchpoints need updating. A revised session time on the page can still conflict with an unchanged confirmation message, so include both in the change worksheet.
Use descriptive links between the programme and registration route. The action should make clear whether it opens an enquiry, a registration request or another documented process. Ask the organiser to define what a successful submission means for the attendee, including any further approval or instruction genuinely required by the operating process.
| Attendee question | Information to confirm | Acceptance observation |
|---|---|---|
| Is this the right event? | Purpose and intended audience | Visitor identifies the event without another document |
| When should I attend? | Event dates, relevant session and time context | Page and registration route agree |
| How do I get access? | Verified venue or joining instructions | Intended attendee can locate the right route |
| Did my registration work? | Agreed submission outcome | Confirmation explains the actual next step |
| What changed? | Named content owner and update record | Schedule and associated messages remain consistent |
This original worksheet keeps the attendee’s questions connected to the organiser’s responsibilities. Adapt it to the actual event format, leaving each factual detail with someone who can confirm and maintain it.
What should happen when registration has an error?
WAI’s form-notification tutorial explains practical feedback. WAI recommends concise, clear form notifications. WAI recommends success messages to confirm task completion. Use those principles to make the end of the registration journey understandable, whether the person needs to correct information or proceed to the next step.
A page title can communicate form success or errors. WAI recommends listing submission errors before the form. Inspect how the implemented page presents that feedback, including the route a person using assistive technology follows to understand what happened.
Error feedback should reference the corresponding form-control label. Error feedback should explain how to correct a mistake. An error list can link to the corresponding form control. Write messages using the attendee’s task and the actual field requirement, then demonstrate the correction rather than accepting a generic “invalid input” message.
Keep a successful form submission distinct from any later event-management decision. The confirmation should describe the organiser’s actual process in plain language. If a request needs further action, explain what the attendee can expect and which route to use for a question, using commitments the organiser has confirmed.
Original schedule-change and registration exercise
Consider a fictional workshop with a morning session and an afternoon session. Prepare approved sample schedule information and non-sensitive registration data in a separate test environment. The exercise follows a visitor choosing a session, correcting an error and reviewing a later schedule change.
First, ask a participant to find the event and identify the intended session, attendance route and registration action. Record any information they have to seek elsewhere. Review those gaps with the organiser and decide whether the page needs clearer content, a better link or confirmation of a missing fact.
Next, submit the sample form with an intentionally incorrect entry. Inspect the error summary, field reference and correction guidance. Follow the proposed correction route and record whether the participant can complete it without reinterpreting an unexplained technical message.
Then complete the sample registration and inspect its confirmation. Compare the session and access information with the main page. Ask the participant to explain the next step in their own words and compare that understanding with the organiser’s agreed process.
Finally, introduce an approved sample schedule change. Inspect the event page, registration route and any confirmation content included in the test arrangement. Record each place that needs updating and give it an owner. Retain the exercise as a practical maintenance checklist for the actual event team.
Include the attendee’s intended device in the review. Ask them to read the schedule, follow the access instructions and correct the sample form using that arrangement. Record cramped controls, unclear session labels and content that becomes difficult to follow. Give those findings to the person responsible for the page rather than assuming that a desktop demonstration answers every attendance question.
For broader planning, see website development and WordPress. Get started with the organiser’s event record and registration journey.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.