Accessibility you can evaluate, not just assume.
Start with the statement. Check its scope. Understand limitations and the evidence behind each claim.
This page explains accessibility design requirements and where approved product evidence belongs. An approved conformance statement, evaluated scope and known-limitations inventory are not supplied in this view.
Explore the Trust Center →A design target is not a conformance claim.
Accessibility design goals, implementation requirements, test results, formal conformance statements and legal-compliance claims are different. Production copy must identify which type of statement is being made and its exact approved scope.
Begin with an approved statement.
A useful accessibility statement identifies what it covers, what was evaluated and what remains outside its claims.
Formal approved conformance statement and evaluated scope are not supplied in this view.
Inclusive design means making information understandable and tasks usable. The approved organizational commitment, exact scope and responsible contact must come from the published statement—not from an inferred product-wide promise.
WCAG 2.2 AA is this design’s target. It is not an assertion of attained product conformance or legal compliance.
Four kinds of authority. No shortcuts between them.
Design intention
The standard and patterns a design is intended to meet.
Observed behavior
A documented result for a specific task, build and test environment.
Formal scope
Authorized conformance wording supported by scoped evidence.
Separate review
Legal-compliance wording requires its own authority and approval.
Scope must be specific—not implied.
These are illustrative scope categories, not a list of evaluated ZoikoTax surfaces. No attained A, AA or AAA level is established here.
Public website
Authenticated service
Individual modules
Downloadable documents
“Not evaluated” and “unknown” are not the same.
Not evaluated is an explicit, approved exclusion. Unknown means evaluation evidence has not been supplied. Neither is a passing result, and neither should be silently included in a formal claim.
Every task needs a clear path.
Implementation requirements for predictable navigation. These design-contract patterns are not claims that the live product has been tested.
Text equivalent: Tab moves forward, Shift + Tab moves back, Enter activates a control. Escape closes a dialog and restores its trigger where implemented.
Reachable, logical, visible
All task controls should be keyboard and touch compatible, follow a logical order and show a high-contrast focus indicator. No keyboard traps.
Predictable transitions
Dialogs, disclosures and route changes need explicit focus behavior. A mobile drawer should return focus to its trigger when dismissed.
Structure before styling
Use native controls, logical headings and landmarks. Provide a skip-to-main path and text that identifies the current page. Site navigation disclosures are not application-menu roles.
Header → Navigation → Main content → Footer
Intended landmarks, one H1 and a logical heading hierarchy—not a runtime verification.
Help people understand—and recover.
Clear labels, useful corrections and announced updates are implementation requirements. A color change alone is not an explanation.
A correction you can act on.
One field needs your attention
Reference code: use at least 4 characters.
Reference code (required)
Use 4–12 letters or numbers. Example: SAMPLE01.
Error: enter at least 4 characters, such as SAMPLE01.
Design pattern, not an issue-report service. No information is submitted.
Labels stay visible
Keep labels, instructions and required-field text visible. Associate them with their fields rather than relying on placeholder text.
Errors point to a correction
Provide a field-level message and an error summary with a meaningful path back to the affected field. Preserve valid input.
Status is communicated
Async progress, success and error updates need appropriate announcements without unnecessary focus movement.
Session and challenge rules need sources
Publish timeout controls, session-extension behavior or accessible challenge alternatives only when those features and their approved scope are established.
Meaning should survive a change in presentation.
Design requirements for readable contrast, scalable text and non-color cues—not a published contrast measurement or media audit.
Contrast & text
Normal text, controls and focus indicators need readable contrast. Text should scale and accept spacing changes without clipping.
More than color
Use explicit state text, labels and symbols. A status must remain understandable without its color or an image.
Motion & media
Respect reduced-motion preferences, avoid flashing and never depend on essential animation. Provide captions or transcripts for relevant, approved media.
Example: the words “Pending review” communicate the state even when color is unavailable. This is a visual pattern, not the current status of a product review.
Structure is a requirement. Support needs evidence.
Screen-reader compatibility must be based on approved, current test combinations—not on a list of technology names.
Approved browser/assistive-technology test matrix not supplied
No browser, operating-system or assistive-technology combination is claimed as supported in this view. An actual matrix must identify its scope and observed results.
Logical structure
Headings and landmarks should express the reading order. Control names must describe the action or destination.
Related information
Table headers and cell relationships need semantic associations. Diagrams need full text equivalents.
Dynamic updates
Meaningful changes need appropriate announcements. Announcements should inform rather than overwhelm.
More room to read. No less room to act.
Intended behavior: preserve content and functions at 200% and 400% zoom, with a single-column reading path at 320px. These are design targets, not verified product results.
Statement scope
- Category
- Public website
- Evidence
- Source required
- Approved scope
- Not supplied
Text equivalent: the same category, evidence and scope fields move from a horizontal row to a labeled vertical card. Information is retained rather than clipped.
Statement scope
- Category
- Public website
- Evidence
- Source required
- Approved scope
- Not supplied
Zoom & spacing
No hidden functions or clipped text. Keep matrices readable as labeled cards, including when text spacing increases.
Mobile & orientation
Use practical 44px targets and flexible orientation. Specify drawer focus, dismissal and return-to-trigger behavior.
Language & direction
Externalize copy, allow text expansion and use logical reading order for right-to-left layouts. Localization support needs its own approved scope.
A web page is not evidence for a document.
Web accessibility does not establish document accessibility. Each format, generated output and evidence file needs a separate approved evaluation.
PDF & DOCX
Reading order, headings, table structure and text alternatives must be evaluated for the actual document. No accessible-file inventory is supplied.
CSV & generated reports
Data relationships and generated report structure need their own evidence. An export does not inherit the website’s accessibility status.
Scanned documents
OCR does not establish accessibility. Reading order, meaningful text and structure still require validation.
File access and accessibility are different questions.
Conceptual states only. ACR/VPAT files and alternative-format arrangements require approved sources; none are supplied. No download or format-support service is claimed here.
Alternative formats: route not supplied
Publish a request route only when approved. Use the channel in the approved accessibility statement once published; do not infer an email address or promise an available format.
Missing information is not “no issues.”
Limitations should describe the affected task, the practical impact and any verified workaround. Material issues must align with the scope of a formal claim.
Approved limitations inventory is not supplied
This does not mean that there are no accessibility issues. No actual issue, workaround, remediation deadline or resolved result is established in this view.
Allowed record states: Known / Planned / In remediation / Resolved / Not applicable. These are governed labels, not product statuses. “Resolved” requires verified validation evidence.
A barrier deserves a clear route—not a sales gate.
This is reporting guidance, not an operational form. An approved report channel and reporting process have not been supplied.
Use the channel in the approved accessibility statement once published.
No report endpoint, receipt process or response timescale is established here. This section does not submit a report. Accessibility reporting should not depend on booking a demo.
Describe the task, not a diagnosis.
Page or task
Identify where you encountered the barrier and what you were trying to do.
Steps and outcome
Share the minimum steps to reproduce it, what you expected and what happened.
Useful context, only if needed
Include relevant technical context voluntarily. Do not include passwords, tax records, account secrets or disability details.
Keep reporting accessible and private.
A reporting route should not force an account unless an approved policy requires one. Accessible attachments should be optional and safe, and any receipt wording must reflect an approved process.
Report contents can be sensitive. Analytics must not collect free text, attachments, disability information or personal details from reports.
Do not infer disability from browsing, zoom, keyboard use or assistive technology. Do not use those signals for risk profiling or experiments that manipulate disclosure of limitations.
Accommodation requests
A separate approved process is needed. No accommodation service, alternative format or contact route is promised in this view.
Product support
Support helps with operational tasks. It is not a substitute for an approved public accessibility-reporting route.
Legal & procurement evidence
Formal statements and controlled evidence have separate approval and access rules. They should not be confused with issue reporting.
Ask for the result—not just the method.
A method describes how to evaluate. An observed result describes what happened in a defined scope. Neither should be promoted into a broader claim.
Automated checks
Identify machine-detectable issues; not proof of full conformance.
Manual keyboard testing
Observe task reachability, focus order, visibility and recovery.
Screen-reader matrix
Evaluate actual approved browser/AT combinations.
Zoom & reflow testing
Evaluate content and functions at intended zoom and narrow widths.
Expert audit
Review a specific scope using a documented evaluation method.
Availability is not established.
Public, controlled, customer-specific and unavailable are possible access states—not an actual file inventory. No ACR/VPAT file, download route or audit evidence is supplied.
A questionnaire is not a certification.
Procurement answers need approved sources and exact scope. A sales response or automated scan cannot establish formal conformance, legal compliance or “100% accessible.”
Evidence has a scope—and a shelf life.
An old evaluation is not proof of the current interface. Reviewed, effective and version fields must come from approved sources.
Revalidate meaningful changes
Major interface or component changes require revalidation of affected tasks and patterns. Release integration should retain traceable evidence.
Resolve only with verification
A fix is not a resolved issue until validation supports it. Keep the relevant build, scope and evidence with the limitation record.
Narrow conflicting claims
Stale, superseded or contradictory evidence should block or narrow a statement. A publishing system cannot infer conformance.
Core trust information should remain readable.
Statement, scope, limitations, evidence and reporting guidance should remain available without JavaScript, in print and in narrow or large-text presentations. These are implementation requirements, not verified behavior of this static design.
Source-state vocabulary, illustrative only: Current / Pending / Scope-limited / Historical / Unavailable. No current release or review date is asserted.
Honest messages when evidence changes.
Conditional copy specimens—not product status reports. Every state should explain its boundary and a useful next step without guessing a claim or contact route.
Approved statement
Only when supplied: read the exact approved wording and evaluated scope.
Check scope, evaluation and exclusions.
Pending review
A statement is awaiting approval. Conformance is not established.
Use the published design target, not an inferred claim.
Scope-limited
Evidence applies only to the named surfaces or tasks.
Review exclusions before relying on the statement.
Known limitation
A published issue affects a specific task or scope.
Read its impact and any verified workaround.
Resolved · Verified
Use only after validation confirms the fix for a specific version.
Review the supporting validation record.
Evidence unavailable
Requested evaluation evidence is not available in this view.
Do not infer a passing result. Review statement boundaries.
Controlled ACR / VPAT
Use only if the file and its access process are approved.
Follow the published controlled-access instructions, if supplied.
Stale / superseded
Historical evidence does not establish current behavior.
Use a current approved source; narrow the claim otherwise.
Missing source
Required statement or evaluation information is not supplied.
Treat scope and conformance as unestablished.
Report route unavailable
An approved reporting channel has not been published here.
Use the channel in the approved statement once published.
No-JS / readable view
Core statement, scope, limitation and report guidance should remain readable.
Preserve the same information in a plain-text presentation.
Why isn’t a conformance level shown?
EXPANDED SPECIMENAn approved statement and evaluated scope are not supplied. This design targets WCAG 2.2 AA, but a target is not proof of implementation, testing, formal conformance or legal compliance.
Direct answers. Clear boundaries.
Start with what is established—and what still requires an approved source.
- What accessibility standard is targeted?
- WCAG 2.2 AA is the target for this design. It describes intended requirements, not an attained product level. An approved statement must identify the exact standard, version, level and evaluated scope.
- Is ZoikoTax WCAG 2.2 AA conformant?
- That is not established in this view. A formal approved conformance statement and evaluated scope are not supplied. Design targets, implementation requirements, test results and legal-compliance claims are different kinds of statements.
- Can I use a keyboard or screen reader?
- Keyboard reachability, logical focus and semantic structure are design requirements. Actual tested product behavior and an approved browser/assistive-technology matrix have not been supplied, so no specific compatibility claim is made.
- Does the product work at 400% zoom and on mobile?
- The design target is readable reflow and retained functions at 200% and 400% zoom, including a 320px single-column path. Verified zoom and mobile test results are not supplied. Practical targets and intended behavior are not proof of product support.
- How do I report an accessibility issue?
- Read the reporting guidance above. Use the channel in the approved accessibility statement once published. No report endpoint or response timescale is supplied here. Share only the minimum reproduction information; a demo should not be required.
- Is a VPAT or ACR available?
- Availability is not established. No approved ACR/VPAT file or access route has been supplied. Public, controlled and customer-specific access require separate approval. A procurement questionnaire is not formal conformance evidence.
Start with the scope. Follow the evidence.
Review statement requirements and limitations, find reporting guidance, then explore the wider trust context. Accessibility information should never be gated by sales.