Déclaration d’accessibilité – Calliweb

Calliweb s’engage à rendre ses services numériques accessibles, conformément à l’article 47 de la loi n° 2005-102 du 11 février 2005.

À cette fin, nous mettons en œuvre la stratégie et les actions suivantes :

  • Schéma pluriannuel de mise en accessibilité 2024-2027 (en cours de rédaction).
  • Plan d’action annuel pour l’année en cours.

Cette déclaration d’accessibilité s’applique au site : https://www.calliweb.fr/.

État de conformité

Le site de Calliweb n’est pas conforme avec le Référentiel Général d’Amélioration de l’Accessibilité (RGAA), version 4.1, en raison des non-conformités et des dérogations énumérées ci-dessous.

Résultats des tests

L’audit de conformité réalisé par nos experts internes révèle que 48 % des critères du RGAA version 4.1 sont respectés.

  • Nombre de critères conformes : 29
  • Nombre de critères non conformes : 31
  • Nombre de critères non applicables : 46

Contenus non accessibles

Les contenus listés ci-dessous ne sont pas accessibles pour les raisons suivantes :

  • 1.1 : Chaque image porteuse d’information a-t-elle une alternative textuelle ? : L’exploration élargie confirme de nombreux liens image ou cartes remontant sans nom accessible sur certaines pages.
  • 1.3 : Pour chaque image porteuse d’information ayant une alternative textuelle, cette alternative est-elle pertinente ? : L’alternative du logo est générique (alt= »Logo ») et plusieurs cartes illustrées ou images-lien restent soit sans intitulé accessible, soit avec un libellé insuffisant sur plusieurs pages de listes.
  • 1.8 : Chaque image texte porteuse d’information doit si possible être remplacée par du texte stylé: Des blocs visuellement présentés comme logos / accroches de solutions sur l’accueil se comportent comme des liens graphiques sans texte accessible.
  • 2.1 : Chaque cadre a-t-il un titre de cadre ? : Des iframes sont présents, notamment le noscript Google Tag Manager, sans attribut title. Les éventuels iframes YouTube doivent aussi être vérifiés.
  • 2.2 : Pour chaque cadre ayant un titre de cadre, ce titre de cadre est-il pertinent ? : Au moins un iframe a été observé sans titre.
  • 3.1 : Dans chaque page web, l’information ne doit pas être donnée uniquement par la couleur : L’état courant de certains éléments de carrousel / pagination est matérialisé essentiellement par une variation de couleur, sans libellé ou indication textuelle complémentaire.
  • 3.2 : Dans chaque page web, le contraste entre la couleur du texte et la couleur de son arrière-plan est-il suffisamment élevé ? : Des textes de placeholder et certains textes secondaires gris / colorés paraissent insuffisamment contrastés.
  • 3.3 : Dans chaque page web, les couleurs utilisées dans les composants d’interface sont-elles suffisamment contrastées ? : Plusieurs composants d’interface reposent sur des icônes, puces ou indicateurs colorés très ténus ; les états actifs / inactifs des puces de slider sont peu contrastés.
  • 6.1 : Chaque lien est-il explicite ? : L’exploration élargie révèle des liens non explicites : », lien !, liens 1/2/3, libellés génériques Lien, ou liens externes remontant comme undefined.
  • 6.2 : Dans chaque page web, chaque lien a-t-il un intitulé ? : L’arbre d’accessibilité remonte plusieurs liens sans intitulé ou mal nommés sur de nombreuses pages (accueil, contact, réalisations, etc.).
  • 7.1 : Chaque script est-il compatible avec les technologies d’assistance ? : Le site repose sur plusieurs composants scriptés non natifs : menu ouvert via faux liens, commandes de slider injectées en, carrousels sans gestion ARIA suffisante.
  • 7.3 : Chaque script est-il contrôlable par le clavier et par tout dispositif de pointage ? : Le menu est déclenché par des liens href= »# » et certaines commandes de carrousel sont injectées en non focalisables, ce qui compromet le contrôle clavier.
  • 7.5 : Dans chaque page web, les messages de statut sont-ils correctement restitués par les technologies d’assistance ? : Le formulaire de contact ne restitue pas de manière claire et exploitable les erreurs ou messages de validation lors d’une tentative d’envoi à vide.
  • 8.2 : Le code source généré est-il valide selon le type de document spécifié ? : Le gabarit contient deux balises successives, ce qui invalide la structure du document.
  • 8.9 : Les balises ne doivent pas être utilisées uniquement à des fins de présentation: Certains éléments sémantiques servent essentiellement de présentation ou de faux contrôles (ex: un p utilisé comme pseudo-bouton téléphonique).
  • 9.1 : Dans chaque page web, l’information est-elle structurée par l’utilisation appropriée de titres ? : Hiérarchies de titres incohérentes (ex: h2 suivi de h4, ou deux h1 sur la même page).
  • 10.7 : Dans chaque page web, pour chaque élément recevant le focus, la prise de focus est-elle visible ? : Le thème supprime globalement le contour de focus via outline: 0 sans compensation systématique.
  • 10.8 : Les contenus cachés ont-ils vocation à être ignorés par les technologies d’assistance ? : Des contenus de navigation censés être masqués restent exposés dans l’arbre d’accessibilité.
  • 10.9 : L’information ne doit pas être donnée uniquement par la forme, taille ou position: Certaines informations d’état ou d’action reposent sur des puces, flèches, icônes ou positions visuelles sans complément textuel.
  • 10.10 : L’information ne doit pas être donnée par la forme, taille ou position uniquement. (Implémentation pertinente): Le design de certains composants laisse dépendre la compréhension de la seule apparence visuelle (carrousels et indicateurs d’état).
  • 11.1 : Chaque champ de formulaire a-t-il une étiquette ? : Les champs s’appuient sur le placeholder au lieu d’une vraie étiquette persistante ().
  • 11.2 : Chaque étiquette associée à un champ de formulaire est-elle pertinente ? : Les pseudo-libellés sont de simples placeholders, ce qui n’est pas une étiquette persistante et robuste.
  • 11.4 : Chaque étiquette de champ et son champ associé sont-ils accolés ? : Le formulaire de contact ne montre pas d’association robuste label/for ; le champ remonte sans id.
  • 11.10 : Dans chaque formulaire, le contrôle de saisie est-il utilisé de manière pertinente ? : Les champs marqués * ne portent pas d’attribut HTML required.
  • 11.11 : Le contrôle de saisie est-il accompagné de suggestions facilitant la correction des erreurs ? : Aucune suggestion claire de correction n’a été observée lors du test d’envoi sans saisie.
  • 11.13 : La finalité d’un champ de saisie peut-elle être déduite (remplissage automatique) ? : Les champs ne portent pas d’attribut autocomplete pour le nom, l’email ou le téléphone.
  • 12.7 : Un lien d’évitement ou d’accès rapide à la zone de contenu principal est-il présent ? : Aucun lien « Aller au contenu » ou équivalent n’a été observé en tête de page.
  • 12.8 : Dans chaque page web, l’ordre de tabulation est-il cohérent ? : Saut sur certains éléments du Menu.
  • 13.2 : L’ouverture d’une nouvelle fenêtre ne doit pas être déclenchée sans action de l’utilisateur: Plusieurs liens ouvrent une nouvelle fenêtre via target= »_blank » sans avertissement explicite (footer, réseaux sociaux, liens externes).
  • 13.8 : Chaque contenu en mouvement ou clignotant est-il contrôlable par l’utilisateur ? : Animations et effets de mouvement (lettres animées, parallaxe, sliders) sans mécanisme de pause ou de désactivation.

Les non-conformités détaillées et les éventuelles dérogations seront listées ici dès la finalisation de l’audit de conformité actuellement en cours. Calliweb s’engage à documenter avec précision chaque point d’amélioration identifié pour garantir une transparence totale sur l’accessibilité de sa plateforme.

Dérogations pour charge disproportionnée :

  • Aucune.

Contenus non soumis à l’obligation d’accessibilité :

  • Les lecteurs vidéo tiers (YouTube) et les cartes interactives (Google Maps).

Établissement de cette déclaration d’accessibilité

Cette déclaration a été établie le 25 novembre 2025. Elle a été mise à jour le 22 avril 2026.

Technologies utilisées pour la réalisation du site

  • HTML5 / CSS3
  • JavaScript
  • WordPress / PHP

Environnement de test

Les vérifications de restitution de contenus, actuellement en cours de réalisation, s’appuient sur la base de référence du RGAA 4.1. Les tests de conformité sont effectués sur un panel de pages représentatives (accueil, contact, expertises, réalisations) avec les combinaisons suivantes :

Technologies & Navigateurs

  • Navigateurs : Google Chrome, Mozilla Firefox et Safari (dernières versions stables).
  • Systèmes d’exploitation : Windows 11, macOS et iOS/Android pour la partie mobile.

Outils d’assistance (Tests de restitution)

Pour garantir une navigation fluide aux personnes utilisant des technologies d’assistance, les tests incluent :

  • NVDA sous Windows.
  • VoiceOver sous macOS et iOS.
  • TalkBack sous Android.

Outils d’analyse technique

Nos experts utilisent un ensemble d’outils spécialisés pour l’audit du code et des contrastes :

  • HeadingsMap (validation de la hiérarchie des titres).
  • Wave, Web Developer et Axe DevTools (analyse de structure).
  • Colour Contrast Checker (vérification des ratios de contraste).
  • Assistant IA

Pages du site ayant fait l’objet de la vérification de conformité

  • Homepage
  • Contact
  • Blog
  • Déclaration d’accessibilité
  • Agence Shopify
  • Agence Magento
  • Agence Prestashop
  • Agence Sylius
  • Réalisations
  • Études de cas
  • Témoignages
  • Agence Calliweb
  • Projet digital
  • Expertises digitales
  • E-commerce B2B
  • Accessibilité web
  • Maintenance Magento
  • Recrutement
  • Glossaire
  • Conformité RGPD
  • Mentions légales
  • Shopify Plus
  • Agence Magento Paris
  • Reprise Magento
  • Intégrations Sylius
  • Maintenance Sylius
  • Connecteur Sage Shopify
  • Shopify B2B
  • Plateforme B2B
  • Livre blanc B2B
  • Témoignage Sabena
  • Replay webinaire
  • Marketplace
  • Solutions CRM
  • Email marketing
  • Agence web Paris
  • Création site web
  • Marketing digital
  • Transformation digitale
  • Click & Collect

Retour d’information et contact

Si vous n’arrivez pas à accéder à un contenu ou à un service, vous pouvez contacter le responsable de Calliweb pour être orienté vers une alternative accessible ou obtenir le contenu sous une autre forme.

  • E-mail : contact@calliweb.fr
  • Téléphone : 01 45 46 91 27
  • Adresse : 149 avenue du Maine, 75014 PARIS

Voies de recours

Cette procédure est à utiliser dans le cas suivant : vous avez signalé au responsable du site internet un défaut d’accessibilité qui vous empêche d’accéder à un contenu ou à un des services et vous n’avez pas obtenu de réponse satisfaisante.

  • Écrire un message au Défenseur des droits (https://formulaire.defenseurdesdroits.fr/)
  • Contacter le délégué du Défenseur des droits dans votre région.
  • Envoyer un courrier par la poste (gratuit, ne pas mettre de timbre) :
    Défenseur des droits Libre réponse 7112075342 Paris CEDEX 07