There are four columns: team, driver points, autonomous points and total points. HTML will not calculate totals automatically.

<table>
  <caption>Robotics skills results</caption>
  <thead>
    <tr>
      <th scope="col">Team</th>
      <th scope="col">Driver points</th>
      <th scope="col">Autonomous points</th>
      <th scope="col">Total points</th>
    </tr>
  </thead>
  <tbody>
    <tr><th scope="row">Falcons</th><td>42</td><td>18</td><td>60</td></tr>
    <tr><th scope="row">Comets</th><td>38</td><td>24</td><td>62</td></tr>
    <tr><th scope="row">Meteors</th><td>30</td><td>20</td><td>50</td></tr>
  </tbody>
  <tfoot>
    <tr><th scope="row">Combined points</th><td>110</td><td>62</td><td>172</td></tr>
  </tfoot>
</table>

The time cell occupies one column. The briefing cell occupies the other two.

<table>
  <caption>Saturday workshop timetable</caption>
  <thead>
    <tr><th scope="col">Time</th><th scope="col">Room A</th><th scope="col">Room B</th></tr>
  </thead>
  <tbody>
    <tr><th scope="row">09:00</th><td colspan="2">Shared safety briefing</td></tr>
    <tr><th scope="row">09:30</th><td>Build chassis</td><td>Program sensors</td></tr>
  </tbody>
</table>

Use merged cells only when they communicate a genuine relationship. Simple tables make header associations and navigation easier to understand.

Labels can use matching for and id values or wrap their controls. Keep ids unique, even where names are shared.

<form action="/workshop-booking" method="post">
  <p><label for="team">Team name</label>
     <input type="text" id="team" name="team_name"></p>
  <p><label for="email">Email address</label>
     <input type="email" id="email" name="email"></p>
  <fieldset>
    <legend>Choose one session</legend>
    <label><input type="radio" name="session" value="build"> Building</label>
    <label><input type="radio" name="session" value="code"> Coding</label>
  </fieldset>
  <fieldset>
    <legend>Equipment interests: choose any</legend>
    <label><input type="checkbox" name="equipment" value="sensors"> Sensors</label>
    <label><input type="checkbox" name="equipment" value="motors"> Motors</label>
  </fieldset>
  <p><label for="idea">Project idea</label>
     <textarea id="idea" name="project_idea" rows="4"></textarea></p>
  <button type="submit">Request a place</button>
</form>

/workshop-booking is a placeholder endpoint. A server must implement it before this becomes a working service. Use fictional data for testing.

Data is built from eligible controls. Repeated names can appear more than once; they are not automatically joined into one string.

team_name = Comets
session = code
equipment = sensors
equipment = motors

id identifies an element within the page. name is the submitted key. value supplies its value. The unnamed note and disabled reference are omitted.

For the participant count, test 0, 1, 6, 7 and 2.5. For the code, test AB123, ab123 and AB12.

<label for="email">Email address (required)</label>
<input type="email" id="email" name="email" required>

<label for="count">Participants (1 to 6, required)</label>
<input type="number" id="count" name="participants"
       min="1" max="6" step="1" required>

<label for="code">Team code (required)</label>
<p id="code-hint">Use two capital letters and three digits, for example AB123.</p>
<input type="text" id="code" name="team_code" required
       pattern="[A-Z]{2}[0-9]{3}" aria-describedby="code-hint">

Expected results: 1 and 6 pass the numeric rules; 0, 7 and 2.5 fail. AB123 passes the format rule; ab123 and AB12 fail. Required empty fields fail. Browser checks can be bypassed, so a real server must enforce the rules again.

These snippets replace or extend existing controls. Do not paste a second email control with the same id into the page.

A placeholder is not a substitute for a label. aria-invalid communicates an error state but does not perform validation.

<label for="contact">Email address (required)</label>
<p id="contact-hint">Use an address such as alex@example.com.</p>
<input type="email" id="contact" name="email" required
       aria-invalid="true"
       aria-describedby="contact-hint contact-error">
<button type="button">Show help</button>
<p id="contact-error">Enter an email address in the form name@example.com.</p>

This represents an error state, not the initial untouched form. Custom code must show and clear the error and update aria-invalid when checks run. The help action needs its own programming. A custom error summary can link to the affected fields and receive focus after a failed submission.

Captions describe speech and meaningful sounds. A transcript can also describe important visual actions. The files referenced in sample code must actually exist.

<video controls preload="metadata" width="800" height="450"
       style="display:block;width:100%;max-width:800px;height:auto;margin:20px auto;">
  <source src="media/robot-demo.mp4" type="video/mp4">
  <track kind="captions" src="media/robot-demo-en.vtt"
         srclang="en" label="English" default>
</video>
<p><a href="media/robot-demo.mp4">Open the demonstration video</a></p>
<section>
  <h2>Demonstration transcript</h2>
  <p>The robot uses a sensor to detect the parcel.</p>
  <p>[The lifting arm raises the parcel onto its platform.]</p>
</section>

WEBVTT

00:00:00.000 --> 00:00:03.000
The robot uses a sensor to detect the parcel.

00:00:03.000 --> 00:00:06.000
[Motor starts]

Save the timed text as robot-demo-en.vtt and adjust it to the actual recording. Test through a local web server or hosted page because local-file restrictions can affect track loading.

Build one section at a time. Keep the form separate from the table and do not nest forms. Reuse tested components, then check the complete page for duplicate ids.

One possible page plan

• header and nav: page name and links to timetable, booking practice and media sections.
• main: introduction followed by a timetable section, a form section and a demonstration section.
• footer: fictional workshop contact information and a reminder that the form is a practice interface.

There is no single correct finished page. For this challenge, keep submission as a demonstration and use fictional data. A live booking system requires implemented processing, server checks and appropriate handling of personal data.

Further stretch: plan an external player with a descriptive iframe title, a direct viewing link and an explanation of its third-party loading behaviour. Use the provider’s official embed URL rather than an ordinary watch-page URL.