
Accessibility at Zoiko iD
We aim to make information and product experiences usable for people with different accessibility needs. Find guidance here and tell us if something prevents access.
This page's scope is our own verified practice, lineage and truthful verified help. It is never invented.
Perceivable
Readable text, required contrast
Operable
Keyboard use, visible focus
Understandable
Clear labels and errors
Robust
Semantic structure

No certification is claimed
Our pages conform to WCAG 2.2 Level AA.
This is a goal, not a past formal audit.
ACCESSIBLE SITE SHELL
Entry, landmarks
and focus
The shell is shared across the site. These are the behaviours this page depends on.
Skip link
Takes to main content on the first keyboard step and moves focus to the main region.
Landmark sequence
Header, navigation, main and footer, in that order, once per page.
Menu and focus
On mobile sizes the menu collapses without losing keyboard access, and focus returns to the menu button on close.
Display preferences
Forced colours, high contrast and reduced motion are respected by the shell.
Accessibility is part of how we design
Four points guide this design work. Each has a subsection below, with the practices behind it.
APPROACH POINT 1
Perceivable content
Information is presented so it can be perceived by every visitor, not only by those who see colour or hear sound.
Example: a destination is never red-text alone.
Text alternatives
Images carry textual alternatives that describe their purpose; decorative images are hidden from assistive technology.
Colour and contrast
Meaning is never conveyed by colour alone, and text and interface contrasts are tested against AA targets.
Text resizing
Content keeps its meaning when text is enlarged, without clipped or overlapping elements.
Time-bound media
Media that depends on sound or motion provides an equivalent text alternative.
APPROACH POINT 2
Operable Controls
Every control and navigation path can be used from the keyboard, with a visible indication of where focus is.
Example: tabbing from the header to the main content.
Keyboard reachable
All interactive elements can be reached and activated without a pointing device.
Visible focus
The focus indicator stays visible on every focused element, meeting the approved contrast criteria.
No keyboard traps
Focus can always move away from a control, including dialogs and menus.
Enough time
Interactions do not expire without warning, and motion can be paused where it is not essential.
APPROACH POINT 3
Understandable interactions
Labels, instructions and error messages are clear, and pages behave in predictable ways.
Example: a form error announces relevance to field.
Clear labels
Form fields have visible labels and descriptions that stay with the input.
Errors explained
Errors name the field, explain what went wrong and describe how to fix it.
Predictable pages
Navigation stays in the same place and does not change context unexpectedly.
Plain language
Short sentences, familiar terms and a clear structure of headings.
APPROACH POINT 4
Robust compatibility
Pages use semantic structure so that current and future assistive technologies can read and interpret them.
Example: landmark labels to a screen reader.
Semantic structure
Headings, lists, landmarks and buttons are used for their meaning.
Valid markup
Markup is complete and uses names and roles that assistive technologies understand.
Status messages
Updates such as search results or confirmations are announced without taking focus away.
Tested, not assumed
Compatibility is judged by testing, and no specific assistive technology is promised.
STANDARDS AND VERIFICATION
Target and verified status are kept apart
This target is stated plainly. A verified status is published only after assessment and sign-off.


USING ZOIKO ID IN MODERN WEB
Practical
guidance
Sections are anchored so you can jump straight to what you need. Each describes the behaviour the platform is designed to support.
Keyboard navigation
Use Tab and Shift+Tab to move between controls. Enter and Space activate buttons and links.
Headings and landmarks
Pages have one main heading, followed by ordered sections, and use landmark roles: header, navigation, main and footer.
Zoom and reflow
Content is designed to remain usable at large text sizes and at narrow widths, without horizontal scrolling for reading.
Forms and errors
Fields have visible labels. Errors are described in text and linked to the field that needs attention.
Reduced motion
Animation is omitted where you ask for reduced motion, and no information depends on motion alone.

WHERE ACCESSIBILITY APPLIES
Surfaces and
their status
Each surface is noted separately. Test status is shown only where verified evidence exists.
| Surface | Covers | Test status |
|---|---|---|
| Public marketing pages | Overview, platform and company pages | Not published |
| Help and documentation | Support, documentation and specialist routes | Not published |
| Identity flows | Authentication sign-in and recovery flows | Not published |
| Enterprise consoles | Organization administration, where released | Not published |
KNOWN LIMITATIONS
Open issues, as
they are approved
Each entry shows its surface, impact, workaround where verified, update date and owner. Sensitive ticket detail is never published.
There are no published limitation notices here.
This does not mean there are no known issues; it means no limitation has been approved for publication.

SUPPORT ROUTING
Need help
accessing
something?
Choose the description that fits. Each card opens only an approved destination.
Accessibility barrier
A page, feature or control prevents you from using the site.
Account or product help
Sign-in, account and product questions.
Privacy request
Questions about your personal data.
Security concern
Suspected compromise or vulnerability. Correct as referenced.
BARRIER REPORT
Report an
accessibility
barrier
This form is shown as a specification. No submit control appears until a verified intake route and a secure backend exist.
CONFIRMATION AND UPDATES
What happens
after you submit
Success is shown only after the server acknowledges the report. A case reference appears only when the system provides one.
Acknowledged
"Your report has been received." Focus moves to the heading.
Unavailable
An error is shown, your input is kept, and retry is safe.
Unknown
No outcome is claimed. You are told how to check before retrying.
RELEASE GATES
What must be
true before this
page is published
Hard blockers: Fabricated conformance, an unsupported contact channel, an inaccessible frontend workflow, unresolved critical keyboard or screen-reader defects, unapproved privacy wording, expired review date, untested high-volume navigation.
| Owner | Requirement before release |
|---|---|
| Accessibility and QA | Keyboard, screen-reader, zoom and forced-colours evidence |
| Legal | Scope-specific statement wording and canary retention |
| Support Engineering | Working intake, acknowledgement and retry behaviour |
| Web Operations | Clear rollout route and scheduled review ticket |
Frequently asked questions
Find answers to common questions about Zoiko iD

Tell us what is getting in
the way.
Use the routes below for your question. Each one is marked with its status, and none is shown active until it is verified.
ACCESSIBLE SITE SHELL
Entry, landmarks and
focus
The shell is shared across the site. These are the behaviours this page depends on.
Skip link
“Skip to main content” is the first keyboard step and moves focus to the main region.
Landmark sequence
Header, navigation, main and footer, in that order. One hit per page.
Menu and focus
On small screens the menu collapses without losing keyboard access, and focus returns to the menu button on close.
Display preferences
Forced colours, high contrast and reduced motion are respected by the shell.
Accessibility at
Zoiko iD
We aim to make information and product experiences usable for people with different accessibility needs. Find guidance here and tell us if something prevents access.
The report route is not yet verified. Until it is, this page points to verified Help & Support instead.
Perceivable
Readable font, text alternatives
Operable
Keyboard use, visible focus
Understandable
Clear labels and errors
Robust
Semantic structure

No certification is claimed
Our target is WCAG 2.1 Level AA. That is a goal, not a verified result.
Accessibility is part of
how we design
Four points guide the design work. Each has its own section below, with the practices behind it.
APPROACH POINT 1
Perceivable content
Information is presented so it can be perceived by every visitor, not only by those who see colour or hear sound.
Example: all styled text with a text equivalent.
Text alternatives
Images carry text alternatives that describe their purpose; decorative images are hidden from assistive technology.
Colour and contrast
Meaning is never conveyed by colour alone, and text and interface contrast are checked against the target.
Text resizing
Content respects meaning when text is enlarged, without clipped or overlapping content.
Time-based media
Media that depends on sound or motion provides an equivalent text alternative.
APPROACH POINT 2
Operable controls
Every control and navigation path can be used from the keyboard, with a visible indicator of where focus is.
Example: tabbing from the header to the main content
Keyboard reachable
All interactive elements can be reached and activated without a pointing device.
Visible focus
The focus indicator stays visible on every control, meeting the approved contrast criteria.
No keyboard trap
Focus can always move away from a control, including dialogs and menus.
Enough time
Interactions do not expire without warning, and motion can be paused where it is not essential.
APPROACH POINT 3
Understandable interactions
Labels, instructions and error messages are clear, and pages behave in predictable ways.
Example: a form error announced beside its field
Clear labels
Form fields have visible labels and descriptions that stay with the field.
Errors explained
Errors name the field, say what went wrong and describe how to fix it.
Predictable pages
Navigation stays in the same place and does not change context unexpectedly.
Plain language
Short sentences, familiar terms and a clear structure of headings.
APPROACH POINT 4
Robust compatibility
Content is compatible with current and future user tools, including assistive technologies.
Example: verified against standard HTML parsers
Semantic structure
Headings, lists, tables and form controls use appropriate HTML elements.
Valid markup
Clean, valid markup prevents parsing errors and ensures reliable screen-reader output.
Status messages
Dynamic updates and state changes are surfaced without moving focus unexpectedly.
Tested, not assumed
Compatibility is verified against real assistive technology configurations.
STANDARDS AND VERIFICATION
Target and verified
status
are kept apart
The target is stated plainly. A verified status is published only after assessment and legal sign-off.



USING ZOIKO ID ACCESSIBLY
Practical guidance
Sections are anchored so you can jump straight to what you need. Each describes the behaviour the platform is designed to support.
Keyboard navigation
Use Tab and Shift+Tab to move between controls. Enter and Space activate buttons and links.
Headings and landmarks
Pages have one main heading, followed by ordered sections, and use landmark roles: header, navigation, main and footer.
Zoom and reflow
Content is designed to remain usable at large text sizes and at narrow widths, without horizontal scrolling for reading.
Forms and errors
Fields have visible labels. Errors are described in text and linked to the field that needs attention.
Reduced motion
Animation is omitted where you ask for reduced motion, and no information depends on motion alone.



WHERE ACCESSIBILITY APPLIES
Surfaces and their status
Each surface is noted separately. Test status is shown only where verified evidence exists.
| Surface | Covers | Test status |
|---|---|---|
| Public marketing pages | Overview, platform and company pages | Not published |
| Help and documentation | Support, documentation and specialist routes | Not published |
| Identity flows | Authentication sign-in and recovery flows | Not published |
| Enterprise consoles | Organization administration, where released | Not published |
KNOWN LIMITATIONS
Open issues, as they are approved
Each entry shows its surface, impact, workaround where verified, update date and owner. Sensitive ticket detail is never published.
There are no published limitation notices here.
This does not mean there are no known issues; it means no limitation has been approved for publication.



SUPPORT ROUTING
Need help accessing something?
Choose the description that fits. Each card opens only an approved destination.
Accessibility barrier
A page, feature or control prevents you from using the site.
Privacy request
Questions about your personal data.
Security concern
Suspected compromise or vulnerability. Do not send secrets.



BARRIER REPORT
Report an accessibility barrier
The form is shown as a specification. No submit control appears until a verified intake route and a secure backend exist.
CONFIRMATION AND UPDATES
What happens after you submit
Success is shown only after the server acknowledges the report. A case reference appears only when the system provides one.
Acknowledged
“Your report has been received.” Focus moves to this heading.
Unavailable
An error is shown, your input is kept, and retry is safe.
Unknown
No success is claimed. You are told how to check before retrying.
RELEASE GATES
What must be true before this page is published
Hard blockers. Fabricated conformance, an unsupported contact channel, an inaccessible feedback workflow, unresolved critical keyboard or screen-reader defects, unapproved privacy wording, expired review date, or broken high-volume navigation.
QUESTIONS
Direct answers
What accessibility standard does Zoiko iD target?
WCAG 2.2 Level AA. This is a target. Verified results are published only with their scope and date.
How do I report a barrier?
A dedicated route is not yet verified. Until it is, use Help & Support, and do not send secrets through any route.
Can I use a keyboard?
Pages are designed for keyboard use. Section 05 describes the behaviour you can rely on.
Where can I get account help?
Through Help & Support. Security concerns go to Security Contact, and privacy requests to the privacy route.
FIND THE RIGHT HELP
Tell us what is getting in the way.
Use the routes below for your question. Each one is marked with its status, and none is shown as live until it is verified.
