A prospective customer spends twenty minutes explaining a project, gathers an attachment and returns to an expired session. The portal sends them to the beginning. Another user corrects an error but cannot find the field that failed. A third presses Submit twice because nothing confirms whether the first attempt worked. These are software failures at the moment the business wants someone to complete a request.
An Ottawa organisation planning a service portal should treat recovery as a core requirement. Accessible labels and sufficient contrast are necessary, but people also need to understand progress, retain work and finish after something goes wrong. The commercial outcome is a complete, usable request and a customer who knows what happens next.
Use accessibility as a journey requirement
The City of Ottawa's engagement platform accessibility statement is one local example of an organisation publicly describing its accessibility approach. A supplier should be able to explain its own implementation and evidence with similar clarity. Do not interpret another organisation's statement as proof that a new portal complies with every obligation that applies to your business.
W3C's guidance on multi-page forms recommends logical stages, clear progress and consideration of time limits. Those principles are a useful starting point for a project brief. The practical test is whether a person can complete your actual form, including its exceptions, with the tools they use.
Remove questions before redesigning them
Begin by listing the decision each field supports. If nobody uses an answer to route, assess or deliver the service, consider removing the question. A shorter relevant form reduces the amount of work that can be lost and the amount of information the business must protect.
Separate required information from details that can be collected later. Explain unfamiliar terms with examples near the relevant field. Avoid asking a customer to identify an internal department or system code when the organisation can determine it from the problem described.
For an illustrative project-intake portal, an initial request may need contact details, the business problem and a broad delivery constraint. Detailed architecture, document uploads and procurement references can follow when they are actually required. The sequence should reflect the customer's task rather than your database schema.
Make saved progress understandable
A save indicator should describe the real state of the draft. Distinguish saved, saving and unable to save. If connectivity disappears, keep the user informed about which work is safe and what they can do next. An optimistic green checkmark is harmful if the server never received the latest section.
Choose a draft identity and access model deliberately. An authenticated customer might resume within their account; another journey may use a carefully scoped recovery mechanism. Decide whether several people can collaborate on the same draft and what happens when their edits conflict. Do not let a second device silently replace newer work.
Keep drafts separate from submitted applications. A staff queue should not treat a half-finished request as an intentional submission. Give the user a clear way to discard a draft and explain relevant retention in the experience. Sensitive entries need an explicit storage and access design, including on shared devices.
Errors should lead back to the work
W3C's user-notification guidance explains the need for clear feedback about successful and unsuccessful submissions, including ways to identify and reach affected controls. Apply that guidance to the portal's real errors, not just to a demonstration with one empty text field.
Keep previously valid answers when a section fails. Link an error summary to the specific fields. Announce meaningful changes to assistive technology and place focus deliberately after a step transition. Avoid communicating status only through colour or a brief toast that disappears before someone can read it.
For document uploads, distinguish selected, uploading, received and rejected. Explain size or format restrictions before the user spends time finding a file. If security processing happens after receipt, show that the document is pending review rather than presenting it as accepted immediately.
Treat final submission as a transaction
The most important failure often occurs after the user presses Submit. If the response is interrupted, the application should determine whether the request was recorded before creating another one. Use a stable submission identity and return the existing result when the same intention is retried.
Display a confirmation reference, the submitted summary and the next expected action. An email can provide an additional record, but its delivery should not be the only proof that the portal received the request. Staff should be able to locate the same reference and explain its current status.
Once submitted, preserve the accepted revision. If the customer needs to amend information, create a visible update process. Otherwise the staff member reviewing a request may be looking at different answers from those the customer confirmed.
Ask for a completion test, not just a checklist
Give the supplier representative journeys and recruit appropriate people to evaluate them. Include keyboard-only navigation, screen-reader use, zoomed layouts and mobile input. Test an interrupted upload, a lost connection, an expired session, a resumed draft and a correction to an earlier step.
Assess the experience and the underlying record together. A successful-looking screen is insufficient if attachments are missing or duplicate requests reach the service team. Automated accessibility checks are useful supporting evidence, but they cannot establish that the whole journey is understandable and recoverable.
Measure abandonment by stage without collecting field contents in analytics. Review help requests about lost work and unclear confirmation. These observations can guide improvements while keeping the project's purpose clear: making it easier for people to complete a legitimate service request.
Our portal security requirements and MVP acceptance tests help combine usability with dependable delivery. TuniCyberLabs provides custom software development for customer-facing workflows. Discuss your portal's hardest form and the point where customers currently need staff to rescue their progress.