Accessibility

A component can pass an automated check while the overall task remains confusing or impossible. Accessibility depends on structure, language, keyboard operation, focus, contrast, error handling, assistive-technology support, media alternatives and the content organisations publish.

This website uses semantic landmarks, a skip link, visible focus, keyboard-operable navigation, labelled forms and reduced-motion support. It has been designed towards WCAG 2.2 AA; no independent audit or formal conformance claim is made.

The Portal Page product should apply the same discipline and be tested with disabled people whose real tasks reveal issues that tools miss.

People may navigate by keyboard, switch, touch, voice or screen reader. They may enlarge text, reduce motion, use high contrast, require captions, prefer plain language or need more time to complete a task.

An accessible portal should keep headings logical, controls predictable, status messages perceivable and touch targets generous. Important meaning should not depend on colour alone. Motion should respect system preferences and avoid obstructing the task.

Authentication and support also matter. A perfectly accessible content page cannot compensate for an inaccessible sign-in flow or a help route that only works by phone.

• Keyboard and focus testing
• Screen-reader task testing
• Zoom and reflow from 320 pixels
• Contrast and non-colour cues
• Captions, transcripts and document alternatives
• Clear errors and recovery

Portal Page can provide accessible foundations, but administrators and members create the living content. Poor headings, unexplained links, image-only notices and inaccessible PDF files can exclude people even when the platform interface is sound.

Organisations need authoring guidance, templates, review practices and a route to request an alternative format. Accessibility should be part of moderator and administrator training, not delegated entirely to a technical team.

A production accessibility statement should describe tested scope, known limitations, contact routes and response expectations. Issues should enter a prioritised remediation process and be checked for regression.

Procurement teams should ask for current evidence rather than accept a generic claim. Portal Page should share the testing approach and be transparent about gaps as the product matures.