Accessibility

Accessibility is a design condition

Accessibility is considered from the first structural decision, not added after visual approval. It affects language, navigation, interaction, media, performance, and implementation.

WCAG conformance is an important baseline. The broader objective is an experience that people can perceive, understand, and operate across different bodies, devices, environments, and levels of familiarity.

Baseline expectations

Every public HAAM interface should:

• use semantic structure and a logical heading hierarchy;
• support complete keyboard operation;
• preserve visible focus indication;
• provide sufficient colour contrast;
• avoid using colour as the only carrier of meaning;
• include text alternatives for meaningful non-text content;
• label controls by purpose rather than appearance;
• respect reduced-motion preferences;
• remain usable at text zoom and narrow viewport widths;
• announce important dynamic changes to assistive technology.

Content and comprehension

Plain language is an accessibility feature. Important information should not depend on cultural references, unexplained abbreviations, decorative metaphors, or familiarity with an organisation's internal vocabulary.

Error messages should identify what happened, where it happened, and what the person can do next. Instructions should appear before the action that requires them.

Testing

Automated checks are necessary but incomplete. Reviews should combine:

1. automated scanning;
2. keyboard-only use;
3. screen-reader inspection of key tasks;
4. zoom and reflow testing;
5. contrast and forced-colour review;
6. testing with representative users when the consequence of failure is significant.

Exceptions

An exception must record the affected people, the reason the barrier cannot yet be removed, the available alternative, the responsible owner, and a review date. Accessibility debt without an owner is treated as an unresolved defect.