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

Proposed v1.4 · 26 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 36 reviewable rules for Digital Sanctum websites, applications and related service journeys. It covers visual communication and product demonstrations alongside 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.

Lead marketing visitors from discovery to a useful next step

Choose a marketing page's primary call to action (CTA) from its audience, arrival context and current task. This is a proposed Digital Sanctum convention applying DS-UX-001–002, not a universal conversion formula or a WCAG placement requirement.

“Above the fold” describes the initial view at a particular viewport and zoom level; it is not a fixed pixel boundary. Keep the opening value proposition and primary route easy to find, then test their actual placement at representative desktop and mobile sizes and with enlarged text. Do not shrink essential content or clip controls merely to force a CTA into the first screen.

This convention does not require hiding a contact route until the bottom. Keep existing-user sign-in, help and appropriate contact navigation discoverable without making them compete visually with the stage's primary action. Use links for navigation, including movement to a section on the same page, and buttons for actions, following DS-UX-003.

A high-intent campaign page or an audience already ready to act may justify a commitment CTA in the hero. Record the intended audience and arrival context, why that action fits, its destination, evidence or assumptions, accountable approver and review trigger. Do not infer an individual visitor's readiness from unapproved tracking. The choice is contextual; there is no universal button label or guarantee of improved conversion.

Worked example: Sanctum Chat

The Sanctum Chat product page uses Discover how Chat works to reach its connected-work explanation. The journey introduces assistant personas carrying out work through connected business software, informed by the business practices, rules, principles and values supplied by the operator. Concrete workflows and product evidence build that explanation; Discuss a demo appears in the closing section. Supplied guidance is distinct from separately enforced permissions and decision controls. This is a scoped page example, not a claim that every business rule or value is automatically enforced.

For review, record the intended visitor/task and each primary label and destination. Walk the whole CTA group and continuation journey at desktop and mobile widths, with enlarged text and by keyboard. Check visible focus, usable targets, meaningful link labels, existing-user access and any documented exception. Separate observed behaviour from untested accessibility or conversion outcomes.

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.

Use visuals to make information easier to understand

For substantive explanations, comparisons and instructions, assess whether a visual would help the reader answer a question, recognise a pattern or complete a task. State that purpose before choosing the format. Use a visual when it clarifies the content; a short sentence or a few exact values may already be sufficient. Do not add decorative charts simply to meet a quota.

Place a concise explanation beside the visual: what it shows, what matters and any qualification needed to interpret it. A visual should support the surrounding text without forcing readers to decode unexplained symbols or repeatedly switch between distant sections.

Keep visual evidence accurate and accessible

Generate quantitative charts from validated data using reproducible charting tools. Do not use an image generator to invent or approximate plotted values. State the source, observation period, units, denominator and relevant version. Distinguish recorded measurements, estimates, targets and missing values. Missing or unavailable data must not silently become zero.

Use zero-based bar axes and comparable scales for direct comparisons. Other chart types may need different ranges; make those ranges explicit and explain breaks or transformations. Avoid decorative 3D effects, unsupported uncertainty intervals and diagrams whose arrows imply an unevidenced causal relationship. Retain source precision even when displayed labels are rounded.

Provide an equivalent route to the information: a short text alternative identifying the visual and, where needed, an adjacent or clearly linked detailed description or accessible data table. For diagrams, describe the meaningful sequence and relationships, not just the shapes. W3C's complex-images tutorial offers informative implementation patterns; the applicable requirement is WCAG 1.1.1 Non-text Content, Level A, with its stated exceptions.

Do not communicate categories, status or conclusions through colour alone. Use visible labels, patterns, shapes or other cues alongside colour. Assess text and meaningful graphics separately: 1.4.1 Use of Color, Level A, 1.4.3 Contrast (Minimum), Level AA, and 1.4.11 Non-text Contrast, Level AA, have different scopes and exceptions. Ordinary text normally needs 4.5:1 contrast; qualifying large text uses 3:1. Parts of graphics required to understand the content use 3:1 against adjacent colours where 1.4.11 applies. These are not blanket contrast requirements for every pixel. See W3C's explanations of colour, text contrast and non-text contrast.

Check narrow screens, zoom, readable labels and contained overflow. Interactive figures need keyboard access and usable focus; essential information must not depend on hover. The proposed Digital Sanctum convention is to retain a useful static or text equivalent when application scripts are unavailable. Where reuse is expected, provide suitable image/vector exports and machine-readable chart data; an image download does not replace an accessible on-page equivalent. Verify that the page, data table and exports agree, and record what was actually tested.

The editorial benchmark score and dimension figures, quality versus estimated cost plot and recorded token composition illustrate these formats and their qualifications. They are examples to inspect, not accessibility conformance certificates or templates for every subject.

Show the experience behind the product or service

Product landing pages and portfolio case studies should help someone see what they would use or receive, how it works and why it matters. This applies to Digital Sanctum products and tools, client products and websites, and services or deliverables we showcase.

The proposed baseline for a new or substantially revised showcase page is a representative view near the opening explanation, plus evidence of one useful workflow or result. A clearly annotated image can satisfy both where the task is simple. Put media beside the relevant benefit and explain the action and visible result in a short caption. A visitor should not have to finish a long feature list before encountering the experience.

Show the real product at a readable scale. Crop or annotate to direct attention and offer a larger view where necessary. Decorative artwork or a device frame does not establish how the product works. Label concept illustrations, prototypes and synthetic demonstrations beside the media; do not present them as current application captures. Disclose simulated outcomes, sped-up footage or omitted waits when they change the apparent result or speed.

Match demonstrated capabilities to the identified product, version and access context. Connect the task to its benefit, while distinguishing a visible result from a measured business outcome. A screenshot cannot establish encryption design, security guarantees, integrations or time savings by itself. Verify those claims separately. If the public app, product description and proposed demo disagree, resolve the identity or capability question before publishing that claim as current.

Record a scoped exception where an authentic public view is unavailable or inappropriate, such as confidentiality or an unreleased product. Identify the reason, publication authority, review trigger and an honest alternative. Do not expose private information to satisfy a media requirement.

Make demos safe, accessible and economical

Capture with synthetic data in an authorised demonstration environment where possible. Inspect the whole frame and recording, including notifications, browser tabs, addresses, account details, credentials and returned links. Sanitise the exported asset itself, not merely its page overlay. Confirm existing client or third-party publication permission, licence, attribution and scope before release. Product access alone does not authorise marketing publication.

Start with clear static evidence. Add animation or video when it explains a particular task. Prefer user-initiated playback, a meaningful poster frame, and a visible task title and duration. Avoid sound on autoplay. Provide usable pause, replay and keyboard controls, honour reduced-motion preferences for non-essential presentation, and retain a useful still/text alternative. Animation is an enhancement, not a prerequisite for a credible product page.

Assess accessibility against the actual media. Relevant WCAG criteria include 1.2.1 Audio-only and Video-only (Prerecorded), Level A, 1.2.2 Captions (Prerecorded), Level A, 1.2.3 Audio Description or Media Alternative (Prerecorded), Level A, and 1.2.5 Audio Description (Prerecorded), Level AA, within their scopes and exceptions. Plan captions for meaningful speech/audio and descriptions of essential visual actions; a silent screen recording still needs an equivalent route to its information. W3C's audio and video guidance explains these options and accessible players.

Apply 2.2.2 Pause, Stop, Hide, Level A to qualifying automatically started moving content. Its five-second condition does not make shorter distracting content good design. 2.3.3 Animation from Interactions is Level AAA, not a blanket AA requirement. Reduced-motion support and static alternatives are also proposed Digital Sanctum conventions. Assess flashing separately under the applicable WCAG requirements; a reduced-motion switch does not establish protection against flashing content.

Choose responsive image sizes, efficient video formats and deliberate loading. Reserve display space, avoid oversized animated GIFs and defer heavy off-screen media or third-party players until needed. Keep the core explanation usable when playback, scripts or an embed fail. Record a page-specific media budget for transferred bytes and loading behaviour, then check it on narrow screens and an appropriate slower connection. Compression alone does not establish a fast or accessible page. See the informative video-performance guidance.

Retain each asset's source product/build, capture date, demonstrated task/claim, publication rights, sanitisation check, accessible alternatives, delivery format/size and accountable maintainer. Review media when the interface, workflow, claim or supported access changes. Remove or clearly identify obsolete views.

The Remote Support guide illustrates placing clearly labelled interface illustrations at the relevant steps. Illustrations can explain where to act without being represented as screenshots or independent proof of a product capability.

Make product media sharp and inspectable

A small preview introduces the experience; it is not the only way to inspect it. Give people a visible enlargement affordance on screenshots and a clear route to a larger video player. Keep the page and reading position available. Our proposed default is an in-page lightbox rather than sending an ordinary image click to another tab. When scripts or modal support are unavailable, a same-tab original-image or native-video link with normal browser Back is an acceptable fallback. The default is a Digital Sanctum convention, not a universal WCAG requirement.

Use sufficient source detail for the largest intended inspection view and target display density. Capture a clean master before creating responsive previews. For text-heavy interfaces, prefer lossless capture and check a high-density source; 2× the intended CSS dimensions is a starting convention, not a guarantee of readability. Cropping to a meaningful task area can communicate more than shrinking an entire desktop. Do not upscale an inadequate bitmap and describe it as higher-resolution evidence. Preserve the original aspect ratio and check fine text, edges, colour and compression in the actual delivered asset.

Baymard's research on image resolution and zoom finds that inadequate enlargement can prevent users inspecting product detail. Applying that principle to application interfaces is our contextual design choice. The browser can select suitable previews through responsive image density/size descriptions; the full inspection source should be loaded on demand. Record capture CSS size, pixel dimensions, density, source version and the largest reviewed presentation. A nominal pixel count alone is not a quality pass.

Enlarge media without losing control or context

An image viewer should offer a whole-image fit and an actual-pixel view with usable zoom/pan. On a high-density display, actual pixels should account for device pixel ratio. Do not stretch beyond available detail by default. Support touch and keyboard inspection, clear focus indication and an explicit Close control. A change of viewport must keep the controls and an understandable image position usable.

Follow the WAI modal-dialog pattern: label the dialog, move focus inside it, keep background content inert, contain the tab sequence, support Escape and return focus to the invoking control. These are implementation patterns supporting applicable keyboard/focus requirements, not proof of whole-page conformance. Prefer a native modal dialog with tested behaviour over a visual overlay that leaves the background interactive. Backdrop dismissal may supplement an explicit Close button; it must not be the only exit.

Give video a readable inline area and an Open larger video action using the same viewer. Retain native play/pause/seek/captions and a fullscreen option where supported; do not rely on a tiny embedded player or a download as the primary viewing experience. Fullscreen availability varies, so feature-detect it and retain the large modal. Escape may first exit browser fullscreen before closing the viewer. Pause playback on dismissal and restore the reader's place and focus. A button that only enlarges video need not start playback; preserve a user's existing playback choice.

Encode from a master that retains the task's readable detail. For landscape product tours, assess Full HD or higher where the task and expected display warrant it, rather than serving a low-resolution export in a larger frame. Resolution is a starting point: check the actual text and controls in the decoded video, poster and expanded view. Keep captions/static equivalents and the deliberate preload/poster strategy. Record separate initial-preview and on-demand transfer budgets; avoid downloading every inspection master or video before the visitor asks for it.

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.

Revision history

• Proposed v1.4 · 26 October 2026: adds DS-UX-037 and a worked Chat example for discovery-led marketing journeys, closing conversion and documented intent-based exceptions. Earlier rules, the original publication date and pending-adoption status remain intact.

• Proposed v1.3 · 26 October 2026: adds DS-UX-034–036 for readable source detail, accessible in-page image inspection and larger controllable video. The earlier rules, publication date and pending-adoption status remain intact.

• Proposed v1.2 · 26 October 2026: adds product, service and portfolio experience-media guidance and DS-UX-029–033, covering authentic captures, demonstrated value, permissions, accessible motion, performance and maintenance. Earlier rules and pending-adoption status are retained.

• Proposed v1.1 · 26 October 2026: adds visual communication guidance and DS-UX-025–028; links worked examples and retains the original publication date and pending-adoption status. DS-UX-024 remains reserved for a separate unpublished navigation amendment.

• Proposed v1.0: content revised 17 October 2026; first published 22 October 2026, with DS-UX-001–023.

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.