HIF Accessibility and Inclusion

Status: normative baseline for HIF 0.5

This document defines the minimum accessibility and inclusive-design contract. The accompanying Accessibility Assurance and Conformance Record defines the evidence required to claim that the contract has been met.

1. Foundational position

Accessibility is the capacity of different people to perceive, understand and control a system in its real context of use. It is an architectural property, not a mode, a theme or a final-stage audit.

Disability is understood as arising through the interaction between a person and their environment. A limitation may be:

• permanent;
• temporary;
• situational;
• created by the interface itself.

2. Normative baseline

For web surfaces, the target minimum is WCAG 2.2 Level AA.

For native and operating-system interfaces, equivalent requirements apply to:

• programmatic semantics;
• keyboard and alternative input;
• focus;
• scaling;
• contrast;
• assistive-technology APIs;
• captions and alternatives;
• error identification;
• documentation.

WCAG does not address every cognitive, neurodivergent or domain-specific need. Formal conformance is not a substitute for research.

3. Perceivable

3.1. Text

• Text MUST support enlargement.
• Reflow MUST preserve content and functionality within the stated limits.
• Line length, line height and spacing SHOULD support sustained reading.
• Images of text MUST NOT be used where genuine text is possible, except for logotypes and essential artefacts.

3.2. Colour and contrast

• Text and meaningful graphics MUST have sufficient contrast.
• Focus indicators and control boundaries must remain perceivable in every relevant state.
• Colour MUST NOT be the sole channel for information.
• Forced colours MUST be supported or an equivalent adaptation provided.

3.3. Media

• Every meaningful image has a text alternative.
• Video containing speech requires captions in the applicable context.
• Audio-only information requires an alternative.
• Autoplaying media should not interfere unexpectedly with a person's work.

3.4. Motion and flashing

• Flashing content MUST remain within safe limits.
• Non-essential motion is disabled or reduced when reduced motion is requested.
• Parallax, zoom and large spatial movement should not be required.

4. Operable

4.1. Keyboard

All primary functionality is available from the keyboard, with:

• reachable controls;
• visible focus;
• a predictable focus order;
• no keyboard traps;
• correctly implemented composite widgets;
• focus restored after temporary layers close.

4.2. Pointer and touch

• Targets have sufficient size and separation.
• Dragging has an alternative.
• Hover is not the only means of access.
• A path-based gesture has a simple alternative unless the gesture is intrinsic to the task.
• An action should not fire unexpectedly on pointer down where a person needs the opportunity to cancel it.

4.3. Timing

• A time limit SHOULD be absent unless necessary.
• The user receives a warning and an opportunity to extend the available time.
• Moving or updating content can be paused when it interferes with the task.

4.4. Voice and speech input

The visible label and accessible name SHOULD match, or begin with the same words, so that a person can address the control by name.

5. Understandable

5.1. Consistency

The same function has a stable name and position within a given context. A change of context does not occur unexpectedly merely because an element receives focus or the user enters data.

5.2. Instructions

Instructions should not depend solely on position, shape, colour or a sensory characteristic.

5.3. Errors

• An error is identified in text.
• Its associated field can be determined programmatically.
• A correction is suggested when one is known.
• Valid data is preserved.

5.4. Cognitive accessibility

The interface SHOULD:

• use clear language;
• disclose complexity progressively;
• preserve orientation;
• provide a preview;
• allow review and correction;
• avoid unnecessary distraction;
• support external memory;
• avoid requiring known information to be entered again without reason.

6. Robust

6.1. Semantics

Every interactive element has:

• a role;
• an accessible name;
• a value or state;
• the relevant relationships;
• supported actions.

Native semantics are used first. ARIA neither supplies behaviour nor repairs an incorrect keyboard model.

6.2. Assistive technologies

The Product Profile defines a support matrix covering:

• screen readers;
• magnification;
• voice control;
• switch control;
• high contrast;
• braille displays;
• platform accessibility APIs.

“Works with ARIA” is not a sufficient support statement.

7. User preferences

The system SHOULD respect:

• text size;
• zoom;
• contrast;
• colour scheme;
• reduced motion;
• reduced transparency;
• reduced data;
• captions;
• input preferences;
• locale;
• content simplification, where supported.

A product setting should not silently override a higher-priority system accessibility preference.

8. Localisation and internationalisation

Accessibility encompasses language and culture, including:

• correct language metadata;
• screen-reader pronunciation;
• right-to-left text;
• plural forms;
• date, number and unit formats;
• text expansion;
• input method editors and composition input;
• the reading of mixed source code and natural language.

9. Accessible authentication

Authentication should not require:

• memorisation or transcription without an alternative;
• a cognitive-function test as the sole route;
• a complex motor operation;
• an inaccessible CAPTCHA.

Password managers, pasting and accessible authentication methods are not blocked without a strong security justification.

10. Documentation and support

Documentation for primary functionality MUST be accessible. It SHOULD describe:

• keyboard commands;
• accessibility settings;
• known limitations;
• alternative workflows;
• a means of reporting an accessibility barrier.

The support process forms part of accessibility.

11. Research

Disabled people participate in research throughout the design process, not only during final acceptance. Research requires:

• representative tasks;
• real assistive technologies;
• different levels of experience;
• privacy and respectful compensation;
• no requirement to disclose a diagnosis unless it is necessary.

The experience of one participant cannot be extrapolated to an entire group.

12. Evaluation

The minimum set comprises:

1. semantic inspection;
2. keyboard-only operation;
3. focus and zoom;
4. contrast and forced colours;
5. reduced motion;
6. an automated scan;
7. screen-reader workflows;
8. alternative pointer workflows;
9. content and error review;
10. user evaluation proportionate to risk.

An automated scan detects only a subset of accessibility barriers.

13. Exceptions

An accessibility exception MUST state:

• the affected function;
• the affected user group;
• the reason;
• the risk;
• an available alternative;
• the responsible owner;
• the review period.

A reference to “technical complexity” without an analysis of alternatives is not sufficient justification.

14. Scope of inclusion

Accessibility concerns whether a disabled person can complete the same meaningful task with comparable autonomy, safety, privacy and dignity. Inclusive design additionally investigates the diversity that a formal conformance standard cannot completely encode.

The design process MUST consider at least:

A persona, checklist or disability simulation MUST NOT be treated as a substitute for disabled participants. Blindfolding a sighted tester, for example, does not reproduce screen-reader expertise or the lived experience of blindness.

No single adaptation is universal. A solution for one group MAY create a barrier for another, so preferences and equivalent routes are preferred to forced presentation.

15. Standards and legal profiles

15.1. Default technical target

The HIF default for web content is WCAG 2.2 Level AA, evaluated against all applicable success criteria and conformance requirements. Selected Level AAA criteria and W3C cognitive-accessibility guidance SHOULD be adopted when they answer identified user needs.

WCAG Level AA is a floor, not a complete definition of an inclusive product. It does not by itself establish compliance with every law, native-software requirement, procurement specification or contractual promise.

For broader ICT and organisational practice, profiles SHOULD consider:

• ISO/IEC 40500:2025, the ISO publication of WCAG 2.2;
• ISO 9241-171:2025, software accessibility;
• ISO/IEC 30071-1:2019, organisational accessibility and inclusive ICT development;
• EN 301 549 V3.2.1, where its ICT scope or legal status applies.

15.2. Jurisdiction register

Every Product Profile MUST record:

• countries and territories;
• public, private, education, employment and procurement contexts;
• product and service categories;
• technical standard, version and conformance level;
• applicable exceptions and who is authorised to decide them;
• statement, reporting, feedback and remediation duties;
• the date on which the legal mapping was checked;
• the accountable accessibility owner and legal-review route.

Examples that MUST remain separate include:

• UK public-sector website and app duties, the Equality Act 2010 or the Disability Discrimination Act 1995 in Northern Ireland;
• the EU Web Accessibility Directive and the European Accessibility Act;
• US ADA Titles II and III, Section 508 and state law;
• sector rules for transport, finance, communications, education, health, employment and self-service terminals.

HIF uses the newer technical baseline where feasible, but MUST NOT silently replace the exact version incorporated into applicable law or a contract.

15.3. Time-sensitive legal facts

The legal register is not copied forward without review. As of 30 July 2026:

• UK government guidance identifies WCAG 2.2 Level AA and an accessibility statement as the public-sector website and app baseline;
• the EU Web Accessibility Directive currently derives a presumption of conformity from the harmonised EN 301 549 V3.2.1; a newer draft is not legally equivalent merely because it exists;
• the European Accessibility Act applies to defined products and services placed on the market or provided after 28 June 2025, subject to its scope and national implementation;
• the current US ADA Title II web and mobile rule identifies WCAG 2.1 Level AA, with compliance dates and exceptions that must be checked from the current rule before making a claim;
• US federal Section 508 includes requirements beyond web content and incorporates its own referenced WCAG version.

These are routing facts, not legal opinions. Applicability, breach, defence, enforcement and remedy require jurisdiction-specific analysis.

16. Conformance is a scoped claim

A WCAG conformance claim applies to complete web pages and complete processes, not selected components or the successful output of a scanner. The record MUST identify:

• exact product, build, date and environment;
• page and screen inventory;
• complete user processes, including authentication, payment, help and error recovery;
• languages, responsive states and content formats;
• relied-upon technologies and accessibility-supported uses;
• third-party, embedded, generated and user-provided content;
• applicable criteria and evaluation method;
• unresolved barriers, alternatives and exceptions.

“WCAG-inspired”, “ARIA-ready”, “passed Lighthouse”, “screen-reader compatible” and “accessible theme available” are not conformance statements.

A sampled evaluation MAY support a bounded finding about the sample. It MUST NOT be generalised to the whole site unless the sampling and full conformance evaluation justify that conclusion.

17. Assistive-technology support matrix

The Product Profile MUST define supported combinations based on the audience, platform, market data, procurement requirements and risk. A combination includes:

operating system and version
+ browser or application runtime and version
+ assistive technology and version
+ input or output device
+ language and relevant settings

Potential combinations include VoiceOver on Apple platforms, TalkBack and Switch Access on Android, Narrator on Windows, and commonly used third-party screen readers where the audience requires them. Inclusion in this list does not make every combination mandatory.

The matrix MUST cover the capabilities relevant to the product:

• speech and braille screen reading;
• screen magnification, zoom and large text;
• keyboard, switch and scanning input;
• voice control and speech input;
• touch, stylus, mouse and alternative pointing devices;
• operating-system contrast and colour settings;
• reduced motion, transparency and animation settings;
• captions, transcripts, audio description and hearing-device paths.

Emulation MAY support debugging but MUST NOT be the sole evidence for a required real-device or assistive-technology workflow.

18. Non-visual interface contract

The accessible representation is an interface in its own right. It MUST expose the intended:

• reading and navigation order;
• landmarks, headings, lists, tables and regions;
• names, roles, values, states and descriptions;
• ownership and relationships;
• available actions and keyboard interaction;
• status, validation, progress and error changes;
• current focus, selection and position within a set.

Visual proximity alone MUST NOT carry a required relationship. DOM, semantic and accessibility-tree order MUST make sense without CSS.

18.1. Screen-reader critical journeys

At minimum, a qualified tester completes representative tasks that include:

1. orienting by title, landmarks and headings;
2. finding content without linear reading of the whole screen;
3. identifying links and controls out of context;
4. completing, reviewing and correcting a form;
5. entering and leaving dialogs, menus and composite widgets;
6. receiving validation, asynchronous status and error feedback;
7. understanding a table, chart or data visualisation;
8. completing authentication and any high-risk transaction;
9. recovering from interruption, timeout and failed submission;
10. accessing help and reporting an accessibility barrier.

For each control, announcement quality is evaluated, not merely the presence of an accessible name. Redundant, verbose, stale or misleading announcements can be as harmful as missing ones.

18.2. Dynamic and custom interfaces

• Client-side route changes MUST update orientation through title, heading and deliberate focus management.
• A modal MUST contain focus while active, provide an operable close path and restore focus predictably.
• Live regions MUST be used sparingly and MUST NOT repeatedly interrupt.
• Virtualised lists MUST expose position, set size and a usable traversal model.
• Canvas, WebGL, maps, diagrams and custom rendering MUST provide an equivalent semantic and task-capable representation.
• Custom controls MUST implement the applicable platform interaction pattern; adding a role without behaviour is insufficient.

19. Low vision, contrast and visual adaptation

19.1. Enlargement and reflow

Web content MUST:

• permit text enlargement to at least 200% without loss;
• reflow at the WCAG reference width equivalent to 320 CSS pixels, except for content that genuinely requires two-dimensional layout;
• preserve content and controls at 400% zoom;
• tolerate the WCAG text-spacing overrides without clipping or overlap;
• avoid disabling browser zoom;
• keep sticky regions, cookie notices and support controls from obscuring the task.

Native products MUST respect the platform's text-size and display-scaling settings to the limits recorded in the Product Profile.

19.2. Contrast

Under WCAG 2.2 Level AA:

• normal text requires at least 4.5:1;
• large text requires at least 3:1;
• meaningful non-text boundaries, icons and states require at least 3:1 against adjacent colours;
• colour MUST NOT be the only means of communicating meaning.

Measure the rendered colour pair in every required state, including hover, focus, selected, disabled where meaningful, validation, overlays, gradients and images. A palette-level calculation does not prove component-level contrast.

The WCAG ratios are acceptance thresholds, not targets for every reader. Products SHOULD permit stronger, weaker or differently hued user-selected contrast where this serves identified needs without weakening the default.

19.3. Forced colours and high contrast

A dark theme is not a high-contrast mode. A custom high-contrast theme is not a substitute for respecting operating-system settings.

When forced colours are active:

• semantic structure and control boundaries remain visible;
• system colours are preferred;
• focus, selection, checked and disabled states remain distinguishable;
• icons that carry meaning remain perceivable;
• background images and shadows are not the only carrier of information;
• forced-color-adjust: none is used only for a proven accessibility need and with an explicit replacement treatment.

Test at least one light and one dark user-defined contrast palette where the supported platform permits it. The normative web behaviour is defined by CSS Color Adjustment Level 1.

20. Hearing, speech and media

• Prerecorded speech and meaningful sound require synchronised captions where the applicable criterion requires them.
• Live media requires live captions where required by the profile.
• Captions identify speakers and meaningful non-speech audio.
• Essential visual information requires audio description or a permitted equivalent.
• Audio-only and video-only information require the applicable alternative.
• A transcript supports search, translation, braille and self-paced reading, but does not automatically replace required captions or audio description.
• Sign-language provision is based on audience need and applicable level or law; it is not assumed to be interchangeable with written captions.
• Alerts, verification and support MUST NOT depend on hearing or speech alone.
• Media controls are keyboard and assistive-technology operable, and caption presentation remains adaptable.

21. Motor and input accessibility

Every task MUST remain operable without precision pointing unless precision is intrinsic to the task.

• Keyboard operation includes all actions, not only reaching controls.
• Focus order follows task logic and remains visible and unobscured.
• Composite widgets use an established internal keyboard model.
• Single-pointer alternatives are provided for multipoint or path gestures.
• Dragging has a non-drag alternative.
• Motion actuation has a conventional control alternative.
• Pointer cancellation prevents accidental activation where required.
• WCAG 2.2 Level AA target-size requirements are tested together with spacing and their stated exceptions; HIF SHOULD prefer larger targets where context permits.
• Time limits are removed, adjustable or extendable unless an exception applies.
• Single-character shortcuts can be disabled, remapped or made active only on focus where required.
• Voice users can address a control using words visible on screen.

Keyboard testing MUST NOT be reduced to pressing Tab: arrow keys, Escape, Enter, Space, platform navigation keys and text-editing commands are exercised according to the control model.

22. Cognitive, learning and neurodivergent needs

The product SHOULD:

• use familiar words and literal, concise language;
• expose one clear primary purpose per step;
• group related information and separate unrelated demands;
• keep navigation, help and identification consistent;
• avoid unnecessary interruption, urgency and animation;
• show progress and preserve orientation;
• externalise memory through visible choices, summaries and histories;
• allow review, correction, undo and safe rehearsal;
• preserve entered information after validation failure or reauthentication;
• support password managers and pasting;
• avoid cognitive-function tests in authentication where an accessible alternative is required;
• explain consequences before irreversible action;
• provide human help through an accessible channel.

W3C cognitive-accessibility guidance is informative and intentionally extends beyond WCAG conformance. A requirement derived from it MUST be labelled as an HIF or product requirement, not misreported as a WCAG success criterion.

23. Flashing, motion and vestibular safety

• Content MUST satisfy the applicable flash thresholds.
• Non-essential animation responds to the system reduced-motion preference.
• A reduction removes large spatial movement, parallax, zoom and repeated pulsing; merely shortening duration may not be sufficient.
• Moving, blinking, scrolling or auto-updating content can be paused, stopped or hidden where required.
• Autoplay does not seize focus or create unexpected sound.
• Essential motion has a documented rationale and a safer alternative where feasible.

24. Inclusive content, language and identity

Inclusive design includes, but is not limited to, disability.

• People are described with the terminology they use for themselves.
• Interface copy does not infer ability, gender, family structure, culture, address format or identity without a task reason.
• Translation, transliteration, right-to-left display, pronunciation and reading level are tested rather than inferred.
• Essential information remains available under low bandwidth and interrupted connectivity where the product context requires it.
• Accessibility settings do not unnecessarily reveal disability status to other users, employers, advertisers or analytics.
• Biometric and AI-mediated paths provide equitable alternatives.

25. Component accessibility contract

Every reusable component MUST document:

semantic role and native element
accessible-name source
states, properties and relationships
keyboard and alternative-input model
focus entry, containment, movement and restoration
reading and DOM order
zoom, reflow and text-spacing behaviour
contrast and forced-colour behaviour
reduced-motion behaviour
announcements and live-region policy
localisation and bidirectional behaviour
supported AT combinations
automated and manual acceptance tests
known limitations and prohibited uses

A component is not “accessible” independently of its content, composition and task context. Component approval reduces repeated defects but does not remove page- and journey-level testing.

26. Assurance lifecycle

Accessibility is tested at every layer:

Automation runs continuously, but a release cannot pass solely because an automated tool reports zero findings. W3C states that no tool alone can determine whether a site meets accessibility standards.

27. Severity and prioritisation

Accessibility severity is based on user harm, not visual prominence or the WCAG conformance level:

Priority additionally considers affected population, frequency, task criticality, legal or contractual scope, breadth of recurrence and remediation dependencies. Several barriers can combine into a higher task-level harm.

WCAG A, AA and AAA are conformance levels, not defect severity. A Level A failure is not automatically more harmful than every Level AA failure.

28. Evidence requirements

Every finding MUST include:

• unique ID and source;
• product build, URL or screen and capture date;
• applicable criterion or product requirement;
• user group and task consequence;
• exact preconditions and reproduction steps;
• expected and observed results;
• platform, viewport, zoom, browser, assistive technology and versions;
• evidence such as code, accessibility-tree excerpt, screenshot or recording;
• severity and rationale;
• owner, remediation guidance and target date;
• retest result, tester and date.

Sensitive recordings and disability-related research data follow the privacy, consent and retention policy. Evidence quality MUST NOT depend on publishing a participant's identity or diagnosis.

29. Statements, alternatives and exceptions

An accessibility statement SHOULD be easy to find and written for users. It identifies:

• the product and scope;
• the standard and claimed status;
• assessment method and date;
• supported environments;
• known limitations in plain language;
• available alternatives and planned remedies;
• accessible feedback routes and response target;
• any required enforcement or escalation route.

The statement is not a marketing badge. “Fully conformant” requires current evidence for the declared scope. Known material failures cannot be hidden behind a generic commitment.

An alternative route MUST provide equivalent information and functionality with comparable timeliness, privacy, cost, reliability and dignity. A phone number is not automatically an equivalent alternative to an independent, private online transaction.

“Disproportionate burden”, “undue burden”, “fundamental alteration” and similar exceptions are legal tests. Only an authorised organisation may claim them after documented analysis and, where required, legal approval.

30. Native, desktop and operating-system interfaces

Native accessibility is expressed through the platform API, not a web-shaped ARIA layer. The applicable profile records, for example:

• UI Automation and Narrator on Windows;
• Apple accessibility APIs, VoiceOver, Voice Control and Switch Control;
• Android accessibility semantics, TalkBack and Switch Access;
• AT-SPI and supported assistive technologies on Linux desktops.

Custom-drawn controls MUST expose the equivalent object, name, role, state, value, actions, bounds, focus and events. Accessibility events are emitted when the user-relevant state changes, not for every internal implementation event.

System text size, display scaling, contrast, colour, reduced motion, captions, input and notification preferences take precedence over product aesthetics unless a documented safety requirement says otherwise.

31. Authoring tools, generated content and AI

Products that enable people to create or publish content SHOULD apply ATAG 2.0 where relevant: the authoring interface is accessible, and the tool supports production and repair of accessible output.

AI or automatic generation does not transfer accountability:

• generated text alternatives are verified in context;
• decorative content is not given noisy descriptions;
• generated UI uses approved semantic components;
• streaming and partial output does not create announcement storms;
• conversational interfaces have non-speech input and output routes;
• summaries and simplifications preserve essential meaning;
• generated captions and transcripts are reviewed to the risk level;
• uncertainty and human escalation are available for consequential tasks.

32. Procurement and third parties

Contracts and procurement MUST state:

• applicable standards, versions and clauses;
• required Accessibility Conformance Report or equivalent;
• evidence and test-method requirements;
• supported assistive-technology environments;
• defect response and remediation times;
• accessibility of updates, documentation and support;
• right to test and retest;
• treatment of third-party and embedded content;
• continuation and exit obligations.

A supplier declaration or VPAT-based report is evidence to assess, not proof to accept without verification. Procurement decisions record gaps, risks, mitigations, owner and review date.

33. HIF accessibility release gate

A release MUST NOT make an accessibility conformance claim unless:

• the Product Profile and jurisdiction register are current;
• the full scope and complete processes are defined;
• the criteria matrix contains no unexplained entries;
• critical journeys pass keyboard and required AT testing;
• zoom, reflow, text spacing, contrast and forced colours pass;
• media alternatives and dynamic announcements pass;
• disabled-user evaluation is proportionate to risk;
• no critical or major barrier remains without an approved, effective alternative;
• every exception has authority, evidence, owner and expiry;
• the public statement matches the evidence;
• regression tests and a barrier-response process are active.

Use the Accessibility Assurance and Conformance Record for this gate.

34. Primary sources

Standards and technical specifications

• W3C, Web Content Accessibility Guidelines (WCAG) 2.2.
• W3C, WCAG-EM 1.0.
• W3C, WAI-ARIA 1.2.
• W3C, ARIA Authoring Practices Guide.
• W3C, Authoring Tool Accessibility Guidelines (ATAG) 2.0.
• W3C, CSS Color Adjustment Module Level 1.
• W3C, Evaluating Web Accessibility.
• W3C, Involving Users in Evaluation.
• W3C, Cognitive Accessibility.
• W3C, Making Audio and Video Media Accessible.
• W3C, Developing an Accessibility Statement.
• ETSI, EN 301 549 V3.2.1.
• ISO, ISO/IEC 40500:2025.
• ISO, ISO 9241-171:2025.
• ISO, ISO/IEC 30071-1:2019.

Platform implementation

• Apple, Accessibility — Human Interface Guidelines.
• Apple, Performing accessibility testing for your app.
• Android Developers, Test your app's accessibility.
• Microsoft, Accessibility testing for Windows apps.

Law, policy and public procurement

• GOV.UK, Accessibility requirements for public-sector websites and apps.
• GOV.UK, Public-sector accessibility monitoring.
• UK legislation, Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.
• European Union, Directive (EU) 2019/882 — European Accessibility Act.
• European Commission, Web Accessibility Directive standards and harmonisation.
• US Access Board, Revised Section 508 Standards.
• ADA.gov, Title II web and mobile accessibility rule guidance.
• Section508.gov, Trusted Tester process.
• Section508.gov, Essential elements of an accessibility test report.