This page provides the intended corporate structure and plain-language content. It must be reviewed against the group’s final legal entities, processing activities, contracts, markets and applicable laws before publication.
1. Our commitment
Accessibility is treated as part of product quality rather than a final visual check. The corporate design system includes keyboard access, focus visibility, responsive layouts, readable contrast, semantic structure and reduced-motion support.
The group intends to address barriers identified through testing and user feedback according to their effect and practical urgency.
2. Accessibility target
The website is being designed toward WCAG 2.2 Level AA. This is a development objective, not a claim of full conformance. A production statement should describe the result of an accessibility audit performed on the deployed website.
3. Accessibility features included in the development system
- A skip link that allows keyboard users to move directly to the main content.
- Visible keyboard focus styles for interactive elements.
- Semantic headings, landmarks, lists and navigation labels.
- Responsive layouts that do not depend on a fixed desktop viewport.
- Text alternatives for meaningful images and decorative treatment that can be ignored by assistive technology.
- Support for the browser’s reduced-motion preference.
- Forms with visible labels, instructions and error messaging.
- Colour choices intended to maintain sufficient contrast for important text and controls.
4. Testing approach
Before launch, the website should be reviewed through a combination of automated checks and manual testing. The test plan should include:
- Keyboard-only navigation and focus order.
- Screen-reader checks on primary templates and forms.
- Zoom, text resizing and responsive reflow.
- Colour contrast and non-colour status indicators.
- Form validation, error identification and recovery.
- Reduced-motion behaviour and animation controls.
- Representative browsers, operating systems and mobile devices.
5. Known limitations during development
The current website is a development build. Final images, documents, embedded services, newsroom materials and recruitment integrations have not all been added or audited.
Any known production limitations should be listed here with an explanation, an available alternative and the expected remediation status. The statement should not claim full compliance while unresolved barriers remain.
6. Browser and assistive-technology compatibility
The production website should support current mainstream browsers and common assistive technologies. Older or unsupported software may not provide the same experience.
The final statement should be updated after compatibility testing and should avoid naming combinations that have not been tested.
7. Accessibility feedback and support
Visitors should be able to report an accessibility problem, request information in an alternative format or ask for help completing a corporate task.
The production page must identify an approved contact route and the information that helps the team investigate, such as the page address, device, browser, assistive technology and a description of the barrier.
8. Review and continuous improvement
The statement should be reviewed after major interface changes and at planned intervals. Accessibility findings should be tracked alongside normal product, content and quality work.
The effective date, audit method, conformance status and responsible contact must be confirmed before this statement is published at the root domain.