Zayloft is committed to making its digital experiences usable by as many people as reasonably possible, including people who use assistive technologies or alternative ways of navigating, reading, hearing or interacting with content.
Our accessibility approach focuses on the underlying product and content experience rather than relying on overlays or claiming universal accessibility. We use WCAG 2.2 Level AA as a reference target for web accessibility work where appropriate.
Translations are provided for convenience. If a translated version conflicts with the English version, the English version controls to the extent permitted by applicable law.
This Statement applies to Zayloft public websites, authenticated account experiences, developer interfaces and related digital content where it is referenced. Different products and integrations can have different accessibility characteristics, and a service-specific statement may supplement this page where appropriate.
Zayloft uses the Web Content Accessibility Guidelines, WCAG 2.2, Level AA as a practical reference target where appropriate. WCAG is organized around content being perceivable, operable, understandable and robust. Unless Zayloft publishes a specific conformance claim for a defined product, version and scope after appropriate evaluation, this Statement should not be read as claiming that every page or feature fully conforms to WCAG 2.2 Level AA.
Accessibility is most effective when issues are addressed in the underlying design, code and content rather than left to an overlay or separate accessibility mode. Zayloft therefore aims to incorporate accessibility into interface structure, interaction design, content authoring, forms, navigation and product review.
Interactive controls should be reachable and usable with a keyboard when the underlying function can reasonably be operated without a mouse or touch. Navigation order should be meaningful and keyboard users should be able to identify focus. Protective website scripts or shortcuts should not block ordinary keyboard navigation, assistive-technology commands or browser accessibility functions.
Interactive elements should provide a visible focus indication with sufficient contrast. Sticky headers, dialogs and other author-created content should not unnecessarily obscure keyboard focus, and temporary interfaces should manage focus in a way that helps keyboard and screen-reader users understand changes in context.
Zayloft aims to use readable typography, sufficient color contrast and layouts that remain usable when text is enlarged or browser zoom is increased. Information should not rely on color alone, and responsive layouts should support reflow on smaller screens and enlarged views without unnecessary two-dimensional scrolling for ordinary page content.
Animation and motion should be restrained so they do not create unnecessary vestibular, cognitive or attention-related barriers. Where appropriate, Zayloft aims to respect reduced-motion preferences, and content should avoid flashing patterns that create avoidable seizure risk.
Pages should use meaningful headings, landmarks, labels, link text and native semantic elements where practical. Custom controls should expose appropriate accessible names, roles, states and values, and page language and direction should be identified so assistive technologies can interpret content correctly.
Informative images should have appropriate text alternatives, while decorative images should be implemented so they do not add unnecessary screen-reader noise. Icons used as interactive controls should have an accessible name that communicates their purpose rather than relying only on the visual symbol.
Where Zayloft publishes prerecorded media that conveys important information, captions, transcripts, audio description or another accessible alternative should be considered according to the content and applicable requirements. Automatically generated captions may require review because inaccurate captions can materially change meaning.
Form controls should have programmatically associated labels or accessible names, and instructions should identify required formats or constraints where needed. Validation errors should be communicated in text and associated with affected fields where practical. Authentication and verification workflows should avoid unnecessary cognitive barriers and provide accessible alternatives where appropriate.
Links and buttons should communicate their purpose through the accessible name and surrounding context. Interactive targets should be sized and spaced to reduce accidental activation where practical. New browsing contexts and irreversible actions should not be unnecessarily surprising and destructive actions should use an appropriate safeguard.
Zayloft aims to support accessible operation across common viewport sizes and input methods, including keyboard, touch and assistive-technology interaction where the platform supports them. Mobile layouts should preserve meaningful reading order, labels and access to core actions.
Zayloft supports multiple interface languages and right-to-left presentation where enabled. Localized content should preserve semantic structure, reading order, labels and meaning rather than treating accessibility as an English-only requirement, and language changes should be identified where needed for correct assistive-technology pronunciation.
Authenticated dashboards and developer experiences can contain complex data, code examples, tables, logs, credential controls and real-time status information. These interfaces should provide meaningful labels, keyboard access and text alternatives for status information where practical. API and SMPP endpoints are not browser accessibility interfaces, but their documentation and configuration tools are part of the digital experience.
Some Zayloft experiences can include payment, authentication, communications, media or support components supplied by third parties. Zayloft aims to select and configure third-party components with accessibility in mind where reasonably possible, but accessibility can also depend on the provider and Customer configuration. Reported barriers can be reviewed for an alternative path or remediation.
Accessibility is an ongoing engineering and content-quality process. Automated tools can identify some issues but do not replace keyboard review, screen-reader testing, visual review or evaluation by people with relevant accessibility experience. Zayloft does not claim that every page, integration or Customer-configured experience is free of accessibility defects.
If you encounter a barrier, contact support@zayloft.com with “Accessibility” in the subject line and describe the page or feature, the action you were trying to complete, what happened, and the browser, device or assistive technology involved if you are comfortable providing that information. Do not include passwords, API keys, access tokens, one-time codes or other secrets.
If a digital barrier prevents access to information or completion of an important account or service action, explain the task you need to complete. Where reasonably available and appropriate to the service, Zayloft can evaluate an alternative format, communication method or assisted path while the underlying barrier is reviewed without requiring unnecessary sensitive information or weakening account security.
Accessibility obligations can vary by jurisdiction, product, Customer type and the nature of the digital service. Zayloft will address requirements that apply to its Services without representing that one technical standard automatically resolves every legal obligation. This Statement may be updated as products, standards, practices or legal requirements change.
Zayloft
Zayloft