Accessibilité e-commerce en 2026 : auditer votre parcours PrestaShop

L’accessibilité e-commerce signifie que les clients peuvent trouver, comprendre et acheter des produits en utilisant différentes façons d’interagir avec un site web. Un passage en caisse fonctionnant avec une souris ne démontre pas qu’il fonctionne pour une personne naviguant au clavier ou avec un lecteur d’écran.

L’acte européen sur l’accessibilité s’applique depuis le 28 juin 2025 et couvre les services e-commerce entrant dans son champ, avec des exemptions et dispositions transitoires. Vérifiez la transposition nationale applicable et la situation de votre entreprise ; cet audit pratique n’est pas une évaluation de conformité juridique. Le résumé EUR-Lex explique le cadre.

Commencez par un parcours d’achat complet dans votre boutique PrestaShop. Vous produirez des constats reproductibles, attribuerez les corrections et retesterez la tâche client après les changements.

1. Définir une tâche d’achat et son périmètre

Choisissez une tâche qu’un vrai client peut accomplir : trouver un carnet bleu, sélectionner la taille requise, comprendre la livraison et passer une commande de test via un circuit de paiement de test approuvé.

Listez toutes les interfaces concernées. Incluez navigation, recherche, filtres, options produit, panier, contrôles de consentement, saisie d’adresse et passage au paiement.

Enregistrez le thème, les versions des modules pertinents, le navigateur, l’appareil et la date. L’accessibilité peut changer lorsqu’un composant de paiement ou de consentement est mis à jour, même si votre modèle produit reste inchangé.

Commencez par le parcours normal, puis ajoutez une visite de retour, une erreur de formulaire et une variante indisponible. Ces états révèlent souvent des obstacles qu’une capture de la première page ne montre pas.

2. Préparer une feuille de constats avec des résultats observables

Notez l’action exacte, ce qui s’est passé et ce qui devrait se passer pour le client. Évitez les rapports vagues comme « le passage en caisse n’est pas accessible ».

Utilisez des captures ou de courts enregistrements lorsqu’ils aident, mais incluez des étapes écrites. Une vidéo sans indication du navigateur et de l’état initial peut être difficile à reproduire pour un développeur.

Priorisez les obstacles empêchant d’accomplir la tâche. Les incohérences esthétiques peuvent attendre derrière une boîte de dialogue de paiement qui bloque le client.

3. Parcourir le trajet au clavier uniquement

Mettez la souris de côté et naviguez depuis le point d’entrée de la page. Observez où va le focus, s’il est visible et si vous pouvez activer les mêmes contrôles utiles que les utilisateurs de souris.

Testez délibérément les menus, filtres et options produit. Un échantillon de couleur visuellement attrayant n’est pas utilisable au clavier s’il ne peut recevoir le focus ou communiquer l’option sélectionnée.

Ouvrez et fermez les boîtes de dialogue, y compris l’aperçu du panier et le panneau de consentement. Vérifiez qu’en quittant une boîte de dialogue vous revenez à un endroit logique et qu’aucun composant ne vous y enferme.

Les recommandations du W3C sur le focus clavier constituent une référence de départ utile. Documentez l’interaction exacte qui a échoué au lieu de supposer que tous les problèmes de clavier partagent une même cause technique.

Répétez l’exercice après l’ajout d’un article au panier. Les changements dynamiques peuvent modifier le comportement du focus d’une façon que le panier vide ne révèle pas.

4. Vérifier les choix produit et les instructions des formulaires

Rendez les informations de décision disponibles à côté du contrôle. Le client doit connaître le nom de l’option, la sélection actuelle, les informations requises et toute contrainte pertinente.

Pour le carnet exemple, examinez l’identification du choix de taille et la communication de la couleur sélectionnée. Ne vous fiez pas uniquement à la couleur pour signaler une option indisponible ou sélectionnée.

Dans le formulaire d’adresse, vérifiez que les instructions restent compréhensibles après saisie. Un texte indicatif qui disparaît peut ne pas donner assez de contexte persistant à une personne vérifiant ses entrées.

Créez un code postal invalide ou omettez un champ obligatoire dans le test. Le message obtenu doit expliquer la correction nécessaire, identifier le champ et conserver les informations utiles déjà saisies.

Utilisez le tutoriel du W3C sur les formulaires comme référence technique pour le responsable de l’implémentation. Votre test d’acceptation marchand consiste à vérifier si l’acheteur peut se remettre de l’erreur sans deviner.

5. Tester le contenu agrandi et les petits écrans

Augmentez le zoom du navigateur et examinez la même tâche. Recherchez les textes ou contrôles cachés derrière des bandeaux fixes, les prix tronqués et les mouvements horizontaux rendant un formulaire difficile à suivre.

Vérifiez le tableau de spécifications produit, pas seulement l’introduction. Un client déterminant si un article convient doit accéder aux dimensions à la taille de texte qu’il préfère.

Testez ensuite sur un petit écran avec le clavier virtuel ouvert. Les boutons fixes et widgets de chat peuvent couvrir des champs qui semblaient corrects avant le début de la saisie.

Enregistrez la zone d’affichage et le niveau de zoom avec le constat. Demandez au responsable de l’implémentation d’évaluer les critères techniques applicables ; votre test vise à révéler un obstacle d’achat concret.

Évitez une correction consistant simplement à désactiver le zoom. Le résultat réussi est une mise en page utilisable lorsque le contenu est agrandi.

6. Examiner les images, titres et ordre de lecture

Lisez la page sans vous appuyer sur sa disposition décorative. Le nom du produit, le prix, les options, les informations de livraison et l’action doivent former une séquence cohérente.

Vérifiez si les alternatives aux images transmettent les informations nécessaires à la tâche. Une photo montrant le contenu exact d’un ensemble exige un traitement différent d’un arrière-plan purement décoratif.

Utilisez un lecteur d’écran avec une personne connaissant l’outil, ou faites intervenir un spécialiste de l’accessibilité. La difficulté d’un débutant à utiliser une technologie d’assistance ne doit pas être confondue avec un défaut confirmé du site.

Les recommandations du W3C pour une première évaluation couvrent des vérifications initiales utiles et expliquent explicitement leurs limites. Réussir une courte liste de contrôle ne démontre pas que le service entier satisfait toutes les exigences.

Ajoutez les constats sur le contenu utile au travail du responsable du catalogue, pas uniquement à la file du développeur. Des informations produit manquantes peuvent rester un obstacle même après amélioration du HTML.

7. Inclure les composants tiers de paiement et d’assistance

Testez le véritable circuit de paiement dans un environnement de test approprié, y compris l’authentification, l’annulation et le retour à la boutique. Un formulaire d’adresse utilisable n’est qu’une partie d’un achat réussi.

Consignez où la responsabilité change entre votre thème, le module de commande et le prestataire de paiement. Envoyez à chaque responsable de maintenance le plus petit exemple reproductible affectant son composant.

Incluez tout chat d’assistance couvrant la page ou prenant le focus. Prévoyez un autre canal de contact accessible lors de l’évaluation d’un nouvel outil d’assistance.

Utilisez le processus de gestion des échecs de paiement pour vérifier les messages de reprise après un paiement infructueux. L’accessibilité et l’exactitude opérationnelle doivent aller ensemble : le client doit comprendre ce qui s’est passé et quoi faire ensuite.

N’approuvez pas un composant uniquement parce que son fournisseur publie une déclaration générale d’accessibilité. Vérifiez la configuration et le parcours que vos clients utilisent réellement.

8. Retester les corrections et intégrer le parcours aux contrôles de publication

Attribuez un responsable, une priorité et un résultat attendu à chaque constat. Après correction, répétez les étapes originales et confirmez que le client peut avancer.

Vérifiez aussi les états voisins. Corriger le focus dans une boîte de dialogue ne doit pas le supprimer de l’étape de paiement suivante ni casser la mise en page mobile.

Conservez un court ensemble de tests récurrents pour les changements du thème, du gestionnaire de consentement, des options produit et du passage en caisse. Enregistrez quand les tests ont eu lieu et les versions concernées.

Pour une évaluation plus large, prévoyez une expertise spécialisée et la participation de personnes ayant des handicaps pertinents. Votre audit initial crée des preuves et priorités utiles ; il ne remplace pas cette expertise.

9. Problèmes courants des audits d’accessibilité

10. Liste de contrôle d’audit du parcours d’achat

• La tâche inclut découverte, options, panier et paiement.
• Le navigateur, l’appareil et les versions pertinentes sont enregistrés.
• La navigation clavier atteint et actionne les contrôles essentiels.
• Les options sélectionnées et les erreurs sont compréhensibles.
• Le contenu agrandi reste utilisable.
• Les informations produit suivent un ordre de lecture cohérent.
• Les boîtes de dialogue tierces et la reprise après paiement sont incluses.
• Les constats ont des responsables et des étapes de nouveau test reproductibles.

Questions fréquentes

L’acte européen sur l’accessibilité s’applique-t-il de façon identique à toutes les boutiques en ligne ?

Non. Le champ d’application, les exemptions, les dispositions transitoires et la transposition nationale doivent être évalués pour l’entreprise et le service. Utilisez le cadre officiel et des conseils locaux appropriés plutôt que supposer qu’une règle unique convient à tous les marchands.

Un score automatisé d’accessibilité suffit-il ?

Non. Les contrôles automatisés peuvent identifier certains problèmes, mais ne prouvent pas qu’une personne peut accomplir toutes les tâches d’achat interactives. Combinez-les avec des tests manuels et une évaluation spécialisée adaptée.

Puis-je résoudre l’accessibilité en installant un seul widget ?

Ne considérez pas un widget comme la preuve que le parcours d’achat est accessible. Testez le thème sous-jacent, les formulaires, les contrôles produit et les composants tiers avec les mêmes tâches client.

Dois-je tester uniquement le passage en caisse ?

Testez le parcours permettant au client d’atteindre et d’utiliser le passage en caisse. La recherche, les filtres, les choix produit et les informations de livraison peuvent empêcher un achat avant l’apparition de la page de paiement.

Qui doit corriger un problème dans une boîte de dialogue de paiement ?

Identifiez le responsable du composant et fournissez un cas reproductible avec les détails de configuration. Votre boutique doit toujours évaluer le parcours client global et coordonner la résolution.

Que peut faire une petite équipe en premier ?

Effectuez un parcours complet au clavier et un parcours avec contenu agrandi, puis documentez les obstacles bloquant la progression. Utilisez ces constats pour prioriser le travail et déterminer où une aide spécialisée est nécessaire.