Digital Sanctum UX and UI Design Standard: clear, accessible and trustworthy interfaces

Proposed v1.0 · 17 October 2026 · Guidance pending adoption

A trustworthy interface helps people understand what to do, what will happen next and what has happened to their information. It supports someone completing a task on a phone, navigating by keyboard, using a screen reader or returning later with a saved document.

This proposed standard sets out 23 reviewable rules for Digital Sanctum websites, applications and related service journeys. Its most detailed examples concern forms, sensitive information, document generation and recovery from mistakes.

It is not an adopted organisational policy, an accessibility conformance certificate or a claim about the behaviour of any existing product. It is also not a complete design system: that requires maintained design tokens, components, patterns, implementation guidance and accountable ownership.

How to read this proposal

The guidance distinguishes three sources of authority:

• Normative accessibility requirements come from an applicable standard. The WCAG 2.2 Recommendation is the authoritative reference for its success criteria, levels, scope and exceptions. W3C’s Understanding pages explain those criteria.
• Advisory guidance offers useful implementation patterns. GOV.UK, WAI tutorials and usability research inform design choices, but their recommendations are not automatically universal obligations.
• Contextual conventions are proposed Digital Sanctum choices. They need adoption before they become internal requirements.

In the appendix, N-linked means that part of the rule relates to a named accessibility requirement. A means advisory guidance; C means a contextual convention. A mixed label does not make every part of a rule normative.

The words “should” and “must not” below describe this proposal’s intended conventions unless explicitly attributed to an external requirement. They do not establish that the proposal has been adopted.

Give each stage a clear purpose

Start with the person’s task, not the database structure. For each stage, write one sentence explaining what the person is trying to achieve, then identify the primary action that advances it.

A contact-details stage might end with Continue. A final review stage might end with Submit request. Secondary actions should remain discoverable without competing with the main task.

GOV.UK’s button guidance recommends avoiding multiple primary buttons because competing actions make the next step harder to identify.

Divide complex journeys into meaningful stages rather than imposing an arbitrary number of fields per page. Reveal specialised detail when it becomes relevant, while keeping essential consequences, privacy information and alternative routes visible. This applies the advisory principle of progressive disclosure; it does not guarantee improved completion rates.

For example, a synthetic document-request journey could use:

1. Contact details.
2. Required output.
3. Relevant supporting information.
4. Review and submit.

That is a starting structure to test, not a universal four-stage template.

Match controls to their actual behaviour

Choose semantics from behaviour, not visual prominence.

A button performs an action: validating a stage, generating a PDF, opening a dialog, saving answers or submitting information. A link navigates to another location or retrieves an existing resource.

That distinction matters for downloads:

• Generate PDF starts processing and can be a button.
• Download the blank form (PDF) can be a link to an existing file.
• Download completed PDF can be a link once the generated resource is available.

A native file input is also appropriate for file selection; the proposal does not require every upload interface to be a custom button. A quiet, text-style button can serve a secondary action if its focus and target styling remain usable.

See GOV.UK’s guidance on buttons and links.

Labels should predict outcomes. Continue must not unexpectedly download a PDF, submit the whole form or imply persistent saving. Use distinct labels for distinct actions.

Explain fields before asking people to correct them

Provide visible, meaningful labels and associate them with their controls. Explain required information, unusual formats and important constraints before entry where useful. Placeholder text is not a replacement for a label.

WCAG 3.3.2 Labels or Instructions, Level A, addresses providing labels or instructions. Correct programmatic association is a related but separate concern, including 1.3.1 Info and Relationships. W3C’s explanation of Labels or Instructions makes this distinction explicit.

Practical input choices include:

• Date of birth: test clearly labelled Day, Month and Year fields as an initial candidate. Support ordinary mobile entry without requiring typed slashes. Avoid automatic focus jumps and unnecessary navigation through decades of calendar pages. This follows advisory GOV.UK date guidance.
• Names and titles: accept the name structures and characters people need. Explain whether an official-document name is required. Avoid collecting a title unless necessary; where collected, prefer optional free text rather than a compulsory restricted list. See GOV.UK’s names guidance.
• Email: allow paste and autofill, use an appropriate input type and avoid unnecessary repeated entry. An unusual domain is not automatically invalid. Format validation does not establish mailbox ownership. See email-address guidance.
• Telephone: accept familiar spaces, brackets, hyphens and relevant international prefixes. A telephone keyboard hint does not validate a number or establish ownership. See phone-number guidance.

Test these choices against downstream requirements. Do not promise input tolerance that the receiving system cannot support; identify and address the constraint instead.

Make choices and conditional questions predictable

Use radio buttons for mutually exclusive answers and checkboxes for independent selections. State when multiple answers are allowed. Do not preselect consent.

An Other option should reveal a labelled request for detail only when selected. Irrelevant fields should not remain active in the keyboard sequence or appear as current questions to assistive technologies. GOV.UK’s radio and checkbox patterns provide implementation guidance.

Medicare, funding and eligibility questions need owner-approved applicability rules. Interface design must not invent entitlement, imply bulk billing or rewrite approved clinical or legal meaning.

Changing an earlier answer requires deliberate handling. If someone enters Other details and then selects a different option, do not silently delete the text or quietly include the now-inapplicable answer in submission.

Explain the available resolution: retain it temporarily where permitted, remove it explicitly, or explain why removal is required and request confirmation. Retained inactive information must be clearly excluded from submission unless the person deliberately makes it applicable again.

Preserve work without silently persisting it

Helping people recover does not authorise storing everything they type.

Distinguish temporary values in the current page from a persistent draft stored in a browser or on a server. Preserve safe input during validation and navigation where supported, but do not silently introduce persistence to make refresh recovery possible.

Before offering a persistent draft, establish an approved mechanism and explain:

• what is stored and where;
• how the person returns, including from another device where supported;
• the verified retention or expiry conditions;
• access protections and shared-device implications;
• how the person can clear or delete the draft.

If refreshing or closing the page loses unsaved answers, explain that before the risk becomes consequential. Do not call movement between stages “saved”.

Offer save-and-finish-later after meaningful input rather than as an obstacle before any answers. A save confirmation should describe a verified outcome. Saving, continuing and resuming do not establish consent to a separate use or disclosure.

Make returning discoverable without visit tracking

A returning-user route should be available from the starting point, including on another device or after local storage has been cleared.

Do not record that a browser visited a sensitive service page merely to decide whether to display Resume. Absence of local history does not establish that someone lacks a saved PDF.

Where supported, one deliberate Use a saved or completed PDF entry can explain the available task: resume editable answers, review a completed document or prepare an explicitly requested submission. State supported files and limitations before selection. Do not imply that any PDF can restore form answers.

Other recovery mechanisms, such as an authorised reference or recovery link, require their own identity, expiry and support design. Describe the implemented mechanism rather than implying knowledge of page visits or appointment attendance.

Separate submission, documents and delivery

Before final submission, explain what will be sent, where it will go and what confirmation to expect.

A completed PDF, a fillable PDF and a submitted record are different outputs. State whether a document is downloaded, stored or sent through an approved delivery route. Explain connectivity requirements and any verified offline capability.

For sensitive downloads, remind people to choose an appropriate storage location on shared devices. Do not promise automatic deletion of files outside the application’s control.

Confirm only evidenced states:

An API acknowledgement does not necessarily establish staff review. When the result is uncertain, offer a safe next step rather than encouraging repeated submissions that may create duplicates.

Where contact help is useful, show a readable, copyable address or telephone number. An email link needs a compatible handler; it does not send itself or automatically attach a generated PDF. Avoid repeating identical contact controls where they add no help.

Make errors and progress usable

Normally validate at meaningful completion attempts, rather than interrupting unfinished typing. Preserve safe, valid input and explain corrections specifically.

“Enter a month from 1 to 12” is more useful than “Invalid date”. Where information is sent to a server, validate there too: browser validation can be bypassed. The WAI validation tutorial explains tolerant input, server-side checks and opportunities for review.

WCAG 3.3.1 Error Identification, Level A, requires automatically detected input errors to identify the affected item and describe the error in text. It does not mandate one error layout. See W3C’s Error Identification explanation.

For multi-field failures, the proposed convention is an error summary linking to affected controls, matching inline messages and predictable focus after the failed attempt. This is informed by GOV.UK’s error-summary pattern, not a claim that WCAG universally mandates that exact presentation.

Qualifying status messages also need suitable programmatic identification. WCAG 4.1.3 Status Messages, Level AA, addresses messages that can be presented by assistive technologies without receiving focus. Not every conditional reveal is such a message; indiscriminate live announcements can make a form noisy. See W3C’s explanation.

Test complete journeys

Test first use, returning, back-navigation, changed answers, invalid input, file rejection, interrupted connectivity, document generation and downstream failure.

Include keyboard operation, absence of keyboard traps, logical and visible focus, screen-reader behaviour, contrast, zoom, narrow-screen reflow and control targets. Relevant WCAG criteria include 2.1.1, 2.1.2, 2.4.3, 2.4.7 and 2.4.11, with their respective levels and scope.

For target sizing, 2.5.8 Target Size (Minimum), Level AA, uses a 24 CSS-pixel threshold with specified alternatives and exceptions. A roughly 44-by-44 CSS-pixel target is a proposed comfort target where feasible, not the blanket AA requirement. Consult the normative Recommendation for exact criteria.

Use synthetic, non-clinical data in examples, demonstrations and audits unless separately authorised otherwise. Compare displayed answers, generated documents and submitted fields. Test contradictory imported and current answers without silently replacing either.

A screenshot can support a visible finding; it cannot establish keyboard behaviour, storage, hidden payloads or delivery. An automated check or successful demonstration is not comprehensive accessibility or security evidence.

Public rule and audit appendix

Classification: N-linked = identified accessibility requirement within the rule; A = advisory guidance; C = contextual proposal. All contextual conventions remain pending adoption.

For every row, record pass, fail, not applicable or not tested, with the journey, build, evidence, user impact and acceptance result. Explain every not-applicable decision.

Ownership, exceptions and review

This proposal should complement existing Product Design Consistency governance rather than create a competing authority for design tokens or components.

Before adoption, confirm the accountable owner, canonical versioned home and responsibilities for accessibility, content, privacy, security and operation. Role descriptions are not evidence of appointments.

An exception record should identify the rule, affected journey, reason, supporting evidence, user impact, compensating measures, accountable approver and review date. An internal exception cannot waive an external obligation or establish a conformance claim.

Keep identifiers stable. Record substantive amendments and retire obsolete rules rather than reusing their IDs. Review after material changes to sources, implementation or user needs, with an initial proposed annual review by 17 October 2027.

The aim is not identical screens everywhere. It is behaviour people can understand, information they can control and recovery they can use.