Aller au contenu principal

Zayloft Accessibility

Zayloft s’engage à rendre ses expériences numériques utilisables par le plus grand nombre raisonnablement possible de personnes, y compris celles qui utilisent des technologies d’assistance ou d’autres modes de navigation, lecture, écoute ou interaction.

Notre approche vise l’expérience, le code et le contenu sous-jacents plutôt que de dépendre d’overlays ou de revendiquer une accessibilité universelle. WCAG 2.2 Niveau AA sert de référence pratique lorsque pertinent.

Les traductions sont fournies pour faciliter la lecture. En cas de conflit, la version anglaise prévaut dans la mesure permise par la loi.

Notre approche de l’accessibilité.

1. Portée

Cette Déclaration s’applique aux sites publics, expériences authentifiées, interfaces développeur et contenus numériques Zayloft qui y renvoient. Les produits et intégrations peuvent présenter des caractéristiques différentes et un avis spécifique peut compléter cette page.

2. Standard de référence

Zayloft utilise WCAG 2.2 Niveau AA comme objectif pratique de référence lorsque pertinent. WCAG est organisé autour des principes perceptible, utilisable, compréhensible et robuste. Sauf publication d’une déclaration de conformité spécifique pour un produit, une version et un périmètre évalués, cette page ne signifie pas que chaque page ou fonction est entièrement conforme.

3. Accessibilité dès la conception

L’accessibilité est plus efficace lorsque les problèmes sont corrigés dans le design, le code et le contenu plutôt que laissés à des overlays ou modes séparés. Zayloft cherche donc à l’intégrer dans structure, interaction, contenu, formulaires, navigation et revue produit.

Interaction et présentation.

4. Accès clavier

Les contrôles interactifs devraient être accessibles et utilisables au clavier lorsque la fonction peut raisonnablement fonctionner sans souris ou touch. L’ordre doit être logique et le focus identifiable. Les scripts de protection ou raccourcis ne devraient pas bloquer la navigation clavier normale, les commandes d’assistance ou les fonctions d’accessibilité du navigateur.

5. Focus visible et gestion du focus

Les éléments interactifs devraient offrir un focus visible avec contraste suffisant. Headers fixes, dialogs et autre contenu ne devraient pas masquer inutilement le focus et les interfaces temporaires devraient gérer le focus de manière compréhensible pour les utilisateurs clavier et screen readers.

6. Texte, contraste, zoom et reflow

Zayloft vise une typographie lisible, un contraste suffisant et des layouts utilisables lorsque le texte ou le zoom est agrandi. L’information ne devrait pas dépendre uniquement de la couleur et les layouts responsives devraient permettre le reflow sans scroll bidimensionnel inutile.

7. Mouvement, animation et flash

Animation et mouvement devraient rester modérés pour réduire les barrières vestibulaires, cognitives ou attentionnelles. Lorsque pertinent, Zayloft cherche à respecter reduced motion et à éviter les motifs de flash présentant un risque évitable.

Structure, contenu et formulaires.

8. Structure sémantique et technologies d’assistance

Les pages devraient utiliser headings, landmarks, labels, liens et éléments sémantiques significatifs lorsque possible. Les contrôles personnalisés devraient exposer nom, rôle, état et valeur accessibles, et la langue et direction de page devraient être correctement définies.

9. Images, icônes et contenu non textuel

Les images informatives devraient avoir une alternative textuelle appropriée et les images décoratives ne pas créer de bruit inutile pour les screen readers. Les icônes interactives devraient avoir un nom accessible indiquant leur fonction.

10. Audio, vidéo et médias temporels

Pour les médias préenregistrés importants, captions, transcripts, audio description ou alternatives appropriées devraient être envisagés selon le contenu et les exigences applicables. Les captions automatiques peuvent nécessiter une révision car des erreurs peuvent changer le sens.

11. Formulaires, authentification et erreurs

Les champs devraient avoir labels ou noms accessibles et les instructions préciser formats ou contraintes lorsque nécessaire. Les erreurs devraient être communiquées en texte et associées aux champs. Les workflows d’authentification et vérification devraient éviter les barrières cognitives inutiles et proposer des alternatives lorsque pertinent.

12. Liens, boutons et taille des cibles

Les liens et boutons devraient communiquer leur but via leur nom accessible et le contexte. Les cibles interactives devraient être dimensionnées et espacées pour réduire les activations accidentelles lorsque possible. Les nouvelles fenêtres et actions irréversibles ne devraient pas être inutilement surprenantes.

Produits, langues et tiers.

13. Expériences mobiles et responsives

Zayloft cherche à permettre une utilisation accessible sur les tailles de viewport et modes d’entrée courants. Les layouts mobiles devraient préserver ordre de lecture, labels et accès aux actions essentielles.

14. Langue, localisation et RTL

Zayloft prend en charge plusieurs langues et la présentation right-to-left lorsque activée. Le contenu localisé devrait préserver structure, ordre, labels et sens, et les changements de langue devraient être identifiés lorsque nécessaire pour les technologies d’assistance.

15. Interfaces développeur et compte

Dashboards et outils développeur peuvent contenir données complexes, code, tables, logs, credentials et états. Ils devraient offrir labels, clavier et alternatives textuelles lorsque possible. API et SMPP ne sont pas des interfaces d’accessibilité navigateur, mais leur documentation et leurs outils de configuration font partie de l’expérience numérique.

16. Contenu et intégrations tierces

Certaines expériences peuvent inclure paiements, authentification, communications, media ou support tiers. Zayloft cherche à sélectionner et configurer ces composants avec l’accessibilité en tête lorsque raisonnablement possible, même si cela dépend aussi du fournisseur et de la configuration Client. Les barrières peuvent être signalées pour évaluer une alternative.

Feedback, évaluation et amélioration.

17. Évaluation et statut de conformité

L’accessibilité est un processus continu. Les outils automatiques ne remplacent pas l’évaluation clavier, screen reader, visuelle ou spécialisée. Zayloft ne prétend pas que chaque page, intégration ou expérience configurée par un Client est exempte de défaut.

18. Signaler une barrière

Si vous rencontrez une barrière, écrivez à support@zayloft.com avec “Accessibility” dans l’objet et indiquez page ou fonction, tâche, problème et, si souhaité, navigateur, appareil ou technologie d’assistance. N’incluez pas mots de passe, clés API, tokens, OTP ou autres secrets.

19. Accès alternatif et assistance raisonnable

Si une barrière empêche une information ou action importante, expliquez la tâche à accomplir. Lorsque raisonnablement disponible, Zayloft peut évaluer format alternatif, méthode de communication ou parcours assisté pendant l’examen du problème, sans exiger d’informations sensibles inutiles ni réduire la sécurité.

20. Exigences applicables et mises à jour

Les obligations d’accessibilité varient selon juridiction, produit, type de Client et service. Zayloft traite les exigences applicables sans prétendre qu’un seul standard technique résout automatiquement toutes les obligations juridiques. Cette Déclaration peut évoluer avec les produits, standards, pratiques ou exigences.

Signaler un problème d’accessibilité

support@zayloft.com