Embed a conference agenda on your event website: choose a method and verify the live schedule

1. Establish the approved agenda and its owner

Download the editable agenda method, field, update and release worksheet (English Markdown)

Name the event edition, dates, venue and local time zone. Identify the authoritative programme record and the person who approves session titles, speakers, start and end times, rooms and participation mode. Give the website editor a separate publication role. If programme and website teams use different systems, record which field is copied or synchronized and who resolves a disagreement. A calendar-looking widget is not a source of truth simply because it appears on the event page.

Set a publication threshold: which sessions are confirmed enough to show, which may be labelled provisional and which stay internal. Decide what the public agenda must answer before registration and on event day. The minimum usually includes day, local time, title, room or joining mode and a way to read further detail. Capacity, RSVP or streaming access should appear only when those functions and terms are real for this event.

Record the canonical agenda URL, source-system URL, editing owner, approval owner and review cadence in the worksheet. If Boletolibre.com is the attendee ticket destination, keep the agenda's event date and ticket link aligned with the published ticket page; that does not imply Boletolibre runs the agenda or its embed. This guide concerns the web display of a schedule. The printable one-page attendee programme and the general register of website embeds answer different production questions.

2. Choose between native HTML, an iframe and a widget

A native HTML agenda is written into the event site's own page as a chronological list or a data table. It offers direct control over wording, layout and links, but every approved programme change must be carried into that page and checked. It suits a small, stable schedule when an editor can maintain it. The article's downloadable worksheet asks who makes those edits and how the team proves that the published page matches the current programme.

An iframe displays a separate provider page inside a frame on the event site. The provider controls the inner interface and its updates; the event-site team controls the surrounding explanation, direct link and space for the frame. A provider may require an embed setting or approved domain, and some interfaces are awkward on small screens. Do not infer that changes are instant or that the inner content will always be attributed to the host page in search; test the actual provider and published URL.[2][5]

A JavaScript widget or API-driven view can use session data to build a more tailored interface. It also introduces data access, script, maintenance and failure questions. Ask who owns credentials, error handling, layout and version compatibility. Whether content appears in the page's initial HTML or only after client-side code runs matters for discoverability and resilience, so inspect the rendered page if those are requirements. No method automatically wins on speed, accessibility or visibility; evaluate the version your team can maintain.[4]

3. Map session fields before selecting a layout

Make a field map from the approved programme to the public agenda: stable session ID, event day, start and end with time zone, title, room or online mode, confirmed speaker, short description and any ticket or attendance condition. Mark which values are required, optional or withheld until approval. A stable ID helps reconcile a moved session with its old version; a changed title alone can be ambiguous. Keep private production notes, contact details and internal cues out of the public feed.

Choose one ordering rule that visitors can understand. For a single track, a day-by-day chronological list may be enough. For simultaneous sessions, group by day and expose room or track without relying on color alone. Keep the current location and time visible with each entry; do not make someone open a separate speaker page to learn where to go. If a session has a detail page, link to it using the same session title and approved description.

Agree how cancellations, room moves and replacements will be represented. A removed row can confuse someone who saved an earlier agenda. When the change matters to attendees, consider a dated change note or clear status alongside the new value, coordinated with the event's communication owner. Keep the downloadable or printed programme's update route separate; an embedded agenda cannot reach a person who is viewing a saved copy offline.

4. Build a native page when editorial control is the priority

For a small confirmed programme, publish ordinary page content first. A list with headings for each day and session can be easier to scan than a wide grid. If time, room and session have genuine row-and-column relationships, use an HTML data table with marked header cells; W3C explains that table structure lets assistive technology announce the relevant row and column context. Do not use a table simply to position cards on a page.[1]

On a phone, check that times, titles and rooms remain associated after the layout narrows. A schedule can become unreadable if each session spills across several screen widths. Test the page with the keyboard and at increased text size. If editors must manually copy changes, give them a field-level checklist and a time to compare the public page against the approved record. Native content is not automatically current just because it is easy to read.

5. Use a provider frame only after checking its actual behavior

Get the embed code or URL from the schedule provider's current instructions, not by guessing a watch or admin URL. Confirm that the agenda is allowed to appear on the published domain and that a person without organizer credentials can view the intended public data. Give the iframe a concise descriptive title, such as “Conference agenda”; W3C notes that this labels the frame for navigation, not the content inside it. The provider still has to make its inner controls usable.[2]

Put a heading and a direct link to the provider's public agenda beside the frame. Keep the event day, time zone and a few essential session facts in the surrounding page text so the page remains meaningful if the frame is blocked, late or unavailable. This is a schedule-specific fallback; a static summary is not a substitute for a live RSVP or seat reservation control. Test the provider link itself as an unauthenticated attendee before offering it.

Open the published page on a narrow phone. Check width, internal scrolling, legibility, focus entry and exit, filtering and links to session details. Note whether a change in the source system appears in the frame after a real test update, how long it took, and what action caused it. The answer belongs in the worksheet, not in a general promise about iframes.

6. Treat a script or API display as maintained software

Use a widget or API only when its extra filtering or layout is worth the owner and testing effort. Ask the supplier what fields are public, how updates are fetched, whether a token is exposed to visitors, how errors are shown and which versions of the code are supported. The website team should know who can deploy or roll back it. Never place private programme notes or privileged API credentials in a public page to make an embed work.

Load a representative day and track, then test with the provider unavailable or slow. Does a useful title and next step remain? Third-party embeds can add substantial resources and change without the event-site code changing; web.dev recommends auditing their performance impact. Measure the agenda on the actual page and device, rather than assuming a lightweight-looking widget is fast. Delay offscreen resources only if the agenda still becomes available when attendees need it.[3]

If search access to the public schedule matters, inspect the rendered page with the site's search tools after publication. Google documents JavaScript rendering limits and a URL Inspection route for examining the rendered DOM; this is a diagnostic check, not a guarantee of indexing or ranking. Preserve an accessible direct agenda link and a concise native summary for visitors even when an automated inspection succeeds.[4]

7. Publish a page that makes the schedule usable

Place the agenda where a visitor would expect it from the event navigation, ticket information and attendee guide. Explain what the schedule covers: dates, time zone, whether room assignments are final, and where to check later changes. Avoid burying the first useful day beneath a large hero image or making a download the only way to read the times. A registration link belongs near the agenda only when it leads to the current, official ticket path.

Use headings that separate days and clear names for tracks, rooms and online participation. If speakers or images are included, they should support the session choice rather than dominate a small screen. A filter is useful only if the full agenda remains available when a filter fails or a visitor cannot operate it. Test the default view as well as search, tabs and collapsed detail panels. The public page should answer what, when and where without requiring an account unless the event explicitly uses restricted access.

Have a person unfamiliar with the event find a named session, compare two simultaneous sessions and identify where a last-minute room change would appear. Repeat on a phone and with a keyboard. Record what they could not discover quickly; then fix the navigation or labels and retest. This checks the attendee task rather than only the appearance of the embed container.

8. Define change flow and a stale-content signal

For every method, document the same sequence: programme owner approves the new fact, editor updates the source, publisher makes or confirms the website change, and reviewer checks the public page. Record the old value, new value, affected session IDs, time zone and approval time. If a room changes, inspect both the summary row and the detail view. A successful save in the source system does not prove that the public agenda has refreshed.

Agree what the page displays while an update is pending. A visible “last checked” time can help if it is maintained honestly, but it must not imply a live feed when publication is manual. If the provider offers synchronization, measure its actual delay and cache behavior with a controlled edit before depending on it. A source-to-page link, an iframe refresh and a scheduled site build are different mechanisms; write down the one in use.

For a material late change, coordinate the agenda correction with the communication lead and any printed or downloadable programme. A changed web page alone does not notify people who saved an old schedule. When the integration fails, the fallback should point to an approved current schedule or a staffed information route, not an untested second embed. Assign a person to retire stale versions after the event.

9. Release with a real-page and failure check

Before launch, compare a sample of sessions across every day and track with the approved source, including start/end times, time zone, room, status and links. Test the published URL without editor login. Check one phone, one desktop width, keyboard navigation, enlarged text and the provider link. If an iframe is used, inspect its frame title and inner controls; if a data table is used, inspect headers and reading order. Fix the actual page, not only the editor preview.[1][2]

On a staging page, use browser network controls to simulate an unavailable provider, or use the vendor’s documented test mode, and see what remains understandable. Record the fallback URL, page owner and restore action. If performance is a concern, capture a before/after measure on the page when adding a third-party script or iframe. Avoid declaring success solely because a preview loads on the organizer's fast connection. Recheck after a provider setting, programme date or domain change.[3]

After a real schedule edit, record source-save time, public-observation time and the person who saw the new value. Close the release only when the attendee view matches the approved agenda. At event close, decide whether the page stays as an accurate archive, links to follow-up material or is replaced; do not leave a “live” label on a frozen schedule. Preserve the field map and release notes for the next edition.