Web Accessibility Testing with QF-Test
In this webinar, we will give a brief introduction to web accessibility and present the new accessibility testing features of QF-Test.
WCAG Compliance: Is your website accessible?
QF-Test dispose d’une étape de test dédiée à l’accessibilité : le nœud « Accessibility Checks ». Vous l’insérez dans votre suite de tests comme n’importe quelle autre étape et définissez les contrôles à exécuter. Un menu de sélection contextuel propose les règles et paramètres appropriés et insère automatiquement la bonne syntaxe.

Vous combinez ainsi deux approches :
Comme QF-Test simule de véritables interactions utilisateur, vous ne testez pas seulement des pages statiques, mais chaque état de votre application, par exemple après la connexion ou dans une boîte de dialogue ouverte.
In this webinar, we will give a brief introduction to web accessibility and present the new accessibility testing features of QF-Test.
In this video we show you how you can use QF-Test 9 to test the accessibility of your website or web application. It’s quick and almost completely automatic! We will also demonstrate some of the other abilities QF-Test has gained with version 9.
QF-Test associe des contrôles d’accessibilité éprouvés à l’automatisation fonctionnelle des tests d’interface utilisateur. C’est ce qui le distingue des simples scanners.
Contrôler aussi les états dynamiques
Les scanners statiques ne voient généralement que la page chargée à l’ouverture. QF-Test parcourt votre application comme le feraient de vrais utilisateurs. Vous pouvez ainsi contrôler de manière ciblée les zones accessibles après la connexion, les boîtes de dialogue et menus ouverts, les formulaires remplis avec messages d’erreur ainsi que les contenus chargés dynamiquement.
Des règles de contrôle éprouvées, sans programmation
axe-core est considéré comme l’un des standards des tests d’accessibilité automatisés. La bibliothèque vérifie notamment l’absence de textes alternatifs, les contrastes de couleurs insuffisants ainsi que les rôles et attributs ARIA erronés selon les WCAG 2.0, 2.1 et 2.2, niveaux A et AA. Vous définissez dans le nœud « Accessibility Checks » quelles règles sont exécutées et avec quelle rigueur.
Des contrôles supplémentaires au-delà d’axe-core
QF-Test complète axe-core par ses propres contrôles : il vérifie le contraste des couleurs des icônes et autres éléments graphiques, contrôle par navigation clavier simulée que le focus reste toujours visible et s’assure que la page indique la bonne langue pour les lecteurs d’écran. Vous pouvez masquer de manière ciblée dans le rapport les problèmes connus de faible priorité. Pour des besoins spécifiques, vous créez vos propres tests d’accessibilité.
Un seul outil pour la fonctionnalité et l’accessibilité
Vous intégrez simplement les contrôles d’accessibilité dans vos cas de test existants. Aucune suite de tests séparée n’est nécessaire, et les erreurs fonctionnelles comme les obstacles à l’accessibilité sont détectés dans la même exécution de test.
Contrôle continu dans le pipeline CI/CD
Si les contrôles sont exécutés à chaque build, vous détectez immédiatement les nouveaux obstacles. Les régressions n’arrivent ainsi jamais en production.
Des rapports avec lesquels votre équipe peut travailler
QF-Test catégorise les erreurs et les avertissements, met en évidence les éléments concernés dans la capture d’écran et fournit des indications pour les corriger. Votre équipe voit ainsi d’un coup d’œil ce qu’il faut traiter en priorité.
Avec QF-Test, les testeurs obtiennent des évaluations précises avec des conseils pour résoudre les problèmes trouvés. Nos rapports de test au format HTML sont flexibles et interactifs.
Faites défiler l’exemple de rapport vers le bas, agrandissez les captures d’écran et les messages en un seul clic, utilisez les touches fléchées pour naviguer rapidement entre les entrées.
Les tests automatisés détectent les erreurs techniques de manière rapide, fiable et reproductible. Ils ne couvrent toutefois pas tous les critères des WCAG. Ce sont en fin de compte des personnes qui jugent si les contenus sont compréhensibles ou si l’utilisation avec un lecteur d’écran fonctionne vraiment. QF-Test décharge votre équipe des contrôles récurrents, afin de laisser plus de temps pour les tests manuels qui comptent vraiment.
Dans un monde de plus en plus numérique, l’accessibilité du web garantit que les contenus numériques sont accessibles à tous. Outre leur responsabilité sociale, les entreprises bénéficient d’une meilleure expérience utilisateur et d’un groupe cible plus large.
De plus en plus, l’accessibilité est également pertinente pour le respect des dispositions légales telles que la directive (UE) 2019/882, appelée European Accessibility Act (EAA), et sa transposition allemande, la Barrierefreiheitsstärkungsgesetz (BFSG), qui s’appliquent depuis le 28 juin 2025.
Un élément central de l’accessibilité numérique est la prise en charge des technologies d’assistance telles que les lecteurs d’écran, les plages braille ou les commandes vocales. Ces technologies permettent aux personnes en situation de handicap d’utiliser efficacement les applications web. Il est donc essentiel que les sites web soient compatibles avec ces technologies d’assistance.
L’accessibilité est un élément essentiel du développement de logiciels et d’applications web modernes. Les testeurs de logiciels et les développeurs sont confrontés à la tâche de vérifier l’accessibilité des sites web. Les tests manuels sont fastidieux et en grande partie répétitifs. Les tests d’accessibilité automatisés ou tests A11y (numéronyme de l’anglais « accessibility ») permettent de gagner énormément de temps en identifiant efficacement les problèmes courants, et ce dès la phase de développement du logiciel.
La garantie de l’accessibilité commence dès le processus de conception. En prenant en compte les aspects d’accessibilité dès le début, les développeurs et les designers peuvent s’assurer que les produits numériques sont conçus de manière inclusive dès le départ. Cela comprend le choix de schémas de couleurs appropriés, la structuration claire du contenu et le placement intuitif des boutons.
Un élément central du développement web accessible est la structuration propre et sémantiquement correcte du code source. Cela permet aux technologies d’assistance telles que les lecteurs d’écran d’interpréter et de restituer correctement le contenu d’un site web. Cela comprend entre autres l’utilisation correcte des éléments HTML et des rôles ARIA. QF-Test aide les développeurs à vérifier l’accessibilité du code source en effectuant des tests automatisés conformément aux règles pour l’accessibilité des contenus web (WCAG) 2.0, 2.1 et 2.2.
Organisme public ou entreprise : presque toutes les exigences légales en matière d’accessibilité numérique renvoient techniquement à la même base, les Web Content Accessibility Guidelines (WCAG) au niveau AA.
| Réglementation | S’applique à | Référence technique |
|---|---|---|
| WCAG (W3C) | Base internationale | – |
| EN 301 549 | Organismes publics et entreprises dans l’UE | WCAG 2.1 AA, à l’avenir WCAG 2.2 AA |
| Directive (UE) 2016/2102 / BITV 2.0 (Allemagne) | Organismes publics | EN 301 549 |
| European Accessibility Act / BFSG (Allemagne) | Certains produits et services destinés aux consommateurs, depuis le 28 juin 2025 | EN 301 549 |
Qu’est-ce que cela signifie pour vos tests ? Avec QF-Test, vous effectuez des contrôles automatisés selon les WCAG 2.0, 2.1 et 2.2 et êtes ainsi déjà préparé à la nouvelle version 4.1.1 de la norme EN 301 549, qui relève les exigences au niveau des WCAG 2.2. Les tests automatisés ne couvrent toutefois pas tous les critères. Une évaluation complète de la conformité nécessite en plus des contrôles manuels.
Votre site web est-il vraiment accessible à tous ? Notre audit d'accessibilité gratuit vous indique exactement où en est votre site — en 2 à 5 jours ouvrés. Avec un rapport interactif et des recommandations concrètes.
Aucune procédure ne permet à elle seule de tester complètement l’accessibilité. Les tests manuels et automatisés ont des points forts différents et se complètent mutuellement.
| Tests manuels | Tests automatisés | |
|---|---|---|
| Points forts | Évaluent l’utilisabilité réelle, par exemple avec un lecteur d’écran ou au clavier. Déterminent si les contenus sont compréhensibles et structurés de manière logique. | Détectent rapidement et de manière reproductible les erreurs techniques telles que les textes alternatifs manquants, les rôles ARIA erronés ou les contrastes insuffisants. Contrôlent de nombreuses pages et de nombreux états en peu de temps. |
| Limites | Chronophages, exigent beaucoup d’expérience. Les résultats peuvent varier d’un testeur à l’autre. | Ne couvrent qu’une partie des critères des WCAG. Ne peuvent pas juger si les contenus sont compréhensibles ou pertinents. |
| Idéal pour | Évaluation finale, interactions complexes, contrôle avec des technologies d’assistance | Contrôle régulier à chaque build, détection des régressions |
Lors des tests manuels, des testeurs expérimentés contrôlent le logiciel du point de vue des personnes en situation de handicap. À l’aide de lecteurs d’écran, de logiciels d’agrandissement ou d’une utilisation exclusivement au clavier, ils évaluent si l’application est utilisable non seulement sur le plan technique, mais aussi dans la pratique. C’est la seule manière de répondre à des questions telles que : l’ordre des contenus est-il logique ? Les instructions sont-elles compréhensibles ? Une boîte de dialogue complexe fonctionne-t-elle vraiment avec un lecteur d’écran ?
Les tests automatisés prennent en charge les contrôles techniques récurrents. Ils fournissent des résultats comparables à chaque exécution et peuvent être intégrés dans le pipeline CI/CD. Vous remarquez ainsi immédiatement lorsqu’une modification introduit de nouveaux obstacles, bien avant qu’ils ne soient détectés lors d’un audit manuel.
La combinaison des deux est la plus efficace : les tests automatisés sécurisent en continu la base technique et déchargent votre équipe des contrôles de routine. Le temps gagné est consacré à des tests manuels ciblés, là où le jugement humain est nécessaire. Notamment dans les projets agiles aux cycles de release courts, l’accessibilité reste ainsi durablement à un bon niveau.
Les exigences en matière d'accessibilité sont là pour durer, et de nombreux sites web ne sont toujours pas conformes. Pour vous donner une idée précise de la situation, nous proposons désormais un bilan d'accessibilité gratuit et sans engagement : partagez votre URL, nos experts analyseront avec QF-Test votre site à la lumière des normes WCAG, et vous recevrez un rapport interactif contenant des recommandations concrètes dans un délai de 2 à 5 jours ouvrés.
Aucun risque, aucun coût caché — juste une vision claire de ce qui doit être fait.
Les tests d’accessibilité peuvent-ils être intégrés dans des pipelines CI/CD ?
Oui. Les vérifications s’exécutent dans vos processus de test existants. Vous voyez ainsi immédiatement si une modification crée de nouveaux obstacles.
Ai-je besoin de compétences en programmation pour les tests d’accessibilité avec QF-Test ?
Non. QF-Test est un outil low-code, et les procédures pour les tests d’accessibilité sont prêtes à l’emploi.
Comment savoir si mon site web est accessible ?
Grâce à la vérification d’accessibilité gratuite : indiquez votre URL et recevez le rapport sous 2 à 5 jours ouvrés.
Grâce à la vérification d’accessibilité gratuite : indiquez votre URL et recevez sous 2 à 5 jours ouvrés un rapport contenant des recommandations concrètes pour votre site web. Nos experts analysent votre site avec QF-Test selon les critères WCAG, comme les textes alternatifs, les contrastes de couleurs, la navigation au clavier et les rôles ARIA.
Peut-on tester l’accessibilité de manière entièrement automatisée ?
Non. Les tests automatisés détectent les erreurs techniques rapidement et de façon reproductible. La compréhensibilité et la structure logique nécessitent toujours une vérification manuelle.
Non. Les tests automatisés détectent rapidement et de façon reproductible les erreurs techniques telles que les textes alternatifs manquants, les rôles ARIA incorrects ou les contrastes insuffisants. La compréhensibilité et la structure logique nécessitent toujours une vérification manuelle. Cependant, le respect des critères techniques aide déjà considérablement les utilisateurs.
Que vérifie QF-Test lors des tests d’accessibilité ?
QF-Test intègre la bibliothèque axe-core sans effort de programmation. S’y ajoutent des vérifications propres, comme un contrôle du contraste des couleurs pour les éléments graphiques.
Quelle est la différence entre WCAG, BITV, BFSG et EAA ?
Les WCAG constituent la référence technique. La norme EN 301 549 et la BITV 2.0 la transposent en exigences européennes et allemandes. L’EAA et la BFSG définissent qui est tenu de garantir l’accessibilité.
Les WCAG (Web Content Accessibility Guidelines) constituent la référence technique pour des contenus web accessibles. La norme EN 301 549 et la BITV 2.0 allemande la transposent respectivement en exigences européennes et allemandes.
L’EAA (European Accessibility Act, ou acte européen sur l’accessibilité) et sa transposition allemande, la BFSG (Barrierefreiheitsstärkungsgesetz), définissent qui est tenu de garantir l’accessibilité – depuis juin 2025, c’est aussi le cas de nombreuses entreprises.
Quel niveau WCAG mon site web doit-il atteindre ?
En règle générale, le niveau AA. C’est le niveau auquel renvoient la norme EN 301 549 et les exigences légales.
En règle générale, le niveau AA. C’est le niveau auquel renvoient la norme européenne EN 301 549 et les exigences légales, comme les lois allemandes BITV 2.0 et BFSG.
Les exigences applicables à chaque cas dépendent notamment du secteur d’activité, de la taille de l’entreprise et du type d’offre numérique. Certains domaines peuvent également être soumis à des règles différentes ou supplémentaires. En cas de doute, veuillez faire vérifier par un juriste quelles exigences s’appliquent à votre offre.
Remarque : ces informations sont fournies à titre d’orientation générale et ne remplacent pas un conseil juridique.