Find out what the clock protects
Imagine an adult learner applying for an evening course on a phone. They pause to check a qualification date, read the cancellation terms and compare the Chinese and English course descriptions. Their answers remain valid, but the form suddenly closes. Before asking the supplier to increase a timeout, ask which clock expired: inactivity, the total application session, or a temporary reservation of the last available place. These require different business decisions.
Request a short inventory of every timer, including those enforced by the server or a connected booking system. Record when each starts, what resets it, what expiry does and who owns the rule. A screen can appear active while the server is preparing to reject the next step. The owner should approve the intended policy; the developer should demonstrate that the displayed warning and the server agree.
Choose the timing control deliberately
Use WCAG 2.2 success criterion 2.2.1, Level A, as the design benchmark for content-set time limits. Its alternatives are to let the user disable the limit before encountering it; adjust it beforehand across a range reaching at least ten times the default; or receive a warning with at least 20 seconds for a simple extension action, with at least ten extensions allowed. These are alternative routes, not three compulsory controls on every form.
For an ordinary enrolment form, first consider whether a user-controlled untimed route is practical. An adjustable limit needs a clear choice before work begins. An extension route suits an existing session design only if its warning and action actually work throughout the journey. Saving a draft is useful, but does not itself provide one of these timing controls. This article uses WCAG as a commissioning benchmark, without asserting a blanket Hong Kong legal duty or claiming whole-site conformance.
Move preparation before the place hold
A popular workshop may genuinely need to release unconfirmed places. Ask the course manager to explain why a longer hold would undermine allocation, rather than assuming every booking deadline must disappear. W3C’s ticketing example places information entry before the time-critical stage. For a training provider, the following is a proposed workflow to discuss with the supplier, not an observed customer result or a required duration.
| Prepare | Enter contact details and qualifications; read course terms. | Use the chosen timing control; do not reserve a place yet. |
|---|---|---|
| Select and hold | Check current availability and confirm the class choice. | Explain any justified hold deadline before it begins. |
| Confirm | Review the total and complete the required confirmation or payment. | Show the actual hold status and handle expiry without implying a booking exists. |
Separating stages creates an important constraint: availability can change while someone prepares their details. Say clearly that preparation does not secure a place. If a hold expires, offer a fresh availability check and retain only the information that the agreed draft policy permits. Extending the working session must never silently promise to extend a scarce place reservation. The two clocks need separate messages if they can expire independently.
Test a warning people can act on
For a supplier demonstration, agree an illustrative ordinary-session policy of a 15-minute idle period, a warning 60 seconds before expiry, and a button that restarts that idle period. These are proposed product settings, not WCAG-prescribed durations. Use wording such as the example below only where no place is currently held. The success message should appear after the server confirms the extension; a cosmetic countdown reset is insufficient.
Run the demonstration separately in English and Traditional Chinese. Ask a reader to explain what is expiring, what the button does and whether a place is held. Then test on a narrow phone screen, with a keyboard and with a screen reader. The warning must be discoverable and the action reachable. Check that extending keeps the applicant on the same step with their answers, and that switching language does not discard work or leave the timer inconsistent.
Give the supplier a reproducible acceptance task
Before approving the change, ask the supplier to repeat the extension through the tenth successful request and then submit the application. Include a slow connection and a request close to expiry: the interface should distinguish a confirmed extension from a failed or late request. Record the warning appearance, action time and server outcome using fictional applicant details. Also let the session expire without responding, so staff can see the actual recovery message rather than infer it from a mock-up.
The next action is a focused review of one live enrolment journey: have the course owner and developer agree its timer inventory, chosen timing control and any documented reservation exception. Attach both language versions of the warning and the demonstration results to the change request. Use the bilingual design guide for the surrounding journey; a UX/UI review can help turn the agreed policy into screens and acceptance criteria.
Read the guide to designing for English and Traditional Chinese usersExplore Astera’s UX/UI design serviceBefore you proceed
- Every timer has a named purpose, start condition and expiry outcome.
- The selected timing control works in both languages and is enforced by the server.
- Any reservation exception has a recorded business reason, and preparation fields sit outside the timed hold where practical.
- For the extension route, the demonstration proves the required warning opportunity and repeated extensions, then a successful submission.
