At a glance
- Keyboard and readable mobile layouts are design requirements.
- An independent accessibility certification is not claimed.
- An alternative-format request channel needs setup.
Our approach
The interface is designed for keyboard navigation, visible focus, labelled controls, readable text and responsive layouts. Loading and error messages should explain the next action, and forms should preserve entered information when safe.
A design goal is not proof of conformance. A complete accessibility audit, assistive-technology review and remediation record are still required; this working statement does not declare WCAG conformance or legal certification.
Reading and controls
Policy pages provide a table of contents, meaningful headings and links between related topics. You can resize text using your browser. Content should reflow on smaller screens without hiding the main action.
Externally linked websites, event registration services and documents may have their own accessibility limitations. Their owners control those experiences.
Tell us about a barrier
Use the contact form to record a local accessibility concern under Other. Helpful details are the page address, task, browser or assistive technology, and the barrier you encountered. Do not send sensitive account credentials.
The form saves a local request and does not send an external email. Before launch, the team needs a verified accessibility contact, response procedure and alternative-format process. This local preview cannot promise a response deadline or a particular format.
Before launch
These remaining decisions explain why this page is a working draft.
- Approve an accessibility target and testing scope.
- Complete assistive-technology and keyboard journey testing.
- Verify the accessibility contact and alternative-format process.